Database files

A database file is one of several types of the system object type *FILE kept in the system that contains descriptions of how input data is to be presented to a program from internal storage and how output data is to be presented to internal storage from a program. There are several types of database files:

Source file Physical file Logical file

Source file
A source file contains uncompiled programming code and input data needed to create some types of objects. A source file can contain source statements for such items as highlevel language programs and data description specifications. A source file can be a source physical file, diskette file, tape file, or inline data file.

Physical file
A physical file is a database file that stores application data. It contains a description of how data is to be presented to or received from a program and how data is actually stored in the database. A physical file consists of fixed-length records that can have variablelength fields. Physical files contain one record format and one or more members. From the perspective of the SQL interface, physical files are identical to tables.

Logical file
A logical file is a database file that logically represents one or more physical files. It contains a description of how data is to be presented to or received from a program. This type of database file contains no data, but it defines record formats for one or more physical files. Logical files let users access data in a sequence and format that is different from the physical files they represent. From the perspective of the SQL interface, logical files are identical to views and indexes.

Member
Members are different sets of data, each with the same format, within one database file. Before you perform any input or output operations on a file, the file must have at least one member. As a general rule, database files have only one member, the one created when the file is created. If a file contains more than one member, each member serves as a subset of the data in the file.

Record
A record is a group of related data within a file. From the perspective of the SQL interface, records are identical to rows.

Database file sizes

The following database file maximums should be kept in mind when designing files on the iSeries server: Description Number of bytes in a record Number of fields in a record format Number of key fields in a file Size of key for physical and logical files Size of key for ORDER BY (SQL) and KEYFLD (OPNQRYF) Number of records contained in a file member Number of bytes in a file member Number of bytes in an access path Number of keyed logical files built over a physical file member Maximum Value 32,767 bytes 8,000 fields 120 fields 2000 characters1 10,000 bytes

4,294,967,294 records2

1,869,162,846,624 bytes3 1,099,511,627,776 bytes3 5 3,686 files

Description

Maximum Value

Number of physical file members in a logical 32 members file member Number of members that can be joined Size of a character or DBCS field Size of a zoned decimal or packed decimal field Maximum number of distinct database files that can be in use at one time 256 members 32,766 bytes4 63 digits

500,000

Maximum number of members in a physical 32,767 or logical file Maximum number of constraints per physical 300 constraints file Maximum number of triggers per physical file Maximum number of recursive insert and update trigger calls :1 When a first-changed-first-out (FCFO) access path is specified for the file, the maximum value for the size of the key for physical and logical files is 1995 characters.
2

300 triggers

200

For files with keyed sequence access paths, the maximum number of records in a member varies and can be estimated using the following formula:

Description 2,867,200,000 10 + (.8 x key length)

Maximum Value

This is an estimated value, the actual maximum number of records can vary significantly from the number determined by this formula.
3

Both the number of bytes in a file member and the number of bytes in an access path must be looked at when message CPF5272 is sent indicating that the maximum system object size has been reached.
4

The maximum size of a variable-length character or DBCS field is 32,740 bytes. DBCS-graphic field lengths are expressed in terms of characters; therefore, the maximums are 16,383 characters (fixed length) and 16,370 characters (variable length).
5

The maximum is 4,294,966,272 bytes if the access path is created with a maximum size of 4 gigabytes (GB), ACCPTHSIZE(*MAX4GB). These are maximum values. There are situations where the actual limit you experience will be less than the stated maximum. For example, certain high-level languages can have more restrictive limits than those described above. Keep in mind that performance can suffer as you approach some of these maximums. For example, the more logical files you have built over a physical file, the greater the chance that system performance can suffer (if you are frequently changing data in the physical file that causes a change in many logical file access paths). Normally, an iSeries database file can grow until it reaches the maximum size allowed on the system. The system normally will not allocate all the file space at once. Rather, the system will occasionally allocate additional space as the file grows larger. This method of automatic storage allocation provides the best combination of good performance and effective auxiliary storage space management. If you want to control the size of the file, the storage allocation, and whether the file should be connected to auxiliary storage, you can use the SIZE, ALLOCATE, and CONTIG parameters on the Create Physical File (CRTPF) and the Create Source Physical File (CRTSRCPF) commands. You can use the following formulas to estimate the disk size of your physical and logical files.

