contact contact

B.08.00 / Release Notes / Changes / Database Server

Database Server

  This document provides a list of enhancements and user visible changes in Eloquence B.08.00, relative to the original B.07.10 release.



An improved threading architecture allows the database server to make better use of all available CPU resources.
As of Eloquence B.08.00 the database server was changed to take advantage of the OS provided threading capabilities. Previous server versions used an Eloquence specific threading implementation.

In addition to changing the internal threads implementation, the server internal locking of resources was changed to improve performance on contemporary hardware, that typically has more but often not faster CPU cores. Internal locking got more fine grained and optimized to not block concurrent operations and internal limitations were removed.

The database server is available as 32 bit and 64 bit versions. Where appropriate, both versions are included and either version may be used. A 64 bit server version, while not necessarily faster by its own, allows to overcome address space limitations and may reduce system administration related to this.

User visible changes include:

  • The Eloquence database server uses OS level threads. Consequently, some thread related kernel parameters may need to be changed appropriately.

  • Due to the use of OS level threads and locking procedures, the Eloquence B.08.00 database server has additional memory requirements. This includes the larger stack space (per thread) as well as increased internal data structures. Consequently, some larger configurations may require the use of the 64 bit server and the maximum allowable memory limit in the kernel may need to be adapted.

  • The 64 bit database server is no longer subject to address space limitations. When running the 64 bit server environment on HP-UX, planning on the use of mappable address space and use of memory windows is no longer required.


The database server was enhanced to support replication of database environments. Please refer to the Eloquence database replication documentation for detailed information.

The Eloquence replication functionality is not specific to a database but performs a replication of all changes to a database environment. It does not perform regular database calls but replicates transaction results.

Replication is unidirectional and performed asynchronously. It is typically close to real-time, if allowed by server performance and connection bandwidth. On the master server, committed transactions are saved in Eloquence forward-log files. The dbrepl replication utility is used to transfer and apply committed transactions from the master to any replicated servers ("slave servers"). On the slave server(s), the databases are available for access in read-only mode. If configured, a DBOPEN in write mode may be redirected to the master server.

User visible changes related to replication:

  • The dbrepl utility is used to replicate committed transactions from the master to one or more slave servers.

  • To use the Eloquence replication functionality, purchase of the replication option and a separate license key is required for each slave server.

  • The [Replication] Role config item may be used to specify the role of a database server. A server process may either function in a Standalone (the default), Master or Slave role.

  • The [Replication] RedirectWrite IgnoreWrite config items may be used on a slave server to define how to handle database opens in write mode. By default they are rejected and fail with a nonzero status. However, they may also be redirected the the master server or (silently) limited to read-only access.

  • The dbctl replication command may be used an a slave server to stop the currently active dbrepl session:
    dbctl -u dba replication stop
    This disconnects the dbrepl process from the slave server.

  • The dbctl replication status command may be used to obtain information on the current replication status.


  • Forward-log files are now created with restrictive file permissions. By default only the user account configured to run the database server may access these files.

    The database server was enhanced to support a new configuration option to enable read access on forward-log files for the group (GID) specified in the database server configuration file.

    Find details on this new "GroupReadAccess" option in the next section.

  • The dbctl logfile command no longer accepts existing files.

  • The builtin dbstore function (dbctl dbstore) was enhanced to create the store archive using more restrictive permissions, which limit access to the account running the db server process.

  • If the server process is started by the root user, ownership of a log file created during the server startup is changed to the user that is configured to run the database.

Configuration Changes

The following configuration changes apply to the B.08.00 database server. Updating the configuration file is recommended but optional as previous configuration files are still accepted.

[Server] StatFile, StatFileFlags
These config items define the logging of server (global) performance information. StatFile specifies the log file and StatFileFlags the format of the information. For detailed description, please refer to the Database server statistics documentation.

[Server] SessionStatFile, SessionStatMode
These config items define the logging of session (application process) specific performance information. SessionStatFile specifies the log file and SessionStatMode enables logging the information. For detailed description, please refer to the Database server statistics documentation.

[Replication] Role
The Replication.Role configuration item defines the role of this server. If not specified, it defaults to Standalone. If set to Master, this specifies a master server. If set to Slave, this specifies a slave server. Role must be set to Slave for a replicated server. If configured as a slave server, any write attempt is rejected (unless RedirectWrite or IgnoreWrite options are used) and the replication is enabled.

For detailed description, please refer to the Database server replication documentation.

[Replication] RedirectWrite
The RedirectWrite configuration item is effective on a slave server and may be used to specify the corresponding master server for a slave server. It specifies the server name or IP address and service name or port number, separated by a colon. If RedirectWrite is defined on a slave server, some DBOPEN modes (modes 1, 3, and 4) are transparently redirected to the specified server (this will also add a note to the log file).

For detailed description, please refer to the Database server replication documentation.

[Replication] IgnoreWrite
The IgnoreWrite configuration item is effective on a slave server. If set, opening a database in write mode on a slave server is accepted but internally converted into a read-only open mode. This way, an application program that opens a database in write mode but only performs read operations may also run on a slave server. Please note: If IgnoreWrite is set, RedirectWrite is implicitly disabled.

For detailed description, please refer to the Database server replication documentation.

[Replication] TmpDir
The TmpDir configuration item is effective on a slave server and may be used to specify a temporary directory that is used as a scratch storage for collecting and processing partial transaction information. It needs to provide sufficient disk space to hold the size of the largest transaction. It defaults to the /tmp directory.

For detailed description, please refer to the Database server replication documentation.

