Subject | Re: [firebird-support] why does restore last so long?? |
---|---|
Author | Helen Borrie |
Post date | 2005-07-15T13:37Z |
At 02:56 PM 15/07/2005 +0200, you wrote:
Restore literally rebuilds your database from scratch. It retrieves the
metadata first and recreates all of the objects. It requests chunks of
disk space ("pages") as required, and builds the page inventory as it
goes. When all of the metadata is in place, it then reads the data into
the newly created structures, applying the constraints as it
goes. Finally, it activates all of the indexes and builds them. A
restored database is squeaky clean.
I must say I've never had a restore of a 1.2 Gb database take 2
hours. More like 2 minutes. But I don't generally have a lot of indexes
and I keep very lean keys on my tables...perhaps you have a lot of indexes
and/or a lot of dependencies involving composite keys...
Restore is very disk-intensive. Is your disk very slow, or very
fragmented, or both? When my restores start looking a bit slow, I'll
schedule a disk defrag. I reserve my 7200 rpm disks for databases, too. I
hadn't realised what a difference disk speed made to performance until I
replaced some 5200 disks recently...
BTW, I've found great benefit from running the Windows defrag tool
TWICE. And defrags are much faster on a 7200 disk, as well.
./heLen
>Hi!Yes. :-=)
>My database has about 1.2 GB and I made a backup with firebird 1.0 and I
>was trying to restore it with firebird 1.5
>Is it normal that restore can last more than 2 hours?? Usage of
>processor during that process is between 10-20 % - so what does engine
>do during that time?
>does any one know?
Restore literally rebuilds your database from scratch. It retrieves the
metadata first and recreates all of the objects. It requests chunks of
disk space ("pages") as required, and builds the page inventory as it
goes. When all of the metadata is in place, it then reads the data into
the newly created structures, applying the constraints as it
goes. Finally, it activates all of the indexes and builds them. A
restored database is squeaky clean.
I must say I've never had a restore of a 1.2 Gb database take 2
hours. More like 2 minutes. But I don't generally have a lot of indexes
and I keep very lean keys on my tables...perhaps you have a lot of indexes
and/or a lot of dependencies involving composite keys...
Restore is very disk-intensive. Is your disk very slow, or very
fragmented, or both? When my restores start looking a bit slow, I'll
schedule a disk defrag. I reserve my 7200 rpm disks for databases, too. I
hadn't realised what a difference disk speed made to performance until I
replaced some 5200 disks recently...
BTW, I've found great benefit from running the Windows defrag tool
TWICE. And defrags are much faster on a 7200 disk, as well.
./heLen