Hpss Metadata Space; 1.Sms Versus Dms Space; 2.'Cfg' Database Allocation; 3.'Subsys' Database Allocation - IBM High Performance Storage System HPSS Installation Manual

Section 5.3.1.2: Install HPSS Documentation and DB2 Software on page 141. The tables and indexes
are separated into separate logical volumes/partitions to ease future expansion of the database and to
maximize performance of database operations.
For Linux, access to a /dev/hdxy partition is through the Linux buffered I/O system. While this is an
appropriate access method for a filesystem that supports journaled logging, for DB2 and Mover
accesses, non-buffered IO is required. Linux, up to release RHEL 4.0, has provided 'raw device'
access mode through the use of the 'raw' command and interface. Before DB2 uses the partitions
defined in the Figures 5 through Figure 8, the mapping of the /dev/hdxy device and the raw interface
must be configured by the administrator.
Though RHEL 4.0 and later supports the LVM manager, HPSS configurations have not attempted to
use logical volumes created on Linux by LVM for DB2 storage and their use is not recommended at
this time.

3.5.4. HPSS Metadata Space

During the HPSS planning phase, it is important to properly assess how much disk space will be
required by DB2 to store HPSS metadata. The first step in this process is to understand the metadata
tables managed by DB2. The sections that follow explain the metadata table layout and how best to
estimate disk space allocation to support these tables.
3.5.4.1. SMS versus DMS Space
DB2 table spaces can be allocated either as System Managed Space (SMS) or Database Managed
Space (DMS). The SMS allocation method uses a local filesystem which is managed by the operating
system. DB2 creates files in the filesystem to store the tables and indexes. In the DMS allocation
method, DB2 manages raw disk space directly, bypassing the operating system's buffers and
filesystem interface. We recommend the use of SMS for storing short or seldom used tables, and
DMS for storing large tables frequently used tables.
Tables used to define the configuration and policies of the system are typically small. These are
contained in the configuration or global database, usually named 'CFG', and should be allocated in
SMS space. Tables such as the BITFILE or STORAGESEGTAPE tables can be quite large and their
placement must be optimized for performance. These tables are contained in one or more subsystem
databases, usually called 'SUBSYSx' (where x is the subsystem number), and should be allocated in
DMS space.
3.5.4.2. 'CFG' Database Allocation
By default, mkhpss will store the DB2 related files for HPSS in the /var/hpss/hpssdb directory. As
recommended above, this directory should be a separate filesystem of RAID disks. The amount of
space needed will vary somewhat depending upon the number of subsystems in use. For a site with
only one subsystem, the amount of space should be about 1GB. For each additional subsystem, an
additional 1/2GB should be allocated.
3.5.4.3. 'SUBSYS' Database Allocation
HPSS support representatives will provide sites with the "6.2 Sizing Spreadsheet" to help determine
the amount of disk resources required to store the HPSS metadata and what the allocation should be
across the DB2 tablespaces. The total amount of disk space should be allocated as a 'raw logical
volume' on AIX or allocated as a raw device on Linux. The space should be allocated on a RAID or
mirrored disk device. The total space can span several logical devices as necessary. DB2 space can be
allocated using mkhpss which provides the option to define the space or use existing equally sized
HPSS Installation Guide July 2008
Release 6.2 (Revision 2.0) 74