Kbase P187462: Records appear to be lost when performing crash recovery.
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
5/22/2011 |
|
Status: Unverified
SYMPTOM(s):
Records appear to be lost when performing crash recovery.
The number of records created by the client does not equal the number recovered after database crash recovery.
The database has far fewer records than the client added.
FACT(s) (Environment):
The client connects to a remote database broker with a client/server connection.
Adding records to a database in a single transaction per record.
The database is being killed (with kill -9) to simulate a crash, and then restarted.
After restarting it is expected that the number of records recovered during crash recovery is one less than that accumulated and added by the client. But the database contains several hundred less records.
All Supported Operating Systems
OpenEdge 10.x
OpenEdge Category: Language (4GL/ABL)
CAUSE:
This is expected behavior. The records being lost are those written to the database buffer pool, and have not yet made it into the BI file.
Committed records are first written to the database buffer pool, then at some interval determined by configuration settings and the Database Manager, are written to the BI file where in the case of a crash, they can be recovered. In contrast the buffer pool resides in memory and cannot be recovered in the case of failure.
FIX:
There are several ways to minimize the time between when a record is written to the database buffer pool and when it gets flushed
to the BI file.
Modify when checkpoints occur by decreasing both the number of buffers in the before image buffer pool (-bibufs) and the size of the bi cluster (proutil dbanme -C truncate bi -bi <cluster size>). The disadvantage to this approach is that it can adversely affect database performance. The optimum values for these parameters will be a compromise between runtime performance and the number of records recovered in the event of failure. The Delayed BI File Write startup parameter (-Mf) can be used to specify the interval that the broker process wakes up to make sure all BI file changes have been written to the BI file on disk. The default value is 3 seconds. This timer is started when a commit record is added to the bi log buffer. When it expires, the buffer containing the commit record and any earlier bi buffer records are written to disk. If you set the timer to zero, then commit records will always be forced to disk. This can however have some negative affect on performance due to the more frequent writing of partially filled bi buffers.