The database files that need to be archived in order to recover the database from catastrophic failure. If any of the database files have not been accessed during the lifetime of the current log files, they will not included in this list. It is also possible that some of the files referred to by the log have since been deleted from the system.

The names of all of the log files that are no longer in use (for example, that are no longer involved in active transactions), and that may safely be archived for catastrophic recovery and then removed from the system.

Perform a hot back up of the open environment.

All files used by the environment are backed up, so long as the normal rules for file placement are followed. For information on how files are normally placed relative to the environment directory, see the "Berkeley DB File Naming" section in the Berkeley DB Reference Guide.

By default, data directories and the log directory specified relative to the home directory will be recreated relative to the target directory. If absolute path names are used, then use the SingleDir method.

This method provides the same functionality as the db_hotbackup utility. However, this method does not perform the housekeeping actions performed by that utility. In particular, you may want to run a checkpoint before calling this method. To run a checkpoint, use the Checkpoint()()() method. For more information on checkpoints, see the "Checkpoint" section in the Berkeley DB Reference Guide.

To back up a single database file within the environment, use the BackupDatabase(String, String, Boolean) method.

In addition to the configuration options available using the BackupOptions class, additional tuning modifications can be made using the BackupReadCount, BackupReadSleepDuration, BackupBufferSize, and BackupWriteDirect properties. Alternatively, you can write your own custom hot back up facility using the IBackup interface.

Perform a hot back up of a single database file contained within the environment.

To back up the entire environment, use the Backup(String, BackupOptions) method.

You can make some tuning modifications to the backup process using the BackupReadCount, BackupReadSleepDuration, BackupBufferSize, and BackupWriteDirect properties. Alternatively, you can write your own custom hot back up facility using the IBackup interface.

Allocate a locker ID in an environment configured for Berkeley DB Concurrent Data Store applications.

By closing the Berkeley DB environment you can free allocated resources and close any open databases along with the underlying subsystems.

Close the Berkeley DB environment, freeing any allocated resources, closing any open databases as well as underlying subsystems.

Run one iteration of the deadlock detector. The deadlock detector traverses the lock table and marks one of the participating lock requesters for rejection in each deadlock it finds.

Determines whether the specified Object is equal to the current Object.

Check for threads of control (either a true thread or a process) that have exited while manipulating Berkeley DB library data structures, while holding a logical database lock, or with an unresolved transaction (that is, a transaction that was never aborted or committed).

Serves as a hash function for a particular type.

Gets the type of the current instance.

This method checks to see if a specified transaction has been replicated from the master of a replication group. It may be called by applications using either the Base API or the Replication Manager.

Map an LSN object to a log filename

The names of all of the log files

Verify log records of this environment.

Append a record to the log

Instantiate a new DatabaseEnvironment object and open the Berkeley DB environment represented by home.

Set the panic state for the database environment. (Database environments in a panic state normally refuse all attempts to call Berkeley DB functions, throwing RunRecoveryException.)

Restore transactions that were prepared, but not yet resolved at the time of the system shut down or crash, to their state prior to the shut down or crash, including any locks previously held.

The amount of memory to be used by shared structures in the main environment region. These are structures other than mutexes and the page cache (memory pool).

The environment regions, including any backing files, are removed. Any log or database files and the environment directory are not removed.

If there are processes that have called Open(String, DatabaseEnvironmentConfig) without calling Close()()() (that is, there are processes currently using the environment), Remove will fail without further action.

Calling Remove should not be necessary for most applications because the Berkeley DB environment is cleaned up as part of normal database recovery procedures. However, applications may want to call Remove as part of application shut down to free up system resources. For example, if SystemMemory was specified to Open(String, DatabaseEnvironmentConfig), it may be useful to call Remove in order to release system shared memory segments that have been allocated. Or, on architectures in which mutexes require allocation of underlying system resources, it may be useful to call Remove in order to release those resources. Alternatively, if recovery is not required because no database state is maintained across failures, and no system resources need to be released, it is possible to clean up an environment by simply removing all the Berkeley DB files in the database environment's directories.

