berkdb env
	[-cachesize {gbytes bytes ncache}]
	[-create]
	[-data_dir dirname]
	[-encryptaes passwd]
	[-encryptany passwd]
	[-errfile filename]
	[-home directory]
	[-log_dir dirname]
	[-mode mode]
	[-private]
	[-recover]
	[-recover_fatal]
	[-shm_key shmid]
	[-system_mem]
	[-tmp_dir dirname]
	[-txn [nosync]]
	[-txn_max max]
	[-use_environ]
	[-use_environ_root]

The berkdb env command opens and optionally creates a database environment. The returned environment handle is bound to a Tcl command of the form envN, where N is an integer starting at 0 (for example, env0 and env1). It is through this Tcl command that the script accesses the environment methods. The command automatically initializes the Shared Memory Buffer Pool subsystem. This subsystem is used whenever the application is using any Berkeley DB access method.

The options are as follows:

• Set the size of the database's shared memory buffer pool (that is, the cache), to gbytes gigabytes plus bytes. The cache should be the size of the normal working data set of the application, with some small amount of additional memory for unusual situations. (Note: The working set is not the same as the number of simultaneously referenced pages, and should be quite a bit larger!)

  The default cache size is 256KB, and may not be specified as less than 20KB. Any cache size less than 500MB is automatically increased by 25% to account for buffer pool overhead; cache sizes larger than 500MB are used as specified.

  It is possible to specify caches to Berkeley DB that are large enough so that they cannot be allocated contiguously on some architectures; for example, some releases of Solaris limit the amount of memory that may be allocated contiguously by a process. If ncache is 0 or 1, the cache will be allocated contiguously in memory. If it is greater than 1, the cache will be broken up into ncache equally sized separate pieces of memory.

  For information on tuning the Berkeley DB cache size, see Selecting a cache size.

• Cause Berkeley DB subsystems to create any underlying files, as necessary.

• Specify the environment's data directory as described in Berkeley DB File Naming.

• Specify the database should be encrypted with the given password using the Rijndael/AES (also known as the Advanced Encryption Standard and Federal Information Processing Standard (FIPS) 197) algorithm.

• Specify the already existing environment should be opened with the given password. This option is used if the environment is known to be encrypted, but the specific algorithm used is not known.

• When an error occurs in the Berkeley DB library, a Berkeley DB error or an error return value is returned by the function. In some cases, however, the errno value may be insufficient to completely describe the cause of the error especially during initial application debugging.

  The -errfile argument is used to enhance the mechanism for reporting error messages to the application by specifying a file to be used for displaying additional Berkeley DB error messages. In some cases, when an error occurs, Berkeley DB will output an additional error message to the specified file reference.

  consist of the environment command name (for example, env0) and a colon (":"), an error string, and a trailing <newline> character.

  This error-logging enhancement does not slow performance or significantly increase application size, and may be run during normal operation as well as during application debugging.

• The -home argument is described in Berkeley DB File Naming.

• Specify the environment's logging file directory as described in Berkeley DB File Naming.

• On UNIX systems, or in IEEE/ANSI Std 1003.1 (POSIX) environments, all files created by Berkeley DB are created with mode mode (as described in chmod(2)) and modified by the process' umask value at the time of creation (see umask(2)). The group ownership of created files is based on the system and directory defaults, and is not further specified by Berkeley DB. If mode is 0, files are created readable and writable by both owner and group. On Windows systems, the mode argument is ignored.

• Specify that the environment will only be accessed by a single process (although that process may be multithreaded). This flag has two effects on the Berkeley DB environment. First, all underlying data structures are allocated from per-process memory instead of from shared memory that is potentially accessible to more than a single process. Second, mutexes are only configured to work between threads.

  This flag should not be specified if more than a single process is accessing the environment, as it is likely to cause database corruption and unpredictable behavior. For example, if both a server application and the Berkeley DB utility db_stat will access the environment, the -private option should not be specified.

• Run normal recovery on this environment before opening it for normal use. If this flag is set, the -create option must also be set because the regions will be removed and re-created.

• Run catastrophic recovery on this environment before opening it for normal use. If this flag is set, the -create option must also be set since the regions will be removed and re-created.

• Specify a base segment ID for Berkeley DB environment shared memory regions created in system memory on systems supporting X/Open-style shared memory interfaces, for example, UNIX systems supporting shmget(2) and related System V IPC interfaces. See Shared Memory Regions for more information.

• Allocate memory from system shared memory instead of memory backed by the filesystem. See Shared Memory Regions for more information.

• Specify the environment's tmp directory, as described in Berkeley DB File Naming.

• Initialize the Transaction subsystem. This subsystem is used when recovery and atomicity of multiple operations and recovery are important. The -txn option implies the initialization of the logging and locking subsystems as well.

  If the optional nosync argument is specified, the log will not be synchronously flushed on transaction commit. This means that transactions exhibit the ACI (atomicity, consistency, and isolation) properties, but not D (durability); that is, database integrity will be maintained, but it is possible that some number of the most recently committed transactions may be undone during recovery instead of being redone.

  The number of transactions that are potentially at risk is governed by how often the log is checkpointed (see db_checkpoint for more information) and how many log updates can fit on a single log page.

• Set the maximum number of simultaneous transactions that are supported by the environment, which bounds the size of backing files. When there are more than the specified number of concurrent transactions, calls to env txn will fail (until some active transactions complete).

• The Berkeley DB process' environment may be permitted to specify information to be used when naming files; see Berkeley DB File Naming. Because permitting users to specify which files are used can create security problems, environment information will be used in file naming for all users only if the -use_environ flag is set.

• The Berkeley DB process' environment may be permitted to specify information to be used when naming files; see Berkeley DB File Naming. As permitting users to specify which files are used can create security problems, if the -use_environ_root flag is set, environment information will be used for file naming only for users with appropriate permissions (for example, users with a user-ID of 0 on IEEE/ANSI Std 1003.1 (POSIX) systems).

The berkdb env command returns an environment handle on success.

In the case of error, a Tcl error is thrown.