TimesTen: Bug 10176825 - Process Failure Leads To Data Store Invalidation
(Doc ID 1327737.1)
Last updated on FEBRUARY 27, 2019
Applies to:Oracle TimesTen In-Memory Database - Version 18.104.22.168.0 to 22.214.171.124.0 [Release 11.2]
Information in this document applies to any platform.
This Note is of interest to all application developers and DBAs working with the TimesTen InMemory DataBase.
This problem is known and has been handled in an unpublished bug. The basic description of the bug and version fix information can be seen in <Note 10176825.8>. What follows here is a detailed description of the bug process and bug "signature" to assist customers in determining if they are encountering this problem.
The bug is a problem in the transaction log generation component of the TimesTen V11 source code. This bug results in an invalid address being written to the log buffer such that any application process attempting to access the buffer may encounter this invalid address and then will abend; the data store to which the process was connected will subsequently become invalid. There are no known restrictions on the type of application process which is vulnerable to this bug, and the failure has been seen in both C++ and Java client application processes.
This bug has a distinct diagnostic signature. Customers encountering this bug will observe the following:
1) An application process connected to the data store terminates abnormally with some kind of OS exception (SIGBUS, SIGSEG, etc.). If the application dumps core, a stack trace from the core file will include a call to the sbLogCTNWrap procedure. For example, see the 3rd entry in the following stack trace taken from a failed process (emphasis added):
What has happened here is that the application process (in this case pid 15758) has failed due to the invalid pointer which was generated in the sbLogCTNWrap procedure. The data store subdaemon detects the process failure and initiates cleanup of the failed process. This cleanup involves rolling back transactions left open by the failed process (in this case, the process was multithreaded with several connections to TimesTen, so there were several open transactions when the process abended, and these all had to be cleaned up.) However, in the process of rolling back the orphaned transactions, the subdaemon also encounters the bad address pointer in sbLogCTNWrap and the subdaemon process also terminates abnormally. By rule, the abnormal termination of a data store subdaemon results in the invalidation of the data store, and that is exactly what happens in the case of this bug.
Note that in all observed cases, subsequent data store recovery is automatically commenced and completed without problem; there is no permanent corruption in the data store and no need for manual intervention.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document