Subject | Re: [firebird-support] firebird schema changes during backup |
---|---|
Author | Helen Borrie |
Post date | 2017-01-23T20:36:44Z |
Hello ,
Monday, January 23, 2017, 11:08:40 PM, kragh.thomas@... wrote:
gbak runs in its own snapshot transaction, so all committed metadata
changes at the start of that transaction will go into the backup.
metadata during backup. But, of course, those changes won't appear in
the restored database.
but, for some object types, the new versions won't be available to new
transactions until the db cache is cleared. Typically this affects
triggers, stored procedures and stored functions. The extent of that
depends on whether the Fb model is using private or shared cache.
As far as gbak is concerned, since it is copying metadata, not
executing any PSQL, the backup won't be affected by this deferred
availability, provided the changes were committed when its transaction
started.
For all that, I don't think it is a good idea to be changing metadata
during a backup. It's too easy for human error to put the states of
the current database and the backup out of synch inadvertently.
Still, it just boils down to the controls the team has in place to
make sure that what's in the backup really is what it is supposed to
be...
HB
Monday, January 23, 2017, 11:08:40 PM, kragh.thomas@... wrote:
> On a product of ours we use continuous deployment where code andPresumably you are talking about gbak backup.
> database schema changes is deployed quite often. Sometimes we would
> like to make a new release during database backup. So my questions are:
> 1) How does Firebird handle schema changes during backup?
gbak runs in its own snapshot transaction, so all committed metadata
changes at the start of that transaction will go into the backup.
> 2) And is it safe to make schema changes during backup?Well, it is "safe", insofar as it won't affect the state of the
>
metadata during backup. But, of course, those changes won't appear in
the restored database.
> 3) Are procedures/tables locked for changes during backup?During normal database operation, changes to metadata are not "locked"
>
but, for some object types, the new versions won't be available to new
transactions until the db cache is cleared. Typically this affects
triggers, stored procedures and stored functions. The extent of that
depends on whether the Fb model is using private or shared cache.
As far as gbak is concerned, since it is copying metadata, not
executing any PSQL, the backup won't be affected by this deferred
availability, provided the changes were committed when its transaction
started.
For all that, I don't think it is a good idea to be changing metadata
during a backup. It's too easy for human error to put the states of
the current database and the backup out of synch inadvertently.
Still, it just boils down to the controls the team has in place to
make sure that what's in the backup really is what it is supposed to
be...
HB