Comments
39 comments
-
Restore never starts at all with 6.4.0.1015. Process is waiting on PREEMPTIVE_OS_GETPROCADDRESS.
-
Can you back up using 6.4.0.1015? Can you back up a small database and restore it?
Thanks. -
petey wrote:Can you back up using 6.4.0.1015? Can you back up a small database and restore it?
Thanks.
Here's what happening. If I specify the filename of a full backup, [\\Recovery\SQLBackups\Nasdaq\CustomerViews\FULL_CustomerViews_20100811_083903.sqb], it will restore. If I use [\\Recovery\SQLBackups\Nasdaq\CustomerViews\*.sqb] LATEST_FULL the restore never starts. -
Could you please download 6.4.0.1015 again? I've fixed the hanging issue with the LATEST_ALL option.
Thanks. -
I think that took care of it. I'm going to try something a bit larger with more files.
-
Everything seems to be working ok now.
-
Yes, 6.4.0.1015 has done it all so far. I have been able to restore that 30GB database using the Latest_All option from a network backup source with many backup files present. The full restore component completed in just over 44 minutes, just like 6.4.0.56. It has also worked with several smaller databases, too.
Fantastic!!
Thanks for all your efforts, Pete. -
Thank you very much for your efforts in testing this patch release.
-
All my test restores went off without a hitch last night. Thanks Pete.
Add comment
Please sign in to leave a comment.
Restoring a database roughly 10Gb in size from a .sqb file takes avg 43min, compared to 1min for a native .bak restore.
First restored from network storage: 41min. Ok, maybe network I/O adds to the restore time, and it was compression level 4.
Ran a second backup (local copy, compression level 1) and restored from that: 46min! I have no idea why it'd take it longer to restore a local copy with less compression.
Compared to SSMS backup/restore (local storage): 3min backup, 1min restore. Same server, same time of day (server loading conditions).