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