In multithreaded applications, only a single thread may call Remove.

Remove log files that are no longer needed. Automatic log file removal is likely to make catastrophic recovery impossible.

RepHoldElection is not called by most replication applications. It should only be called by applications implementing their own network transport layer, explicitly holding replication group elections and handling replication messages outside of the replication manager framework.

If the election is successful, Berkeley DB will notify the application of the results of the election by means of either the REP_ELECTED or REP_NEWMASTER events (see EventNotifyfor more information). The application is responsible for adjusting its relationship to the other database environments in the replication group, including directing all database updates to the newly selected master, in accordance with the results of the election.

The thread of control that calls RepHoldElection must not be the thread of control that processes incoming messages; processing the incoming messages is necessary to successfully complete an election.

Before calling this method, the RepTransport delegate must already have been configured to send replication messages.

Create DbChannel with given eid.

Configure a site in the replication manager.

There are two ways to build Berkeley DB replication applications: the most common approach is to use the Berkeley DB library "replication manager" support, where the Berkeley DB library manages the replication group, including network transport, all replication message processing and acknowledgment, and group elections. Applications using the replication manager support generally make the following calls:

1. Configure the local site in the replication group, RepMgrLocalSite.
2. Call RepMgrSiteConfig(DbSiteConfig) to configure the remote site(s) in the replication group.
3. Configure the message acknowledgment policy (RepMgrAckPolicy) which provides the replication group's transactional needs.
4. Configure the local site's election priority, RepPriority.
5. Call RepMgrStartClient(Int32) or RepMgrStartMaster(Int32) to start the replication application.

For more information on building replication manager applications, please see the Replication Getting Started Guide included in the Berkeley DB documentation.

Applications with special needs (for example, applications using network protocols not supported by the Berkeley DB replication manager), must perform additional configuration and call other Berkeley DB replication methods. For more information on building advanced replication applications, please see the Base Replication API section in the Berkeley DB Programmer's Reference Guide for more information.

Starting the replication manager consists of opening the TCP/IP listening socket to accept incoming connections, and starting all necessary background threads. When multiple processes share a database environment, only one process can open the listening socket; RepMgrStartClient(Int32) (and RepMgrStartMaster(Int32)) automatically open the socket in the first process to call it, and skips this step in the later calls from other processes.

Start the replication manager as a master site, and do not call for an election.

Process an incoming replication message sent by a member of the replication group to the local database environment.

Set the clock skew ratio among replication group members based on the fastest and slowest measurements among the group for use with master leases.

Set a threshold for the minimum and maximum time that a client waits before requesting retransmission of a missing message.

Set a byte-count limit on the amount of data that will be transmitted from a site in response to a single message processed by RepProcessMessage(DatabaseEntry, DatabaseEntry, Int32). The limit is not a hard limit, and the record that exceeds the limit is the last record to be sent.

Initialize the communication infrastructure for a database environment participating in a replicated application.

RepStartClient is not called by most replication applications. It should only be called by applications implementing their own network transport layer, explicitly holding replication group elections and handling replication messages outside of the replication manager framework.

Replication master environments are the only database environments where replicated databases may be modified. Replication client environments are read-only as long as they are clients. Replication client environments may be upgraded to be replication master environments in the case that the current master fails or there is no master present. If master leases are in use, this method cannot be used to appoint a master, and should only be used to configure a database environment as a master as the result of an election.

Before calling this method, the RepTransport delegate must already have been configured to send replication messages.

RepStartMaster is not called by most replication applications. It should only be called by applications implementing their own network transport layer, explicitly holding replication group elections and handling replication messages outside of the replication manager framework.

Replication master environments are the only database environments where replicated databases may be modified. Replication client environments are read-only as long as they are clients. Replication client environments may be upgraded to be replication master environments in the case that the current master fails or there is no master present. If master leases are in use, this method cannot be used to appoint a master, and should only be used to configure a database environment as a master as the result of an election.

Before calling this method, the RepTransport delegate must already have been configured to send replication messages.

