it needs some time to "create" the empty database before
it starts populating the data, but this is ridiculous...
I have an approximately 60gb database (with separate log
and data drives) that I backup up (to the data drive) in
22 minutes.
I'm now trying to restore that database and it has so far
literally taken 4 hours and the restore progress bar (in
EM) hasn't even started moving yet. Checking current
activity I can see that the restore process is "Waiting
For ASYNC_IO_COMPLETION".
Now I know that my disk configuration is okay because SQL
was able to read the enter 60gb database and write it out
to a backup file in 22 minutes. Why in the world would
it take so long to restore?
My experience has been that this initial part of the
restore (where my guess is that it is creating the "blank"
database) takes forever and then once the progress bars
start it goes really quick.
What is making this take so long? How can I back
something up and then try to restore and it literally take
10 or 20 times as long?
Any help would be greatly appreciated!
thanks!
-dave
P.S. as a postscript... how come apps like SQL and
Exchange can write out 60gb backup files in a matter of
minutes but if I try to copy (not move) a 60gb file from
one directory on a drive to another directory on the same
drive it takes 2 hours? What do Exchange/SQL do that
makes disk access so fast and how can we make is that fast
for normal file copy operations?Dave,
From what I understand, it goes a little something like this...
When you restore, SQL Server has to initialize all pages in the database.
Then, it has to put the data back on _exactly_ those same pages.
If it did not do this, then the internal list linking strategy would be
hosed.
You might consider not having the backup device on the same disk system
during the restore, or you will be stepping all over yourself with
read/write ops, and waste a lot of time thrashing.
James Hokes
"Dave Rose" <anonymous@.discussions.microsoft.com> wrote in message
news:92a801c3eab8$3eb2c090$a301280a@.phx.gbl...
quote:
> Okay, I understand that when I'm restoring a database that
> it needs some time to "create" the empty database before
> it starts populating the data, but this is ridiculous...
> I have an approximately 60gb database (with separate log
> and data drives) that I backup up (to the data drive) in
> 22 minutes.
> I'm now trying to restore that database and it has so far
> literally taken 4 hours and the restore progress bar (in
> EM) hasn't even started moving yet. Checking current
> activity I can see that the restore process is "Waiting
> For ASYNC_IO_COMPLETION".
> Now I know that my disk configuration is okay because SQL
> was able to read the enter 60gb database and write it out
> to a backup file in 22 minutes. Why in the world would
> it take so long to restore?
> My experience has been that this initial part of the
> restore (where my guess is that it is creating the "blank"
> database) takes forever and then once the progress bars
> start it goes really quick.
> What is making this take so long? How can I back
> something up and then try to restore and it literally take
> 10 or 20 times as long?
> Any help would be greatly appreciated!
> thanks!
> -dave
> P.S. as a postscript... how come apps like SQL and
> Exchange can write out 60gb backup files in a matter of
> minutes but if I try to copy (not move) a 60gb file from
> one directory on a drive to another directory on the same
> drive it takes 2 hours? What do Exchange/SQL do that
> makes disk access so fast and how can we make is that fast
> for normal file copy operations?
No comments:
Post a Comment