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
db.
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
<[EMAIL PROTECTED]> 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
