Quantcast
Channel: SQL Server Database Engine forum
Viewing all articles
Browse latest Browse all 12554

SS2008 Log Shipping Performance Issues on Secondary Server Restore Job

$
0
0

Hi folks,

I'm having an issue with log shipping. What has taken 2-5 minutes in the past is now taking 20-40 minutes which is no good really. File sizes have not increased.

I've run the log shipping with a global trace on 3004 & 3605.

The issue appears to be the step Restore: Transferring data to <db_name>which is taking about 90% of the process time in the Restore job on the secondary server.

I'm unsure what this element does in the restore, so am looking for further details / suggestions / where to look for issues.

I'm providing the log from the trace below,

many thanks

Stuart

2014-01-24 09:56:01.41 spid88      RestoreLog: Database <db_name>
2014-01-24 09:56:01.41 spid88      X-locking database: <db_name>
2014-01-24 09:56:01.41 spid88      Opening backup set
2014-01-24 09:56:01.43 spid88      Restore: Configuration section loaded
2014-01-24 09:56:01.43 spid88      Restore: Backup set is open
2014-01-24 09:56:01.43 spid88      Restore: Planning begins
2014-01-24 09:56:01.44 spid88      Halting FullText crawls on database <db_name>
2014-01-24 09:56:01.44 spid88      Dismounting FullText catalogs
2014-01-24 09:56:01.44 spid88      Restore: Planning complete
2014-01-24 09:56:01.44 spid88      Restore: BeginRestore (offline) on <db_name>
2014-01-24 09:56:01.44 spid88      Restore: Undoing STANDBY for <db_name>
2014-01-24 09:56:03.10 spid88      SnipEndOfLog from LSN: (19960:7863:1)
2014-01-24 09:56:03.10 spid88      FixupLogTail(progress) zeroing F:\<db_name>_Log1.ldf from 0x139b6e00 to 0x139b8000.
2014-01-24 09:56:03.10 spid88      Zeroing F:\<db_name>_Log1.ldf from page 40156 to 40177 (0x139b8000 to 0x139e2000)
2014-01-24 09:56:03.10 spid88      Zeroing completed on F:\<db_name>_Log1.ldf
2014-01-24 09:56:03.10 spid88      Restore: Finished undoing STANDBY for <db_name>
2014-01-24 09:56:03.13 spid88      Restore: PreparingContainers
2014-01-24 09:56:03.13 spid88      Restore: Containers are ready
2014-01-24 09:56:03.13 spid88      Restore: Restoring backup set
2014-01-24 09:56:03.13 spid88      Restore: Transferring data to <db_name>
2014-01-24 10:15:44.16 spid88      Restore: Waiting for log zero on <db_name>
2014-01-24 10:15:44.16 spid88      Restore: LogZero complete
2014-01-24 10:15:44.41 spid88      FileHandleCache: 440 files opened. CacheSize: 14
2014-01-24 10:15:44.41 spid88      Restore: Data transfer complete on <db_name>
2014-01-24 10:15:44.41 spid88      Restore: Backup set restored
2014-01-24 10:15:44.41 spid88      Restore-Redo begins on database <db_name>
2014-01-24 10:15:52.18 spid88      Rollforward complete on database <db_name>
2014-01-24 10:15:52.18 spid88      Restore: Done with fixups
2014-01-24 10:15:52.20 spid88      Transitioning to STANDBY
2014-01-24 10:15:52.33 spid88      Starting up database '<db_name>'.
2014-01-24 10:15:52.34 spid88      The database '<db_name>' is marked RESTORING and is in a state that does not allow recovery to be run.
2014-01-24 10:15:58.25 spid88      FixupLogTail(progress) zeroing F:\<db_name>_Log1.ldf from 0x5b000 to 0x5c000.
2014-01-24 10:15:58.25 spid88      Zeroing F:\<db_name>_Log1.ldf from page 46 to 526 (0x5c000 to 0x41c000)
2014-01-24 10:15:58.27 spid88      Zeroing completed on F:\<db_name>_Log1.ldf
2014-01-24 10:15:59.03 spid88      Recovery is writing a checkpoint in database '<db_name>' (10). This is an informational message only. No user action is required.
2014-01-24 10:16:00.46 spid88      Recovery completed for database <db_name> (database ID 10) in 8 second(s) (analysis 5796 ms, redo 0 ms, undo 546 ms.) This is an informational message only.                                              No user action is required.
2014-01-24 10:16:00.58 spid88      Starting up database '<db_name>'.
2014-01-24 10:16:00.69 spid88      Database <db_name> was started . 
2014-01-24 10:16:01.00 spid88      CHECKDB for database '<db_name>' finished without errors on 2014-01-18 17:31:21.020 (local time). This is an informational message only; no user action is required.
2014-01-24 10:16:01.01 spid88      Database is in STANDBY
2014-01-24 10:16:01.01 spid88      Resuming any halted fulltext crawls
2014-01-24 10:16:01.01 spid88      Restore: Writing history records
2014-01-24 10:16:01.01 Backup      Log was restored. Database: <db_name>, creation date(time): 2012/07/18(16:20:49), first LSN: 19960:7863:1, last LSN: 19961:712:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {'G:\<db_name>_LS\<db_name>_20140124095000.trn'}). This is an informational message. No user action is required.
2014-01-24 10:16:01.01 spid88      Writing backup history records
2014-01-24 10:16:01.40 spid88      Restore: Done with MSDB maintenance
2014-01-24 10:16:01.40 spid88      RestoreLog: Finished
2014-01-24 10:16:01.43 spid88      Setting database option MULTI_USER to ON for database <db_name>.




Viewing all articles
Browse latest Browse all 12554

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>