Kbase P17959: How does the before image file work
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
24/02/2009 |
|
Status: Verified
GOAL:
How does the BI (before image) file work?
GOAL:
What is the BI (before image) file used for?
FACT(s) (Environment):
Progress 8.x
Progress 9.x
OpenEdge 10.x
All Supported Operating Systems
FIX:
The Before Image file(s) stores information about every transaction which makes a change to the database.
The information stored in the BI contains the transaction number, the user, the pre-modified value of block in binary form. After the transaction is complete it stores binary information on how to modify the blocks for records and indices.
If the transaction is aborted then the client, broker, or server will read the before image information from the BI file and restore original values of the database back into the database if necessary.
Periodically it is necessary to keep the database Buffers sync'ed down to disk for permanence sake.
Since any change to the database must be recorded in the BI, the BI can be used as an effective time-keeper to moderate the frequency that the database buffers are written down to disk drives.
To manage the BI file, we keep track of clusters, an arbitrary amount of BI blocks.
We set the frequency of writes for the database buffers to be no more than every one or two BI clusters.
When Asynchronous Page Writers (APWs) are running we have a rolling pair of BI clusters that we are using, after one BI cluster is filled we order the APWs to get to work writing each related database buffer described in that BI cluster, down to the database files on disk. When the second BI cluster is filled, we check the status of the APWs to see if they completed all notes from the first BI cluster. If at the filling up of the second BI cluster the APWs did not finish writing the database buffers related to every note in the first BI cluster then all write operations to the database are suspended and a forced flush is performed of all database buffers not already written by the APWs.
If the APWs did complete writing all the database buffers related to the notes in the first BI cluster then we re-label BI cluster 2 to be known as BI cluster 1 and we open a new BI cluster and call it cluster 2. We then tell the APWs to work on BI cluster 1 and the cycle continues.
We constantly keep track of how many transactions are open.
As we are writing to the BI file if we write to the end of the pre-formatted space we will loop from the end of the file back to the beginning to see if we can re-use the clusters at the beginning of the BI file.
The determination of whether we can or can not re-use a cluster within the BI is based off of a few rules:
1) We can not re-use a cluster if it has any open transactions in it.
2) We can not re-use a cluster if less than 60 seconds have elapsed since the last open transaction ended within a cluster.
From the point where any one transaction is open within a BI cluster, all clusters from that point forward will note that that transaction is counted as open.
Roughly speaking A note is placed in the header of each BI cluster indicating how many transactions are open.
If user 1 opens a transaction in cluster 1, there will be 1 transaction listed as open.
If user 2 opens a transaction in cluster 2, there will be "2" transactions listed as open, the transaction which began in cluster 1 and the transaction opened in cluster 2.
If a database crash occurs, Progress will read through the BI clusters first to make sure we didn't crash while adding more clusters.
The BI clusters are organized as a linked list and have double pointers, one points to the next cluster and one points to the previous cluster).
Once we have confirmed the beginning and end clusters we then start from the last cluster and go backwards two closed clusters from the end.
(Note, the cluster that was being written to when a crash occurred is not considered closed).
We check the block update counter listed in the bi note against the database block update counter it would be updating to see if the database has a more recent block update counter than what is listed in the bi note.
If the bi note is newer than the database block. update counter then we go back further in the bi cluster chain so that we don't miss any notes that might not have been written.
If the database has the same or newer update counter we start reading forward till we find a bi note whose block update counter is newer than the database.
We then begin redo-ing those operations listed in that cluster and move forward through each of the clusters to the end handling each note.
When we finish the last complete note of the last cluster of the BI we go from last cluster to first cluster and undo all incomplete transactions.
Since we are reading backwards we undo all actions and when we come to the transaction start note for that transaction we were undoing, we close the transaction as completely undone.
When we have undone all incomplete transactions listed in the BI we should have no more notes to process..