mirror of
https://github.com/berkeleydb/libdb.git
synced 2024-11-16 17:16:25 +00:00
127 lines
7.3 KiB
HTML
127 lines
7.3 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
|||
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|||
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|||
|
|
<head>
|
|||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
|
|||
|
|
<title>Copying or moving databases</title>
|
|||
|
|
<link rel="stylesheet" href="gettingStarted.css" type="text/css" />
|
|||
|
|
<meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
|
|||
|
|
<link rel="start" href="index.html" title="Berkeley DB Programmer's Reference Guide" />
|
|||
|
|
<link rel="up" href="program.html" title="Chapter 15. Programmer Notes" />
|
|||
|
|
<link rel="prev" href="program_cache.html" title="Disk drive caches" />
|
|||
|
|
<link rel="next" href="program_compatible.html" title="Compatibility with historic UNIX interfaces" />
|
|||
|
|
</head>
|
|||
|
|
<body>
|
|||
|
|
<div xmlns="" class="navheader">
|
|||
|
|
<div class="libver">
|
|||
|
|
<p>Library Version 11.2.5.2</p>
|
|||
|
|
</div>
|
|||
|
|
<table width="100%" summary="Navigation header">
|
|||
|
|
<tr>
|
|||
|
|
<th colspan="3" align="center">Copying or moving databases</th>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td width="20%" align="left"><a accesskey="p" href="program_cache.html">Prev</a> </td>
|
|||
|
|
<th width="60%" align="center">Chapter 15.
|
|||
|
|
Programmer Notes
|
|||
|
|
</th>
|
|||
|
|
<td width="20%" align="right"> <a accesskey="n" href="program_compatible.html">Next</a></td>
|
|||
|
|
</tr>
|
|||
|
|
</table>
|
|||
|
|
<hr />
|
|||
|
|
</div>
|
|||
|
|
<div class="sect1" lang="en" xml:lang="en">
|
|||
|
|
<div class="titlepage">
|
|||
|
|
<div>
|
|||
|
|
<div>
|
|||
|
|
<h2 class="title" style="clear: both"><a id="program_copy"></a>Copying or moving databases</h2>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
<p>There are two issues with copying or moving databases: database page log
|
|||
|
|
sequence numbers (LSNs), and database file identification strings.</p>
|
|||
|
|
<p>Because database pages contain references to the database environment
|
|||
|
|
log records (LSNs), databases cannot be copied or moved from one
|
|||
|
|
transactional database environment to another without first clearing the
|
|||
|
|
LSNs. Note that this is not a concern for non-transactional database
|
|||
|
|
environments and applications, and can be ignored if the database is not
|
|||
|
|
being used transactionally. Specifically, databases created and written
|
|||
|
|
non-transactionally (for example, as part of a bulk load procedure), can
|
|||
|
|
be copied or moved into a transactional database environment without
|
|||
|
|
resetting the LSNs. The database's LSNs may be reset in one of three
|
|||
|
|
ways: the application can call the <a href="../api_reference/C/envlsn_reset.html" class="olink">DB_ENV->lsn_reset()</a> method to reset the
|
|||
|
|
LSNs in place, or a system administrator can reset the LSNs in place
|
|||
|
|
using the <span class="bold"><strong>-r</strong></span> option to the <a href="../api_reference/C/db_load.html" class="olink">db_load</a> utility, or by
|
|||
|
|
dumping and reloading the database (using the <a href="../api_reference/C/db_dump.html" class="olink">db_dump</a> utility and the <a href="../api_reference/C/db_load.html" class="olink">db_load</a> utility).</p>
|
|||
|
|
<p>Because system file identification information (for example, filenames,
|
|||
|
|
device and inode numbers, volume and file IDs, and so on) are not
|
|||
|
|
necessarily unique or maintained across system reboots, each Berkeley DB
|
|||
|
|
database file contains a unique 20-byte file identification bytestring.
|
|||
|
|
When multiple processes or threads open the same database file in Berkeley DB,
|
|||
|
|
it is this bytestring that is used to ensure the same underlying pages
|
|||
|
|
are updated in the database environment cache, no matter which Berkeley DB
|
|||
|
|
handle is used for the operation.</p>
|
|||
|
|
<p>The database file identification string is not a concern when moving
|
|||
|
|
databases, and databases may be moved or renamed without resetting the
|
|||
|
|
identification string. However, when copying a database, you must
|
|||
|
|
ensure there are never two databases with the same file identification
|
|||
|
|
bytestring in the same cache at the same time. Copying databases is
|
|||
|
|
further complicated because Berkeley DB caches do not discard cached database
|
|||
|
|
pages when database handles are closed. Cached pages are only discarded
|
|||
|
|
when the database is removed by calling the <a href="../api_reference/C/envremove.html" class="olink">DB_ENV->remove()</a> or
|
|||
|
|
<a href="../api_reference/C/dbremove.html" class="olink">DB->remove()</a> methods.</p>
|
|||
|
|
<p>Before physically copying a database file, first ensure that all
|
|||
|
|
modified pages have been written from the cache to the backing database
|
|||
|
|
file. This is done using the <a href="../api_reference/C/dbsync.html" class="olink">DB->sync()</a> or <a href="../api_reference/C/dbclose.html" class="olink">DB->close()</a> methods.</p>
|
|||
|
|
<p>Before using a copy of a database file in a database environment, you
|
|||
|
|
must ensure that all pages from any other database with the same
|
|||
|
|
bytestring have been removed from the memory pool cache. If the
|
|||
|
|
environment in which you will open the copy of the database has pages
|
|||
|
|
from files with identical bytestrings to the copied database, there are
|
|||
|
|
a few possible solutions:</p>
|
|||
|
|
<div class="orderedlist">
|
|||
|
|
<ol type="1">
|
|||
|
|
<li>Remove the environment, either using system utilities or by calling the
|
|||
|
|
<a href="../api_reference/C/envremove.html" class="olink">DB_ENV->remove()</a> method. Obviously, this will not allow you to access
|
|||
|
|
both the original database and the copy of the database at the same
|
|||
|
|
time.</li>
|
|||
|
|
<li>
|
|||
|
|
Create a new file that will have a new bytestring. The simplest way to
|
|||
|
|
create a new file that will have a new bytestring is to call the
|
|||
|
|
<a href="../api_reference/C/db_dump.html" class="olink">db_dump</a> utility to dump out the contents of the database and then use the
|
|||
|
|
<a href="../api_reference/C/db_load.html" class="olink">db_load</a> utility to load the dumped output into a new file. This allows you
|
|||
|
|
to access both the original and copy of the database at the same time.
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
If your database is too large to be dumped and reloaded, you can copy
|
|||
|
|
the database by other means, and then reset the bytestring in the
|
|||
|
|
copied database to a new bytestring. There are two ways to reset the
|
|||
|
|
bytestring in the copy: the application can call the <a href="../api_reference/C/envfileid_reset.html" class="olink">DB_ENV->fileid_reset()</a>
|
|||
|
|
method, or a system administrator can use the <span class="bold"><strong>-r</strong></span> option to the <a href="../api_reference/C/db_load.html" class="olink">db_load</a> utility. This allows you
|
|||
|
|
to access both the original and copy of the database at the same time.
|
|||
|
|
</li>
|
|||
|
|
</ol>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
<div class="navfooter">
|
|||
|
|
<hr />
|
|||
|
|
<table width="100%" summary="Navigation footer">
|
|||
|
|
<tr>
|
|||
|
|
<td width="40%" align="left"><a accesskey="p" href="program_cache.html">Prev</a> </td>
|
|||
|
|
<td width="20%" align="center">
|
|||
|
|
<a accesskey="u" href="program.html">Up</a>
|
|||
|
|
</td>
|
|||
|
|
<td width="40%" align="right"> <a accesskey="n" href="program_compatible.html">Next</a></td>
|
|||
|
|
</tr>
|
|||
|
|
<tr>
|
|||
|
|
<td width="40%" align="left" valign="top">Disk drive caches </td>
|
|||
|
|
<td width="20%" align="center">
|
|||
|
|
<a accesskey="h" href="index.html">Home</a>
|
|||
|
|
</td>
|
|||
|
|
<td width="40%" align="right" valign="top"> Compatibility with historic UNIX interfaces</td>
|
|||
|
|
</tr>
|
|||
|
|
</table>
|
|||
|
|
</div>
|
|||
|
|
</body>
|
|||
|
|
</html>
|