Pages

This section includes the following information about pages and how Btrieve handles them:

Page Types

Files consist of a series of pages. A page is the unit of storage that the MicroKernel transfers between memory and disk. A file is composed of the following types of pages:


File Control Record (FCR)	Contains information about the file, such as the file size, page size, and other characteristics of the file. The first two pages in every 6.0 and later data file are FCR pages. At any given time, the MicroKernel considers one of the FCR pages to be current. The current FCR page contains the latest file information.
Directory pages (DIR)	Only used in 8.x and later file formats. Contains information about which PAT pages contain bitmaps with the highest number of free slots. The third and fourth pages in an 8.x file are DIR pages.
Page Allocation Table (PAT)	Part of the MicroKernel's internal implementation for tracking pages in a file.
Data	Contains the fixed-length portion of records. The MicroKernel does not split a single fixed-length record across two data pages. If a file does not allow variable-length records or use data compression, the file has data pages and no variable pages.
Variable	Contains the variable-length portion of records. If the variable-length portion of a record is longer than the remaining space on a variable page, the MicroKernel splits the variable-length portion over multiple variable pages. If a file allows variable-length records or uses data compression, the file has both data and variable pages.
Index	Contains key values used in retrieving records.
Alternate Collating Sequence (ACS)	Contains alternate collating sequences for the keys in a file.

All 6.0 and later files have FCR and PAT pages. Standard files also contain data and index pages, and optionally, variable and ACS pages. All 8.0 and later files also have DIR pages. Data-Only Files (page 4-9) contain no index pages. Key-Only Files (page 4-9) contain no data pages.

Page Size

You specify a fixed page size when you create a file. You can specify any multiple of 512 up to 4,096 bytes. All pages in a file (that is, data pages, index pages, and so on) are the same size.

Page Size Criteria

Large vs. Small Page Size

Page Size Criteria

The page size you specify should satisfy the following criteria:

Enables data pages appropriate to the file's record length.

Each data page contains 6 bytes of overhead information (or 8 bytes in an 8.0 or later file). After that, the MicroKernel stores as many records as possible in each data page, but does not break the fixed-length portion of a record across pages.

The optimum page size accommodates the most records while minimizing the amount of space left over in each data page. Larger page sizes usually result in more efficient use of disk space. However, with the 7.0 and later file formats, a data page cannot have more than 256 records in it. If the internal record length (user data + overhead) is small and the page size is large, the wasted space could be substantial (up to 2554 bytes, considering a 4,096 page size and an internal record length of 6).

Allows index pages appropriate to the file's key definitions.

Each index page contains 12 bytes of overhead information. After that, the file's index pages must be large enough to accommodate eight keys, plus overhead information for each key. (The overhead information for each key is 8 bytes for keys that allow no duplicates or repeating duplicates, and 12 bytes for keys that use linked duplicates.)

Allows the number of key segments that the file needs.

As discussed in Segmentation , the page size you define for a file limits the number of key segments you can specify for that file.

Optimizes performance.

For optimum performance, set the page size to an even power of two-512, 1,024, 2,048, or 4,096 bytes. The internal MicroKernel cache can store multiple size pages at once, but it is divided in powers of 2. Page sizes of 1536, 2560, 3072, and 3584 actually waste memory in the MicroKernel cache. Page sizes that are powers of 2 result in a better use of cache.

Large vs. Small Page Size

To make the most efficient use of modern operating systems, you should choose a larger page size. The smaller page sizes were used when DOS was the prominent operating system (when a sector was 512 bytes and all I/O occurred in multiples of 512). This is no longer the case. Windows 2000/NT moves data around its cache in blocks of 4,096 bytes. The block size of NetWare 4.x formatted partitions are also 4,096 bytes. CD ROM drives are read in blocks of 2,048 bytes.

Btrieve indexes are most efficient with a page size of 4,096. The key will have more branches per node and thus will require fewer reads to find the correct record address. This is important if the application is doing random reads using a key. This is not important when an application accesses the file in a sequential manner either by key or by record.

A good reason for having smaller page sizes is to avoid contention. With fewer records in each page it becomes less likely that different engines or transactions will need the same page at the same time. If a file has relatively few records, and the records are small, you may want to choose a small page size. The larger the file, the less likely contention will happen.

Another potential problem with large page sizes is specific to version 7.0 and later files. There is a maximum of 256 records or variable-length sections that can fit on the same data page. If you have short or compressed records, or short variable-length sections, you can easily reach the limit while you still have hundreds of bytes available on every page. The result is a much larger file than needed. Knowing your record size, you can calculate how big of an issue this is.

To determine Page Size in a Pervasive.SQL data file:

Keys work better with larger pages. There are more branches per Btree node and thus fewer levels to the Btree. Fewer levels means less input/output. Fewer disk reads means better performance.

Concurrency works better with smaller pages, especially when client transactions are used. Since the MicroKernel locks all pages changed during the transaction. All other clients must wait for these locked pages until the transaction is ended or aborted. With a lot of client trying to access the same pages concurrently, the less that is found on each page is better.

Random access to pages works better with smaller pages since more of the stuff you actually use is in cache. If you access anything again, it is more likely to be still in cache.

Sequential access to a large volume of records works better with larger pages since more is read at once. Since you are using most everything on each page read, there will definitely be fewer reads.

The database designer must choose between these conflicting needs. A reference table that is not changed very often, but is searched or scanned most of the time, should have larger page sizes. A transaction file which is inserted and updated a lot in transaction should have smaller page sizes.

Note
You have to balance these needs.

Only careful consideration of all factors can give the right answer to what the page size should be. For more information about choosing a page size, refer to Choosing a Page Size .