Contents:

• Security
• Performance
• Replication
• Configuration changes
• Other changes

Security

• 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 "GroupReadAccess" to enable read access on forward-log files for the group (GID) specified in the database server configuration file.

  Find more info on this new option in the section on config changes.

• 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.

Performance

• The dbctl dbrestore operation was enhanced to support the /nice command line option. This should result in better performance for concurrent processes while a dbrestore is ongoing, at the cost of slowing down the dbrestore.

• 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, internal data set meta information was updated to reflect the new first or last record in the set. The implementation was modified so that the first/last record meta information, as well as updating this information during DBDELETE, is no longer needed.

• Improved dbctl 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 eloqdb6 server was changed to bypass the index transaction logic during bimport to improve database load time.

• The lock scheduler was revised to enhance scalability and performance with a large number of competing locks.

• The server process was enhanced to use a more efficient format to record index and meta data changes. This enhancement may result in a substantial reduction in disk space for the forward-log files when index entries are changed frequently.

• The internal locking strategy was revised to allow for additional concurrency. This specifically improves performance in cases of a cache miss in the database server cache.

Replication

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

User visible changes related to replication:

• The configuration options "Role", "RedirectWrite", "IgnoreWrite" and "TmpDir" have been added to the new [Replication] section. The supplied template configuration file was updated accordingly.

  Find more info on these new options in the section on config changes.

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

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

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

• The dbctl replication status output was modified.

  On a replication slave, it is now displayed in addition whether the replication is active (i.e. the dbrepl process is connected) or not.

  Please note: If you use external utilities that process the dbctl replication status output it may be necessary to adapt them to the new output format.

• The STOP argument was added to the dbctl replication command on a replication slave:

  dbctl -u dba replication stop

  This disconnects the dbrepl process from the slave server.

Configuration Changes

The following configuration changes apply to the B.07.10 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.

[forwardlog]
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.

Other changes

• Enhanced the dbctl dbstore/dbrestore operations to support canceling the operation. If the dbctl session is terminated the dbstore/dbrestore operation will now terminate as well.

  A message as below is logged by the server:

  Session was terminated - database not stored
  Session was terminated - database not restored

• 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 [Config] 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
  

  Also see the section on config changes for info on TransactionSizeLimit.

• 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 eloqdb6 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 compatibility issue with the Linux glibc2.4 (and newer) was corrected. The Linux glibc 2.4 library introduced a (deliberate) incompatibility that was causing the eloqdb6 server process to crash.

• The message indicating a previous unclean shutdown was recovered is now written to the server log (at all log levels).