Show TOC

Process documentationSpace Management with DB2 for z/OS Locate this document in the navigation structure

 

Space management might not at first seem to be an area of relevance for high availability. However, if neglected, it can lead to downtime. For example, if a database object needs to expand, but is not able to do so, applications cannot continue writing to the database and you quickly have to make more space available.

You can manage space for the SAP system with DB2 for z/OS using either of the following:

  • DB2 itself, known as DB2-managed data

  • Data Facility Storage Management Subsystem (DFSMS), which is system-managed storage, known as SMS-managed data

SAP does not support the DB2 method user-managed data for the SAP system.

Storage Management Subsystem (SMS) is the IBM automated approach to managing auxiliary storage such as disk space. It uses software programs to manage data security, placement, migration, backup, recall, recovery, and deletion. Using these functions, SMS makes sure that current data is available when needed and obsolete data is removed from storage.

In this section, both SMS-managed and DB2-managed data are described. Both options provide a high degree of automation. We recommend you to use SMS-managed data if possible.

With DB2 for z/OS the data to be managed consists of:

  • SAP and DB2 system data (tablespaces and indexspaces)

  • DB2 bootstrap dataset (BSDS)

  • Catalog and directory data

  • Image copies (that is, database backups)

  • Archive logs

All of these can be managed by SMS. However, with both SMS-managed and DB2-managed data it is still possible to run out of space:

  • With SMS-managed data, an SMS storage group can fill up.

  • With DB2-managed data, a DB2 stogroup (that is, a storage group) can fill up.

In both cases, a dataset can reach its maximum number of extents, when you must provide more space as described below.

Process

  1. If all the volumes in a DB2 stogroup (DB2-managed data only) are full:

    1. You add additional volumes by executing the following SQL statement:

      ALTER STOGROUP <FULL_STOGROUP> ADD VOLUMES (<VOLID_NEW1>, <VOLID_NEW2>, ...)

    2. You prevent this happening again by using transaction DB02 to check each DB2 stogroup for sufficient free space.

      Note Note

      A DB2 stogroup is a collection of one or more volumes (that is, disks). If all the volumes in a stogroup are full, any transaction that writes data to tables or indexes associated with that stogroup fails.

      End of the note.
  2. If an SMS storage group (SMS-managed data only) is full:

    1. You add additional volume(s) to the full storage group by using the DFSMS application or the appropriate DFSMS commands.

    2. You prevent this happening again by checking each SMS storage group for sufficient free space. Depending on the granularity of your SMS storage groups, you can significantly reduce the number of objects to check for available free space, compared to DB2-managed data.

      Note Note

      An SMS storage group is a collection of one or more volumes. If all the volumes in an SMS storage group are full, transactions fail when attempting to write data to tables or indexes in that storage group.

      End of the note.
  3. You monitor your tablespaces and indexes carefully with a suitable monitor, such as those mentioned above. Check for scattering of rows in a tablespace or indexspace caused by updates. Scattering causes performance degradation.

  4. Online reorganization

    The DB2 online reorganization allows the SAP system read-write access to the data during most of the time it is running. The online reorganization makes a “shadow copy” of the tablespace and reorganizes this copy. After the reorganization of the shadow copy is complete, DB2 reproduces changes from the original tablespace to the shadow copy using the DB2 recovery log. During this action, the SAP system has full read-write access to the data. During the very last updates to the shadow copy, DB2 only allows read-only data access.

    After this, DB2 switches from the original dataset to the shadow copy. During the switch phase, the SAP system has no access to the tablespace. If you need to reorganize SAP tablespaces or indexes, use online reorganization because this increases the availability of SAP data.

  5. If required, you separate tables.

    Most DB2 utilities, such as REORG, operate with tablespaces rather than tables. DB2 monitoring is better supported for tablespaces than for tables. Therefore, if a tablespace in a multi-table tablespace becomes very large, grows rapidly in size, has to be reorganized frequently, or is accessed very often, you can move it to a single-table tablespace. Moving tables from a multi-table tablespace to a single-table tablespace involves moving the table data. Depending on the table size, this can cause significant downtime.

    All SAP tables that are not SAP-buffered are in single-table tablespaces by default. Therefore, you very rarely need to separate tables.

    With DB2 V9 and SAP NetWeaver Basis Release 7.10, each table has its own tablespace.

More Information

For more information on this topic, see the section Space Management in SAP Database Administration Guide for SAP NetWeaver on IBM DB2 for z/OS