Subject | Re: Truncating transaction logs in Firebird in v2.01 - v2.03 |
---|---|
Author | Adam |
Post date | 2008-04-14T06:10:38Z |
--- In firebird-support@yahoogroups.com, Niben M Singh <niben_s@...>
wrote:
stored in the backup file. That switch is about whether you wish to
take the opportunity to clean up the database you are currently
backing up. So if you are running a nightly backup, then use gbak
without that switch. If you are just making a backup, and have no
intention to keep the original database, you can use -g to let it
backup faster.
backup into new file -- SWEEPED new database again -- again backed it
up with garbage collection -- and eventually re-restored again into
new database file.
That does not make sense. A backup/restore cycle *is* likely to result
in a smaller file (as the garbage is no longer there after the
restore). But immediately performing a second backup-restore cycle on
a database that has just been through one should make absolutely no
difference.
Perhaps someone connected during the restore operation causing it to
not restore properly?
Adam
wrote:
>Correct. Although no matter what you select, the garbage is *never*
> Thanks for the responses!
>
> I guess in Firebird term it is called SWEEP or GARBAGE COLLECTION.
> GBAK does garbage collection by default, unless you specify "-g" option.
stored in the backup file. That switch is about whether you wish to
take the opportunity to clean up the database you are currently
backing up. So if you are running a nightly backup, then use gbak
without that switch. If you are just making a backup, and have no
intention to keep the original database, you can use -g to let it
backup faster.
>SWEEPING and with Garbage Collection -- Restored the database from
> So it is confusing to me when I backed up the database after manual
backup into new file -- SWEEPED new database again -- again backed it
up with garbage collection -- and eventually re-restored again into
new database file.
>reduced. The data and schema has not changed, however....
> After doing that the final size of the new file is dramatically
That does not make sense. A backup/restore cycle *is* likely to result
in a smaller file (as the garbage is no longer there after the
restore). But immediately performing a second backup-restore cycle on
a database that has just been through one should make absolutely no
difference.
Perhaps someone connected during the restore operation causing it to
not restore properly?
Adam