For a physical file (excluding the access path) that does not contain null capable fields: Disk size = (number of valid and deleted records + 1) x (record length + 1) + 12288 x (number of members) + 4096 The size of the physical file depends on the SIZE and ALLOCATE parameters on the CRTPF and CRTSRCPF commands. If you specify ALLOCATE(*YES), the initial allocation and increment size on the SIZE keyword must be used instead of the number of records.

For a physical file (excluding the access path) that contains null capable

fields: Disk size = (number of valid and deleted records + 1) x (record length + 1) + 12288 x (number of members) + 4096 + ((number of fields in format) 8) rounded up) x (number of valid and deleted records + 1) The size of the physical file depends on the SIZE and ALLOCATE parameters on the CRTPF and CRTSRCPF commands. If you specify ALLOCATE(*YES), the initial allocation and increment size on the SIZE keyword must be used instead of the number of records. For a logical file (excluding the access path): Disk size = (12288) x (number of members) + 4096 For a keyed sequence access path the generalized equation for index size, per member, is: let a = (LimbPageUtilization - LogicalPageHeaderSize) * (LogicalPageHeaderSize - LeafPageUtilization - 2 * NodeSize) let b = NumKeys * (TerminalTextPerKey + 2 * NodeSize) * (LimbPageUtilization - LogicalPageHeaderSize + 2 * NodeSize) + CommonTextPerKey * [ LimbPageUtilization + LeafPageUtilization - 2 * (LogicalPageHeaderSize - NodeSize) ] - 2 * NodeSize * (LeafPageUtilization - LogicalPageHeaderSize + 2 * NodeSize) let c = CommonTextPerKey * [ 2 * NodeSize - CommonTextPerKey - NumKeys * (TerminalTextPerKey + 2 * NodeSize) ] then NumberLogicalPages = ceil( [ -b - sqrt(b ** 2 - 4 * a * c) ] / (2 * a)) and TotalIndexSize = NumberLogicalPages * LogicalPageSize This equation is used for both three and four byte indexes by changing the set of constants in the equation as follows:

Constant NodeSize LogicalPageHeaderSize LimbPageUtilization LeafPageUtilization

Three-byte Index 3 16 .75 * LogicalPageSize .75 * LogicalPageSize

Four-byte Index 4 64 .75 * LogicalPageSize .80 * LogicalPageSize

The remaining constants, CommonTextPerKey and TerminalTextPerKey, are probably best estimated by using the following formulas: CommonTextPerKey = [ min(max(NumKeys - 256,0),256) + min(max(NumKeys - 256 * 256,0),256 * 256) + min(max(NumKeys - 256 * 256 * 256,0), 256 * 256 * 256) + min(max(NumKeys - 256 * 256 * 256 * 256,0), 256 * 256 * 256 * 256) ] * (NodeSize + 1) / NumKeys TerminalTextPerKey = KeySizeInBytes - CommonTextPerKey This should reduce everything needed to calculate the index size to the type of index (that is, 3 or 4 byte), the total key size, and the number of keys. The estimate should be greater than the actual index size because the common text estimate is minimal.

Given this generalized equation for index size, the LogicalPageSize is as follows: Table 1. LogicalPageSize Values *MAX4GB (3-byte) LogicalPageSize 4096 bytes 8192 bytes 16384 bytes *MAX1TB (4-byte) LogicalPageSize 8192 bytes 16384 bytes 32768 bytes

Key Length 1 500 501 - 1000 1001 - 2000

