Chunk and Dbspace Configuration

All the data that resides in an Informix database is stored on disk. The Optical Subsystem also uses a magnetic disk to access TEXT or BYTE data that is retrieved from optical media. The speed at which the database server can copy the appropriate data pages to and from disk determines how well your application performs.

Disks are typically the slowest component in the I/O path for a transaction or query that runs entirely on one host computer. Network communication can also introduce delays in client/server applications, but these delays are typically outside the control of the database server administrator. For information on actions that the database server administrator can take to improve network communications, see Network Buffer Pools and Connections and CPU Utilization.

Disks can become overused or saturated when users request pages too often. Saturation can occur in the following situations:

• You use a disk for multiple purposes, such as for both logging and active database tables.
• Disparate data resides on the same disk.
• Table extents become interleaved.

The various functions that your application requires, as well as the consistency-control functions that the database server performs, determine the optimal disk, chunk, and dbspace layout for your application. The more disks that you make available to the database server, the easier it is to balance I/O across them. For more information on these factors, see Table Performance Considerations.

This section outlines important issues for the initial configuration of your chunks, dbspaces, and blobspaces. Consider the following issues when you decide how to lay out chunks and dbspaces on disks:

• Placement and mirroring of critical data
• Load balancing
• Reduction of contention
• Ease of backup and restore

Together with round-robin fragmentation, you can balance chunks over disks and controllers, saving time and handling errors. Placing multiple chunks on a single disk can improve throughput.

While it is recommended that you use raw disk devices on UNIX to achieve better performance, recent advances in I/O caching for cooked writes can provide similar if not better performance. To determine the best device performance, perform benchmark testing on the system with both types of devices for the dbspace and table layout.