Berkeley DB Reference Guide: Copying databases
Description: Berkeley DB: An embedded database programmatic toolkit.
Keywords: embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++

### Berkeley DB Reference Guide: Programmer Notes |

# Copying databases

Because file identification cookies (e.g., file names, device and inode numbers, volume and file IDs, etc.) are not necessarily unique or maintained across system reboots, each Berkeley DB database file contains a 20-byte file identification bytestring that is stored in the first page of the database at a page byte offset of 36 bytes. When multiple processes or threads open the same database file in Berkeley DB, it is this bytestring that is used to ensure that the same underlying pages are updated in the shared memory buffer pool no matter which Berkeley DB handle is used for the operation.

It is usually a bad idea to physically copy a database to a new name. In the few cases where copying is the best solution for your application, you must guarantee there are never two different databases with the same file identification bytestring in the memory pool at the same time. Copying databases is further complicated by the fact that the shared memory buffer pool does not discard all cached copies of pages for a database when the database is logically closed, that is, when DB->close is called. Nor is there a Berkeley DB interface to explicitly discard pages from the shared memory buffer pool for any particular database.

Before copying a database, you must ensure that all modified pages have been written from the memory pool cache to the backing database file. This is done using the DB->sync or DB->close interfaces.

Before using a copy of a database from Berkeley DB, you must ensure that all pages from any database with the same bytestring have been removed from the memory pool cache. If the environment in which you intend to open the copy of the database potentially has pages from files with identical bytestrings to the copied database (which is likely to be the case), there are a few possible solutions:

1. Remove the environment, either explicitly or by calling DBENV->remove. Note, this will not allow you to access both the original and copy of the database at the same time.

2. Overwrite the bytestring in the copied database with a new bytestring. This allows you to access both the original and copy of the database at the same time.

3. 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 db_dump utility to dump out the contents of the database, and then use the db_load utility to load the dumped output into a new file name. This allows you to access both the original and copy of the database at the same time.

Copyright Sleepycat Software