On 23/06/11 01:08, gastrocus wrote:
> So if there are existing database connections to a database (using a connection string with an alias defined in aliases.conf), then this file is edited to change the db that the aliases refer to, then saved.
Hmmm. The gbak manual does advise shutting down your database prior to
making any backups. I assume that's not always possible but the manual
also states that the backup takes place, by default, in a single
transaction and the backup will be a copy of the entire database as of
the time that the backup transaction started. Any data changes made
within the period of that one transaction will not be reflected in the
backup file.

So, for the most complete and consistent backup, get your applications
and users out!

You can make the backup run in one_at_a_time mode. There is a single
transaction per table. This implies that the backup will possibly be
"all over the place" if your users are making changes to numerous tables
while the backup is running - what if the backup has copied out table_a
but not yet table_z and your user(s) are updating both? What if these
two tables are in a relationship?

When you come to restore, I think it's possible that there can be
occasions where there could be missing parent rows, if table_z was the
child of table_a for example, and a new parent child was added after
table_a was copied but before table_z.

As you said, interesting!

Anyway, enough warbling, my point is that I would tend to get my users
and applications logged out and the database shut down before I backed
up my database and cloned it in the manner described in the manual. The
examples show this being done - in most cases!

If you do this, then when you come to clone the database - and you don't
have to do that every time you back it up - then you don't have to worry
about existing connections.


Cheers,
Norm.

--
Norman Dunbar
Dunbar IT Consultants Ltd

Registered address:
Thorpe House
61 Richardshaw Lane
Pudsey
West Yorkshire
United Kingdom
LS28 7EL

Company Number: 05132767