Subject | Re: Safe Automation of BackUp/Restore |
---|---|
Author | Adam |
Post date | 2005-09-15T00:59:43Z |
--- In firebird-support@yahoogroups.com, "robertgilland"
<robert_gilland@b...> wrote:
inevitable happens. If your application is not well written for
Firebird, it is possible and likely that it unnecessarily keeps old
versions of records "interesting", and prevents the garbage
collection from doing its job. The basic rule is to not keep
transactions open for longer than they are required to acheive the
atomic business operation they are doing. Backup using gbak also goes
a sweep which may be enough to keep the database working well.
file. That means you do not use the -R[eplace] option in GBak unless
you really don't care about your database. So restore it to a
different path, confirm no errors were raised during the restore,
confirm you can connect to it. I would also be tempted to run a sweep
or some other operation that is likely to encounter corruption if it
exists. If all is OK, then you can move the database file and enable
its alias entry. I would recommend keeping the "half decent" old
database in tact for a day / week / forever / depends on the size of
it.
Delphi? Java? VB? .NET?
Adam
<robert_gilland@b...> wrote:
> Apparently firebirdNot really. Obviously it requires regular backups in case the
> requires regular Backup and Restores.
inevitable happens. If your application is not well written for
Firebird, it is possible and likely that it unnecessarily keeps old
versions of records "interesting", and prevents the garbage
collection from doing its job. The basic rule is to not keep
transactions open for longer than they are required to acheive the
atomic business operation they are doing. Backup using gbak also goes
a sweep which may be enough to keep the database working well.
> Our customers are mainly computer illiterateFor a start, do not restore over the top of the "half decent" GDB
> so we would like to be able to backup and restore
> in such a way,
> as if the cycle fails the backup and restore does not
> make the situation worse by overwriting a half decent GDB
> with a failed backup file.
file. That means you do not use the -R[eplace] option in GBak unless
you really don't care about your database. So restore it to a
different path, confirm no errors were raised during the restore,
confirm you can connect to it. I would also be tempted to run a sweep
or some other operation that is likely to encounter corruption if it
exists. If all is OK, then you can move the database file and enable
its alias entry. I would recommend keeping the "half decent" old
database in tact for a day / week / forever / depends on the size of
it.
>A component for
> Does anyone know of any component that does this?
>
Delphi? Java? VB? .NET?
Adam