A database contains user data objects (tables and indexes), and supporting information maintained by the database manager. Specifically, it contains:
Figure 56. The DB2 Server for VSE Database
|
A dbextent is an allocation of actual DASD space. Storage pools are composed of one or more dbextents. The size of a storage pool can be increased by adding more dbextents, or reduced by deleting existing ones. Each dbextent is the primary allocation of a VSAM data set. When dbspaces are assigned to a storage pool and their pages are filled, physical DASD pages are taken from the dbextents of the storage pool.
Storage pools can be defined so that they are either recoverable or nonrecoverable. By default, storage pools are recoverable, that is, the database manager does full recovery for them. For nonrecoverable storage pools, only limited recovery is done. For more information on nonrecoverable storage pools, refer to Nonrecoverable Storage Pools.
A dbspace is a logical allocation of space in the database, divided into 4096-byte blocks called pages. A dbspace is not a real allocation of DASD space, but only an allocation of page tables in the directory. These page tables map logical dbspace pages to DASD locations. The database manager dynamically allocates real DASD storage space to support dbspace pages on a demand basis so unused pages do not occupy DASD space.
Figure 57. Physical Database Concepts
 |
Tables and their indexes are stored in dbspaces. At the beginning of every dbspace are one to eight header pages, which contain control information on the tables and indexes that follow. Next come data pages, which hold the rows of the tables. At the end are index pages, which hold the index entries. A page in a dbspace is defined as a header page, a data page, or a index page, when the dbspace is acquired. Figure 58 shows how information is stored in a dbspace.
Figure 58. Table and Index Storage in a Dbspace
When a table is created, its creator can either assign it to a dbspace explicitly by specifying a dbspace in the CREATE TABLE statement, or can let the database manager assign it to a default dbspace. Any indexes created on the table obtain their storage from the same dbspace as that table.
Figure 57 shows two tables and their indexes in dbspace A, two tables and their indexes in dbspace B, and one table with three indexes in dbspace C.
The potential capacity of a dbspace is fixed when it is defined with the ADD DBSPACE command. A dbspace can hold up to 255 tables along with their indexes.
More than one table can be stored in the same dbspace, but a table cannot reside in multiple dbspaces. If you store multiple tables in a dbspace, be aware that the database manager may store rows from different tables on the same data pages. For performance reasons, it is frequently desirable to have only one table per dbspace. (Index entries from different indexes are never stored on the same page.)
There are three types of dbspaces: private, public, and internal. For private data, there should be one private dbspace reserved for each user. These are locked at the dbspace level, so the database manager does not incur unnecessary overhead while users are accessing their own private data. Any tables that are to be accessed by multiple users who will be doing UPDATE, INSERT, or DELETE operations should be placed in public dbspaces, which have page- or row-level locking to support concurrent access. Internal dbspaces are temporary spaces used only by the database manager to perform tasks such as sorting.