The master TSN is stored in the Log Area (LXX). When the Log Area is initialized, the TSN number is set either to zero or to a value specified by the user. An false wait condition can possibly occur when the Log Area is initialized with a lower TSN number than currently exists in the existing rows. This can be prevented by assigning a larger TSN number when initializing a Log Area. The false wait condition occurs because, if TSN numbers are reused, a new transaction could possibly wait on another executing transaction that has the same number as an already committed transaction. This would involve a short wait on the wrong transaction and is only a minor concern. It is not an integrity concern.
Resetting the TSN is desirable because the previously described error condition, involving the possibility of having duplicate TSNs, can produce a large overhead when running as part of a MUFplex. As already mentioned, this would only occur and be a concern if the Log Area was initialized with a lower TSN than has been assigned. It is also possible if the TSN number ’wraps’ going from 4 billion less one to 1, a very rare occurrence.
Resetting the TSN requests that the MUF zero every row TSN in the specified database and area that is committed. This includes multi-block reads of every block in the area. Every block with a row is written with multi-block writes or single block writes.
One normal condition could occur where a reset of the TSN should be used for all areas. When you are running a MUFplex, if the TSN number wraps from four billion back to one, the code then continues to execute properly but in wrap mode. This continues for the next 16 million transactions, which is typically a very long time. Before that situation occurs, it is best to reset the TSN for all the areas.
|
Copyright © 2014 CA.
All rights reserved.
|
|