Pages

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

•

Files consist of a series of pages. A page is the unit of storage that the database 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 transactional database engine considers one of the FCR pages to be current. The current FCR page contains the latest file information.
Page Allocation Table (PAT)	Part of the transactional database engine’s internal implementation for tracking pages in a file.
Data	Contains the fixed-length portion of records. The transactional database engine 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 transactional database engine 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. Data-Only Files (page 4-24) contain no index pages. Key-Only Files (page 4-24) contain no data pages.

Page Size

You specify a fixed page size when you create a file. The page size you can specify, the file overhead, and so forth, depends on a variety of factors, including the file format. See Chapter 5 Designing a Database for information on page sizes. The following sections provide an overview:

•

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 a certain number of bytes for overhead. See Table 19. After that, the transactional database engine 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. If the internal record length (user data + record overhead) is small and the page size is large, the wasted space could be substantial.

•

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

Each index page contains a certain number of bytes for overhead. See Table 19. After that, the file’s index pages must be large enough to accommodate eight keys, plus overhead information for each key (see Tables 17, 18, 19, 20, and 21 for information the number of bytes of overheard per your configuration.)

•

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—such as 512; 1,024; 2,048; 4,096; 8,192; or 16,384 bytes. The internal transactional database engine cache can store multiple size pages at once, but it is divided in powers of 2. Page sizes of 1,536; 2,560; 3,072; and 3,584 actually waste memory in the transactional database engine 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. Both 32-bit and 64-bit operating systems move data around its cache in blocks of 4,096 bytes or larger. CD ROM drives are read in blocks of 2,048 bytes.

The transactional interface indexes are most efficient when a page size of 4,096 bytes or larger is used. 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.

Factors To Consider When Determining Page Size

•

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

•

Concurrency works better with smaller pages, especially when client transactions are used. Since the transactional database engine locks some pages changed during the transaction, all other clients must wait for locked pages until the transaction is ended or aborted. With a lot of clients 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 within transactions 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.