----------------------------------------------------------------------
ELOQUENCE B.07.10 - patch PE71-0904060
----------------------------------------------------------------------
This patch adds enhancements or fixes defects of the eloqdb6 server
program as released with Eloquence B.07.10. This patch will be
integrated in the Eloquence B.07.10 release.
Eloquence B.07.10 must be installed before applying this patch.
Severity:
PE71-0904060: BUG FIX
Superseded patches:
PE71-0903030: BUG FIX
PE71-0811250: BUG FIX
PE71-0809150: BUG FIX, ENHANCEMENT
PE71-0807210: ENHANCEMENT
PE71-0807010: BUG FIX
PE71-0805070: BUG FIX
PE71-0803070: BUG FIX, ENHANCEMENT
PE71-0802120: BUG FIX, ENHANCEMENT
PE71-0801240: ENHANCEMENT, BUG FIX
PE71-0709050: BUG FIX
PE71-0708130: BUG FIX
PE71-0708030: BUG FIX
PE71-0707310: ENHANCEMENT, BUG FIX
PE71-0707200: ENHANCEMENT, BUG FIX
PE71-0705300: ENHANCEMENT
PE71-0704110: BUG FIX, ENHANCEMENT
PE71-0702080: BUG FIX
PE71-0610130: BUG FIX
PE71-0609270: BUG FIX
PE71-0609120: BUG FIX
PE71-0608110: ENHANCEMENT
PE71-0607210: BUG FIX
PE71-0607100: ENHANCEMENT
PE71-0606290: BUG FIX
PE71-0603280: BUG FIX
PE71-0603100: ENHANCEMENT
PE71-0602280: ENHANCEMENT, BUG FIX
For additional information on the replication functionality
please refer to the Eloquence web site:
http://eloquence.marxmeier.com/support/B0710/doc/repl/
Patch PE71-0904060
------------------
Platforms: All
* Fixed a problem where a database was not immediately available
after a dbutil restructuring (#3751). A subsequent DBOPEN executed
immediately after a restructuring dbutil process had finished could
in some cases encounter a database status -2 (database in use).
* Resuming a replication or recovery could in rare cases abort with
a message like below (#3752):
Assertion failed: Fwr_PageHashAdd() failed: key already present
server panic: Aborting on internal failure, file volfwr.c, line 5367
This could happen in a corner case if a user transaction spans
multiple forward-log files, where BTREE PAGE actions are present
in different files at identical offsets. Under these conditions
the problem could be triggered if these files had to be processed
to locate the last status of the replication progress.
* Resuming a replication or recovery could in rare cases abort with
a message like below (#3755):
recovery failed ... node ... page ... not in expected state
Assertion failed: h->lower == data->lower
server panic: Aborting on internal failure, file btree.c, line 2382
This could happen in a corner case if a user transaction spans
multiple forward-log files, where the transaction was executed
immediately after the last status of the replication progress
was found and the replication was resumed.
* In a rare corner case, a dbutil RENAME DATABASE operation could
cause the database server to abort with a message like below (#3704):
Assertion failed: SysCat_LinkAddrEquals ...
server panic: Aborting on internal failure, file syscat.c, line 1922
* Changed the Windows file version to "7.1.1.32"
Notes / Related patches:
- The following related patches (or superseding) should be installed
with this patch:
- PE71-0801241 - dblogreset utility
- PE71-0809151 - dbrecover utility
- PE71-0807030 - fwaudit utility
- PE71-0809152 - dbfsck utility
- To use replication functions, the following related patches (or
superseding) need to be installed in addition:
- PE71-0903300 - dbrepl
- PE71-0705304 - chklic
- PE71-0705305 - dbvolextend
- PE71-0705306 - dbvolchange
- PE71-0804170 - dbcfix
Patch PE71-0903030
------------------
Platforms: All
* In rare cases, a malformed client request or an incomplete tcp/ip
network packet could cause the eloqdb6 to abort with a message
like below:
Assertion failed: size != 0
Aborting on internal failure, file buffer.c, line 777
* If forward-logging was manually disabled and later enabled again
it could happen that btree index actions were missing from the
forward-log (#3694).
If a user transaction was started while forward-logging was
disabled but this transaction was then committed after enabling
forward-logging, those btree index actions that were executed
while forward-logging was disabled could be missing from the
forward-log.
As a consequence, a recovery or replication from this forward-log
would fail, for example with a message like below:
recovery failed in action ... page ... not in expected state
server panic: Fatal problem detected in btree_FWR__verify_page
Assertion failed: h->lower == data->lower
* The "dbctl forwardlog status" command does no longer require dba
privileges.
Platforms: Windows
* In the HTTP status display, a default VolumeFileSizeLimit = 0
is now correctly displayed as "unlimited (128 GB)".
* Changed the Windows file version to "7.1.1.31"
Notes / Related patches:
- The following related patches (or superseding) should be installed
with this patch:
- PE71-0801241 - dblogreset utility
- PE71-0809151 - dbrecover utility
- PE71-0807030 - fwaudit utility
- PE71-0809152 - dbfsck utility
- To use replication functions, the following related patches (or
superseding) need to be installed in addition:
- PE71-0705303 - dbrepl
- PE71-0705304 - chklic
- PE71-0705305 - dbvolextend
- PE71-0705306 - dbvolchange
- PE71-0804170 - dbcfix
Patch PE71-0811250
------------------
Platforms: All
* A DBGET mode 6 or 16 on an index item could improperly return an
end-of-chain condition when the last key in the index was deleted
(#3683).
* The database server could refuse to start due to an inconsistent
volume generation count after a startup recovery was aborted while
recovering from on-line backup mode (#3676).
* Executing "dbctl backup start" or "dbctl forwardlog restart" could
result in a corrupted transaction journal if the execution of the
dbctl command encountered a server panic for any reason (#3677).
* A missing newline in the "dbctl replication stop" output was fixed
(#3674).
* Changed the Windows file version to "7.1.1.30"
Notes / Related patches:
- The following related patches (or superseding) should be installed
with this patch:
- PE71-0801241 - dblogreset utility
- PE71-0809151 - dbrecover utility
- PE71-0807030 - fwaudit utility
- PE71-0809152 - dbfsck utility
- To use replication functions, the following related patches (or
superseding) need to be installed in addition:
- PE71-0705303 - dbrepl
- PE71-0705304 - chklic
- PE71-0705305 - dbvolextend
- PE71-0705306 - dbvolchange
- PE71-0804170 - dbcfix
Patch PE71-0809150
------------------
Platforms: All
* In rare cases the eloqdb6 could abort with a message like below
during a DBGET operation on an index item (#3540):
Assertion failed: session->node_cnt == 0
Aborting on internal failure, file runutil.c, line 228
If a cache-miss is encountered during a DBDELETE commit phase a
concurrently running DBGET could detect an inconsistency between
indexes and data. The DBGET would then internally repeat the index
access, which could cause the eloqdb6 to abort because the data set
reference was not correctly reset before repeating the access.
This problem was introduced with patch PE71-0803070.
* The [Replication] IgnoreWrite configuration item was added (#3604).
If set, opening a database in write mode on a replication slave
server is granted but internally converted into a read-only open
mode.
This way, a program that opens a database in write mode but then
only performs read operations may run on a replication slave server.
* Fixed a problem where in rare cases the eloqdb6 could abort with a
message like below when stopping on-line backup mode (#3637):
Assertion failed: !extend_list
Aborting on internal failure, file volredir.c, line 609
Restarting the eloqdb6 should resolve this problem. The eloqdb6
should then recover from on-line backup mode and resume normal
operation.
* Fixed a problem where in rare cases a forward recovery (dbrecover)
or database replication could fail due to a wrong order of actions
in the forward-log (#3634).
When erasing or purging a database or restructuring a database with
dbutil a checkpoint operation could result in a wrong order of
operations in the forward-log. This could result in data corruption
during forward recovery or replication.
If this problem is encountered on a replicated slave server the
slave server must be rebuilt from the master server volume files.
When encountered during dbrecover, recovery must be restarted
from the last backup after installing a corrected dbrecover
binary (restarting dbrecover will not work).
* Fixed a problem where a replication slave server could fail to
resume replication after a crash of the master server (#3642).
The replication could fail with a message like below returned by
dbrepl:
ERROR: replication failed, see slave server log for details
dbrepl: Server replication call failed: REPL 1 [-810:1]
A message like below was written to the slave server log:
replication header sequence mismatch (...)
The problem could occur if the dbrepl process was stopped after the
master server crashed. The slave server could then fail to resume
replication after the master was restarted because an internal state
was not correctly maintained in this situation.
The problem can be resolved by installing a corrected eloqdb6
binary on the slave server. The slave server should then correctly
resume replication.
* A message like below could be logged on a repliction slave server
while a dbutil database restructuring is replicated (#3645):
idb__repl_callback: entry not found (...)
There is no problem involved with this message.
* Changed the Windows file version to "7.1.1.29"
Notes / Related patches:
- The following related patches (or superseding) should be installed
with this patch:
- PE71-0801241 - dblogreset utility
- PE71-0809151 - dbrecover utility
- PE71-0807030 - fwaudit utility
- PE71-0809152 - dbfsck utility
- To use replication functions, the following related patches (or
superseding) need to be installed in addition:
- PE71-0705303 - dbrepl
- PE71-0705304 - chklic
- PE71-0705305 - dbvolextend
- PE71-0705306 - dbvolchange
- PE71-0804170 - dbcfix
Patch PE71-0807210
------------------
Platforms: All
* The dbrestore operation was enhanced to no longer block concurrent
tasks while data is written to the volume files.
* The dbrestore /nice option was enhanced to periodically synchronize
the forward-log to disk after some data has been written.
In case of high disk i/o load, this should reduce contention on the
operating system buffer cache and performance of concurrent tasks.
* Changed the Windows file version to "7.1.1.28"
Notes / Related patches:
- The following related patches (or superseding) should be installed
with this patch:
- PE71-0801241 - dblogreset utility
- PE71-0805071 - dbrecover utility
- PE71-0803041 - fwaudit utility
- PE71-0802121 - dbfsck utility
- To use replication functions, the following related patches (or
superseding) need to be installed in addition:
- PE71-0705303 - dbrepl
- PE71-0705304 - chklic
- PE71-0705305 - dbvolextend
- PE71-0705306 - dbvolchange
- PE71-0804170 - dbcfix
Patch PE71-0807010
------------------
Platforms: All
* A potential problem was fixed that could in rare cases result in
an internal deadlock condition under high load when concurrently
updating a btree index (#3599).
When splitting or deleting a page in a btree index a lock to a
related page was not obtained correctly and could cause a deadlock
with a commit operation of a concurrent session.
Platforms: Linux
* A potential corruption of an internal memory area was fixed which
could happen on multi-CPU Linux installations while starting the
eloqdb6 server (#3075).
This could cause the eloqdb6 to hang or crash during startup. Also,
in some cases, if the eloqdb6 started correctly it could later abort
with a panic message indicating a data corruption, for example:
Assertion failed: Pool_TestFlag(Pool_BLOCKUSED, &header)
Assertion failed: Node_GetItemPageReadOnly() failed: file is corrupt
Assertion failed: flag_byte == FixRec_DELETED
However, real data corruption did not occur. Restarting the eloqdb6
resolved the problem.
* A similar corruption with similar symptoms and consequences could
happen when running the eloqdb6 server with a D2 or D3 log flag,
for example LogFlags=*2 or LogFlags=*1D2 (#3075).
Platforms: Windows
* Changed the Windows file version to "7.1.1.27"
Notes / Related patches:
- The following related patches (or superseding) should be installed
with this patch:
- PE71-0801241 - dblogreset utility
- PE71-0805071 - dbrecover utility
- PE71-0803041 - fwaudit utility
- PE71-0802121 - dbfsck utility
- To use replication functions, the following related patches (or
superseding) need to be installed in addition:
- PE71-0705303 - dbrepl
- PE71-0705304 - chklic
- PE71-0705305 - dbvolextend
- PE71-0705306 - dbvolchange
- PE71-0804170 - dbcfix
Patch PE71-0805070
------------------
* Fixed a problem affecting a replicated slave server or recovery
with dbrecover which in rare cases could cause a panic with a
message like below (#3568):
Assertion failed: h->lower == data->lower
Aborting on internal failure, file btree.c, line 1866
The line number may differ. Besides the "lower" element, the failed
assertion may also apply to the "prevpg" or "nextpg" or "upper" or
"flags" elements.
This could happen when replication was stopped and later resumed
or when performing an incremental recovery with dbrecover.
If replication or recovery is restarted it needs to continue at the
exact point it left off previously. The last checkpoint is recorded
in the volume file. However, any changes beyond the last checkpoint
need to be verified if they were previously applied.
If similar actions affecting specific btree changes are found the
replication or recovery could fail to correctly locate the
point-of-resume in the forward log. This could happen, for example,
on multiple DBDELETE / DBPUT sequences affecting an index in a way
that the same btree page was modified identically multiple times.
The implementation was changed to maintain additional information
in the volume files on the replicated slave server or during
recovery to correctly identify the last change applied.
If this problem is encountered on a replicated slave server the
slave server must be rebuilt from the master server volume files.
When encountered during dbrecover, recovery must be restarted
from the last backup after installing a corrected dbrecover
binary (restarting dbrecover will not work).
* Fixed a potential page leak in the log volume when a replication
was stopped and later resumed.
* In some cases a replication master server did not correctly update
the recovery status in the root volume file.
This could have the effect that a subsequent dbrecover would then
assume a previously incomplete recovery and unnecessarily require
a previous forward log file to be present.
For example, an on-line backup is performed. This starts a new
forward log generation. If these volume files are later used in a
recovery, dbrecover applies forward log files from the generation
started with the backup. However, as the recovery status was not
correctly updated, it would instead expect the previous generation
(and just skip it).
This could only happen if the eloqdb6 is configured as replication
master server, not in standalone mode (default).
* In rare cases DBFIND or DBGET on index items could return the
status -804 (#3590).
An internal index cursor invalidation could happen if an index
traversal was interrupted by a concurrent commit or rollback
on the same index. Under rare conditions this could result in an
unexpected index cursor state and status -804 was returned to
the application.
* Fixed a problem with DBGET mode 5 or 6 on index items using packed
decimal (P) or zoned decimal (Z) item types (#3574). This could have
the effect that an improper end-of-chain condition could be returned
to the application in some cases.
With P or Z items, identical values may have a different binary
representation. For example, the values 42 (unsigned) and +42
(positive) have the same numeric value but differ in their binary
representation.
Eloquence compares these items by their value, regardless of the
binary representation. For example, when a P or Z item is used as
search item, the values 42 (unsigned) and +42 (positive) use the
same chain, they are considered identical.
However, using DBGET mode 5 or 6 with a P or Z index item behaved
differently. Although the underlying index correctly locates the
entry by its value, a binary comparison was used on the result,
causing an improper end-of-chain condition if a key value did not
match the search argument in the binary comparison.
* Changed the Windows file version to "7.1.1.26"
Notes / Related patches:
- The following related patches (or superseding) should be installed
with this patch:
- PE71-0801241 - dblogreset utility
- PE71-0805071 - dbrecover utility
- PE71-0803041 - fwaudit utility
- PE71-0802121 - dbfsck utility
- To use replication functions, the following related patches (or
superseding) need to be installed in addition:
- PE71-0705303 - dbrepl
- PE71-0705304 - chklic
- PE71-0705305 - dbvolextend
- PE71-0705306 - dbvolchange
- PE71-0804170 - dbcfix
Patch PE71-0803070
------------------
* Fixed a problem affecting a replicated slave server or recovery
with dbrecover which in rare cases could cause a panic with a
message like below (#3552):
Assertion failed: h->pgno == data->pgno
Aborting on internal failure, file btree.c, line 1808
This problem was caused by a defect in the btree recovery code
that could result in a corrupted index page if a btree root page
was split for the first time and the page was previously not in
the buffer cache.
If this problem is encountered on a replicated slave server the
slave server must be rebuilt from the master server volume files.
When encountered during dbrecover, recovery must be restarted
from the last backup after installing a corrected dbrecover
binary (restarting dbrecover will not work).
* The builtin dbstore function (dbctl dbstore) was enhanced to
create the store archive using more restrictive permissions
(#3544).
The builtin dbstore function now restricts access to the account
running the db server process.
* Fixed a problem which could result in unexpected "protocol
failure" and -700:-6 error messages in dbrepl.
In some cases a replication slave server process prematurely
closed the connection of the dbrepl utility when encountering
a problem. This could have the effect that the actual error
message was lost and a generic error message was output.
* In rare cases a DBGET could return the status -803:258 (#3540).
A potential race condition was identified that could result in
DBGET returning status -803:258 in rare cases. If a cache-miss
is encountered during a DBDELETE commit phase a concurrently
running DBGET could detect an inconsistency between indexes and
data and return an unexpected status code.
* On a replication slave the forward-log file permissions were not
correctly set and the [forwardlog] GroupReadAccess configuration
option had no effect (#3548).
* Changed the Windows file version to "7.1.1.25"
Notes / Related patches:
- The following related patches (or superseding) should be installed
with this patch:
- PE71-0801241 - dblogreset utility
- PE71-0803071 - dbrecover utility
- PE71-0803041 - fwaudit utility
- PE71-0802121 - dbfsck utility
- To use replication functions, the following related patches (or
superseding) need to be installed in addition:
- PE71-0705303 - dbrepl
- PE71-0705304 - chklic
- PE71-0705305 - dbvolextend
- PE71-0705306 - dbvolchange
- PE71-0801245 - dbcfix
Patch PE71-0802120
------------------
* A problem in DBDELETE was fixed that could in some cases result
in a noticeable delay (#3524). 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.
Please note: If a previous dbfsck utility is used it may report
first/last record meta data inconsistencies. Please consider
installing patch PE71-0802121 which provides a new dbfsck version
where the first/last record check is relaxed, according to the way
the new database server implementation handles the first/last
record meta information.
* Fixed a problem on creating a case insensitive index (#1073).
A case insensitive index being created using the previous patch
PE71-0801240 may have inconsistencies so that not all key values
can be located in the index.
As this correction affects new functionality introduced with the
previous patch PE71-0801240, no existing database should be
affected by this problem. However, if a case insensitive index was
created with the previous version it should be re-created (deleted
and then added again) using the dbutil program.
* The STOP argument was added to the dbctl replication command on a
replication slave (#3523):
dbctl -u dba replication stop
This disconnects the dbrepl process from the slave server.
* The dbctl replication status output was modified (#3523).
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.
* Fixed a problem where a configured StatFile was truncated during
database server startup although StatFileFlags included the "a"
(append) flag (#3536).
* Changed the Windows file version to "7.1.1.24"
Notes / Related patches:
- The following related patches (or superseding) should be installed
with this patch:
- PE71-0801241 - dblogreset utility
- PE71-0801242 - dbrecover utility
- PE71-0801243 - fwaudit utility
- PE71-0802121 - dbfsck utility
- To use replication functions, the following related patches (or
superseding) need to be installed in addition:
- PE71-0705303 - dbrepl
- PE71-0705304 - chklic
- PE71-0705305 - dbvolextend
- PE71-0705306 - dbvolchange
- PE71-0801245 - dbcfix
Patch PE71-0801240
------------------
Platforms: All
* The database server was enhanced to support case insensitive
indexes (#1073). When specified for an index, key comparison
on strings is performed in a case insensitive manner.
* Fixed a potential TurboIMAGE compatibility problem (#3502).
A TurboIMAGE DBGET call that fails with a status code may
return the current record number in the status array.
The database server was modified to return the current record
number in case a DBGET call fails with a status code.
* Fixed a problem during incremental recovery or replication
(#3515). An incremental dbrecover or replication could in
rare cases fail with a message like below:
Assertion failed: offset == data->offset
Aborting on internal failure, file btree.c, line 2342
This was caused by an already modified btree page not being
skipped during the sychronization phase of an incremental
dbrecover or replication.
In case this problem is encountered, the incremental dbrecover
or replication will correctly continue after this patch is
installed.
* The internal SCAN_REC function was enhanced to gracefully
handle a BOF status and to output a detailed log message
in case of a failure.
* Fixed a corner case problem in btree error handling (#3052).
If a btree page split fails due to lack of disk space a cache
page might not be properly released. This may result in a
subsequent server panic with a message like below:
buf_Sync: PIN LEAK detected. bhp=40329c58, node=#116
Assertion failed: !(bhp->flags & BUF_PINNED)
Aborting on internal failure, file mpool.c, line 926
* Fixed a problem in the volume file extension procedure that
could result in growing a volume file infinitely until the
disk space is exhausted (#3481).
This could happen if the volume file size is limited below the
current size by changing the VolumeFileSizeLimit config item
to a value below the size of existing volume files.
Platforms: HP-UX and Linux
* 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 (#3475).
By default the database server creates any forward-log files with
restrictive permissions that only allow the configured user (and
the superuser) to access the forward-log files.
The new [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.
Platforms: Windows
* Changed the Windows file version to "7.1.1.23"
Notes / Related patches:
- The following related patches (or superseding) should be installed
with this patch:
- PE71-0801241 - dblogreset utility
- PE71-0801242 - dbrecover utility
- PE71-0801243 - fwaudit utility
- To use replication functions, the following related patches (or
superseding) need to be installed in addition:
- PE71-0705303 - dbrepl
- PE71-0705304 - chklic
- PE71-0705305 - dbvolextend
- PE71-0705306 - dbvolchange
- PE71-0705307 - dbfsck
- PE71-0801245 - dbcfix
Patch PE71-0709050
------------------
Platforms: All
* Fixed a problem with DBFIND modes 6 and 7 with arguments using
wildcards (#3429). These DBFIND modes are used internally by the
TurboIMAGE compatibility library (image3k library) to implement
TPI and index access.
This problem was introduced in the previous patch PE71-0708130.
Platforms: Windows
* Changed the Windows file version to "7.1.1.22"
Notes / Related patches:
- The following related patches (or superseding) should be installed
with this patch:
- PE71-0705301 - dblogreset utility
- PE71-0708131 - dbrecover utility
- PE71-0705231 - fwaudit utility
- To use replication functions, the following related patches (or
superseding) need to be installed in addition:
- PE71-0705303 - dbrepl
- PE71-0705304 - chklic
- PE71-0705305 - dbvolextend
- PE71-0705306 - dbvolchange
- PE71-0705307 - dbfsck
- PE71-0705308 - dbcfix
Patch PE71-0708130
------------------
Platforms: All
* Fixed a problem that could result in a crash of the server
process during replication or forward-recovery of a database
restructuring with a log message like below (#3444):
Assertion failed: meta->ulist_cache_used
<= (int)node->node.ulist.num_pages
* A TurboIMAGE/SuperDex compatibility problem was solved (#3429).
If the wildcard tokens (?, #, @) were used within a DBFIND search
argument, using the "greater than (or equal)" or "less than (or
equal)" conditions caused the server to return a status 53 (bad
argument). A wildcard search argument could not be used to
evaluate a greater/less comparison.
The implementation was modified to support "greater/less than
(or equal)" conditions on search arguments if leading literal
characters are present in the search argument. In this case,
the leading literal part is used to evaluate a greater/less
comparison.
* A TurboIMAGE/SuperDex compatibility problem was solved (#3000).
After a DBFIND on an index using a "greater than" or "less than"
condition, the DBGET modes 15 or 16 behaved as "greater than or
equal" or "less than or equal", respectively.
Platforms: Windows
* Changed the Windows file version to "7.1.1.21"
Notes / Related patches:
- The following related patches (or superseding) should be installed
with this patch:
- PE71-0705301 - dblogreset utility
- PE71-0708131 - dbrecover utility
- PE71-0705231 - fwaudit utility
- To use replication functions, the following related patches (or
superseding) need to be installed in addition:
- PE71-0705303 - dbrepl
- PE71-0705304 - chklic
- PE71-0705305 - dbvolextend
- PE71-0705306 - dbvolchange
- PE71-0705307 - dbfsck
- PE71-0705308 - dbcfix
Patch PE71-0708030
------------------
Platforms: All
* Fixed a possible internal deadlock condition when purging huge
databases (#3426).
This problem was introduced as a side effect by changing the
checkpoint locking behavior in PE71-0707200.
Platforms: Windows
* Changed the Windows file version to "7.1.1.20"
Notes / Related patches:
- The following related patches (or superseding) should be installed
with this patch:
- PE71-0705301 - dblogreset utility
- PE71-0705302 - dbrecover utility
- PE71-0705231 - fwaudit utility
- To use replication functions, the following related patches (or
superseding) need to be installed in addition:
- PE71-0705303 - dbrepl
- PE71-0705304 - chklic
- PE71-0705305 - dbvolextend
- PE71-0705306 - dbvolchange
- PE71-0705307 - dbfsck
- PE71-0705308 - dbcfix
Patch PE71-0707310
------------------
Platforms: All
* Fixed a problem resulting in dbutil database restructuring to
fail with an error message like below (#3412):
*** Database in use [-2]
FATAL: Fatal problem during schema upload - can't continue
This problem was introduced as a side effect with patch
PE71-0707200 (#3111).
* Enhanced the dbstore/dbrestore operations to support canceling
the operation (#3421). 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
* The dbrestore operation was enhanced to support the /nice command
line option (#3421). This results in better performance for
concurrent processes while a dbrestore is ongoing, at the cost of
slowing down the dbrestore.
The dbstore operation also supports the /nice option but it makes
little difference in practice.
* 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 each 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
Platforms: Windows
* Changed the Windows file version to "7.1.1.19"
Notes / Related patches:
- The following related patches (or superseding) should be installed
with this patch:
- PE71-0705301 - dblogreset utility
- PE71-0705302 - dbrecover utility
- PE71-0705231 - fwaudit utility
- To use replication functions, the following related patches (or
superseding) need to be installed in addition:
- PE71-0705303 - dbrepl
- PE71-0705304 - chklic
- PE71-0705305 - dbvolextend
- PE71-0705306 - dbvolchange
- PE71-0705307 - dbfsck
- PE71-0705308 - dbcfix
Patch PE71-0707200
------------------
Platforms: All
* Added the option to limit database transaction sizes (#3388).
Two size limits are implemented: A configurable "softlimit" and
an internal "hardlimit". The minimum of either value defines the
max. 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 new [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 max. 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.
* Fixed a potential starvation problem of the checkpoint thread.
When a large number of transactions are committed concurrently
the internal checkpoint thread could, in theory, be blocked for
a long time. The internal locking protocol was changed to
escalate the checkpoint lock after some timeout.
* Fixed a problem that could result in a transient index problem
on a replication slave when replication was active. A missing
lock could potentially result in an inconsistent index lookup.
* Fixed a server hang if the DBLOCK-COMPAT database property
was set for a database and [Config] LockConflictingItems was
enabled in the server configuration. This could result in an
endless loop and hang the server process.
* Fixed a problem where a database could be purged after it was
renamed although it was still opened by another session (#3111).
* Fixed a problem that could result in a crash of the server
process if the server log flags were set to output debug and
replication was active.
* 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.
* On the replication slave server, a DBCLOSE could wrongly
resume the replication after a database is closed (#3383).
* If forward-logging is disabled, the server now immediately
stops writing to the forward-log (#3089).
* Disabling forward-logging on the replication slave server
(eg. through dbctl) could result in a server abort due to
an internal inconsistency.
Platforms: Windows
* Changed the Windows file version to "7.1.1.18"
Notes / Related patches:
- The following related patches (or superseding) should be installed
with this patch:
- PE71-0705301 - dblogreset utility
- PE71-0705302 - dbrecover utility
- PE71-0705231 - fwaudit utility
- To use replication functions, the following related patches (or
superseding) need to be installed in addition:
- PE71-0705303 - dbrepl
- PE71-0705304 - chklic
- PE71-0705305 - dbvolextend
- PE71-0705306 - dbvolchange
- PE71-0705307 - dbfsck
- PE71-0705308 - dbcfix
Patch PE71-0705300
------------------
Platforms: All
* This patch adds the option to Eloquence B.07.10 to replicate
database transactions to other database environments.
For documentation please refer to the Eloquence web site:
http://www.marxmeier.com/eloquence/support/B0710/doc/repl/
* 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.
When set to 1, a DBLOCK is required for writing to the database.
When set to 0 (or undefined) 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
note if it discovers this situation.
Platforms: Windows
* Changed the Windows file version to "7.1.1.17"
Notes / Related patches:
- The following related patches (or superseding) should be installed
with this patch:
- PE71-0705301 - dblogreset utility
- PE71-0705302 - dbrecover utility
- PE71-0705231 - fwaudit utility
- To use replication functions, the following related patches (or
superseding) need to be installed in addition:
- PE71-0705303 - dbrepl
- PE71-0705304 - chklic
- PE71-0705305 - dbvolextend
- PE71-0705306 - dbvolchange
- PE71-0705307 - dbfsck
- PE71-0705308 - dbcfix
Patch PE71-0704110
------------------
Platforms: All
* In rare cases, a DBPUT could fail with status -809:976 (#3255).
This is caused by a race condition while the same automatic
master entry is added/deleted concurrently.
* A problem in the client request handling was fixed that could in
some cases result in a slight prioritization of some connections
over others (#3325).
* DBGET mode 4 does not update index position (#3333)
After a DBFIND on an index, a DBGET mode 4 could not be used
to position the current record inside the result.
The index position was not updated by a dbget mode 4.
This was inconsistent with the behavior of image paths and
not compatible with TurboIMAGE/SuperDex behavior.
* The server was modified to solve a compatibility issue with
TurboIMAGE applications (#3247).
TurboIMAGE documents that a DBFIND resets the current record
number for a data set. The Eloquence DBFIND call previously did
not affect the current record number.
This changed DBFIND behavior is enabled if both, this patch and
the corresponsing client library patch PE71-0704100 (or superseding)
is installed. Otherwise the behavior is unchanged.
* The server was enhanced to support additional options for logging
server or individual session performance information. The following
config items are supported:
[server] StatFile
StatFile specifies a file name to be used for logging the server
utilization. If enabled, this file is updated once a minute.
As the file is re-opened each time it is updated it may be
moved/deleted freely.
This config item was introduced with the B.07.10 release. Please
refer to the B.07.10 release notes for details.
User visible change: The config file must specify an absolute
file name. This is consistent with the corresponding dbctl command.
[server] StatFileFlags
StatFileFlags specifies options that influence the StatFile format.
By default (StatFileFlags not set) the file content is replaced
each time it is updated. Also, the content is formatted with
multiple lines, each containing a descriptive text and the actual
value, separated by a colon.
The following flags are supported:
s (single line) causes the values to be formatted into a single
line. Values are separated by a space and no descriptive text is
present.
a (append) causes additional values to be appended to the file
instead of replacing the previous content.
t (local timezone) causes the timestamp to include the offset
of the local timezone from UTC. If not present, the timestamp
value denotes UTC. This flag allows to use the timestamp value
with DSI (MeasureWare) on HP-UX without requiring a conversion.
These flags may be combined (eg. StatFileFlags = sat).
Example output (single line format):
1172193450 6 110 0 441 0 0 1
[server] SessionStatFile
If specified, SessionStatFile is used for logging session
utilization information. Depending on the SessionStatMode
setting, information is logged when a session ends or after
the next database call after the specified interval expires.
This file is opened on the first event and kept open until a
new value is specified with dbctl SessionStatFile or the
SessionStatMode is changed through dbctl.
The config file must specify an absolute path name. This is
consistent with the corresponding dbctl command.
The information logged to SessionStatFile is substantially
similar to session details provided in the HTTP status and
may be used to evaluate performance/behavior of an application
after it has completed.
Every entry in SessionStatFile consists of a single line,
fields are separated by a vertical bar (|) character.
The following information is provided in SessionStatFile:
timestamp - the timestamp (UTC) the entry was added
TID - The id of the database thread
Type - Type of Entry (E or U character), E specifies the entry
was logged when the thread had completed (application
disconnected from the database), U specifies the entry
was logged after the interval specified in SessionStatMode
had expired
OSuser - Operating system account used by the application
DBuser - database login (most recently) used by the application
ConnTime - Connect time (in ISO format YYYY-MM-DD HH:MM:SS)
ConnSec - Number of seconds elapsed since connecting
Stat - Three numerical values for each monitored database
activity (a subset of database activity typically called
from applications). The values specify two counters and
the wall time for the sum of all calls of a category.
The first counter specifies the number of database calls
(from the client library, may be different from application
calls if client side caching is used), the second counter
may specify a count related to the particular call (see below).
The wall time is specified in usec (1 mio per second).
The follwing database activities are monitored
IO_READ - Disk reads accounted to the session.
This includes both reading activity as well as any
disk reads required for writing activity. The count field
specifies the number of IO requests, the count2 field
specifies the number of pages (8K units).
DBFIND - DBFIND calls.
DBGET - DBGET calls (single record).
DBGETB - Multi-record DBGET calls. These are used internally
by the client library if client side caching is used.
The count2 field specifies the number of records obtained.
DBPUT - DBPUT calls
DBUPDATE - DBUPDATE calls
DBDELETE - DBDELETE calls
DBLOCK - DBLOCK calls, count2 specifies the number of
unconditional DBLOCK calls that could not be granted
immediately but were blocked by a competing lock.
DBUNLOCK - DBUNLOCK calls
TXBEGIN - Begin Transaction
TXCOMMIT - Commit Transaction
TXROLLBACK - Transaction Rollback
IP - IP Address and port number (separated by a colon) used
to connect to the database
AppEnv - Information collected from the application environment,
such as process ID, operating system specific user id,
(subset of the) command line, EQ_AUDIT_INFO content
Please Note: The content of the SessionStatFile is subject to
change without notice.
Example output (single line):
1172196823|9|E|mike|public|2007-02-22 16:54:39|4|11|11|751|
0|0|0|0|2|163|45|6|10591|0|0|0|0|0|0|0|0|0|0|1|8879|0|1|6|
0|0|0|0|0|0|0|0|0|127.0.0.1:64169|uid=102 pid=4812 pname=query3k
[server] SessionStatMode
SessionStatMode is a numeric value that specifies when an entry is
logged to the SessionStatFile.
The following values are supported:
0 - (zero) The SessionStatFile is disabled
1 - (one) A log entry is written to the SessionStatFile when
a session ends.
Any other value is understood to specify an interval (in seconds)
after which an entry is logged to the SessionStatFile in addition
to the entry that is logged after the session ends. The specified
value must be at least 60 seconds.
* The server was enhanced to support additional dbctl commands to
allow dynamically changing the logging of performance information.
The following additional dbctl commands were added
dbctl statfile [FileName|DISABLED]
Obtain the current value of [server] StatFile or specify a
new value.
If used without additional file name argument this returns the
current value for [server] StatFile.
When a file name is present, it specifies a new value for
[server] StatFile. If DISABLED is specified, the [server] StatFile
is unconfigured and no longer used. Otherwise an absolute file name
must be specified. The file may not exist. When a file name is
specified dba capabilities are required.
For example:
dbctl statfile
dbctl -u dba statfile /tmp/server.stat
dbctl statfileflags [flags]
Obtain the current value of [server] StatFileFlags or specify
a new value.
If used without additional flags argument this returns the
current value for [server] StatFileFlags.
When a flags argument is present, it specifies a new value for
[server] StatFile. An empty argument may be used to reset the
flags. When a flags argument is specified dba capabilities are
required.
For example:
dbctl statfileflags
dbctl -u dba statfileflags sat
dbctl -u dba statfileflags ""
dbctl sessionstatfile [FileName|DISABLED]
Obtain the current value of [server] SessionStatFile or specify
a new value.
If used without additional file name argument this returns the
current value for [server] SessionStatFile.
When a file name is present, it specifies a new value for
[server] SessionStatFile. If DISABLED is specified, the
[server] SessionStatFile is unconfigured and no longer used.
Otherwise an absolute file name must be specified. The file
may not exist. When a file name is specified dba capabilities
are required.
For example:
dbctl sessionstatfile
dbctl -u dba sessionstatfile /tmp/session.stat
dbctl sessionstatmode [mode]
Obtain the current value of [server] SessionStatMode or specify
a new value.
If used without additional mode argument this returns the
current value for [server] SessionStatMode.
When a mode argument is present, it specifies a new value for
[server] SessionStatMode. When a mode argument is specified
dba capabilities are required.
For example:
dbctl sessionstatmode
dbctl -u dba sessionstatmode 1
* 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.
Platforms: HP-UX
* On HP-UX PA-RISC the listen queue backlog size was increased (#3324)
Due to a build problem a smaller listen queue backlog value was
used on HP-UX PA-RISC. If a large number of new connections is
started concurrently this could, in some cases, cause new
connections to fail temporarily (ETIMEDOUT error returned by connect).
Platforms: Windows
* Changed the Windows file version to "7.1.0.16"
Notes / Related patches:
- The following related patches (or superseding) should be installed
with this patch:
- PE71-0702081 - dblogreset utility
- PE71-0610132 - dbrecover utility
- PE71-0608010 - fwaudit utility
Patch PE71-0702080
------------------
Platforms: All
* A cache-miss (in the eloqdb6 buffer cache) might result in
temporarily blocking concurrent access to the same set until the
disk access was completed.
If some structural information was not found in the buffer cache
the server might fetch the data from disk with an internal lock
held. This could impact performance.
The server was modified to no longer hold this internal lock
during disk access. In addition, internal lock handling was
improved for database read operations.
* A DBGET call might overly impact performance of concurrent
applications when client-side caching is used (#3315).
When client side caching is enabled (the default), a DBGET might
request multiple records from the server in one request. The
number of records requested from the server depends on previous
application database use.
In some situations the performance of concurrent applications
might be impacted when a large number of records was requested
in one call.
The server was changed to improve concurrency in this case.
* Aborting on-line backup mode recovery could result in data
corruption (#3279).
The server process (or the dblogreset utility) performs a recovery
from on-line backup on startup if the server was previously shut down
while in on-line backup. This recovery transfers any changes
temporarily stored in the log volume(s) during the on-line backup
mode to the data volume(s). Depending on the amount of data
that was saved in the log volume(s) and disk performance this
could take some time.
If this recovery was interrupted (or aborted for some reason) in
some cases this recovery could not be re-run afterwards because
the generation count of the data volume would differ from the
log volume(s) generation count.
In this case the data volume is corrupted as the changes were
only partially transferred.
* Forward-log files are now created with restrictive file
permissions. Only the user account configured to run the database
server may access these files (#3304).
* The dbctl logfile command no longer accepts existing files (#3303).
* The [ForwardLog] EnableAudit and AuditOnly configuration values were
not displayed in the HTTP status (#3311)
Platforms: HP-UX and Linux
* If the server process is started from 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 (#2368).
* The eloqdb6 IO threads did not correctly change the log file after a
dbctl logfile command. The previous log file was not closed (#3294).
Platforms: Windows
* Changed the Windows file version to "7.1.0.14"
Notes / Related patches:
- The following related patches (or superseding) should be installed
with this patch:
- PE71-0702081 - dblogreset utility
- PE71-0610132 - dbrecover utility
- PE71-0608010 - fwaudit utility
Patch PE71-0610130
------------------
Platforms: All
* A rare defect was fixed that could result in a server abort while
stopping on-line backup (#3217). A message like below is written
to the server log file:
Assertion failed: page_addr < vol->curr_size
file volume.c, line 6183
This problem could happen if during on-line backup the data volume was
virtually extended and the volume list of available blocks had to be
extended as well (this is required around every 500 MB). When on-line
backup was later stopped, the stored free-list information was then
applied in a wrong way.
This problem was introduced with changes to the recovery code in the
previous patch PE71-0609120.
* Using dbrestore with a pipe (for example with gzip) could in rare
cases cause the server process to hang (#2987). This was caused by
a log message that was output asynchronously when the pipe was
closed and could in rare cases result in internal memory corruption.
* Changed the Windows file version to "7.1.0.13"
Notes / Related patches:
- The following related patches (or superseding) should be installed
with this patch:
- PE71-0610131 - dblogreset utility
- PE71-0610132 - dbrecover utility
- PE71-0608010 - fwaudit utility
Patch PE71-0609270
------------------
Platforms: All
* Fixed a rare race condition that could result in a server abort
when extending a volume file (#2525). A message like below is
written to the server log file:
Assertion failed: page != 0
It is expected that this problem can only happen in on-line backup
mode. As a workround the volume extension size for the log volume
could be enlarged above the default 1 MB.
* Fixed a corner case in the lock scheduler that could result in a
server panic on a DBUNLOCK (#3204). A message like below is
written to the server log file:
Assertion failed: lock_granted_tail && lq->l_prev
This problem was introduced with the revised lock scheduler in
patch PE71-0607100. A specific sequence of DBLOCK and DBUNLOCK calls
could result in a situation that violates an internal assumption.
* Changed the Windows file version to "7.1.0.12"
Notes / Related patches:
- The following related patches (or superseding) should be installed
with this patch:
- PE71-0609121 - dblogreset utility
- PE71-0609122 - dbrecover utility
- PE71-0608010 - fwaudit utility
Patch PE71-0609120
------------------
Platforms: All
* Fixed a problem in btree management that could result in an
internal error when a page split operation failed due to
insufficient disk space (#3052).
* Corrected an internal problem where a zero record number in
the free-record list could in rare cases result in an internal
failure during the checkpoint (#3131).
* A problem was solved that could result in an inconsistency of
the internal volume generation number between data and log
volumes (#3129).
This problem could result in an error during eloqdb6 startup
as below:
failed to open volume: volume #1 has inconsistent generation count
This could happen under a rare condition when forward-logging was
configured but disabled subsequently and afterwards the eloqdb6
process terminated unexpectedly. It could also happen if the
forward log was configured and the eloqdb6 process did abort
twice in a row. In both cases, the log volume header was not
updated and therefore contained a wrong volume generation.
* Fixed problem with the volume generation number that could get
out of sync if forward-logging was restarted during on-line
backup and the eloqdb6 was then stopped while still in
on-line backup mode (#3130).
* Fixed a potential corruption of the server catalog that could
happen in some cases if the server was aborted after changing
the server catalog (schema, dbcreate, dbutil, dbrestore) but
before running an internal checkpoint (#3163). In this case
the records allocated for the server catalog could not be
marked in use by the crash recovery and become corrupted
subsequently.
This problem could only affect eloqdb6 patch levels PE71-0606290
and newer.
* Session statistic was enhanced to separate regular DBGET calls
from multiple record fetches (using client side caching).
* Changed the Windows file version to "7.1.0.11"
Notes / Related patches:
- The following related patches (or superseding) should be installed
with this patch:
- PE71-0609121 - dblogreset utility
- PE71-0609122 - dbrecover utility
- PE71-0608010 - fwaudit utility
Patch PE71-0608110
------------------
Platforms: Linux
* This patch solves a compatibility issue with the glibc2.4.
Patch PE71-0607210
------------------
Platforms: HP-UX, Linux
* In some situation the queue entry of an completed IO request was
not released (#3118). This could after some time result in the
server message tio_enqueue: TIO queue is full
Patch PE71-0607100
------------------
Platforms: All
* The lock scheduler was revised to enhance scalability and
performance with a large number of competing locks.
* Changed the Windows file version to "7.1.0.10"
Notes / Related patches:
- The following related patches (or superseding) should be installed
with this patch:
- PE71-0606291 - dblogreset utility
- PE71-0606292 - dbrecover utility
- PE71-0606293 - fwaudit utility
Patch PE71-0606290
------------------
Platforms: All
* Improved scalability of dbunlock with a large number of blocked
competing lock requests.
* Fixed a problem with forward log files that could cause an internal
failure with dbrecover as below (#3072).
L0: Fwr_TranslatePage(page=0x3229) failed: page not found
Assertion failed: page not found, file volfwr.c, line 1504
The problem was triggered by an inconsistency in the forward log
that could happen in some cases if dbrestore was used while the
eloqdb6 server was active. This problem could no longer happen
as a side effect of installing patch PE71-0603280. This patch
provides a fix for the root cause.
* The forward log format that was slightly changed. This requires
installing updated utilities that access the forward log.
* Changed the Windows file version to "7.1.0.9"
Platforms: HP-UX
* Work around HP-UX problem with memory windows (#3050).
When using memory windows on HP-UX with a configured buffer size
of 1 GB the server process could abort with a SEGV with a message
like below:
** Cought signal 11 -- traceback follows:
signo = 11
addr = bffffff0
As a workaround, a configured buffer size of exactly 1 GB is
internally reduced by one page.
Notes / Related patches:
- The following related patches (or superseding) should be installed
with this patch:
- PE71-0606291 - dblogreset utility
- PE71-0606292 - dbrecover utility
- PE71-0606293 - fwaudit utility
Patch PE71-0603280
------------------
Platforms: All
* Fixed a problem with forward log files that could cause an internal
failure with dbrecover (#3059).
Internal failure: temporary file for transaction # not found
Assertion failed: Internal failure during forward-recovery
This problem was introduced with patch PE71-0602280 that enables use
of a more efficient format to record index changes in the forward
log files. In a specific case this could result in an inconsistent
transaction status recorded in the forward log file that is catched
by a consistency check in dbrecover.
This problem can possibly affect installations that previously
installed patch PE71-0602280 or PE71-0603100 and use additional
indexes. A patched dbrecover is available on request to workaround
this problem if necessary.
* Fixed a problem with forward logging not enabled after a server abort
without a server restart (#3056). A message like below is written is
the server log file:
Note: forward-logging has been disabled because the server was
not shutdown cleanly
After a server abort any recently committed transactions are
re-applied. This temporarily disables forward logging. A temporary
flag was not reset after completing recovery causing forward logging
to remain disabled until the server process is restarted.
Notes / Related patches:
- The following related patches (or superseding) should be installed
with this patch:
- PE71-0602281 - dblogreset utility
- PE71-0602282 - dbrecover utility
- PE71-0602283 - fwaudit utility
Patch PE71-0603100
------------------
Platforms: All
* Improve bimport performance on master sets (#3045).
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.
Patch PE71-0602280
------------------
Platforms: All
* An internal deadlock condition was fixed that could result in
on-line backup requests (dbctl backup start|stop|status) to
hang (#3014). A server shutdown would not succeed in this case
requiring to kill the server process.
An on-line backup request needs to obtain an internal lock to
ensure transactional consistency. If an on-line backup request
gets blocked initially due to a concurrent operation (for example
a dbstore operation is currently running) and another on-line
backup request is issued a deadlock condition occurred that caused
both requests to hang.
* The server process was enhanced to use a more efficient format
to record index and meta data changes.
This enhancement results in a substantial reduction in disk space
for the forward-log file when index entries are changed frequently.
This change required a modification of the forward-log file format.
While older forward-log files are still supported, related utility
programs need to be updated to handle the new format. This requires
installation of additional patches on dbrecover, dblogreset and
fwaudit utilities (see related patches).
* A rare defect with forward-recovery was fixed that could result in
a corrupted volume set (#2999). This causes an internal consistency
check to fail and eloqdb6 to abort on startup with an error message
like below:
Assertion failed: page == new_vol->flist_tail
server panic: Aborting on internal failure, file volume.c, line 3988
This problem could happen if the data volume was extended and the
volume list of available blocks had to be extended as well (this
is required around every 500 MB). The recovery then missed to update
the flist_tail field in the volume header, causing a panic the next
time the server was restarted.
The dbrecover utility was fixed to correctly update the flist_tail
field. In addition the eloqdb6 behavior was modified to detect
and correct this problem on startup. A notice is written to the
server event log file in this case.
* On HP-UX and Linux some log messages regarding eloqdb6 startup and
shutdown were raised in priority so they show up in the server event
log file even if LogFlags=*0 (default) is used. The following
messages are affected:
- "Eloquence database server active" when the eloqdb6 server process
started successfully.
- A new message outputs the current server patch level to the log.
- "Eloquence data base server terminated" when the eloqdb6 server
finished shutdown.
- The message when a new forward-log segment was created.
On all platforms the message indicating a previous unclean shutdown
was recovered is now written to the server log.
Platforms: Windows
* On the Windows platform, dbctl bimport refused an absolute path
beginning with a drive letter (#2997).
* Changed the Windows file version to "7.1.0.7"
Installation:
-------------
Please download the patch archive that corresponds with the installed
release. The patch files follow the conventions below:
PE71-0904060-hpux-ia64.tar.gz
^ ^ ^
| | Architecture / OS specific build
| Operating system
Patch ID
HP-UX:
In order to install this patch, you need to unpack it with gzip and tar.
Gzip is included with HP-UX. Installation requires root privileges.
cd /opt/eloquence6
gzip -dc /path/to/PE71-0904060-hpux.tar.gz | tar xf -
Files:
bin/eloqdb6
newconfig/config/eloqdb6.cfg
share/doc/PE71-0904060-README
Linux:
In order to install this patch, you need to unpack it with tar.
Installation requires root privileges.
cd /opt/eloquence6
tar xzf /path/to/PE71-0904060-linux.tar.gz
Files:
bin/eloqdb6
newconfig/config/eloqdb6.cfg
share/doc/PE71-0904060-README
Windows XP/2000/NT:
This patch should *only* be installed if you previously installed
the Eloquence server components on your system.
Installation requires administrative capabilities.
Two options are available for patch installation. The patch is
available as self extracting archive for automatic installation
and as a zip archive for manual installation. Both patches are
equivalent. Installation requires administrative capabilities.
For automatic installation of this patch, please download the patch
file PE71-0904060-win32.exe. Before installation, please consider
closing all applications, then execute the patch installation program.
Installation does not require a reboot unless the patched files
were active.
For a manual installation of the patch, please download the
patch file PE71-0904060-win32.zip and unpack its contents.
Then perform the following steps:
* Please make sure the eloqdb6 service has been stopped previously
(in the Service Control Manager or with NET STOP eloqdb6).
* Please copy the eloqdb6.exe file into the WINDOWS SYSTEM DIRECTORY
(for example C:\Windows\System32).
* Please copy the eloqdb6.cfg.sam file into the etc subdirectory of
your Eloquence installation (for example C:\Programs\Eloquence\etc).
* Please copy the PE71-0904060-README.txt file into the share\doc
subdirectory of your Eloquence installation (for example
C:\Programs\Eloquence\share\doc).
Files:
eloqdb6.exe
eloqdb6.cfg.sam
PE71-0904060-README.txt