Transaction Log shipping Restore Job running very slow in STAND BY MODE-Explanation

Description:


Sometimes you may notice your restore job on the secondary server will be taking much more time than usual, so what is wrong??

This is because of long running transactions (uncommitted transactions) spanning multiple log backups and the LS being configured as STANDBY…

Detailed Explanation:

• When restoring transaction log with the “STAND BY” option, SQL Server will go over the transaction log and save all uncommitted transactions to a file with .tuf(Transaction UNDO File) extension.

• You will not see the uncommitted data in the secondary DB even if you read the data in “READ Uncommitted Isolation Level". Thus is, because the SQL Server performs UNDO for all uncommitted transactions and saves their data to the tuf file. It simply saves the entire content of the pages that it had to undo.



The tuf file will be used when you restore the next transaction log file. First, the SQL Server will REDO all the uncommitted transactions that are in the tuf file and then continue to restore the next transaction log.The tuf file will contain the uncommitted transactions not just from the latest transaction log but uncommitted transactions in all previous transaction logs that have been restored.

• So with the above explanation let us assume a rebuild index on a big table that has run for 45 mins and let’s say 3 log backups were taken in this duration, so first log backup uncommitted transactions will be written to tuf file while restoration and when the second log backup is being restored, the sql server will redo all the uncommitted transactions from the tuf file and will continue the restoring the log backup but the second log backup also has uncommitted transactions so SQL server will again UNDO the index operation and will save the uncommitted transactions to tuf file and this process continues until transaction is committed in further log backups causing the delay in LOG RESTORE…

I hope above explanation had helped you understand the reason behind slow restore on secondary stand by log shipping server.

References: Dan's madebysql Blog.

Restoring Master Databse in SQL 2005

It is always recomemded to document the steps in disater recovery scenarios.
Below are the steps to restore master db in sql 2005 server
Step 1: Stop the SQL SERVICES
Step 2:Enter Command Prompt
Step 3: Go to the path where sqlservr.exe resides.[ default it will be available in : Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn]
Step 4: Execute below query to take the instance into Single User Mode.
sqlservr -c -m
Step 5: Goto MangementStudio-->Cilck on New Query Tab-->Execute Below Query.
RESTORE DATABASE MASTER FROM DISK = '.BAK FILE PATH' WITH REPLACE
Output:
The master database has been successfully restored. Shutting down SQL Server.
SQL Server is terminating this process.
Step 6: Start the services

Restoring Master Database in Sql 2000

Scenario:
Restoring Master Database in Cluster Environment.
Assuming Master DB backup is available.
Environment: Cluster Server
Solution:

Identify which cluster node SQL Server is currently running on, such as node1.
From Cluster Administrator, take the SQL Server resources off-line.
Go to the node running SQL Server (see step 1) and start it from the command prompt using: sqlservr.exe -c -m
Restore the Master database using Query Analyzer or Enterprise Manager.
Quit SQL Server from the command prompt.
Using Cluster Administrator, restart the SQL Server resources