Database restore is very slow - by TimWright

Status : 

  Not Reproducible<br /><br />
		The product team could not reproduce this item with the description and steps provided.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


1
0
Sign in
to vote
ID 697014 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 10/27/2011 2:25:58 AM
Access Restriction Public

Description

I'm restoring a database backup and transaction backup from one server to another. I'm restoring with no recovery because I'm trying to start up mirroring. The restore runs through to 100% fairly rapidly but then stalls for a long time. I've turned on the trace flags (DBCC TRACEON (3004, 3605, -1)) and the log shows it getting to Restore-Redo begins on database xxx.

Both servers are identical. This used to be quick but has just started to become very slow.
Sign in to post a comment.
Posted by Microsoft on 10/27/2011 at 9:57 AM
Tim,
I'm happy to read that you've been able to resolve this issue by addressing the number of VLFs in your log file.
As the problem seems to no longer be occurring, I'll close out this bug.

Thanks for your input,
Kevin Farlee
Posted by TimWright on 10/27/2011 at 8:42 AM
I've sorted this out. It's caused by massive fragmentation of the db log. I've followed the details on http://www.sqlskills.com/blogs/kimberly/post/8-Steps-to-better-Transaction-Log-throughput.aspx and reduced the number of VLFs to a sensible amount and now it's back working as before.
Posted by TimWright on 10/27/2011 at 3:16 AM
Anybody think that KB2524743 is a fix for this?