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 with the specific area highlighted in bold,
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>.
EDIT
Thanks for the responses esp John S. I was away on holiday hence my silence. I was always pondering on the disk side of things, but didn't say that as everyone then just agrees with what has already been said by the op ie myself. I unfortunately have not
had a chance to analyse the disks, but when I do I will post an update. Thx again, S