db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Safe backups
Date Fri, 18 Jul 2008 17:03:34 GMT
At a very high level here is the problem with backing up an active
derby database without using the provided procedures to properly
coordinate with Derby.  In an active derby database, the database
state is a coordinated combination of the database files on disk,
the updated pages of those database files still in internal derby
cache, and the transaction log file.  Derby is carefully coded
to be able to handle a crash that loses the updates in cache -- but
only if the the database files on disk and the transaction log
files are exactly in the coordinated state that Derby expects.
Copying files by hand during a running system from outside derby
loses this careful coordination.  This is why derby provides a number
of supported ways to backup an active db.

Derby uses write ahead logging for transactional consistency, which
means it guarantees that log records are forced to disk before
data file updates.  So take 2 simple cases of un-coordinated backup:

1) you copy log before data
    Now you may have inconsistent data as you may miss log updates
    associated with the data that you copied - may lead to corrupt

2) you copy the data before the log
    Derby may, after guaranteeing that all data associated with a
    particular logged transaction has been forced to disk, delete that
    portion of the log as unneeded.  But your copy of the data may
    not include these updates, and when you go to copy the log
    you are now missing log records associated with the pages of the
    data you have copied.

This is just one of the problems you may encounter.

Raymond Kroeker wrote:
> If you are looking to backup your database realtime; take a look at
> the SYSCS_BACKUP_DATABASE stored procedure.  It works well.
> http://db.apache.org/derby/docs/10.4/adminguide
> Raymond
> On Fri, Jul 18, 2008 at 09:28, Bryan Pendleton
> <bpendleton@amberpoint.com> wrote:
>>> Could someone explain the mechanism(s) for getting a corrupt database
>>> copy?  I'm using transactions, so isn't there protection against this
>>> sort of problem anyway?  How long does it take to commit a
>>> transaction?
>> Yes, Derby uses transactions to protect the database integrity, and
>> committing an individual transaction is quite speedy.
>> You can ensure that your database copy is valid by following the
>> techniques described here:
>> http://db.apache.org/derby/docs/10.4/adminguide/cadminhubbkup98797.html
>> thanks,
>> bryan

View raw message