The Logical Page Sizes in Table 1 generate the following LimbPageUtilizations: *MAX4GB (3-byte) LimbPageUtilization 3072 bytes 6144 bytes 12288 bytes *MAX1TB (4-byte) LimbPageUtilization 6144 bytes 12288 bytes 24576 bytes

Key Length 1 500 501 - 1000 1001 - 2000

The LogicalPageSizes in Table 1 generate the following LeafPageUtilizations: *MAX4GB (3-byte) LeafPageUtilization 3072 bytes *MAX1TB (4-byte) LeafPageUtilization 6554 bytes

Key Length 1 500

Key Length 501 - 1000 1001 - 2000

*MAX4GB (3-byte) LeafPageUtilization 6144 bytes 12288 bytes

*MAX1TB (4-byte) LeafPageUtilization 13107 bytes 26214 bytes

Then to simplify the generalized equation for index size, let: CommonTextPerKey = 0 which would cause: TerminalTextPerKey = KeySizeInBytes b = NumKeys * (KeySizeInBytes + 2 * NodeSize) * (LimbPageUtilization - LogicalPageHeaderSize + 2 * NodeSize) - 2 * NodeSize * (LeafPageUtilization - LogicalPageHeaderSize + 2 * NodeSize) c=0 NumberLogicalPages = ceil( [ -b - sqrt(b ** 2 ) ] / (2 * a)) = ceil[ (-2 * b) / (2 * a) ] = ceil[ -b/a ]

Examples: Database file sizes

A *MAX1TB (4-byte) access path with 120 byte keys and 500,000 records TotalIndexSize would have a TotalIndexSize in bytes as follows:
a = (LimbPageUtilization - LogicalPageHeaderSize) * (LogicalPageHeaderSize - LeafPageUtilization - 2 * NodeSize) = (6144 - 64) * (64 - 6554 - 2 * 4) = 6080 * -6498 = -39,507,840 b = NumKeys * (KeySizeInBytes + 2 * NodeSize) * (LimbPageUtilization - LogicalPageHeaderSize + 2 * NodeSize) - 2 * NodeSize * (LeafPageUtilization - LogicalPageHeaderSize + 2 * NodeSize) = 500,000 * (120 + 2 * 4) * (6144 - 64 + 2 * 4) - 2 * 4 * (6554 - 64 + 2 * 4) = 500,000 * 128 * 6088 - 8 * 6498 = 3.896319e+11 NumberLogicalPages = ceil[ -b/a ] = ceil[ -3.896319e+11/-39507840 ] = 9863 TotalIndexSize = NumberLogicalPages * LogicalPageSize = 9863 * 8192 = 80,797,696 bytes

The equation for index size in previous versions of the operating system would produce the following result:
TotalIndexSize = (number of keys) * (key length + 8) * (0.8) * (1.85) + 4096 = (NumKeys) * (KeySizeInBytes + 8) * (0.8) * (1.85) + 4096 = 500000 * 128 * .8 * 1.85 + 4096 = 94,724,096

This estimate can differ significantly from your file. The keyed sequence access path depends heavily on the data in your records. The only way to get an accurate size is to load your data and display the file description.

The following is a list of minimum file sizes: Description Physical file without a member Physical file with a single member Keyed sequence access path Minimum Size 8192 bytes 20480 bytes 12288 bytes

Note: Additional space is not required for an arrival sequence access path. In addition to the file sizes, the system maintains internal formats and directories for database files. (These internal objects are owned by user profile QDBSHR.) The following are estimates of the sizes of those objects: For any file not sharing another file's format: Format size = (96 x number of fields) + 4096 For files sharing their format with any other file: Format sharing directory size = (16 x number of files sharing the format) + 3856 For each physical file and each physical file member having a logical file or logical file member built over it: Data sharing directory size = (16 x number of files or members sharing data) + 3856 For each file member having a logical file member sharing its access path: Access path sharing directory size = (16 x number of files or members sharing access path) + 3856