You are on page 1of 10

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

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 high- level 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 variable- length 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.

Record A record is a group of related data within a file. From the perspective of

Database file sizes

The following database file maximums should be kept in mind when designing files on the iSeries server:

Description

Maximum Value

Number of bytes in a record

32,767 bytes

Number of fields in a record format

8,000 fields

Number of key fields in a file

120 fields

Size of key for physical and logical files

2000 characters 1

Size of key for ORDER BY (SQL) and KEYFLD (OPNQRYF)

10,000 bytes

Number of records contained in a file member

4,294,967,294 records 2

Number of bytes in a file member

1,869,162,846,624 bytes 3

Number of bytes in an access path

1,099,511,627,776 bytes 3 5

Number of keyed logical files built over a physical file member

3,686 files

Description
Description

Maximum Value

Number of physical file members in a logical 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

Maximum number of members in a physical or logical file

Maximum number of constraints per physical file

Maximum number of triggers per physical file

Maximum number of recursive insert and update trigger calls

32

members

256

members

32,766 bytes 4

63

digits

500,000

32,767

300

constraints

300

triggers

200

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.

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

: 1

2

Description
Description

Maximum Value

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).

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

10 + (.8 x key length)

2,867,200,000

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

Three-byte Index

Four-byte Index

NodeSize

3

4

LogicalPageHeaderSize

16

64

LimbPageUtilization

.75 * LogicalPageSize

.75 * LogicalPageSize

LeafPageUtilization

.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

Key Length

*MAX4GB (3-byte) LogicalPageSize

*MAX1TB (4-byte) LogicalPageSize

– 500

1

  • 4096 bytes

8192

bytes

- 1000

501

  • 8192 bytes

bytes

16384

1001

- 2000

16384

bytes

32768

bytes

The Logical Page Sizes in Table 1 generate the following LimbPageUtilizations:

Key Length

*MAX4GB (3-byte) LimbPageUtilization

*MAX1TB (4-byte) LimbPageUtilization

1

– 500

  • 3072 bytes

6144

bytes

501

- 1000

  • 6144 bytes

  • 12288 bytes

1001

- 2000

12288

bytes

  • 24576 bytes

The LogicalPageSizes in Table 1 generate the following LeafPageUtilizations:

Key Length
Key Length

*MAX4GB (3-byte) LeafPageUtilization

*MAX1TB (4-byte) LeafPageUtilization

1 – 500
1 – 500
3072 bytes
3072 bytes
6554 bytes
6554 bytes

Key Length

*MAX4GB (3-byte) LeafPageUtilization

*MAX1TB (4-byte) LeafPageUtilization

501 - 1000

6144 bytes

  • 13107 bytes

1001 - 2000

12288 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

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)

  • - 4 * (6554 - 64 + 2 * 4) = 500,000 * 128 *

2

*

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

Minimum Size

Physical file without a member

8192 bytes

Physical file with a single member

20480 bytes

Keyed sequence access path

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