Force master synchronization to begin for this client.

Allow database files to be copied, and then the copy used in the same database environment as the original.

Allow database files to be moved from one transactional database environment to another.

Limit the number of sequential write operations scheduled by the library when flushing dirty pages from the cache.

Returns a string that represents the current object.

Ensure that a specified percent of the pages in the cache are clean, by writing dirty pages to their backing files.

WriteToLog allows applications to include information in the database environment log files, for later review using the db_printlog utility. This method is intended for debugging and performance tuning.

WriteToLog allows applications to include information in the database environment log files, for later review using the db_printlog utility. This method is intended for debugging and performance tuning.

If true, database operations for which no explicit transaction handle was specified, and which modify databases in the database environment, will be automatically enclosed within a transaction.

The size of the buffer, in bytes, to read from the database during a hot backup.

Sets the IBackup interface to be used when performing hot backups.

This interface is used to override the default behavior used by the Backup(String, BackupOptions) and BackupDatabase(String, String, Boolean) methods.

The number of pages to read before pausing during the hot backup.

Increasing this value increases the amount of I/O the backup process performs for any given time interval. If your application is already heavily I/O bound, setting this value to a lower number may help to improve your overall data throughput by reducing the I/O demands placed on your system. By default, all pages are read without a pause.

The number of microseconds to sleep between batches of reads during a hot backup.

Increasing this value decreases the amount of I/O the backup process performs for any given time interval. If your application is already heavily I/O bound, setting this value to a higher number may help to improve your overall data throughput by reducing the I/O demands placed on your system.

If true, direct I/O is used when writing pages to the disk during a hot backup.

For some environments, direct I/O can provide faster write throughput, but usually it is slower because the OS buffer pool offers asynchronous activity.

The size of the shared memory buffer pool -- that is, the cache.

If true, Berkeley DB Concurrent Data Store applications will perform locking on an environment-wide basis rather than on a per-database basis.

If true, Berkeley DB subsystems will create any underlying files, as necessary.

The array of directories where database files are stored.

The deadlock detector configuration, specifying what lock request(s) should be rejected. As transactions acquire locks on behalf of a single locker ID, rejecting a lock request associated with a transaction normally requires the transaction be aborted.

The algorithm used by the Berkeley DB library to perform encryption and decryption.

The mechanism for reporting detailed error messages to the application.

The prefix string that appears before error messages issued by Berkeley DB.

A delegate which is called to notify the process of specific Berkeley DB events.

Monitor progress within long running operations.

If true, flush database writes to the backing disk before returning from the write system call, rather than flushing database writes explicitly in a separate system call, as necessary.

If true, the object is free-threaded; that is, concurrently usable by multiple threads in the address space.

The database environment home directory.

Whether there is any hot backup in progress.

The number of locks allocated when the environment is created

The number of lockers allocated when the environment is created

The number of lock objects allocated when the environment is created

The number of log identifier objects allocated when the environment is created

The initial number of mutexes allocated

If true, Berkeley DB will page-fault shared regions into memory when initially creating or joining a Berkeley DB environment.

The number of thread objects allocated when the environment is created

The number of transaction objects allocated when the environment is created

The intermediate directory permissions.

The current lock conflicts array.

If true, lock shared Berkeley DB environment files and memory-mapped databases into memory.

The number of lock table partitions used in the Berkeley DB environment.

The size of the lock table in the Berkeley DB environment.

A value, in microseconds, representing lock timeouts.

If true, Berkeley DB will automatically remove log files that are no longer needed.

The size of the in-memory log buffer, in bytes

The path of a directory to be used as the location of logging files. Log files created by the Log Manager subsystem will be created in this directory.

The absolute file mode for created log files. This property is only useful for the rare Berkeley DB application that does not control its umask value.

If true, Berkeley DB will flush log writes to the backing disk before returning from the write system call, rather than flushing log writes explicitly in a separate system call, as necessary.

If true, transaction logs are maintained in memory rather than on disk. This means that transactions exhibit the ACI (atomicity, consistency, and isolation) properties, but not D (durability).

