db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jørgen Løland <Jorgen.Lol...@Sun.COM>
Subject Re: Clean derby shutdown - shutdown a db so no recovery needed on startup
Date Wed, 15 Apr 2009 07:07:17 GMT
Nick Puz wrote:
> I've been doing performance evaluation of derby for a potential project (using dtrace
on osx and sun) and noticed that recovery is still run after doing what I thought was a clean
shutdown. I've stepped through derby10.4 (svn rev 751303) with java 6 and can see that recovery
is being run and the three operations being applied are: start tx, checkpoint, then endtx.

> Attached is a test program and copy of the dtrace output (showing file operations). The
test program:
> 1)  opens a connection to the db then closes it.
> 2) shuts down the db by opening a connection with ";shutdown=true" added to the url.
> 3) prompts for input (to add spacing to dtrace output/ start tracing)
> 4) repeats steps 1 & 2 -- starts on line 236 of attached dtrace output.
> Is there a way to close the DB to avoid the subsequent recovery actions on open? Not
so much the recovery (i understand it has to check on startup) but the write/fsync of the
log, log.ctrl, and logmirror.ctrl.

The recovery algorithm will always be executed when you boot a database, 
even when you have performed a clean shutdown like you have. Thus, the 
{start tx, checkpoint, commit} sequence is the least amount of recovery 
work currently possible in Derby.

AFAIK, there's no way to avoid this sequence - I don't think anyone ever 
considered writing a single block to disk at boot time would be a problem.

You may consider adding a bug report about this if it causes problems 
for you. Writing a patch for it would be even better if it is important 
to you :-)

BTW: should you consider working on this issue, the commit is what 
causes the write to disk. The checkpoint does nothing in this case.

Jørgen Løland

View raw message