Troubleshooting
Problem
IBM Tivoli Storage Manager requires certain behaviors of storage subsystems for database volumes, recovery log volumes, and DISK device class storage pool volumes. Similar, but slightly relaxed requirements, must be satisfied for storage pool volumes of FILE device types. IBM Tivoli Storage Manager requires that I/O operation results are reported synchronously and accurately. For database and recovery log volumes, unreported or asynchronously reported write errors that result in data not being permanently committed to the storage subsystem may result in catastrophic failure. These failures may range from internal processing errors to the inability to restart the server. Depending upon the nature of the error, this may also result in the loss of all or some of the data stored in ITSM.
Cause
IBM Tivoli Storage Manager requires that the writes performed for database, recovery log and DISK device class storage pool volumes be nonvolatile. Data must be permanently committed to the storage known to IBM Tivoli Storage Manager. IBM Tivoli Storage Manager has many of the attributes of a database system and the data relationships that are maintained require that data written as a group be permanently resident as a group or not resident as a group. Intermediate states produce data integrity issues. The requirement is that data be permanently resident following each individual operating-system write API invocation. Storage used for FILE device type storage pool volumes has a slightly relaxed requirement. Data must be permanently resident following an operating system flush API invocation. This API is used at key processing points within the IBM Tivoli Storage Manager application. This API is used when data is to be permanently committed to storage and kept in synchronization with database and log records which have already been permanently committed to disk storage. For subsystems that use caches of various types, Tivoli Storage Manager requires that the data be permanently committed by the write APIs (for database, recovery log, and DISK device class storage pool volumes) and by the flush API (for FILE device class storage pool volumes). IBM Tivoli Storage Manager uses write-through flags internally when using storage for the database, recovery log, and DISK device class storage pool volumes. In cases where nonvolatile cache is used to safeguard I/O writes to a device, if the nonvolatile cache is battery protected and the power is not restored before the battery is exhausted, data for the I/O operation may be lost. This would be the same case as having uncommitted storage resulting in data integrity issues.
Resolving The Problem
To properly write to the IBM Tivoli Storage Manager database, recovery log, and DISK device class storage pool volumes, the operating system API write invocation must synchronously and accurately report the outcome of the operation. Similarly, the operating system API flush invocation for FILE device type storage pool volumes must also synchronously and accurately report the outcome of the operation. A successful result from the operating system API for either write or flush must guarantee that the data is permanently committed to the storage subsystem.
Contact the vendor for the disk subsystem if there are questions or concerns about whether or not the stated requirements for IBM Tivoli Storage Manager are supported. The vendor should be able to provide the configuration settings to meet these requirements.
Product Synonym
ITSM TSM ADSM
Was this topic helpful?
Document Information
Modified date:
17 June 2018
UID
swg21137676