Eloquence B.08.00 ================= Revision: RC5, 2008-09-30 Thank you for your interest in the Eloquence B.08.00 RC5 release. This release candidate is a pre-release of the upcoming Eloquence version B.08.00. It is expected to be functional complete and has no known critical defects. By making test releases available publicly we hope to encourage wider testing and additional feedback. Please contact support@marxmeier.com to share your feedback or report a problem. Please note: This release is available under the terms of the Eloquence Beta Test Agreement which is specified in the file AGREEMENT. http://www.marxmeier.com/eloquence/download/beta/B0800/AGREEMENT Downloading and installing the software indicates your agreement to the Beta Test terms and conditions. This test release may not meet the release criteria for quality or performance and is intended for test and non-critical use. Introduction ------------ Major B.08.00 changes include - scalability improvements - make use of available CPU resources (improved multi-threading) - improved scalability on large memory configurations - support for 64 bit database server - database replication - incremental / point-in-time database recovery - support for case-insensitive indexes - Eloquence B.08.00 is installed in a different location and may be installed concurrently with previous (or future) Eloquence releases - new support for Linux on IA64 platform - new support for Linux on AMD64/EM64T platform Requirements ------------ To use replication the following requirements must be met: - Currently, only the HP-UX and Linux operating systems are supported. - HP-UX 11.11 (or newer) on PA-RISC 2.0 and HP-UX 11.23 (or newer) on IA64 based systems NOTE: Installation of the most recent HP-UX pthread patches (and related kernel patches) is strongly recommended to improve performance and correctness of thread operations: HP-UX 11iv2 (HP-UX 11.23) PHCO_37940 - pthread library cumulative patch PHNE_37670 - cumulative ARPA Transport patch PHKL_37121 - ksleep kwakeup performance cumulative patch PHCO_37115 - libxcurses cumulative patch PHKL_32542 - libscall-pdk.a cumulative patch HP-UX 11iv1 (HP-UX 11.11) PHNE_37671 - cumulative ARPA Transport patch PHCO_36946 - libxcurses cumulative patch PHCO_35743 - libc cumulative patch (PHCO_23093 or newer) PHKL_34926 - Buffer cache performance improvement PHKL_34534 - vPar,callout, abstime, sync perf, wakeup PHCO_33282 - pthread library cumulative patch PHKL_28489 - fixes erroneous EFAULT - Linux glibc2.3 (or newer) on x86 and x86_64 based systems supporting the NPTL based threading - Installation of the most recent B.07.10 patches is required for close compatibility with B.07.10, if you intend to use a database environment with either B.07.10 or B.08.00 (as a fallback, for example). - A B.08.00 license key is required to use this release. Please contact support@marxmeier.com. - To use replication, a separate replication license key is required. Please contact support@marxmeier.com. Installation ------------ The Eloquence B.08.00 test releases are available for download from the following location: HTTP protocol: http://eloquence.marxmeier.com/download/beta/B0800/ FTP protocol: ftp://ftp.marxmeier.com/eloq/beta/B0800/ Different versions of the Eloquence software are available. Please choose the appropriate version which corresponds with your hardware. Additional details on installation are provided in the INSTALL document. B.07.10 compatibility --------------------- Eloquence B.08.00 is upwards compatible with previous Eloquence versions and binary compatible with recent B.07.10 patch levels, if the server was shutdown cleanly. To revert to B.07.10 the following procedure is required: 1. If the 8.0 database server was not shutdown cleanly, for example due to a server crash, you need to first run the 8.0 version of dblogreset to re-apply (roll forward) any recently committed transactions. 2. Restart the server with the Eloquence 7.10 version To ensure a successful reversion to B.07.10 please make sure that recent B.07.10 patches are installed. These are currently (as of 27. June 2008): PE71-0802120 - database server PE71-0801241 - dblogreset utility PE71-0803071 - dbrecover utility PE71-0803041 - fwaudit utility PE71-0802121 - dbfsck utility The following B.07.10 patches (or superseding) are suggested to be installed: PE71-0801250 - database client library PE71-0801251 - image3k library PE71-0802150 - eloqcore To use replication, the following B.07.10 patches (or superseding) must be installed: PE71-0705303 - dbrepl utility PE71-0705304 - chklic utility PE71-0705305 - dbvolextend utility PE71-0705306 - dbvolchange utility PE71-0804170 - dbcfix utility Download location, installation instructions and release notes: http://eloquence.marxmeier.com/support/B0710/patch/B0710.html The database client and image3k libraries are currently located in the B.07.10 beta patch directory: http://eloquence.marxmeier.com/download/B0710/patch/beta/ HP-UX Kernel Parameters ----------------------- Eloquence B.08.00 may require the configuration of additional HP-UX kernel parameters: max_thread_proc - defines the maximum number of concurrent threads allowed per process. max_thread_proc limits the maximum number of threads allowed per process on the system. max_thread_proc needs to be set to at least the highest number of configured database connections serviced by any B.08.00 database server (threads= config item) plus 10. nkthread - number of threads allowed to run simultaneously The nkthread tunable controls the absolute number of threads allowed on a system at any given time. Increasing it will allow more threads, and lowering it will restrict the number of threads. It can be determined that nkthread is too low when the kthread: table is full message is seen in the message buffer. The message can be read via dmesg or syslog. This message indicates that an application was unable to create a thread. nkthread needs to be set to at least the sum of all configured database connections serviced by an B.08.00 database server (threads= config item, system wide) plus 10 per instance. nkthread must be greater than max_thread_proc. Documentation ------------- At this point no separate B.08.00 documentation is available. However, as this release is functionally close to the most recent B.07.10 patches (PE71-0803070 and related) the corresponding B.07.10 documentation applies to this release as well. Database replication This document describes the Eloquence replication functions. http://eloquence.marxmeier.com/support/B0710/doc/repl/index.html Database Server statistics This document describes the Eloquence Database Server statistics. http://eloquence.marxmeier.com/support/B0710/doc/stats/index.html Summary of enhancements (relative to the initial B.07.10 release) ----------------------------------------------------------------- * All B.07.10 patches (as applicable) are merged to B.08.00 * Add support for case insensitive indexes * Add the option to replicate database transactions to other database environments. * 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. * A forward-log is now retained across a crash of the database server. * After a DBFIND on an index, a DBGET mode 4 could not be used to position the current record inside the result. * A DBFIND resets the current record number for a data set. * The server was enhanced to support additional options for logging server or individual session performance information. * The server was enhanced to support additional dbctl commands to allow dynamically changing the logging of performance information. * Fixed compatibility with the glibc2.4 (and newer) on Linux. * The lock scheduler was revised to enhance scalability and performance with a large number of competing locks. * Improve bimport performance on master sets. * The server process was enhanced to use a more efficient format to record index and meta data changes. * The "conntime" session item was added to allow fwaudit to filter by the session connection timestamp (#3343). * The dbrecover utility was enhanced to support incremental recovery. * The dbrecover utility was enhanced to support recovery up to a specified point in time without previously switching the forward- log file. * The dblogreset utility was enhanced to retain a forward-log in case of a recovery after an abnormal termination of the database server. * Impose a limit on the max. transaction size * Improve performance of client side caching in high latency networks. Recent Changes -------------- User visible changes to previous B.08.00 test releases include: RC5: - Fixed an internal race condition between DBLOCK and DBUNLOCK that in rare cases could result in a database server abort with a message like below (#3648): Assertion failed: current_task->waiting_for == NULL Aborting on internal failure, file thread.c, line 2469 This is a transient problem which is resolved by restarting the database server. - 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 database server binary on the slave server. The slave server should then correctly resume replication. - The database server could write a message like below to the log file (#3646): Node_RemoveFirstItem: skipping entry id == 0 at idx == ... This is an internal debug message which was output with the wrong severity. There is no problem involved with this message. - The SFA file format and utilities (Eloquence language profiler) were changed to support an improved resolution. The sfagen utility supports an new command line option -2 to force creation of .SFA files in a format compatible with older Eloquence releases. RC4: - Fixed an internal race condition that could in rare cases cause an inconsistent session sign-on record being written to the forward-log file (#3644). This could subsequently cause the fwaudit utility to abort with a message like below: Assertion failed: rem_sz >= entry_sz, file audit.c, line 440 - Stopping the database server or starting on-line backup mode could take a long time under high load (#3640). - 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. RC3: - 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). - A data corruption could occur during a forward recovery (dbrecover) or database replication under certain conditions using a forward log that was created by Eloquence B.07.10 when a database was purged (#3636). Eloquence B.08.00 used a different procedure than B.07.10 when purging a data set. In rare cases this could result in data corruption when a B.07.10 forward log file was used with B.08.00. When starting the server process (or using an off-line database utility), a panic message like below could be output: Node_ReadNodePage() failed: invalid page header ... Assertion failed: Node_ReadNodePage() failed: file is corrupt Aborting on internal failure, file nodecore.c, line 3487 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 in rare cases a replication slave server could abort with a message like below when stopping on-line backup mode (#3637): Assertion failed: vol->extend_rec Aborting on internal failure, file volredir.c, line 1331 Restarting the replication slave server should resolve this problem, the slave server should then be able to resume replication. - Fixed an internal race condition which in rare cases could cause data corruption when stopping on-line backup mode after the volume was extended (#3638). If the data volume is extended while the server is in on-line backup mode, this is recorded internally and only performed when the on-line mode backup is stopped (virtual volume extension). When backup mode is stopped it could happen that a concurrent thread might write to a page address beyond the current size of the volume while this disk space was initialized. This could result in data corruption so that the database environment must be restored from a previous backup. dbrecover may be used to recover the database environment to a recent state. - Fixed a problem with the start/stop script on HP-UX. Specifying the db environment id "eloqdb" affected all configured database environments rather than just the one named eloqdb (default). - The http database session detail information was enhanced to output an average time per call and separate the two counter columns. RC2: - Fixed an internal race condition where a duplicate transaction identifier could be written to the forward-log under high load (#3631). This causes a subsequent recovery to abort with a message like below: Internal failure: transaction ... does already exist Assertion failed: Internal failure during forward-recovery Aborting on internal failure, file volfwr.c, line 5693 This problem affects both dbrecover and database replication. It is not possible to recover beyond the point in the forward-log where the duplicate transaction identifier occurs. The affected database environment must be restored from a backup. - A replication slave server could abort with a message like below (#3632): Assertion failed: buf_sync_active == 0 Aborting on internal failure, file mpool.c, line 1863 This problem was caused by a wrong assumption in the buffer cache implementation, introduced in the previous RC1 release. - The dbvolextend utility could abort with a segmentation violation after a new volume was created (#3633). This happened during the cleanup phase after successfully creating a new volume or recreating a log volume. The message had no further effect, the created volume was not functionally affected. RC1: - A recovery could abort with a message like below (#3620): Assertion failed: item_idx < ilist->last_item Aborting on internal failure, file volfrec.c, line 3002 This was caused by a wrong order of actions in the transaction journal or the forward-log. The problem affects the database server startup recovery (or the dblogreset utility) as well as a forward- recovery (dbrecover) and database replication. In the worst case it could result in data corruption so that the database environment must be restored from a backup. - The database server could abort with a message like below while disconnecting a session or shutting down the database server (#3623): epoll_ctl: write failed. [9] Bad file number Assertion failed: err == 0 Aborting on internal failure, file event.c, line 613 - An internal race condition in the buffer cache management was fixed that could affect the integrity of the transaction journal in case of a crash of the database server. - An internal race condition was fixed which could cause a record number not being reused under high load. This could happen if a DBDELETE added a record number to the free-list which was then fetched by a concurrent DBPUT while the record was still locked by the transaction containing the DBDELETE. - The lock contention on the internal VNode structure was further reduced (#3624). This minimizes the overhead and avoids lock conflicts while disconnecting a session. - The database server could abort on startup with a message like below if the volume generation of the data volume files differs from the log volume generation but the data volume is consistent (#3627). recursive lock tmp_root_vol[idx].vol_lock ... volredir.c:1108 Assertion failed: unexpected recursive lock Aborting on internal failure, file thread.c, line 1455 This could for example happen if the data volume was restored from a backup and the log volume was not recreated. The problem could be solved by recreating the log volume with dbvolextend -R. - When connecting more than 4096 database sessions, the first session (usually TID 9) failed with a client-side message like below: Connection was aborted by server REMOTE: Problem during send (-700:-5) With more than 4096 database connections, an overflow occurred on the internal status array located in the IPC shared memory segment which could corrupt the transfer status of the first session. - When IPC communication was enabled and the application ended, a misleading log message could be written to the database server log (#3600): Unexpected TCP event - closing connection This message should only be output if the application is aborted during a database call. - The TERM signal used to shutdown the database server process could execute in a wrong thread, causing a message like below being written to the database server log (#3621): task ... spurious wakeup (stat=3) - When a database session is aborted the database server could write a misleading message like below to the database server log (#3625): Unable to down semaphore semop(DOWN): Invalid argument (errno 22) wait_on_client failed - Long running database maintenance operations such as dbctl dbstore, dbctl dbrestore and dbctl bimport could not be aborted on remote database sessions (using a TCP network connection). - The terminal descriptions on HP-UX were incomplete. - On 64 bit Linux installations the 32 bit fwutil library was missing. beta15: - On HP-UX RA-RISC the database server and some utility processes processes could hang due to a changed address of an internal lock. - The query3k utility used a wrong path to locate its message catalogs (#3619). - On Linux a wrong query3k build was distributed in previous beta releases. beta14: - Due to an internal deadlock condition, a DBOPEN could hang on a replication slave server if the replication was stopped and restarted (#3618). When restarting the replication, the actions that were already processed are skipped. In this context, an unlock was missing which could cause a later deadlock on DBOPEN. beta13: - The database server could abort with a message like below while executing a DBDELETE: Assertion failed: lrec != NULL Aborting on internal failure, file btree.c, line 1541 This was caused by an internal race condition where a btree page buffer was accessed after being released. The information being read from the page buffer could become overwritten concurrently by another thread. This way, a wrong page reference could become written to the transaction log, which could later cause a server panic during commit. - On the HP-UX platform the efficiency of the thread locking has been further improved. - Redundant write operations on the log volume have been removed. - The Database Locks HTTP status page now outputs a summary on the total number of granted and blocked locks (#3605). - 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 avoid contention on the operating system buffer cache. - 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. - database client library: DBOPEN could return a status -21 if multiple databases are opened on the same local database server but different database server addresses are used (#3484). For example, opening one database using the localhost address and then opening another database with the IP address of a local network adapter could cause DBOPEN to fail with status -21. - database client library: Introduced the EQ_DBENABLEIPC environment variable to specify whether or not IPC communication should be used on a local connection. The client library and the database server negotiate each other when a connection is local so that the efficient IPC communication method is used. This is usually the desired behavior. However, when using a tunneled network connection to a remote server, for example with SSH forwarding, the connection may appear to be local to both the client library and the database server, although it is remote. This would cause the connection to fail because the IPC communication method cannot be established on a remote connection. To work around this, the EQ_DBENABLEIPC environment variable may be set to zero for the connecting program, for example: export EQ_DBENABLEIPC=0 ... start the program using a tunneled connection ... The database client evaluates the EQ_DBENABLEIPC variable. If it is set to zero, the IPC communication method is never used. - eloqcore program: The 64 bit build of the eloqcore program could hang while establishing a DLG connection (#3609). - eloqcore program: On the HP-UX platform the eloqcore program could abort with a segment violation if /etc/utmpx is not readable. - Query3K program: Due to an internal buffer overflow, the REDO command could abort with a segment violation if the command length exceeds 256 characters (#3603). - fwaudit utility: An overflow of the internal expression stack could cause an error with a message like below: Error in filter expression: expression too complex Originally, the capacity of the expression stack was 100 elements. This has been increased to 1000 elements to allow more complex filter expressions. beta12: - Fixed a potential corruption of an internal memory arena that could occur while a database is created. As a consequence the database server could crash. This could result in data corruption in the worst case so that the database environment had to be restored from a backup. beta11: - On the HP-UX platform the efficiency of the thread locking has been significantly improved. In turn, both the database server scalability as well as the single-user performance benefit and at the same time the overall CPU usage is noticably reduced. - In case of a database server abort a subsequent startup recovery could fail in rare cases because a modification of an internal volume file data structure was not properly recorded in the transaction journal. This could result in data corruption in the worst case so that the database environment had to be restored from a backup. Volume file data structure modifications are now immediately recorded so that the integrity of the transaction journal is always maintained and the recovery problems observed with previous beta versions should no longer occur. - In rare cases the database server could issue a panic if a session disconnects while at the same time new connections are established (#3598). This could cause different messages to be logged, such as: pthread_mutex_lock(self->p_mutex) failed (errno 22) pthread_cond_wait(self->cond) failed (errno 22) pthread_cond_broadcast failed (errno 22) Due to an internal race condition, a new connection could use the data structure of a terminating session. This could cause the new connection's lock objects to become destroyed by the disconnecting session, resulting in an internal errno 22. - A 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. - Due to an internal race condition the database server could lose a timer signal event under high load. This had the effect that internal timer controlled updates were no longer performed. beta10: - Performance was improved by reducing the potential lock contention on a number of important objects. - Concurrent sequential acess to large data sets could result in a performance problem. - Some objects used to lock server statistics information being displayed on the HTTP statistics page turned out to have a high contention. These objects were removed. - The database server could abort with a message like below while executing a rollback: Assertion failed: Tlog_GetMeta() failed: file is corrupt Aborting on internal failure, file voltxn.c, line 5480 - The consistency of the transaction journal has been improved. Before a data volume is written, the transaction journal is synchronized so that a startup recovery will successfully execute. In this context, the method to determine whether or not it is necessary to synchronize the transaction journal has been improved for consistency in a multi-threaded environment. beta9: - Eloquence is installed in the /opt/eloquence/8.0 directory. Configuration files reside in the /etc/opt/eloquence/8.0 directory. The directory /var/opt/eloquence/8.0 is used for temporary storage. - HP-UX: /sbin/init.d/eloq8 is used as the start/stop script. The startup configuration file is maintained in the config file /etc/rc.config.d/eloquence8. - Linux: /etc/init.d/eloq8 is used as the start/stop script. The startup configuration file is maintained in the config file /etc/sysconfig/eloquence8. - The database server program has been renamed to eloqdb32 (the 32 bit version) or eloqdb64 (the 64 bit version), respectively. This change is transparent when using the eloq8 start script. - The default database server config file has been renamed to eloqdb.cfg and resides in the /etc/opt/eloquence/8.0 directory. Also see INSTALL file for manual changes needed when updating from Eloquence 7 or switching between Eloquence 7.10 and 8. - Eloquence 8 includes a set of updated database client libraries in /opt/eloquence/8.0/lib (or HP-UX specific subdirectories). To use those new library versions, user programs need to be either relinked or enabled to use the environment vars LD_LIBRARY_PATH or SHLIB_PATH (for PA-RISC programs on HP-UX). - A B.08.00 license key is required - Fixed a problem with DBUNLOCK which in rare cases could cause a panic with a message like below (#3551): Assertion failed: current_task->waiting_for == NULL Aborting on internal failure, file thread.c, line 1211 This problem was caused by a race condition that could occur on concurrently executed DBLOCK and DBUNLOCK invocations. A fix for this problem was already integrated into the previous beta8 release but turned out to be incomplete. - Under rare conditions it could happen that a record number was not reused (#3573). Due to an internal race condition during DBDELETE a deleted record number was sometimes not written into the list of free record numbers. The list of free record numbers can be fixed by running dbfsck in write mode. - The database server could output a message like below although there were sufficient free buffers available in the buffer cache: bf_newbuf: Cache buffers mostly in use - trying harder The buffers are organized in multiple queues. If by occasion the current queue was empty, this message was output, although there may have been buffers available in the other queues. - Due to an internal race condition, the database server could under certain conditions output an internal debug message like below: poll() returned 1, processed 0 - Due to an internal race condition when a session is shutdown, the database server could under certain conditions output a misleading warning message like below: BUG: Inconsistent fd mapping - Fixed a problem affecting a replicated slave server or a startup recovery or a 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. In theory it could also happen during a startup recovery when processing incremental btree recovery actions. 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). If this problem is encountered during a startup recovery, the volume files should be restored from the last backup and a forward recovery should be applied using the dbrecover utility. - 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 database server 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. beta8: - Scalability was improved by reducing the lock contention on the internal VNode structure. - Write performance was improved by significantly reducing the number of file system writes and this way reducing the lock contention on the transaction journal. - Fixed a problem with DBUNLOCK which in rare cases could cause a panic with a message like below (#3551): Assertion failed: current_task->waiting_for == NULL Aborting on internal failure, file thread.c, line 1211 This problem was caused by a race condition that could occur on concurrently executed DBLOCK and DBUNLOCK invocations. - A potential problem was fixed which could cause a btree to return wrong results due to a concurrently committed transaction. - 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. - On a replication slave the forward-log file permissions were not correctly set and the [forwardlog] GroupReadAccess configuration option had no effect (#3548). beta7: - Buffer cache locking was optimized to reduce lock contention on the internal LRU queue. - Fixed an internal deadlock condition that could occur when a user transaction was internally serialized after repeatedly retrying to resolve a lock conflict with concurrent database sessions. - Fixed a problem that caused the 32 bit database server to abort on startup if BufferCache is configured higher than 700 MB (#3485). The server terminated with a message like below: Unable to allocate buf_table(131071,8192,12) Memory allocation failed failed: Not enough space (errno 12) Unable to initialize buffer-cache subsystem. - Fixed a problem where the database server could hang in an endless loop on startup if the listen socket could not be bound (#3528). In this case, a message like below was output to the server log: Unable to bind address. [226] Address already in use - The dbctl killthread command did not have any effect if the thread to be killed is currently blocked waiting for a client request (#3530). - 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 database server 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. - 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 synchronization 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. - 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. - 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. - 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). - The internal SCAN_REC function was enhanced to gracefully handle a BOF status and to output a more detailed log message in case of a failure. beta6: - Fixed a performance problem caused by lock contention related to cache buffer aging with a large number of concurrent sessions. - Reduced system CPU utilization on lock contention. beta5: - Fixed a performance problem caused by lock contention related to cache buffer aging when a large number of processes repeatedly access the same cached page at a high frequency. - Fixed an internal race condition where an index page is accessed while another thread modifies the same page (#3476). This could result in a crash of the server with a log message like below: Assertion failed: bhp->refcount == 1 - 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 with the beta4 release. beta4: - Added support for the Linux platform. - Fixed a performance problem on DBPUT/DBUPDATE/DBDELETE if too many threads simultaneously try to acquire the same resource. In this case messages like below were output to the server log: dbput: excessive retries on tx conflict (CUSTOMERS ) The new implementation solves this by detecting a retry due to a resource conflict and then serializing this access. This results in improved throughput with lower CPU utilization. - 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 session could hang during cleanup due to an internal deadlock condition (#3443). As a consequence, the server could no longer shut down gracefully and had to be killed. On the replication slave server this could cause a situation where subsequent dbrepl invocations fail with a -700:-6 status. - A dbctl dbbexp invocation caused an internal deadlock after completion (#3442). As a consequence, the server could no longer shut down gracefully and had to be killed. - 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. - Fixed a problem that could result in a crash of the server process during dbutil database restructuring with a log message like below (#3414): Assertion failed: bhp->refcount == 1 - 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 the beta3 release (#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 - 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 - 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 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. beta3: - Fixed an internal deadlock condition that could happen in some cases when a record that spans a page boundary was accessed concurrently by multiple threads while I/O was pending (#3386). - Fixed a race condition that could cause a server abort in some cases when an index page was accessed while a concurrent session modified the same index page during commit. - Fixed a problem where a database could be purged after it was renamed although it was still opened by another session (#3111). - 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. beta2: - Fixed an internal cache corruption problem that could happen on DBDELETE of master records and subsequently cause various problems (#3390). - Fixed an internal hangup in the buffer cache if a page having a pending disk write was shadowed. - 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 could cause an internal inconsistency. beta1: - The order of actions in the forward-log file was not always consistent if entries were added by multiple sessions simultaneously. This could cause a crash during forward-recovery or replication. - The server could crash if concurrent sessions accessed the same btree page. - Added the DBLOCK-COMPAT database property. - Improved commit concurrency by removing an avoidable lock.