If true, system buffering is turned off for Berkeley DB log files to avoid double caching.

The size of the underlying logging area of the Berkeley DB environment, in bytes.

If true, all pages of a log file are zeroed when that log file is created.

The maximum cache size

The maximum number of locking entities supported by the Berkeley DB environment.

The maximum number of locks supported by the Berkeley DB environment.

The maximum size of a single file in the log, in bytes. Because LSN Offsets are unsigned four-byte values, the size may not be larger than the maximum unsigned four-byte value.

The total number of mutexes allocated

The maximum number of locked objects

The number of file descriptors the library will open concurrently when flushing dirty pages from the cache.

The number of sequential write operations scheduled by the library when flushing dirty pages from the cache.

The number of active transactions supported by the environment. This value bounds the size of the memory allocated for transactions. Child transactions are counted as active until they either commit or abort.

The path of directory to store the persistent metadata.

The maximum file size, in bytes, for a file to be mapped into the process address space. If no value is specified, it defaults to 10MB.

The mutex alignment, in bytes.

The number of additional mutexes allocated.

If true, turn off system buffering of Berkeley DB database files to avoid double caching.

If true, Berkeley DB will grant all requested mutual exclusion mutexes and database locks without regard for their actual availability. This functionality should never be used for purposes other than debugging.

If true, Berkeley DB will copy read-only database files into the local cache instead of potentially mapping them into process memory.

If true, Berkeley DB will ignore any panic state in the database environment. (Database environments in a panic state normally refuse all attempts to call Berkeley DB functions, throwing RunRecoveryException.) This functionality should never be used for purposes other than debugging.

The number of times that test-and-set mutexes should spin without blocking. The value defaults to 1 on uniprocessor systems and to 50 times the number of processors on multiprocessor systems.

If true, overwrite files stored in encrypted formats before deleting them.

If true, allocate region memory from the heap instead of from memory backed by the filesystem or system shared memory.

The bytes component of the byte-count limit on the amount of memory to be used by shared structures in the main environment region. These are the structures other than mutexes and the page cache (memory pool).

The gigabytes component of the byte-count limit on the amount of memory to be used by shared structures in the main environment region. These are the structures other than mutexes and the page cache (memory pool).

If true, Berkeley DB will have checked to see if recovery needed to be performed before opening the database environment.

The amount of time the replication manager's transport function waits to collect enough acknowledgments from replication group clients, before giving up and returning a failure indication. The default wait time is 1 second.

If true, the replication master will automatically re-initialize outdated clients (defaults to true).

If true, the replication master sends groups of records to the clients in a single network transfer

The amount of time a master site will delay between completing a checkpoint and writing a checkpoint record into the log.

The value, relative to RepClockskewSlow, of the fastest clock in the group of sites.

The value of the slowest clock in the group of sites.

The amount of time the replication manager will wait before trying to re-establish a connection to another site after a communication failure. The default wait time is 30 seconds.

If true, the client should delay synchronizing to a newly declared master (defaults to false). Clients configured in this way will remain unsynchronized until the application calls RepSync()()().

Configure the amount of time the replication manager will wait before retrying a failed election. The default wait time is 10 seconds.

The timeout period for an election. The default timeout is 2 seconds.

An optional configuration timeout period to wait for full election participation the first time the replication group finds a master. By default this option is turned off and normal election timeouts are used. (See the Elections section in the Berkeley DB Reference Guide for more information.)

The amount of time the replication manager, running at a client site, waits for some message activity on the connection from the master (heartbeats or other messages) before concluding that the connection has been lost. When 0 (the default), no monitoring is performed.

The frequency at which the replication manager, running at a master site, broadcasts a heartbeat message in an otherwise idle system. When 0 (the default), no heartbeat messages will be sent.

If true, replication only stores the internal information in-memory and cannot keep persistent state across a site crash or reboot. By default, it is false and replication creates files in the environment home directory to preserve the internal information.

The amount of time a client grants its master lease to a master. When using master leases all sites in a replication group must use the same lease timeout value. There is no default value. If leases are desired, this method must be called prior to calling RepStartClient()()() or RepStartMaster()()().

