Local Bufferpool Parameters
The bufferpool contains pages that hold actual database data and various control information about databanks, tables, and transactions in the system. The following bufferpool parameters can be viewed by using the "Memory" tab after the dialog displaying local database parameters first appears:
Parameter | Description |
---|---|
4K bufferpool pages | This sets the number of 4K size pages to allocate to the bufferpool. 4K pages are used to cache tables with short record lengths. |
32K bufferpool pages | This sets the number of 32K size pages to allocate to the bufferpool. 32K pages are used to cache tables with intermediate record lengths and also for transaction control. For server type Auto this parameter is disabled and not used. |
128K bufferpool pages | This sets the number of 128K size pages to allocate to the bufferpool. 128K pages are used to cache tables with long record lengths. For server type Auto this parameter is disabled and not used. |
Transactions | Each active transaction is tracked by the system. A transaction starts when an application initiates a transaction, and ends when the background threads in the Mimer SQL database server has finished processing the transaction. A typical values is 2000 transactions. |
Databanks | The databanks are the physical files that store the database information. This parameter controls how many databank files may be held open at the same time. For server type Auto this parameter is disabled and not used. |
Tables | This parameter defines the maximum number of tables that may be open concurrently in the database. |
Large page memory region | When using the 64-bit Mimer SQL implementation it is possible to use a large page memory region. This means that the memory is allocated consecutively is physical memory. The memory is not paged and cannot therefore be used for anything else as long as the database server is running. In addition, the allocation may fail if the memory is fragmented. The benefit is that no paging file is used and that memory accesses are very efficient. |
See Also