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: drop table does not delete .dat files
Date Tue, 06 Nov 2007 08:29:48 GMT
Fabian Merki wrote:
> hi all
> 
> thanks for your help.
> 
> should i regularly call SYSCS_UTIL.SYSCS_CHECKPOINT_DATABASE 
> 
> every day or so? what happens if the db gets a kill -9 and the checkpoint was not done?
> 
> thanks
> 
> fabian

Hi Fabian,

As Knut commented in another reply, checkpoints are invoked on a regular 
basis (based on the size of the log) by Derby. Calling 
SYSCS_UTIL.SYSCS_CHECKPOINT_DATABASE does the same as is done by the 
"automatic checkpoint" mechanism. Thus, depending on the workload on 
your system, checkpoints may already be created multiple times every 
day. Normally, it should not be necessary to manually invoke 
checkpoints, but I can't guarantee that it won't have positive effects 
in your system.

Checkpoints are implemented as transactions, and do this (simplified 
version):

1) Stop all write operations while the transaction log that has not yet 
been written to disk is flushed
2) Start a checkpoint transaction and gather some interesting info
3) Write data blocks that have been modified (by any transaction) to disk
4) Commit the checkpoint transaction

If a crash/kill -9/power loss/etc happens after a checkpoint has been 
started but before it had the time to complete (commit), Derby will 
understand that it did not complete and remove it's effects when the 
database is rebooted. For the record, this is what happens for all 
transactions that were active at the time of the crash/kill -9/...: If a 
transaction did not complete, it's effects are removed at database 
reboot time.

If you are interested in more details about checkpoints in Derby, I 
suggest you have a look at the following link:

http://db.apache.org/derby/papers/recovery.html#Checkpoints

Hope this helps :)

---
Jørgen Løland


Mime
View raw message