Set the message dispatch function. It is responsible for receiving messages sent from remote sites using either SendMessage(array<DatabaseEntry>[]()[]) or SendRequest(array<DatabaseEntry>[]()[], UInt32). If the message received by this function was sent using SendMessage(array<DatabaseEntry>[]()[]), then no response is required. If the message was sent using SendRequest(array<DatabaseEntry>[]()[], UInt32), then this function must send a response using SendMessage(array<DatabaseEntry>[]()[]).

Specify how master and client sites will handle acknowledgment of replication messages which are necessary for "permanent" records. The current implementation requires all sites in a replication group configure the same acknowledgement policy.

The local site of the replication manager. Returns null if the local site has not been configured.

The status of the sites currently known by the replication manager.

If true, Replication Manager automatically runs elections to choose a new master when the old master appears to have become disconnected (defaults to true).

If true, Berkeley DB method calls that would normally block while clients are in recovery will return errors immediately (defaults to false).

The total number of sites in the replication group.

The database environment's priority in replication group elections. A special value of 0 indicates that this environment cannot be a replication group master. If not configured, then a default value of 100 is used.

The maximum number of microseconds a client waits before requesting retransmission.

The minimum number of microseconds a client waits before requesting retransmission.

Replication Manager observes the strict "majority" rule in managing elections, even in a group with only 2 sites. This means the client in a 2-site group will be unable to take over as master if the original master fails or becomes disconnected. (See the Elections section in the Berkeley DB Reference Guide for more information.) Both sites in the replication group should have the same value for this parameter.

The bytes component of the byte-count limit on the amount of data that will be transmitted from a site in response to a single message processed by RepProcessMessage(DatabaseEntry, DatabaseEntry, Int32).

The gigabytes component of the byte-count limit on the amount of data that will be transmitted from a site in response to a single message processed by RepProcessMessage(DatabaseEntry, DatabaseEntry, Int32).

The delegate used to transmit data using the replication application's communication infrastructure.

If true, master leases will be used for this site (defaults to false).

If true, catastrophic recovery was run on this environment before opening it for normal use.

If true, normal recovery was run on this environment before opening it for normal use.

The number of microseconds the thread of control will pause before scheduling further write operations.

A delegate that returns a unique identifier pair for the current thread of control.

A delegate that formats a process ID and thread ID identifier pair.

If true, allocate region memory from system shared memory instead of from heap memory or memory backed by the filesystem.

The path of a directory to be used as the location of temporary files.

An approximate number of threads in the database environment.

A delegate that returns if a thread of control (either a true thread or a process) is still running.

If true, database calls timing out based on lock or transaction timeout values will throw LockNotGrantedException instead of DeadlockException.

If true, Berkeley DB will not write or synchronously flush the log on transaction commit.

If true and a lock is unavailable for any Berkeley DB operation performed in the context of a transaction, cause the operation to throw DeadlockException (or LockNotGrantedException if configured with TimeNotGranted).

If true, all transactions in the environment will be started as if Snapshot was passed to BeginTransaction()()(), and all non-transactional cursors will be opened as if SnapshotIsolation was passed to Cursor()()().

A value, in microseconds, representing transaction timeouts.

The recovery timestamp

If true, Berkeley DB will write, but will not synchronously flush, the log on transaction commit.

The Berkeley DB process' environment may be permitted to specify information to be used when naming files; see Berkeley DB File Naming in the Programmer's Reference Guide for more information.

If true, all databases in the environment will be opened as if UseMVCC was set.

If true, locking for the Berkeley DB Concurrent Data Store product was initialized.

If true, the locking subsystem was initialized.

If true, the logging subsystem was initialized.

If true, the shared memory buffer pool subsystem was initialized.

If true, the replication subsystem was initialized.

If true, the transaction subsystem was initialized.

Specific additional informational and debugging messages in the Berkeley DB message output.

If true, Berkeley DB will yield the processor immediately after each page or mutex acquisition.