[forwardlog] GroupReadAccess
By default the database server creates any forward-log files with restrictive permissions to only allow the configured user account (and the superuser) to access the forward-log files.

The [forwardlog] GroupReadAccess configuration option may be used to specify read access for the configured group to the forward-log files.

GroupReadAccess = 0|1
If set to a nonzero value, forward-log files are created with a permission that allows group read access (configured with the [Server] GID option). If set to zero, forward log files are created with a permission to restrict access to the owner (configured with the [Server] UID option).

The default value is 0 to permit owner access only.

[Config] TransactionSizeLimit
This config item may be used to configure a "soft limit" for the size of database transactions. It is defined as below:
  • If set to zero, the transaction size is not limited (the internal "hard limit" applies)
  • If set to -1 (the default), the size limit is set to a default value which depends on the configured log volume space.
  • Otherwise, the value specifies the maximum transaction size in MB.

[Config] IOThreads
The IOThreads config item is no longer used in B.08.00 and its value is ignored.

Other changes

  • The Database Locks HTTP status page now outputs a summary on the total number of granted and blocked locks.

  • Added the dbrestore /nice option. When set, the forward-log is pre-synchronized to disk after a chunk of data has been written. In case of high disk i/o load, this should reduce contention on the operating system buffer cache.

  • Database restructuring was changed to include additional progress information in the log file. For each completed step a message is logged. In addition, a progress message is logged every 10 minutes (subject to the LogFlags setting). Messages like below are output to the server log:
    restructuring data set 'ARTIKEL': 49760 records processed
    rebuilding indexes for data set 'ARTIKEL': 76024 records processed
    relinking detail data set 'BUCHUNG' paths: 1094500 records processed

  • Added the option to limit database transaction sizes. Two size limits are implemented: A configurable "softlimit" and an internal "hardlimit". The minimum of either value defines the maximum size an uncommitted transaction may have.

    The internal "hardlimit" is determined by the half of the configured log space and subtracting the configured checkpoint size: configured log space / 2 - configured checkpt size.

    The "softlimit" is configurable with the new TransactionSizeLimit config item. By default it is set to half the size of the internal hardlimit.

    For example, assuming a size limit of 1 GB for the log volume and a checkpt size of 50 MB the hardlimit would be 450 MB and the default softlimit would be 225 MB.

    Once the size of an uncommitted transaction reaches or exceeds the limit, a status -801:28 is returned. The only valid options at this point are to commit or rollback the transaction. If the status -801:28 is returned by the DBCOMMIT call, the only valid option is to rollback the transaction.

    A message like below is logged to the server log: Transaction size limit exceeded, size: xxx pages, limit: xxx pages

  • The [Config] TransactionSizeLimit config item may be used to configure a size limit for database transactions. It is defined as below:

    This configuration item may be used to limit the maximum size of a database transaction in MB. If set to zero, the transaction size is not limited. If set to -1 (the default), the size limit is set to a default value which depends on the configured log volume space. The default value is -1.

  • The item format flags in the node schema audit record was enhanced to indicate the role of an item as below:
    • Bit 16 (0x10000) is set if the item is a search item.
    • Bit 18 (0x40000) is set if the item is a unique key. Currently, this indicates it is a master search item.
    • Bit 19 (0x80000) is set if the item is a sort item.

  • The DBLOCK-COMPAT database property may be used to modify the locking policy for a database. This may be used to specify an IMAGE compatible lock behavior for a database.

    If set to 1, a DBLOCK is required for writing to the database. This matches the TurboIMAGE behavior. If undefined or set to 0, writing to a database does not require a previous DBLOCK (but no competing lock may be granted). This is the default behavior of Eloquence.

    This db property may be changed with dbutil, either interactively or using a script as below:

    database "SAMPLE";
    create property "DBLOCK-COMPAT" value "1";

  • A forward-log is now retained across a crash of the database server.

    If the server process terminates abnormally, a subsequent server start or use of the dblogreset utility performs a startup recovery.

    Previous releases disabled an existing forward-log in such a situation so that it became necessary to create a new backup.

    The eloqdb startup recovery and the dblogreset utility have been enhanced to reliably continue the forward-log after a server crash. Please note that audit information are not retained for any recovered transactions. The fwaudit utility outputs a warning message when it discovers this situation.

  • The template config file for the database server was updated. This version adds the new config options provided with this server release and corrects some mistakes in the inline comment.

  • The [ForwardLog] EnableAudit and AuditOnly configuration values were added to the HTTP status display.

  • Session statistics were enhanced to separate regular DBGET calls from "DBGETB" multiple record fetches (using client side caching).

  • A problem in DBDELETE was fixed that could in some cases result in a noticeable delay. This delay could affect concurrent database sessions during write operations (DBPUT/DBUPDATE/DBDELETE) on the same data set.

    During DBDELETE, if the first or last record is deleted in a data set, the data set meta information was updated to reflect the new first or last record in the set. However, if there is a significant number of deleted records in the set that must be traversed to locate the new first or last record, this might take some time, subject to caching.

    The implementation was modified so that the first/last record meta information, as well as updating this information during DBDELETE, is no longer needed. This was achieved in a way that the data remains backwards-compatible with previous eloqdb6 versions.

  • Improve bimport performance on master sets.

    The bimport performance for master sets is often dominated by creating the associated index. This may also apply to detail sets when an additional index is used. The eloqdb server was changed to bypass the index transaction logic during bimport to improve database load time.

  • The "dbctl list session" command no longer hides the own dbctl session.

  Privacy | Webmaster | Terms of use | Impressum Revision:  2010-02-12  
  Copyright © 2008 Marxmeier Software AG