Subject | Re: [firebird-support] Re: script for nbackup |
---|---|
Author | Ann Harrison |
Post date | 2011-06-02T23:17:54Z |
Robert,
reading the entire database in a single snapshot transaction, so it
literally can't see changes made while it is running. There is no
such thing as a "delta file in gbak format", which make the
possibility of saving gbak deltas more remote. Some aspects of
replication are a bit like a gbak delta file, but most replication
requires that you have unique keys on every table, which is not a
restriction that Firebird or gbak currently imposes.
Technically, your application could have a mode in which it archives
all its changes and applies them to the restored backup.
Practically, figuring out what's causing the slowdown in the large
databases is the best bet.
Good luck,
Ann
>Technically, anything is possible. But gbak gets its consistency by
> If an option was added to gbak to start a delta file in gbak format, when a backup was started. Then at the end of the restore for that delta file to be added in at completion of the restore.
>
> Is this technically possible?
reading the entire database in a single snapshot transaction, so it
literally can't see changes made while it is running. There is no
such thing as a "delta file in gbak format", which make the
possibility of saving gbak deltas more remote. Some aspects of
replication are a bit like a gbak delta file, but most replication
requires that you have unique keys on every table, which is not a
restriction that Firebird or gbak currently imposes.
Technically, your application could have a mode in which it archives
all its changes and applies them to the restored backup.
Practically, figuring out what's causing the slowdown in the large
databases is the best bet.
Good luck,
Ann