Gecko [ 122.154.134.11 ]

Name	Size	Permission
admin.html	3.28 KB	-rw-r--r--
app.html	16.29 KB	-rw-r--r--
archival.html	9.52 KB	-rw-r--r--
atomicity.html	4.19 KB	-rw-r--r--
checkpoint.html	4.7 KB	-rw-r--r--
cursor.html	4.99 KB	-rw-r--r--
data_open.html	5.89 KB	-rw-r--r--
deadlock.html	5.78 KB	-rw-r--r--
env_open.html	6.53 KB	-rw-r--r--
fail.html	4.98 KB	-rw-r--r--
faq.html	7.8 KB	-rw-r--r--
filesys.html	4.22 KB	-rw-r--r--
hotfail.html	5.51 KB	-rw-r--r--
inc.html	6.1 KB	-rw-r--r--
intro.html	2.72 KB	-rw-r--r--
logfile.html	3.57 KB	-rw-r--r--
nested.html	4.19 KB	-rw-r--r--
put.html	10.51 KB	-rw-r--r--
read.html	7.93 KB	-rw-r--r--
reclimit.html	9.7 KB	-rw-r--r--
recovery.html	6.42 KB	-rw-r--r--
term.html	4.09 KB	-rw-r--r--
throughput.html	7.14 KB	-rw-r--r--
transapp.cs	10.34 KB	-rw-r--r--
tune.html	10.76 KB	-rw-r--r--
why.html	2.49 KB	-rw-r--r--
writetest.cs	2.32 KB	-rw-r--r--

Code Editor : checkpoint.html

<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,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++">
</head>
<body bgcolor=white>
<a name="2"></a>
<table width="100%"><tr valign=top>
<td><dl><dt>Berkeley DB Reference Guide:<dd>Berkeley DB Transactional Data Store Applications</dl></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>
Checkpoints
The second component of the infrastructure is performing checkpoints of
the log files. Performing checkpoints is necessary for two reasons.
First, you may be able to remove Berkeley DB log files from your database
environment after a checkpoint. Change records are written into the log
files when databases are modified, but the actual changes to the
database are not necessarily written to disk. When a checkpoint is
performed, changes to the database are written into the backing database
file. Once the database pages are written, log files can be archived
and removed from the database environment because they will never be
needed for anything other than catastrophic failure. (Log files which
are involved in active transactions may not be removed, and there must
always be at least one log file in the database environment.)
The second reason to perform checkpoints is because checkpoint frequency
is inversely proportional to the amount of time it takes to run database
recovery after a system or application failure. This is because
recovery after failure has to redo or undo changes only since the last
checkpoint, as changes before the checkpoint have all been flushed to
the databases.
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:
<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;

	while ((ch = getopt(argc, argv, "")) != EOF)
		switch (ch) {
		case '?':
		default:
			usage();
		}
	argc -= optind;
	argv += optind;

	env_dir_create();
	env_open(&dbenv);

	/* 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);
	}

	/* Open database: Key is fruit class; Data is specific type. */
	db_open(dbenv, &db_fruit, "fruit", 0);

	/* Open database: Key is a color; Data is an integer. */
	db_open(dbenv, &db_color, "color", 0);

	/*
	 * Open database:
	 *	Key is a name; Data is: company name, cat breeds.
	 */
	db_open(dbenv, &db_cats, "cats", 1);

	add_fruit(dbenv, db_fruit, "apple", "yellow delicious");

	add_color(dbenv, db_color, "blue", 0);
	add_color(dbenv, db_color, "blue", 3);

	add_cat(dbenv, db_cats,
		"Amy Adams",
		"Oracle",
		"abyssinian",
		"bengal",
		"chartreaux",
		NULL);

	return (0);
}

void *
checkpoint_thread(void *arg)
{
	DB_ENV *dbenv;
	int ret;

	dbenv = arg;
	dbenv-&gt;errx(dbenv, "Checkpoint thread: %lu", (u_long)pthread_self());

	/* 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);
		}

	/* NOTREACHED */
}</pre></blockquote>
Because checkpoints can be quite expensive, choosing how often to
perform a checkpoint is a common tuning parameter for Berkeley DB
applications.
<table width="100%"><tr><td> </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>
Copyright (c) 1996,2008 Oracle. All rights reserved.
</body>
</html>

${this.title}

Code Editor : checkpoint.html