<!--$Id: checkpoint.html,v 1.2 2004/03/30 01:22:59 jtownsen Exp $--> <!--Copyright 1997-2003 by Sleepycat Software, Inc.--> <!--All rights reserved.--> <!--See the file LICENSE for redistribution information.--> <html> <head> <title>Berkeley DB Reference Guide: Checkpoints</title> <meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> <meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++"> </head> <body bgcolor=white> <a name="2"><!--meow--></a> <table width="100%"><tr valign=top> <td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Berkeley DB Transactional Data Store Applications</dl></h3></td> <td align=right><a href="../transapp/deadlock.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../transapp/archival.html"><img src="../../images/next.gif" alt="Next"></a> </td></tr></table> <p> <h3 align=center>Checkpoints</h3> <p>The second component of the infrastructure is performing checkpoints of the log files. As transactions commit, change records are written into the log files, but the actual changes to the database are not necessarily written to disk. When a checkpoint is performed, the changes to the database that are part of committed transactions are written into the backing database file.</p> <p>Performing checkpoints is necessary for two reasons. First, you can remove the Berkeley DB log files from your system only after a checkpoint. Second, the frequency of your checkpoints is inversely proportional to the amount of time it takes to run database recovery after a system or application failure.</p> <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 has to redo or undo changes only since the last checkpoint since changes before the checkpoint have all been flushed to the filesystem.</p> <p>Berkeley DB provides a separate utility, <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/txn_checkpoint.html">DB_ENV->txn_checkpoint</a> function. The following code fragment checkpoints the database environment every 60 seconds:</p> <blockquote><pre>int main(int argc, char *argv) { extern int optind; DB *db_cats, *db_color, *db_fruit; DB_ENV *dbenv; pthread_t ptid; int ch; <p> while ((ch = getopt(argc, argv, "")) != EOF) switch (ch) { case '?': default: usage(); } argc -= optind; argv += optind; <p> env_dir_create(); env_open(&dbenv); <p> <b> /* Start a checkpoint thread. */ if ((errno = pthread_create( &ptid, NULL, checkpoint_thread, (void *)dbenv)) != 0) { fprintf(stderr, "txnapp: failed spawning checkpoint thread: %s\n", strerror(errno)); exit (1); }</b> <p> /* Open database: Key is fruit class; Data is specific type. */ db_open(dbenv, &db_fruit, "fruit", 0); <p> /* Open database: Key is a color; Data is an integer. */ db_open(dbenv, &db_color, "color", 0); <p> /* * Open database: * Key is a name; Data is: company name, cat breeds. */ db_open(dbenv, &db_cats, "cats", 1); <p> add_fruit(dbenv, db_fruit, "apple", "yellow delicious"); <p> add_color(dbenv, db_color, "blue", 0); add_color(dbenv, db_color, "blue", 3); <p> add_cat(dbenv, db_cats, "Amy Adams", "Sleepycat Software", "abyssinian", "bengal", "chartreaux", NULL); <p> return (0); } <p> <b>void * checkpoint_thread(void *arg) { DB_ENV *dbenv; int ret; <p> dbenv = arg; dbenv->errx(dbenv, "Checkpoint thread: %lu", (u_long)pthread_self()); <p> /* Checkpoint once a minute. */ for (;; sleep(60)) if ((ret = dbenv->txn_checkpoint(dbenv, 0, 0, 0)) != 0) { dbenv->err(dbenv, ret, "checkpoint thread"); exit (1); } <p> /* NOTREACHED */ }</b></pre></blockquote> <p>Because checkpoints can be quite expensive, choosing how often to perform a checkpoint is a common tuning parameter for Berkeley DB applications.</p> <table width="100%"><tr><td><br></td><td align=right><a href="../transapp/deadlock.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../transapp/archival.html"><img src="../../images/next.gif" alt="Next"></a> </td></tr></table> <p><font size=1><a href="../../sleepycat/legal.html">Copyright (c) 1996-2003</a> <a href="http://www.sleepycat.com">Sleepycat Software, Inc.</a> - All rights reserved.</font> </body> </html>