All data in database tables is stored permanently on disk. How fast the database server can copy required data pages from disk and write them back if they change is important in improving performance.
Disks are often the slowest component in the I/O path for a transaction or query, even for queries that run on multi-node database servers.
Disks can become overused or saturated when you use a disk for multiple purposes, such as for both activity logging and active database tables, when data for commonly joined tables resides on the same disk, or when table extents are interleaved.
The various functions that your applications perform, as well as the consistency-control functions that the database server performs, determine the optimal disk, chunk, and dbspace layout for your database.
This section outlines important issues for the initial configuration of your chunks and dbspaces. Consider the following issues when you decide how to lay out chunks and dbspaces on disks:
The number of chunks, dbslices, and dbspaces that you can create is determined by the CONFIGSIZE configuration parameter, and the parameters that override its defaults, MAX_DBSLICES, MAX_CHUNKS, and MAX_DBSPACES.For information about these parameters, refer to the IBM Informix: Extended Parallel Server Administrator's Reference.
If possible in your disk configuration, follow these guidelines:
If possible, create chunks that occupy entire disk partitions. When a chunk coincides with a disk partition or raw device, you can easily track disk-space use, and you avoid errors caused by miscalculated offsets.
If disks are in a RAID or similar array, you might not be able to follow this guideline. Ask your Information Services personnel about the size and stripe location of each logical unit. If logical units are on separate disks, you might be able to create raw devices and chunks of the logical unit size for efficient use by the database server. For information about RAID, see Disk Arrays.
For ease of monitoring and troubleshooting, associate a dbspace with a single chunk if possible. The database server displays I/O statistics for each chunk. This information is useful only if a single table fragment is contained in a single chunk.