Safe backups

[Amir Michail]

Hi,

Would it be sufficient to shut down tomcat (using
/etc/init.d/tomcat5.5 stop) before copying derby databases?

What would happen to open connections if I do this?  Could the copy be corrupt?

Amir

--
http://chatbotgame.com
http://numbrosia.com
http://twitter.com/amichail

[Donald McLean-3]

That's what I did for a long time and I didn't have any problems. That
doesn't mean that properly closing/shutting down things isn't a good
habit to get into.

Donald

On Thu, Jul 17, 2008 at 11:45 PM, Amir Michail <amichail@...> wrote:
> Hi,
>
> Would it be sufficient to shut down tomcat (using
> /etc/init.d/tomcat5.5 stop) before copying derby databases?
>
> What would happen to open connections if I do this?  Could the copy be corrupt?

[Amir Michail]

On Fri, Jul 18, 2008 at 9:55 AM, Donald McLean <dmclean62@...> wrote:
> That's what I did for a long time and I didn't have any problems. That
> doesn't mean that properly closing/shutting down things isn't a good
> habit to get into.
>
> Donald

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?

Amir

>
> On Thu, Jul 17, 2008 at 11:45 PM, Amir Michail <amichail@...> wrote:
>> Hi,
>>
>> Would it be sufficient to shut down tomcat (using
>> /etc/init.d/tomcat5.5 stop) before copying derby databases?
>>
>> What would happen to open connections if I do this?  Could the copy be corrupt?
>



--
http://chatbotgame.com
http://numbrosia.com
http://twitter.com/amichail

[Bryan Pendleton]

> 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

[raykroeker]

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@...> 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
>
>

--
---------------------------------------------------------
Raymond Kroeker

[Mike Matrigali]

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
> <bpendleton@...> 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
>>
>>
>
>
>