Berkeley DB Reference Guide: Opening multiple databases in a single file
Description: Berkeley DB: An embedded database programmatic toolkit.
Keywords: embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++

### Berkeley DB Reference Guide: Access Methods |

### Opening multiple databases in a single file

Applications may create multiple databases within a single physical file. This is useful when the databases are both numerous and reasonably small, in order to avoid creating a large number of underlying files, or when it is desirable to include secondary index databases in the same file as the primary index database. Multiple databases are an administrative convenience and using them is unlikely to affect database performance. To open or create a file that will include more than a single database, specify a database name when calling the DB->open method.

Physical files do not need to be comprised of a single type of database, and databases in a file may be of any mixture of types, except for Queue databases. Queue databases must be created one per file and cannot share a file with any other database type. There is no limit on the number of databases that may be created in a single file other than the standard Berkeley DB file size and disk space limitations.

It is an error to attempt to open a second database in a file that was not initially created using a database name, that is, the file must initially be specified as capable of containing multiple databases for a second database to be created in it.

It is not an error to open a file that contains multiple databases without specifying a database name, however the database type should be specified as DB_UNKNOWN and the database must be opened read-only. The handle that is returned from such a call is a handle on a database whose key values are the names of the databases stored in the database file and whose data values are opaque objects. No keys or data values may be modified or stored using this database handle.

The main difference when storing multiple databases in a single file rather than in separate files is that if any of the databases in a file is opened for updates, all of the databases in the file must share a memory pool. In other words, they must be opened in the same environment. In addition, there are some constraints on configuration information that apply to databases in the same file.

If databases are in separate files, and access to each separate database is single-threaded, there is no reason to perform any locking of any kind, and the two databases may be read and written simultaneously. Further, there would be no requirement to create a shared database environment in which to open the databases.

However, since multiple databases in a file exist in a single physical file, opening two databases in the same file simultaneously requires locking be enabled unless all of the handles are read-only. As the locks for the two databases can only conflict during page allocation, this additional locking is unlikely to affect performance.

Also, because multiple databases in a file exist in a single physical file, opening two databases in the same file requires the databases share an underlying memory pool so that per-physical-file information common between the two databases is updated correctly.

In summary, programmers writing applications that open multiple databases in a single file will almost certainly need to create a shared database environment in the application as well. For more information on database environments, see Database environment introduction.

In addition, there are four types of configuration information which must be specified consistently for all databases in a file, rather than differing on a per-database basis. They are: byte order, checksum and encryption behavior, and page size. When creating additional databases in a file, any of these configuration values specified must be consistent with the existing databases in the file or an error will be returned.

Copyright (c) 1996-2006 Oracle Corporation - All rights reserved.