The intention of this Article is to provide a basic description and guidance on when to (and when not to) use the Alternate Buffer Pool -B2.
Since OpenEdge 10.2B, there are two buffer pools in shared-memory:
- The Primary Buffer Pool (-B) where the LRU chain is always enabled
- The Secondary or Alternate Buffer Pool (-B2) which is optional and only starts to use it's LRU2 chain when the -B2 Buffer Pool becomes fully used.
Reasons for using -B2:
- When B2 is correctly sized, it should never have to load so many database blocks so as to use up all of its available buffers, there should always have some empty buffers remaining.
- To have assigned database objects permanently available in shared memory, thereby reduces disk i/o
- Avoiding or reducing the usage of an LRU (Least Recently Used) chain, reduces CPU and locking overhead, improving performance
The main -B Buffer Pool uses a LRU (Least Recently Used) chain to maintain a list of blocks that are loaded into the Primary Buffer Pool.
- When the Buffer Pool is full and a new block needs to be read from disk into the Buffer Pool, it will evict the Least Recently Used block from the Buffer Pool by querying the LRU chain.
- The maintaining and reviewing the LRU chain requires latching and CPU cycles.
When -B2 becomes completely full, the LRU2 chain is enabled and performance degradation may be experienced as new blocks are read in at the MRU2 end and LRU2 blocks are swapped out at the tail. The Alternate Buffer Pool will then perform exactly like the Primary Buffer Pool LRU’ing, except that its memory usage is restricted to only the area or objects allocated to it (rather than that memory being available to all non-assigned objects in the Primary Buffer Pool). Due to the need to ensure that the database doesn't use all -B2 buffers, on-going monitoring and adjusting may be required. For example:
Used buffers” as a proportion of “Total buffers” are reported in: PROMON > R&D > 2 Status Displays > 3 Buffer Cache
- "LRU2 replacement policy disabled" or
- "LRU2 replacement policy enabled"
What could be assigned to the Alternate Buffer Pool (-B2) ?
There is no universally applicable right answer for what should be located in the secondary buffer pool, other assignments may yield better performance depending on individual application requirements, but general recommendations are:
1. Consider Database Objects / Storage Areas which are configured for Transparent Data Encryption:
If using Encryption, put all tables / areas which have Transparent Data Encryption (aka block level encryption) enabled into the Alternate Buffer Pool. Since there is added overhead to perform encryption and decryption, keeping the block in memory at all times reduces the need to repeat these steps. While a block is in memory it is unencrypted. It is only encrypted when it is written down to disk. It is decrypted when it is read from disk.
2. Consider Database Objects / Storage Areas that need high availability for performance considerations.
- Highly active tables, indexes, LOBs, or Storage Areas. The database “Schema Area” containing only the database metaschema is a good example of this. As a Type I storage area, the entire area is assigned to the Alternate Buffer Pool with the offline PROUTIL enableb2 command. As such, any application database objects should be moved out of the Schema Area beforehand.
- Static tables, indexes, LOBs, or Storage Areas. An Item inventory (which is rarely updated, but always read) is one of many examples and may additionally benefit from being pre-loaded at database startup. Static Tables should either be placed in their own storage area and assigned at the area level or in Type II Storage areas and individually assigned with the Data Dictionary Tool.
What should not be allocated to the Alternate Buffer Pool (-B2) ?:
- Database objects / areas that have a very broad range of record usage. For example, a table that users might run queries/tasks that cover many years of data or has high Create-Delete-Update activity.
- Database objects that are rarely used. For example, Historical or Audit data.
Sizing the Alternate Buffer Pool (-B2):
Once Alternate Buffer Pool Assignments have been considered, a sizing exercise needs to be undertaken in a controlled fashion.
- A -B2 that is too small, that can't contain the complete object/area block usage and the LRU2 mechanism will be enabled as a result.
- A -B2 that is too big. -B2 will only be used by database objects or Storage Areas that have been assigned to the Alternate Buffer Pool, -B is for all remaining objects. So if memory is taken away from -B to use for -B2, (which is typically needed in 32-bit OpenEdge environments) you are restricting what can use that memory and can experience a performance decrease (an overall sustained reduced buffer hit rate) if it is not appropriate. Considering that -B2 should always have some empty buffers, that is memory can't be utilized, but with proper sizing this should be minimal.
- Primary (-B) and Alternate -B2 memory usage needs to be balanced appropriately to the memory resources available. For further information, refer to Article: How to size the Alternate Buffer Pool (-B2)
