Step 2: Determining the Page Size

Determining the Size of the Database › Calculating the Size of an Area › Step 2: Determining the Page Size

Step 2: Determining the Page Size

Page size

Whenever possible, you should select a page size that will hold two to three clusters of data used by an application program. The maximum page size is 32764.

The following considerations apply to selecting a page size for a database area.

Physical device blocking

A database page is a fixed block. As a general rule, you should use pages that are an even fraction of the track size.

The following table lists the optimal page sizes by device type for six IBM disk drives. Manufacturers of other brands of direct access storage devices (DASD) should be able to provide similar information for their own equipment.

per track	3330	3340	3350	3375	3380	3390
1	13028	8368	19068	32764	32764	32764
2	6444	4100	9440	17600	23476	27996
3	4252	2676	6232	11616	15476	18452
4	3156	1964	4628	8608	11476	13680
5	2496	1540	3664	6816	9076	10796
6	2056	1252	3020	5600	7476	8904
7	1744	1052	2564	4736	6356	7548
8	1508	896	2220	4096	5492	6516
9	1324	780	1952	3616	4820	5724
10	1180	684	1740	3200	4276	5064
11	1060	608	1564	2880	3860	4564
12	960	544	1416	2592	3476	4136
13	876	488	1296	2368	3188	3768
14	804	440	1180	2176	2932	3440
15	740	400	1096	2016	2676	3172

Note: The bytes per page for FBA devices must be a multiple of 512.

Considerations

Entity size

The size of a fixed-length entity or of a variable-length entity's minimum root or fragment cannot exceed 30 percent of page size without causing additional overhead for space management. Page size should always be at least three and one-third times greater than the largest entity in the area. A higher ratio (up to ten times greater) is preferable.

Note: With a variable-length entity, the length of the root and fragment must conform to the consideration stated above. The entity itself (root plus all fragments) can be larger than the page.

Page reserve

When you calculate the page size, you need to take into consideration the amount of space necessary for the page reserve. A page reserve is used to allow space for:

Future growth—At load time, you may want to reserve space in the database for storage of new data entities or for splitting of SR8 entities in an index structure. In either case, you should specify the page reserve when the database is first defined and then remove this page reserve after the database has been loaded.
Expansion of variable-length entities—The page reserve for an area that contains variable-length entities is specified when the database is defined and is never removed.

Calculating the page reserve

To calculate the size of a page reserve, perform the following procedures:

For each variable-length entity in the area, find the difference in bytes between the anticipated starting and expanded sizes.
Multiply the difference for each entity type by the anticipated number of occurrences of the entity.
Divide the total by the number of pages in the area.

The page reserve should never exceed 30 percent of the page size.

Buffer pool size

The size of a buffer pool depends on the amount of concurrent processing to be performed against the database. To avoid excessive database I/O operations, the buffer pool should be able to hold at least five pages.

If sufficient main storage cannot be allocated for a 5-page (or larger) buffer pool, you should reduce the page size.

Suppose an installation uses type 3380 disk devices. In this environment, the main storage required to create a buffer pool of six buffer pages is:

Page Size	Main Storage Required for Six Buffers
32,764 bytes	196,584 bytes
23,476 bytes	140,856 bytes
15,476 bytes	92,856 bytes
11,476 bytes	68,856 bytes
9,076 bytes	54,456 bytes
7,476 bytes	44,856 bytes

Note: There is additional overhead for each page in the buffer pool not included in the above numbers.

Processing requirements

The number of clusters (or portions of clusters) to be stored on a page should be determined by application processing requirements:

For typical random processing where direct access to data is essential, you should use small page sizes (few clusters). A small page requires less time per access and permits more concurrent processing on a channel. However, a small page also reduces the data transfer rate, causes more I/Os, and uses more disk space for a given quantity of data.
For typical serial processing, large page sizes (several clusters) allow a high data transfer rate and reduce the number of I/Os. However, large pages also monopolize the channel for longer periods of time.

Page header and footer

You need to allow 32 bytes on each page for the header and footer.

Large clusters

If the size of a cluster is excessively large (greater than 1/3 to 1/2 of a track), define a new database area and move a portion of the cluster to this area. Move one or more child entities in the cluster to the new area. You can adjust the size of this new area to accommodate a large cluster by increasing the page size or by adding more pages.

Storing clusters in a separate area

When you store child entities in a cluster in a separate area from their parent entities, the position of the child entity occurrences is proportional to the position of the parent entities in their area. Therefore the sizing considerations for both areas should be similar.