db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Puz <nick.de...@me.com>
Subject Re: Clean derby shutdown - shutdown a db so no recovery needed on startup
Date Wed, 15 Apr 2009 17:59:25 GMT
Hi Jørgen, 
Thanks for the quick response. Due to our planned derby usage pattern (open derby, do something
for a user request, close derby) this is more of an issue. This usage is done so that any
mid-tier box can handle client requests and access the derby db on a nas/filer. I notice the
following writes/fsyncs in a read only test, are they all due to the commit log record or
is there another cause of the writes to log ctrl files: 

1 - open: opened fd=36 ns=24000 flags=514 path '/testDBHome/simpleDerbyTest/log/log.ctrl'

1 - write: write of size=48 ns=22000 to fd 36 - /testDBHome/simpleDerbyTest/log/log.ctrl
1 - fsync: fsync ns=1378000 fd=36 - '/testDBHome/simpleDerbyTest/log/log.ctrl'
1 - close: close on fd=36 - '/testDBHome/simpleDerbyTest/log/log.ctrl' 
1 - open: opened fd=36 ns=30000 flags=514 path '/testDBHome/simpleDerbyTest/log/logmirror.ctrl'

1 - write: write of size=48 ns=30000 to fd 36 - /testDBHome/simpleDerbyTest/log/logmirror.ctrl
1 - fsync: fsync ns=250000 fd=36 - '/testDBHome/simpleDerbyTest/log/logmirror.ctrl'
1 - close: close on fd=36 - '/testDBHome/simpleDerbyTest/log/logmirror.ctrl'

and another set when shutting down:
1 - write: write of size=144 ns=321000 to fd 35 - /testDBHome/simpleDerbyTest/log/log1.dat
0 - open: opened fd=40 ns=32000 flags=514 path '/testDBHome/simpleDerbyTest/log/log.ctrl'

0 - write: write of size=48 ns=20000 to fd 40 - /testDBHome/simpleDerbyTest/log/log.ctrl
0 - fsync: fsync ns=168000 fd=40 - '/testDBHome/simpleDerbyTest/log/log.ctrl'
0 - close: close on fd=40 - '/testDBHome/simpleDerbyTest/log/log.ctrl' 
0 - open: opened fd=40 ns=21000 flags=514 path '/testDBHome/simpleDerbyTest/log/logmirror.ctrl'

0 - write: write of size=48 ns=17000 to fd 40 - /testDBHome/simpleDerbyTest/log/logmirror.ctrl
1 - fsync: fsync ns=190000 fd=40 - '/testDBHome/simpleDerbyTest/log/logmirror.ctrl'
1 - close: close on fd=40 - '/testDBHome/simpleDerbyTest/log/logmirror.ctrl' 
1 - close: close on fd=39 - '/testDBHome/simpleDerbyTest/seg0/cd1.dat' 
1 - close: close on fd=36 - '/testDBHome/simpleDerbyTest/seg0/c10.dat' 
1 - open_nocancel: opened fd=36 ns=27000 flags=1048580 path '/testDBHome/simpleDerbyTest/tmp'

1 - close_nocancel: close on fd=36 - '/testDBHome/simpleDerbyTest/tmp' 
1 - open_nocancel: opened fd=36 ns=19000 flags=1048580 path '/testDBHome/simpleDerbyTest'

0 - close: close on fd=38 - '/testDBHome/simpleDerbyTest/seg0/cc0.dat' 
0 - close_nocancel: close on fd=36 - '/testDBHome/simpleDerbyTest' 
0 - open_nocancel: opened fd=36 ns=17000 flags=1048580 path '/testDBHome/simpleDerbyTest/seg0'

0 - close_nocancel: close on fd=36 - '/testDBHome/simpleDerbyTest/seg0' 
0 - write: write of size=70 ns=264000 to fd 35 - /testDBHome/simpleDerbyTest/log/log1.dat


On Wednesday, April 15, 2009, at 12:07AM, "Jørgen Løland" <Jorgen.Loland@Sun.COM>
>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