No, buffers allocated to the Alternate Buffer Pool (-B2) work exactly like the Primary Buffer Pool (-B), except that -B2 has it's own LRU chain that is activated when required.
Buffers are added to the secondary Buffer Pool in the order they're read from disk. There's no ordering or grouping logic.
While any performant advantage has yet to be proven, the secondary Buffer Pool could be pre-loaded logically by immediately after database startup, where the Alternate buffer pool objects are pre-loaded sequentially with either a table-scan or by the most used index (iow: not necessarily the Primary index).
In order to keep the buffers in that order, the LRUSKIPS2 database startup parameter could be employed, but one would never want to 'freeze' the LRU chain, it's there to ensure that the MRU blocks are at the head and the LRU are at the tail. Of course LRUSKIPS2 don't matter if the LRU2 chain hasn't needed to be enabled when -B2 is sufficiently sized for the allocated database objects assigned.
Other areas that could be looked into for the Alternate Buffer Pool assigned objects are how the records are currently 'ordered' in the associated database blocks. This would include:
a. Best record per block settings (128 rpb is not a magic rule, even with the Type II Storage Area structure)
b. That the associated records are initially loaded into their database blocks by LOGICAL ordering as opposed to primary key ordering. viz: by ITEM name as opposed to ITEM number.
c. The createlimit and tosslimit can be tuned PER database object, for Type II storage areas, in order to get the database block itself best filled for the purpose of that data. IOW: x blocks are read into the buffer pool, are the tosslimit and createlimit set to best compact the 'static' data in these blocks?
