It's again a question of curiosity.
But first of all my (mis-)understanding of how Progress uses the latches to access data in database buffer pool:
Each request of db block that is already stored in db buffer pool creates the BHT, LRU, 2*BUF latch locks.
When a process retrieves db block from the disk it creates 3*BHT, LRU, 3*BUF latch locks.
The number of LRU latch locks can be reduced by the -lruskips times.
BHT latch controls an access to a hash table that contains the pointers to the linked lists of buffer headers.
The database buffer pool is a collection of buffer headers and buffers themselves. Buffer headers contain descriptions of buffer contents (the size of each buffer header was 140 bytes in V7.3 and is 292 bytes in V11.6.1).
I guess one BUF latch lock is used to access just a buffer header and another one - for a buffer itself.
BHT and LRU are regular latches (one latch per database).
BUF latches are the statistics aggregators for the multiplexed latches (or sub-latches or object latches - which term to use?). These latches control an access to each individual block in the buffer pool.
SYSTEM ERROR: Releasing regular latch. latchId: <latch-num> (5028)
SYSTEM ERROR: Releasing multiplexed latch. latchId: <latch-num> (5029)
Four BUF latches (BF1-BF4 in _Latch VST) just represent 4 equal areas in the buffer pool.
The hash table should provides the even distribution of the blocks in the buffer pool. Thereby we should get more or less even distribution of the locks between BF1-BF4 latches.
But what if a process uses the private buffers (-Bp) ?
Let's see the results:
proutil largedb -C dbanalys [-Bp 1]
2579804 total blocks found in the database.
probkup online largedb /dev/null
2579714 active blocks out of 2579725 blocks in largedb will be dumped. (6686)
Activity: Summary
DB Reads 2579880 (without -Bp)
DB Reads 2580451 (-Bp 1)
DB Reads 2479720 (probkup)
Status: Buffer Cache
Total buffers: 100002
Used buffers: 100002 (without -Bp)
Used buffers: 32 (-Bp 1)
Used buffers: 30 (probkup)
Activity: Latch Counts (Locks)
without -Bp -Bp 1 probkup online
BHT 7752194 7753440 7739659
LRU 2592538 2592545 2580204
BUF 1941506 1555421 1459884
BUF 1938869 1553112 6329981
BUF 1945953 1553212 25095
BUF 1938628 3103782 25211
--- ------- ------- -------
BUF 7764956 7765527 7840171 (Total)
For comparison: reading one area only (the unique dbkeys).
proutil largedb -C dbanalys "Table Area" -Bp 1
Active blocks: 2046463
Activity: Summary
DB Reads 2046566 (without -Bp)
DB Reads 2046691 (-Bp 1)
Activity: Latch Counts (Locks)
without -Bp -Bp 1
BHT 6144363 6144595
LRU 2051233 2051220
BUF 1536583 1230737
BUF 1538560 1229415
BUF 1537040 1230396
BUF 1536849 2458569
--- ------- -------
BUF 6149032 6149117 (Total)
When dbanalys uses the private buffers then one BUF latch has the lock count that is almost twice higher than three others. IOW, the same number of latch locks is divided by 5. Three BUF latches aggregate by 1/5 of total lock count and fourth BUF latch get 2/5 of all locks.
Probkup uses a "native" private buffer. One BUF latch aggregates 80.7% of latch locks, second one - 18.6% and last two - by 0.3%. What is the rule?
I would expect the zero values for three BUF latches and 100% of locks for one latch.
Normal processing: area+dbkey -> the hash table -> an unique address of a buffer header.
The private buffers are just the list of buffer headers and a process knows the address of the first buffer header on the list. All the time a private buffer should be in the same area of buffer pool and its statistics should be aggregated by only one of four BUF latches. But it's obviously not true.
BTW, what is the purpose of BFP (Buffer Pool Control Block Latch)? It's a regular latch and at first look it's used only by probkup: one lock per block. But other processes should use it as well. Is it used by the normal sessions to be allowed to update a database block while online backup is running?
Thanks in advance,
George