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: derby 10.5.1 - embedded - crash recovery and logging
Date Wed, 21 Sep 2011 16:55:18 GMT
Knut Anders Hatlen wrote:
> 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
> "derby.storage.logArchiveMode=true".
To be clear running with logArchiveMode=true should not increase your
recovery time.  There will be many log files, but the system knows where
the last checkpoint was and only replays the necessary files.  So the
amount of work done should be the same whether logArchiveMode=true or 
not.  The point is with logArchiveMode=true it is not as easy to tell 
from just looking at the files if there is a lot of work to do.

View raw message