db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <knut.hat...@oracle.com>
Subject Re: derby 10.5.1 - embedded - crash recovery and logging
Date Wed, 21 Sep 2011 09:33:11 GMT
Paul French <paul.french@kirona.com> writes:

> Hello All,
> we have an issue where derby takes a long time to startup. Anything
> from minutes to hours.
> We are running derby on J9 on a windows mobile 6.5
> It seems to be due to the fact that devices are being powered off and
> so derby is not shutdown cleanly.
> Question is, what is derby doing to recover? Why so long? Even when we
> start the application cleanly, do nothing, power off the device and
> then on again, it can take a very long time to make the first database
> connection vie the embedded driver.

Hi Paul,

During recovery, Derby replays all write operations performed after the
last checkpoint and finally undoes all the operations performed by
transactions that hadn't been committed at the time the database was
taken down. If the database is shut down cleanly, a checkpoint will be
invoked, so that there should be nothing to do in the recovery phase on
the next start-up.

If shutting down the database cleanly isn't an option, one way to reduce
the recovery time is to increase the checkpoint frequency. Then there
should be fewer operations to replay on the next start-up. This can be
achieved by setting the (undocumented) database property
derby.storage.checkpointInterval, which specifies the maximum number of
bytes of transaction log before a checkpoint is triggered. The default
is 10MB. The minimum value accepted is 100000 bytes.

However, you say that you see that recovery takes a very long time even
if no operations were performed the last time the database was running,
in which case there should be no operations to replay. Does the
database's log directory contain many and/or big files? The files in
that directory contain the transaction logs that need to be replayed on
recovery. If there are many files there, it might be that you are
running with log archive mode enabled (typically used when taking
backups), which prevents old log from being deleted. You can check if
that's the case by looking at the service.properties file in the
database directory and see if it contains

Knut Anders

View raw message