1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
|
<! "@(#)checkpoint.so 10.2 (Sleepycat) 11/10/98">
<!Copyright 1997, 1998 by Sleepycat Software, Inc. All rights reserved.>
<html>
<body bgcolor=white>
<head>
<title>Berkeley DB Reference Guide: Transaction Protected Applications</title>
<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btr
ee,hash,hashing,transaction,transactions,locking,logging,access method,access me
thods,java,C,C++">
</head>
<h3>Berkeley DB Reference Guide: Transaction Protected Applications</h3>
<p>
<h1 align=center>Performing Checkpoints</h1>
<p>
The second component of the infrastructure, <i>performing
checkpoints</i>, is necessary for two reasons. First, you can only remove
the Berkeley DB log files from your system after a checkpoint. Second, the
frequency of your checkpoints is inversely proportional to the amount of
time it takes to run database recovery when the system or application
fails.
<p>
As transactions commit, records are written into the log files, but
the actual changes to the database are not written into the filesystem.
When a checkpoint is performed, all changes to the database which are
part of committed transactions are written into the filesystem.
<p>
Once the database pages are written, log files can be archived and removed
from the system because they will never be needed for anything other than
catastrophic failure. In addition, recovery after system or application
failure only has to redo or undo changes since the last checkpoint, since
it is known that changes before the checkpoint have all been flushed to
the filesystem.
<p>
Berkeley DB provides a separate UNIX-style utility, named <a href="../../utility/db_checkpoint.html">db_checkpoint</a>,
which can be used to perform checkpoints.
Alternatively, applications can write their own checkpoint utility using
the underlying <a href="../../api_c/DbTxnMgr/checkpoint.html">txn_checkpoint</a> function.
<p>
As checkpoints can be quite expensive, choosing how often to perform a
checkpoint is a common issue needing consideration when tuning Berkeley DB
applications.
<p>
<a href="../../ref/transapp/deadlock.html"><img src="../../images/prev.gif"></a>
<a href="../../ref/toc.html"><img src="../../images/toc.gif"></a>
<a href="../../ref/transapp/archival.html"><img src="../../images/next.gif"></a>
</tt>
</body>
</html>
|
