Subject | Re: firebird snapshot |
---|---|
Author | Adam |
Post date | 2005-11-16T22:24:55Z |
--- In firebird-support@yahoogroups.com, "clockhat" <cas@p...> wrote:
database, what version Firebird are you using, what architecture
(classic / superserver / embedded), what OS and what speed hardware
are you using. Also what gbak string are you using. Using the service
manager is a lot quicker.
GBak does run as a snapshot. If gbak runs abnormally slow on Firebird
1.5 or lower, then generally it is because of a limitation in the ODS
(On Disk Structure) that makes garbage collection expensive when you
have indices with lots of duplicates.
Try using the -g option with gbak which prevents garbage collection on
the database being backed up. (Note that the garbage records
themselves are not stored in the backup, just any garbage encountered
along the way is not cleaned up during the backup process).
If -g fixes your problem, then you need to address the issue of why
the garbage collection is taking so long.
Alternatively, if you have a period where access to the database is
not required, you can shutdown the service, rename the database then
take an OS level file copy, rename the database back and start the
service again.
But it is important to get to the bottom of why it is taking a long
time for you, and not just take the easy way out, because if it is a
build up of garbage, then it will slow down other functions as well.
Adam
>As Helen said, more information is required. Like how large is the
> does firebird support a snapshot of the databse, which can then be
> backed up later.
> the standard backup gbak takes too long.
>
database, what version Firebird are you using, what architecture
(classic / superserver / embedded), what OS and what speed hardware
are you using. Also what gbak string are you using. Using the service
manager is a lot quicker.
GBak does run as a snapshot. If gbak runs abnormally slow on Firebird
1.5 or lower, then generally it is because of a limitation in the ODS
(On Disk Structure) that makes garbage collection expensive when you
have indices with lots of duplicates.
Try using the -g option with gbak which prevents garbage collection on
the database being backed up. (Note that the garbage records
themselves are not stored in the backup, just any garbage encountered
along the way is not cleaned up during the backup process).
If -g fixes your problem, then you need to address the issue of why
the garbage collection is taking so long.
Alternatively, if you have a period where access to the database is
not required, you can shutdown the service, rename the database then
take an OS level file copy, rename the database back and start the
service again.
But it is important to get to the bottom of why it is taking a long
time for you, and not just take the easy way out, because if it is a
build up of garbage, then it will slow down other functions as well.
Adam