Reduce Restore Time
-
How can i Reduce our restore times? Our site is 20GB database, 4 way xenon 900mhz Proc, and Max'd memory. Our restore time from full is 1 hour and 50 minutes. This seems to be be a little on the slow side. Also, Stats doesnt seem to be working properly because the first 1 hour and 30 minutes we see no progress. Then stats will start running making it appear that the first 10 percent took 1 hour and 30 minutes and the last 90 percent in 20 minutes. I suspect that sql server is trying to format the drive space before beginning the restore. Please help a beginning DBA.
-
Hi John,
This doesnt sound to far wrong to tell the truth, when you do a restore to a new server/database the first thing that gets done is that the data and log files are all created empty to the same size as the one in the backup. This is done before the data is restored which explains the long delay up front followed by a barrage of activity afterwards.
If you are restoring to the same database it will also be a little slow (but not as slow as creating the DB from scratch) because once the process has restored all of the data it then initialised the rest of the file to make sure that it's an identical copy of what was there originally.
Hope this helps
-
Is there any way to prevent the preparation time for the Restore. IE: eliminate the format or enable quick format?
-
Not that I know of... the best way to reduce restore time is to get faster disks on your data drive subsystems. Either faster disks or more disks on the drive array. When we went from a disk of lesser quality to a higher quality disk drive our backup and restore times were cut in half.
As far as the ability to eliminate the task of creating file extents, I'm not sure if there is a way to turn this off. Make sure your disks are defragmented and you should get better performance.
-
I changed our Raid Configuration on our test server from Raid 5 to Raid 1 + 0. The change in raid type reduced our restore time from 1 hour 50 minutes to 1 hour 10 minutes. We shaved 40 minutes. Keep in mind the hardware hasn't changed.
-
First of all, dump to disk and keep an history of several day's and secondly dump using a tool like SQL Lite Speed. You should be ready dumping in less than 20 minutes.
The dump to tape can be done without affecting your SQL Server and you can in case of database corruption easily restore the dump from the other day from disk without first search your tape and restore from tape wich is slower.
-
Actually all of our backups are to disk. We found arcserve's sql agent to be unreliable, so we began dumping to disc then using arcserve's file agent to backup our dumps. We keep 2 weeks worth of dumps on disc.
-
Then you can win a lot of time with the mentioned tool in my previous post.
-
What size are your databases/backups?? If they're large you'll get a good performance boost with Litespeed.
Also, do you dump to disc, are the files stored on the same raid array, or use the same physical controller?
--------------------
Colt 45 - the original point and click interface
-
our primary database backup file is approximately 17-20 gb. We dump to a seperate raid array over a gb switch. Our backup times are not unreasonable. We wanted to reduce the time to restore. I may investigate LiteSpeed. Thanks for the suggestions.
-
You will find restore times over an excisting database be reduced as much as the backup times. The restore times for new databases (when the files have to be created) will be still slow, but quicker due to the time needed for restoring the actual data will be reduces.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply