|
|
|
|
|
|
1 October 2011
Affected Builds: All FairCom DB SQL builds prior to 110914
Criteria: Highly concurrent FairCom DB SQL insertions involving floating point conversions
Indications: Unexpected KDUP_ERR (2) errors
A potential data integrity issue was identified in FairCom's internal testing that demonstrated a potential field overwrite that could occur with highly concurrent FairCom DB SQL updates that include a floating point conversion. Affected field types include:
NUMERIC, NUMBER, DECIMAL, MONEY, (N)CHAR, (N)VARCHAR
A remote possibility exists with multi-threaded FairCom DB SQL applications (excluding JDBC and ADO.Net) when a floating point value (either a variable in the application using native floating points or a FLOAT SQL type) requires conversion into an aforementioned FairCom DB SQL type.
A combination of events must take place for this overwrite to occur:
Consider the case of an ODBC driver binding a MONEY column to a SQL_C_DOUBLE type. When an insert is performed, the C type data undergoes a conversion to an SQL type. During this conversion, there is a possibility a buffer is not protected from multi-threaded updates.
Solution: This possibility has been avoided by ensuring proper thread safe C library functions are used on respective platforms and the buffer used for conversion is properly protected.
FairCom customers on current maintenance can request an updated V9 FairCom DB SQL line at any time. Please contact your nearest FairCom office should you have any concerns that you are impacted by this update.
|
|
|
20 January 2010
Affected Builds: All builds between 050722 through 100120
Criteria: Concurrent FPUTFGET record add/updates to variable length files.
Indications: Unexpected ITIM_ERROR (160) errors
In c-tree multi-user standalone (FPUTFGET) mode, when a process updates a record, increasing the size of the record, while at the same time another process adds a record, and if there is deleted space available after the record that is being updated, the update logic could reuse that space even though the add operation has already used the space for the newly-added record.
This issue only affects the c-tree multiuser standalone mode (FPUTFGET) and does not affect the c-tree Server.
A code change applied in July 2005 modified previously correct behavior. As a result, the logic in RWTVREC() that reads the key from the space management index after locking the space that is a candidate for reuse skips the call to read the key from the space management index. This omission can cause the update to enlarge the record into space that has been reused by a record add operation. The ITIM_ERR (160) was observed in that an index key entry pointed to an offset in the data file that was within another record. That record had been enlarged by an update operation, and it overwrote a record that was added at the same time the record was updated. A simple rearrangement of code prevents this behavior.
FairCom customers on current maintenance can request an updated V9 FairCom DB line at any time. Please contact your nearest FairCom office should you have any concerns that you are impacted by this update.
|
|
|
5 October 2009
Affected Builds: All builds prior to 091005
Criteria: Variable Length Files under Transaction Control that have Undergone Automatic Recovery After a Failed Server Process
Indications: Error 37 during recovery and/or evidence of data or index corruption
Sometime after automatic recovery on a system where the FairCom DB Server had previously gone through the process of automatic recovery, data and index files were found to contain unexpected 10-byte headers beginning with 0xfbbf marks. The headers appeared at unexpected locations, sometimes overwriting data records or index nodes, and sometimes written at the physical end of the file, preceded by a region of 0x00 bytes.
A second observed symptom was automatic recovery failing with error 37 due to an invalid file descriptor, as indicated by the following entries in CTSTATUS.FCS:
- User# 00002 trandat: scanning log 815
Wed Sep 23 15:44:25 2009
- User# 00002 WRITE_ERR: ???? at 0:1457a4ex sysiocod=6 bufsiz=10 bytes written=0[0] ioLoc=0: 37
Automatic recovery invalidates the space management index for variable-length data files, and it queues entries for the space reclamation thread to process. These entries trigger the space reclamation thread to reconstruct the space management index by physically scanning the variable-length data files for deleted records and adding keys to the space management index for each deleted region found in the file.
Changes to the space management index can place entries - with associated file numbers - into the transaction log. One such entry was written to the server's preImage space, however, not immediately written to the transaction logs. A later transaction can then commit this entry with a transaction file number not associated with the original file, as the original file could have been physically closed and the file number reassigned to another physical file.
Should the server then experience an abnormal failure and automatic recovery takes place, the entry is processed from the transaction log with a transaction file number associated with the wrong physical file. An attempt is then made to write this entry to the incorrect file causing either data to be overwritten, or a failed write due to an invalid file descriptor.
To prevent this behavior, the transaction log entries are now written immediately and directly to the physical transaction log ensuring a correct associated transaction file number upon recovery.
FairCom customers on current maintenance can request an updated V9 FairCom DB line at any time. Please contact your nearest FairCom office should you have any concerns that you are impacted by this update.
|
|
|
4 June 2009
Affected Builds: All V9 lines with build dates prior to 090602
Criteria: FairCom DB Server with DATA_LRU_LISTS or INDEX_LRU_LISTS configurations set greater than 1
Indications: Server crash after large number of cache misses
When a FairCom DB Server is running with the configuration options DATA_LRU_LISTS or INDEX_LRU_LISTS set greater than 1, after a large number (2^32, over 2 billion) data or index cache misses occur, the c-tree Server terminates with an unhandled exception. These options default to 4 in FairCom DB Version 9. Thus all FairCom DB Version 9 servers are susceptible to this situation. You can verify these options in the server startup information found in the server status log file, CTSTATUS.FCS.
When a cache page is required to hold a page that is not already in cache and multiple data or index LRU lists are in use, the data and index cache logic increments a variable used to calculate which data or index LRU list is to be used . However, the variable was declared as a signed long integer, and after 2^32 increments, became negative, resulting in a negative index offset for an array of data/index cache LRU list mutexes. Redeclaring the variables as unsigned long integers resolves this issue.
An immediate fix for anyone with potential to be affected by this Version 9.0 only issue is to directly specify DATA_LRU_LISTS 1 and INDEX_LRU_LISTS 1 in the FairCom DB configuration file (ctsrvr.cfg) to avoid this unhandled exception condition. You will need to restart your server to enable this configuration change.
FairCom customers on current maintenance can request an updated V9 FairCom DB line at any time. Please contact your nearest FairCom office should you have any concerns that you are impacted by this update.
|
|
|
22 May 2009
Affected Builds: All V8 and V9 lines that enabled this feature through the use of the LOGIDX file mode within the application or through the server configuration keyword FORCE_LOGIDX YES. This feature was enabled by default for FairCom DB V9 Servers with build dates 080111 through 090126.
Criteria: FORCE_LOGIDX YES enabled in the FairCom DB Server configuration
Indications: Failed recovery
FairCom DB provides a feature called LOGIDX which can allow for quicker automatic recovery time on server startup should you experience an unexpected failure (for example, a power outage). This feature can be enabled with a file mode of LOGIDX, or using the FORCE_LOGIDX server configuration keyword.
Extensive testing identified an isolated possibility of failure during automatic recovery when the LOGIDX logic is active. The net effect is a possibility for failed recovery in the event the c-tree Server was not properly shut down. This has been corrected as of V9.1 build 090522.
A simple solution to ensure you will not be impacted by this default setting is to disable the LOGIDX feature via your server configuration file. Follow these easy steps to perform this change:
FORCE_LOGIDX OFF
FairCom customers on current maintenance can request an updated V9 server line at any time. Please contact your nearest FairCom office should you have any concerns that you are impacted by this update.
|
|
|
20 December 2011
The latest Linux versions, notably Redhat 6 (RHEL 6) have demonstrated a potential problem with FairCom DB buffer management functions. The most common symptoms are ITIM_ERR errors (160) or KDEL_ERR errors (4).
Previously, FairCom DB used a C library memcpy() function in certain buffer management areas. However, when the source and destination buffer locations overlap, this can cause unexpected memory corruption issues, and the latest Linux versions appear to exhibit this with greater frequency. The memmove() function has been utilized in place of the memcpy() function to avoid this problem. Latest versions of FairCom DB since V9.5 (builds since 110420) incorporate this change.
In most cases, an updated server in this environment, and a quick index rebuild is all that is needed. Existing data has been shown to be secure.
FairCom customers on current maintenance can request an updated V9 server line at any time. Please contact your nearest FairCom office should you have any concerns that you are impacted by this update.
|
|
|
10 June 2009
Affected Builds: All builds prior to 090610
Criteria: Segmented file, Automatic recovery after a failed FairCom DB Server process
Indications: Renamed file segments
During automatic recovery of a failed FairCom DB process, existing file segments were renamed and thus subsequently not available to the application resulting in apparent missing data. During recovery, an attempt is made to open all segments of a segmented file found in the transaction logs. To open the segments, the segment definition resource must be read from the primary segment. However, an internal file map attribute had not been initialized resulting in a failed call. This failed call caused the recovery process to believe the additional segments did not exist. When later attempting to create the file segment, and that segment already existed, FairCom DB then renamed the segment. The uninitialized attributes are now properly assigned avoiding this potential incorrect renaming of segmented files.
FairCom customers on current maintenance can request an updated V9 server line at any time. Please contact your nearest FairCom office should you have any concerns that you are impacted by this update.
|
|
|
Two independent issues affect FairCom's multi-user standalone operational model (FPUTFGET) which relies on the underlying operating system to ensure file locking integrity. This contrasts with FairCom's server-based models where locking is independently and solely maintained by the c-tree Server. These issues manifest in either of the following scenarios:
Applications using the c-tree Server and c-treeSQL Server are not impacted by these issues.
Testing your FPUTFGET Application
It is easy to test your c-tree Plus FPUTFGET application for this behavior. The c-tree Plus example program, ctixmg, provides an easy-to-use application allowing for a simple controlled test. This example is built when you include samples in your c-tree Plus mtree build.
You should receive a DLOK_ERR error (42) from the second instance indicating that the expected and appropriate locking has taken place. If your application hangs (Vista to Vista), or the Update succeeds (Vista to XP), then you may require the Windows Vista hotfix and/or a c-tree Plus update.
What if I am affected?
All FairCom maintenance customers in good standing have been notified of this serious matter. A FairCom DB update is available. Now is also a great time to consider FairCom's FairCom DB technology which does not rely on the operating system to manage locking. With only a few simple changes, you can be up and running with enhanced speed, performance, huge data caching, dynamic backups, and the security of knowing your data is intact and secured!
Contact your nearest FairCom office should you have any questions or believe you are impacted by this potentially serious issue.
|
|
|
Six-byte transaction numbers allow you to take advantage of a vast volume of available numbers to greatly increase the lifespan of your active FairCom DB data files.
Some transaction-intensive applications using older versions of FairCom DB have experienced exhausting these numbers. With faster and faster hardware, and greater volumes than ever, there are good reasons to migrate to the latest version of FairCom Server.
Consider a moderately high volume application with 1000 transactions per second:
Transaction Number Limits
FairCom has created a comprehensive white paper describing this limitation of four byte transaction numbers, how to recover when you exhaust your supply of numbers, and how to convert and take advantage of six byte transaction number support. Download this valuable resource today! Six Byte Transaction Number Support
Contact FairCom and put the latest version of FairCom DB in action today!
Migrate to 6-Byte Transaction #’s in 5 Easy Steps
Warning: You will lose all User IDs and passwords when FAIRCOM.FCS is deleted. These can be recreated with the FairCom DB Administration utility, ctadmn.
Note: You can use rebuild and other standalone programs linked with c-tree V8 as a single-user library, however be sure the 6 byte transaction number is activated with #define ctFeat6BT in your ctoptn.h file. It is off by default in this operational model.
