Hello , Monday, January 23, 2017, 11:08:40 PM, [email protected] wrote:
> On a product of ours we use continuous deployment where code and > 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? Presumably you are talking about gbak 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
