VST one

To collect performance related data, I think VST is the way to go. It is original and nothing beats the original. I feel like I never know enough of them and here is the place I can learn a few "useful" one, There will be "VST two", "VST three", etc.

this writing is the summary of an old document "Progress Tuning Workshop" from 2001.

1. _actSummary
aiming for high commit(high throughput), that's _summary_commits field
look at the _summary_flushed row for the flushed block, that will tell you if you have enough APWs
_summary-dbreads vs _summary-recread, 10:1 ration, but I think it depends the records per block value
_summary-dbwrites vs _summary-dbreads to see the updates vs reads
watch out for _summary-recwaits

2. _actAPWs
_apwQWrite, needed buffer is dirty, need to be written to the disk, -B might not be big enough if this number is high.
_chkQWrite, flushed buffer at checkpoint, not a good thing to have. everyone will stop for this activity.

3. _actBuffer
looking for high logical reads/write to OS reads/writes ratio
-deferred writes is a good thing to have

4. _actBiLog
if see any _actBiLog._BiLog-EbuffWaits, that menas you need to raise the -bibufs startup values or adjust BI block size
BIW and AIW are both doing the writes.
Partial writes means BI buffer are being flushed before that are full. BI block size if too big or increase the BI file write delay (-Mf).

5. _actLock
any value in the "wait" column means uses are wiating to get record locks, _lock-exclWiat, _lock-RecGetWait and _lock-ShrWait
_lock-UpgWait are an indication that a user has gotten a rec to update and has to wait for another user to release it.
_lock-UpgReq tells us the records are not retrieved correctly in the first place.

6. _checkpoint
the goal is to write all buffers from checkpoint queue just before the end of the checkpoint
_checkpoint-flush are not good, that means every update activity will pause while those buffers are being flushed.