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

Page 74
Image 74
IBM HPSS manual Hpss Metadata Space, SMS versus DMS Space, CFG Database Allocation, Subsys Database Allocation