checkpoint.html   [plain text]


<!--$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-&gt;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-&gt;errx(dbenv, "Checkpoint thread: %lu", (u_long)pthread_self());
<p>
	/* Checkpoint once a minute. */
	for (;; sleep(60))
		if ((ret = dbenv-&gt;txn_checkpoint(dbenv, 0, 0, 0)) != 0) {
			dbenv-&gt;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>