Home Dashboard Directory Help

Database restore is very slow by TimWright


 as Not Reproducible Help for as Not Reproducible

Sign in
to vote
Type: Bug
ID: 697014
Opened: 10/27/2011 2:25:58 AM
Access Restriction: Public
User(s) can reproduce this bug


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
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?
Sign in to post a workaround.