The aimage scan verbose output cannot be used to directly determine how many locks were held at a certain time the database was running
The AI will record transaction note changes made during the period covered by the AI file but will cannot be used to determine the locks held during that period, if locks were being held by clients that made no changes to the locked records in that period. AI scan verbose output would need to be run on all ai files created since the database was started to track this activity.
By reviewing the transaction notes in the AI scan verbose output, it may be possible to determine if there were large scoped transactions, by grepping the output to see each transaction ID's associated transaction notes.
In the following example: Transaction 27989 deleted a record in area 9 in the block for dbkey 128
Trid: 27989 - The transaction ID is recorded for every entry.
Trid: 27989 code = RL_RMDEL - codes detail the operations for each Transaction
Trid: 27989 area = 9 dbkey = 128 - the dbkey/area the Transaction operation affected
A record CREATE, UPDATE or DELETE implicitly requires a lock, therefore during this transaction at least one lock table entry was needed.
- If there are RL_RMCR, RMCHG or RMDEL those will typically require a lock.
- If the transaction scope is small, it won't hold the lock for too long (usually).
- If the transaction scope is large it holds the locks either as exclusive or shared for the duration of the transaction. Repetition of the same transaction ID indicates multiple notes for one transaction. If there are thousands, or millions of notes related to a single transaction ID it can indicate a large single scoped transaction.
How many locks may have been used can be loosely determined by grepping the aimage scan verbose output and performing line counts for each transaction id.
cat aioutput.txt | grep "\<Trid: 27989\>" | egrep "RL_RMCR|RL_RMDEL|RL_RMCHG" | wc -l