Managing auxiliary storage pools

You can use system service tools (SST) and dedicated service tools (DST) or IBM Navigator for i to manage auxiliary storage pools (ASPs).

By separating libraries, documents, or other objects in an ASP, you protect them from data loss if a disk unit in a different ASP fails. The importance of protecting the data in the ASP and the capacity of the ASP are factors in determining what protection mechanisms (mirroring or device parity, for example) you choose to implement. You can make independent ASPs available or unavailable as you need the information in them. You can take low-usage data offline until it needs to be accessed, thus reducing system start time. In a clustered environment, you can configure independent ASPs to switch between systems.

Using ASPs also increases performance. You can place libraries or objects in an ASP and the ASP is used exclusively for those objects. If you do extensive journaling, a dedicated disk unit for the journal receiver can also improve journaling performance.

Note: Placing many active journal receivers in the same user ASP is not productive. The resulting contention between writing to more than one receiver in the ASP can slow system performance. For maximum performance, place each active journal receiver in a separate user ASP.

If the amount of data in a storage pool increases, you might need to increase the size of the storage pool. Conversely, if data in a storage pool decreases, you might want to decrease the size of that storage pool and use the disk space elsewhere.

Changing the size of an ASP by adding a disk unit, removing a disk unit, moving a disk unit, or deleting an ASP from the system. You must typically have QSECOFR authority to access these tasks.