Extents

When you create a table, the database server allocates a fixed amount of space to contain the data to be stored in that table. When this space fills, the database server must allocate space for additional storage. The physical unit of storage that the database server uses to allocate both the initial and subsequent storage space is called an extent. Figure 55 illustrates the concept of an extent.

Figure 55. An Extent That Consists of Six Contiguous Pages on a Raw Disk Device

An extent consists of a collection of contiguous pages that store data for a given table. (See Tables.) Every permanent database table has two extent sizes associated with it. The initial-extent size is the number of kilobytes allocated to the table when it is first created. The next-extent size is the number of kilobytes allocated to the table when the initial extent (and any subsequent extents) becomes full. To specify the initial-extent size and next-extent size, use the CREATE TABLE and ALTER TABLE statements. For more information, see the IBM Informix: Guide to SQL Syntax.

Figure 56 illustrates the following key concepts concerning extent allocation:

• An extent is always entirely contained in a chunk; an extent cannot cross chunk boundaries.
• If the database server cannot find the contiguous disk space that is specified for the next-extent size (six pages in Figure 56), it searches the next chunk in the dbspace for contiguous space.
  Figure 56. Process of Extent Allocation

  

Disabling I/O Errors

Informix divides disabling I/O errors into two general categories: destructive and nondestructive. A disabling I/O error is destructive when the disk that contains a database becomes damaged in some way. This type of event threatens the integrity of data, and the database server marks the chunk and dbspace as down. The database server prohibits access to the damaged disk until you repair or replace the disk and perform a physical and logical restore.

A disabling I/O error is nondestructive when the error does not threaten the integrity of your data. Nondestructive errors occur when someone accidentally disconnects a cable, you somehow erase the symbolic link that you set up to point to a chunk, or a disk controller becomes damaged.

Before the database server considers an I/O error to be disabling, the error must meet two criteria. First, the error must occur when the database server attempts to perform an operation on a chunk that has at least one of the following characteristics:

• The chunk has no mirror.
• The primary or mirror companion of the chunk under question is off-line.

Second, the error must occur when the database server attempts unsuccessfully to perform one of the following operations:

• Seek, read, or write on a chunk
• Open a chunk
• Verify that chunk information on the first used page is valid

  The database server performs this verification as a sanity check immediately after it opens a chunk.

You can prevent the database server from marking a dbspace as down while you investigate disabling I/O errors. If you find that the problem is trivial, such as a loose cable, you can bring the database server offline and then online again without restoring the affected dbspace from backup. If you find that the problem is more serious, such as a damaged disk, you can use onmode -O to mark the affected dbspace as down and continue processing.