A key responsibility of the database server administrator is to control where the database server stores data. By storing high-use access tables or critical dbspaces (root dbspace, physical log, and logical log) on your fastest disk drive, you can improve performance. By storing critical data on separate physical devices, you ensure that when one of the disks holding noncritical data fails, the failure affects only the availability of data on that disk.
These strategies require the ability to control the location of data. The logical storage unit that provides this ability is the dbspace. The dbspace provides the critical link between the logical and physical units of storage. It allows you to associate physical units (such as chunks) with logical units (such as tables).
As Figure 57 shows, to control the placement of databases or tables, you can use the IN dbspace option of the CREATE DATABASE or CREATE TABLE statements. (See Tables.)
Before you create a database or table in a dbspace, you must first create the dbspace. For more information on how to create a dbspace, see Creating a Dbspace.
A dbspace includes one or more chunks, as Figure 58 shows. You can add more chunks at any time. It is a high-priority task of a database server administrator to monitor dbspace chunks for fullness and to anticipate the need to allocate more chunks to a dbspace. (See Monitoring the Database Server for Disabling I/O Errors.) When a dbspace contains more than one chunk, you cannot specify the chunk in which the data resides.
The database server uses the dbspace to store databases and tables. (See Tables.)
You can mirror every chunk in a mirrored dbspace. As soon as the database server allocates a mirrored chunk, it flags all space in that mirrored chunk as full. See Monitoring Disk Usage.
You can use onutil to perform any of the following tasks related to dbspace management:
The root dbspace is the initial dbspace that the database server creates. The root dbspace is special because it contains reserved pages and internal tables that describe and track all physical and logical units of storage. (For more information on these topics, see Tables and the disk structures and storage chapter in the IBM Informix: Administrator's Reference.) The initial chunk of the root dbspace and its mirror are the only chunks created during disk-space initialization. You can add other chunks to the root dbspace after disk-space initialization.
The following disk-configuration parameters in the ONCONFIG configuration file refer to the first (initial) chunk of the root dbspace:
The root dbspace is also the default dbspace location for any database created with the CREATE DATABASE statement.
The default value for the DBSPACETEMP configuration parameter in Extended Parallel Server is NOTCRITICAL. Therefore, implicit temporary tables do not use the root dbspace in Extended Parallel Server. For more information on temporary tables, refer to Temporary Tables.
Size of the Root Dbspace explains how much space to allocate for the root dbspace. You can also add extra chunks to the root dbspace after you initialize database server disk space.
A temporary dbspace is a dbspace reserved for the exclusive use of temporary tables (see Table Types.)
The database server never drops a temporary dbspace unless it is explicitly directed to do so. A temporary dbspace is temporary only in the sense that the database server does not preserve any of the dbspace contents when the database server shuts down abnormally. Temporary dbspaces are designed exclusively for the storage of temporary tables.
Whenever you initialize the database server, all temporary dbspaces are reinitialized. The database server clears any tables that might be left over from the last time that the database server shut down.
The database server does not perform logical or physical logging for temporary dbspaces. Backup utilities do not include temporary dbspaces as part of a full-system dbspace backup. You cannot mirror a temporary dbspace.
For detailed instructions on how to create a temporary dbspace, see Creating a Temporary Dbspace.
For more information on temporary dbspaces on Extended Parallel Server, see dbspaces for temporary tables in your IBM Informix: Performance Guide.
The database server logs table creation, the allocation of extents, and the dropping of the table for a temporary table in a standard dbspace. In contrast, the database server suppresses all logical logging for implicit temporary tables and explicit temporary tables created with the WITH NO LOG options that reside in a temporary dbspace. Logical-log suppression in temporary dbspaces reduces the number of log records to roll forward during logical recovery as well, thus improving the performance during critical down time.
The database server does not perform any physical logging in temporary dbspaces. This practice helps performance in two ways. First, physical logging itself generates I/O. Reducing I/O always improves performance. Second, whenever the physical log becomes 75 percent full, a checkpoint occurs. Checkpoints require a brief period of inactivity to complete, which can have a negative impact on performance. When temporary tables reside in temporary dbspaces, the database server does not perform physical logging for operations on the temporary tables, thus requiring fewer checkpoints.
Using temporary dbspaces to store temporary tables also reduces the size of your dbspace backup because the database server does not backup temporary dbspaces.
Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]