| |
This document provides a list of enhancements and user visible changes
in Eloquence B.08.00, relative to the original B.07.10 release.
Contents:
Scalability
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.
Replication
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:
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 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.
[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.
-
[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.
|
|
