Friday, July 27, 2012
Task 10: Halloween Problem
Did you heard about Halloween Problem?
In computing, the Halloween Problem refers to a phenomenon in databases in which an update operation causes a change in the physical location of a row, potentially allowing the row to be visited more than once during the operation. This could even cause an infinite loop in some cases where updates continually place the updated record ahead of the scan performing the update operation.
Please have a look to understand what is the meaning of this problem through an example:
-------------------------------------------------------------------------------
--- Halloween problem script ---
-------------------------------------------------------------------------------
CREATE TABLE halloweenProblem
(
Pk int NOT NULL PRIMARY KEY,
Name varchar(20),
Salary money
)
insert into halloweenProblem(pk, Name, Salary) values(1, 'Joe Blow', 20000.00)
insert into halloweenProblem(pk, Name, Salary) values(2, 'Joe Smith', 30000.00)
insert into halloweenProblem(pk, Name, Salary) values(3, 'Jane Doe', 40000.00)
insert into halloweenProblem(pk, Name, Salary) values(4, 'Boss Man', 50000.00)
DECLARE RaiseSalary CURSOR
FOR
SELECT salary, pk
FROM halloweenProblem
WHERE salary < 50000
ORDER BY pk
FOR UPDATE OF pk
OPEN RaiseSalary
FETCH RaiseSalary
WHILE ( @@fetch_status =0)
BEGIN
UPDATE halloweenProblem
SET pk=pk*10
WHERE CURRENT OF RaiseSalary
SELECT * FROM halloweenProblem
FETCH RaiseSalary
END
CLOSE RaiseSalary
DEALLOCATE RaiseSalary
DECLARE abc CURSOR FOR
SELECT salary
FROM halloweenProblem
WHERE salary < 50000
ORDER BY salary
FOR UPDATE OF salary
OPEN abc
GO
FETCH NEXT FROM abc
GO
UPDATE halloweenProblem
SET salary= salary*2
WHERE CURRENT OF abc
GO
CLOSE abc
DEALLOCATE abc
------------------------------------------------------------------------------
Friday, July 6, 2012
Task 9: Simple Q&A
- I have a direct relationship with my clients and we're frequently confronted with interesting Q&A. For this task I'll update the questions and answers in progress.
1Q. In order to move the DataWarehouse from production to development server, can we just move the DataMart.mdf, DataVault.mdf , StagingArea.mdf and the log files *.ldf from one server to another?
1A. It’s not so easy to move the data from one server to another.
We need to back-up all databases
from production server and restore them to the development one. Or use attach-detach commands for the same scope. We also need to pay
attention on disk space for back-up and also to the VPN connection between user and servers.
2Q. The back-up should be placed on development server Local Disk(U:). This is a disk that’s not “snapshotted”.On production server you can map to this disk. Before starting the restore on development server we have
to stop “snapshot”. Can we do in this way the back up procedure?
2A. I’m afraid this option could not
be possible because the database back-up can be done only on local disks, not
shared or mapped one. We need a disk with sufficient space for back-up directly on production server because the mapped disk does not appear
in backup location list.
SQL Server backup across the network
3Q. How to resolve the error received while processing a cube using the BIDS (Business Intelligence Development Studio) : "The following system error occurred: The trust relationship between the primary domain and the trusted domain failed."
3A. This error occurred during cube processing might occur because of inapprotiate role definitions between the development and the target deployment environments of SSAS applications. Drill down to the Roles folder in the Solution Explorer of the SSAS database solution. A list of roles will be listed under the Roles folder as seen in the following screenshot.
If you double-click the role definition and navigate to the Membership tab in the role definition screen, you will see a list of users and groups assigned for this role. These assigned users and members of these assigned groups have the privileges and required permissions in all of the SQL Server Analysis Services objects within the SSAS database. If you remove the user or the user group that is defined for the SSAS role object using the Remove button, you can handle this error and finish the deployment and so the process of the cube successfully.
3Q. How to resolve the error received while processing a cube using the BIDS (Business Intelligence Development Studio) : "The following system error occurred: The trust relationship between the primary domain and the trusted domain failed."
3A. This error occurred during cube processing might occur because of inapprotiate role definitions between the development and the target deployment environments of SSAS applications. Drill down to the Roles folder in the Solution Explorer of the SSAS database solution. A list of roles will be listed under the Roles folder as seen in the following screenshot.
If you double-click the role definition and navigate to the Membership tab in the role definition screen, you will see a list of users and groups assigned for this role. These assigned users and members of these assigned groups have the privileges and required permissions in all of the SQL Server Analysis Services objects within the SSAS database. If you remove the user or the user group that is defined for the SSAS role object using the Remove button, you can handle this error and finish the deployment and so the process of the cube successfully.
Subscribe to:
Posts (Atom)