|
This document provides a list of enhancements and user visible changes
in Eloquence patch bundle PE71-B100209, relative to the original B.07.10 release.
Contents:
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.
-
The "dbctl forwardlog status" command no longer requires dba privileges.
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).
-
When a dbutil ADD ITEM data set clause is used to add an item
of type P (packed) to a data set, the subsequent restructuring
process now initializes this new P item to unsigned zero.
Previously, a new P item was initialized to binary zero.
-
The "dbctl list session" command no longer hides the own dbctl session.
-
Improved database compatibility checks on DBOPEN have been implemented
to prevent opening incompatible databases from newer Eloquence versions.
|
|