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?

1AIt’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.