Filter
Top Products
A DMS table space containing user-defined tables and data can be defined as:
v A regular table space to store any table data, and optionally, index data
v A large table space to store long field or LOB data, or index data
When designing your DMS table spaces and containers, you should consider the
following:
v The database manager uses striping to ensure an even distribution of data across
all containers.
v The maximum size of regular table spaces is 64 GB for 4 KB pages, 128 GB for 8
KB pages, 256 GB for 16 KB pages, and 512 GB for 32 KB pages. The maximum
size of large table spaces is 2 TB.
Unlike SMS table spaces, the containers that make up a DMS table space do not
have to be the same size. However, the use of unequal container sizes is not
usually recommended because it results in uneven striping across the containers,
and results in suboptimal performance. If any container is full, DMS table spaces
use the available free space from other containers.
v Because space is preallocated, it must be available before the table space can be
created. When using device containers, the device must also exist with enough
space for the definition of the container. Each device can have only one
container defined on it.
To avoid wasted space, the size of the device and the size of the container
should be equivalent. If, for example, the device is allocated with 5000 pages,
and the device container is defined to allocate 3000 pages, 2000 pages on the
device will not be usable.
By default, one extent in every container is reserved for overhead. Only full
extents are used. For optimal space management, use the following formula to
determine an appropriate size when allocating a container:
extent_size * (n + 1)
In this formula:
– extent_size is the size of each extent in the table space
– n is the number of extents that you want to store in the container
v Device containers must use logical volumes with a "character-special interface,"
and not physical volumes.
You can use files instead of devices with DMS table spaces. No operational
difference exists between a file and a device; however, a file can be less efficient
because of the run-time overheads associated with the file system. Files are
useful when devices are not directly supported, a device is not available,
maximum performance is not required, or you do not want to set up devices.
If your workload involves LOBs or LONG VARCHAR data, you can derive
performance benefits from file system caching.
Automatic Storage Management (ASM)
Automatic storage grows the size of your database across disk and file systems. It
removes the need to manage storage containers manually by taking advantage of
the performance and flexibility of database managed storage. In DB2 9.x, automatic
storage is enabled by default.
A database needs to be enabled for automatic storage when it is created. DB2 9.5
and DB2 9.7 enable automatic storage by default when you create new databases.
46 Sterling B2B Integrator: Performance Management