Re: [firebird-support] firebird schema changes during backup

[Tim Ward t...@telensa.com [firebird-support]]

On 24/01/2017 01:03, 'Leyne, Sean' s...@broadviewsoftware.com 
[firebird-support] wrote:



Firebird does support dynamic changes, you can change the database 
schema while users are connected.


Dmitry was referring more to the inherent risks of using a production 
database as a development platform -- schema changes need to be tested 
and carefully applied.


In our case, we use strict SQL script numbering process along with a 
CI process that ensures that all scripts are checked/tested against 
exemplar database*0*s before a master script is created/applied.


And even then you can have fun when one of your production databases has 
patterns of data that weren't included in your test data sets.


--
Tim Ward

RE: [firebird-support] firebird schema changes during backup

['Leyne, Sean' s...@broadviewsoftware.com [firebird-support]]

>  On Mon, 23 Jan 2017 15:48:15 -0500 Dimitry Sibiryakov
> mailto:s...@ibphoenix.com [firebird-support]  supp...@yahoogroups.com> wrote 
> 
> Changing metadata is a bad idea in general.
> Continuous development is the worst thing that can happen to a database.
> 
> 
> And that is the traditional database's Achilles Heel because "change" is
> inevitable and rapid change is a fact of life today.
> 
> If Firebird were to bolster its support for dynamic changes it would become a
> much more attractive beast.

Firebird does support dynamic changes, you can change the database schema while 
users are connected.

Dmitry was referring more to the inherent risks of using a production database 
as a development platform -- schema changes need to be tested and carefully 
applied. 

In our case, we use strict SQL script numbering process along with a CI process 
that ensures that all scripts are checked/tested against exemplar database*0*s 
before a master script is created/applied.


Sean

Re: [firebird-support] firebird schema changes during backup

[DougC d...@moosemail.net [firebird-support]]

 On Mon, 23 Jan 2017 15:48:15 -0500 Dimitry Sibiryakov s...@ibphoenix.com 
[firebird-support] firebird-support@yahoogroups.com wrote 



Changing metadata is a bad idea in general. 

 Continuous development is the worst thing that can happen to a database. 







And that is the traditional database's Achilles Heel because "change" is 
inevitable and rapid change is a fact of life today.



If Firebird were to bolster its support for dynamic changes it would become a 
much more attractive beast.


Doug C.

Re: [firebird-support] firebird schema changes during backup

[Dimitry Sibiryakov s...@ibphoenix.com [firebird-support]]

23.01.2017 21:36, Helen Borrie hele...@iinet.net.au [firebird-support] wrote:
> For all that, I don't think it is a good idea to be changing metadata
> during a backup.

   Changing metadata is a bad idea in general.
   Continuous development is the worst thing that can happen to a database.


-- 
   WBR, SD.






++

Visit http://www.firebirdsql.org and click the Documentation item
on the main (top) menu.  Try FAQ and other links from the left-side menu there.

Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ 

++


Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/firebird-support/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/firebird-support/join
(Yahoo! ID required)

<*> To change settings via email:
firebird-support-dig...@yahoogroups.com 
firebird-support-fullfeatu...@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
firebird-support-unsubscr...@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

Re: [firebird-support] firebird schema changes during backup

[Helen Borrie hele...@iinet.net.au [firebird-support]]

Hello ,

Monday, January 23, 2017, 11:08:40 PM, kragh.tho...@yahoo.com 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