Managing auxiliary storage pools

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

ASPs Using ASPs helps protect your data. By separating libraries, documents, or other objects in an ASP, you protect them from data loss should a disk unit in a different ASP fail. 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 on the disk units in each ASP. Independent ASPs are unique in that you can make them available or unavailable as you need the information. This allows you to store 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, allowing you to dedicate the disk units in the ASP exclusively for the use of 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 can mean 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.