One thing that I observed playing with B2 - one should make sure that the B2 is big enough. As far as I understand, one method to determine whether B2 is too small is that lru2skips occur. Therefore you might want to consider something like B2 > 0 and lru2skips ( _BuffStatus._BfStatus-LRU2-Skips) > 0 as an issue.
The value of -lru2skips is a broker startup parameter, not a performance metric. It can be useful to set it to a non-zero value (usually doing so online) once you have determined that there are no free buffers in -B2 and you now have LRU2 latch activity. Setting a value for -lru2skips will minimize that latch activity.
The -lru2skips parameter has the same function in -B2 that -lruskips has in -B. Ordinarily, every time a block is accessed it is moved to the head (MRU end) of the LRU chain (or LRU2 chain, in B2). When doing many reads on a small table this can cause thrashing as the same few blocks continually get moved to the head of the chain, moved a few steps down, back the the head, etc.
As an example, setting a value of 10 for -lruskips tells the database to put an access counter on each block in the buffer pool. Each time the block is accessed, the counter is incremented. Only when the counter reaches the value of -lruskips (10 in this case) is it moved to the head of the chain and the counter zeroed. So that would reduce LRU latch contention by 90%. Setting -lruskips 100 would reduce it by 99%.
As you said, it is very important when setting -B2 to make sure it is large enough. You should do a sizing exercise on a test DB before setting -B2. Progress doesn't make this as straightforward as it should be unfortunately, as it is difficult to determine the size of a table in blocks. One approach you can take to size assigned tables is to create a test DB (via probkup of prod DB) and then start that test DB with a -B value large enough to hold all the tables. (You will know, in retrospect, that it wasn't large enough if promon R&D 1 7 shows zero unused buffers). Then do FOR EACH table TABLE-SCAN: END. on each table that you want to assign to -B2. The total used buffers in R&D 1 7 is the size of those tables in blocks. The size in blocks of the indexes you want to assign can be taken directly from dbanalys/idxanalys. Sum those and add some extra, let's say 20%, to allow for growth of those objects (depending on whether historical CRUD stats show creates and updates). That's the value to use for -B2.
As for monitoring if you've used all of -B2, there are a couple of things to look at. One is whether you have
ongoing LRU2 latch activity (in _Latch or in promon R&D debghb 6 11). The other is whether the ABP OS reads (in promon R&D 2 3) are greater than -B2. Also, check that the bottom of R&D 2 3 shows "LRU2 replacement policy disabled". (That's from memory; may not be the exact wording but you want to see "disabled", not "enabled".)