Kbase P3622: Why the .bi file grows larger than original bi with roll forward?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
3/29/2011 |
|
Status: Verified
GOAL:
Why the .bi file grows larger than original bi with roll forward?
GOAL:
Why applying after image files causes BI file to grow?
GOAL:
Is the Before Image (BI) file used on a standby database?
GOAL:
Why is the before image area on the target database growing beyond its set level?
GOAL:
Why is the bi file on my target database growing?
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Versions
FIX:
In order to explain how transactions are written to a .bi file and to the .ai file, and what may happen to a .bi file when roll forwarding with an .ai file, the following symbols and diagrams will be used to represent notes, clusters, etc.:
There are 4 notes written to a .bi and .ai file for each transaction. They are:
1. Begin note
2. Pre note (snapshot of record before change; can be big)
3. Post note (changes to record)
4. End note
We'll represent each note by Nn, where n represents either note 1 (Begin), note 2 (pre), note 3 (post) or note 4 (end).
Let's represent a transaction with a Tn, where n is the transaction number.
Boxes such as these will represent clusters:
-------------------------------------------------------------------------------
|- Cluster 1 |- Cluster 2 |- Cluster 3 |- Cluster 4 |
-------------------------------------------------------------------------------
Typically a pre note follows closely after a begin note, and an endnote follows closely after a post note.
Therefore, in a multi-user multi-threaded environment, you could see a cluster with the following information:
T1N1 T1N2 T2N1 T1N3 T2N2 T1N4
This would represent Transaction 1 with a begin and pre note, Transaction 2 with a begin note, followed by Transaction 1's post note, Transaction 2's pre note, then Transaction 1's end note. Assuming this was all in one cluster, this would mean Transaction 1 was complete, but Transaction 2 is still under way. This cluster is not available for reuse until Transaction 2 is finished.
If you had just truncated the .bi file and were starting out with a fresh .ai extent, the first four clusters would contain the same information until the fourth cluster was full (given that they were the same size). At this point, this is where the contents of the .ai and the .bi file will begin to look differently. In our previous example, once Transaction 2 was finished, the first cluster of the .bi file would be available for re-use.
For a picture of this, let's assume we have the following 5 multi-threaded sessions taking place:
T1 |.........N3.N4
T20 |..N1.N2.N3.N4
T21 |...................N1........N2...................N3.N4
T22 |.....................N1.N2....N3.N4
T8 |N3.N4
------------------------------------------------->
time
The .bi file could look something like this:
-------------------------------------------------------------------------------------------------------------------------------------
T1N1 T1N2...| ... |...T8N3 T20N1 T8N4 T20N2 T1N3 T20N3 T1N4 T20N4 | T21N1 T22N1 T22N2 T21N2 |
-------------------------------------------------------------------------------------------------------------------------------------
cluster1 Cluster 3 Cluster 4
Note that Cluster 3 has the end note for Transactions 8 and 1, plus the begin and end notes for Transaction 20. There are no other "open" transactions residing in this cluster or in th.e earlier cluster 1 and cluster 2. Therefore, these three clusters are available for reuse. At this point, we are ready to write T22N3 to the .bi file. Rather than extending the .bi file with another cluster, Progress will reuse cluster 1. Therefore, the clusters will look like this after we put the remaining notes into the .bi file:
-----------------------------------------------------------------------------------------------------------------------------------------------------
T22N3 T22N4 T21N3 T21N4 | ... |...T8N3 T20N1 T8N4 T20N2 T1N3 T20N3 T1N4 T20N4 | T21N1 T22N1 T22N2 T21N2 |
-----------------------------------------------------------------------------------------------------------------------------------------------------
cluster1 Cluster 3 Cluster 4
However, the .ai file is a sequential file, and will not reuse clusters. Therefore, the .ai file looks like this:
-------------------------------------------------------------------------------------------------------------------------------------
T1N1 T1N2...| ... |...T8N3 T20N1 T8N4 T20N2 T1N3 T20N3 T1N4 T20N4 | T21N1 T22N1 T22N2 T21N2 | ---->
-------------------------------------------------------------------------------------------------------------------------------------
cluster1 Cluster 3 Cluster 4
--------------------------------------
T22N3 T22N4 T21N3 T21N4
--------------------------------------
Cluster 5
Obviously at this point, the .bi and the .ai files are no longer the same length. The .al file continues to grow sequentially while the .bi file is constantly taking advantage of the reusable clusters in the .bi file.
It is important to note that the .bi file is not allowed to reuse a cluster until it has aged at least 60 seconds.(This is the default, and can be overridden with the -G parameter, but please read up on this before using it so you fully understand the implications first.) Since we have users who will stop to answer a phone, get a cup of coffee, shuffle papers, etc., the writing to the .bi file by users will not necessarily be a constant stream. This aids in the aging of clusters in the .bi file.
P>These two factors: aging of clusters and the rate at which the .bi file is being written to during normal processing is important to remember for the journey into roll-forwarding.
ROLL FORWARDING: THE AFFECT ON THE .BI FILE
Let's assume we now have stopped using this .ai file and are ready to apply it to a previous backup. The .bi file during this day's activity yielded a .bi file of approximately 8MB.
Will the .bi file that's created during roll forward create a .bi file of the same size, smaller, or larger?
It would not be unlikely at all to have the .bi file created during roll forward to be larger, and this is why:
Using the .ai file above, the .bi file notes the transactions as they are applied to the database. They are applied in rapid succession, as we are not talking hand-entered data from our previous real-time experience. By the time cluster 4 is full, cluster 1 cannot be reused, as proper aging has not occurred for Cluster 1. Therefore, the .bi file will be extended, and the information will be written to cluster 5.
Additionally, please note that having different cluster sizes for your .bi and .ai files could also further impact how big the .bi will grow during roll forward.
SUMMARY:
An infrequent occurrence of .bi file growth to many times the size of the .ai file during roll forward recovery is not usually an indicator of required tuning with respect to modification of bi blocks, bi cluster, or database block sizes. Each roll forward of the new ai file will cause the bi file to grow in very different patterns as opposed to the previous ai roll forward. This is due to the very differently recorded sequence of events..