Recommended structure for independent disk pools

The recommended structure for using independent disk pools is to place the majority of your application data objects into independent disk pools and a minimal number of nonprogram objects in system disk pool and basic user disk pools, which is the system disk pool and all configured basic disk pools.

The system disk pool and basic user disk pools (SYSBAS) should contain primarily operating system objects, licensed program libraries, and few user libraries. This structure yields the best possible protection and performance. Application data is isolated from unrelated faults and can also be processed independently of other system activity. Vary on and switchover times are optimized with this structure.

Other advantages of this structure are:

  • No library in the system disk pool is switchable.
  • Since a database network cannot span an independent disk pool boundary, entire database networks are contained within disk pool groups.
  • Coding of application transactions are simplified since all data libraries are contained within a single disk pool group.
  • Library names can be duplicated across disk pool groups, but not between a disk pool group and the libraries in SYSBAS.

This recommended structure does not exclude other configurations. For example, you might start by migrating only a small portion of your data to a disk pool group and keeping the bulk of your data in SYSBAS. This is certainly supported. However, you should expect longer vary-on and switchover times with this configuration since additional processing is required to merge database cross-reference information into the disk pool group.

Structuring disk pool groups

A system supports up to 223 independent disk pools, any number of which can be primary, secondary, or user-defined file system (UDFS) disk pools. Therefore, you have significant flexibility in how you place your data into independent disk pools and how you structure disk pool groups. For example, all application data might be placed in a single disk pool group which consists of one primary disk pool and one secondary disk pool. Alternatively, you might create several disk pool groups, some with only a primary disk pool and some with one or more secondary disk pools.

Consider the following factors when planning the placement of your data in disk pools:

  • If an application consists solely of data in user-defined file systems and the data is not to be journaled, a UDFS disk pool might be the best choice. There is less overhead associated with a UDFS disk pool. There is also less extendibility since the UDFS disk pool cannot contain any library-based objects.
  • If you have an application with multiple instances of the application data that you want to keep separate, then you should consider a separate disk pool group for each data instance. See Dedicated independent disk pools for an example of this scenario.
  • If you have multiple applications and the application data is independent, a separate disk pool group for each application might be the appropriate answer. One application's data is then isolated from other applications and each application is unaffected by actions on others. The application data can therefore be brought online, taken offline, or switched without affecting other applications.
  • If you have multiple applications with interdependent data objects, the data for those applications should be combined into a single disk pool group.
  • You can use secondary disk pools to separate data objects into different storage domains and thus achieve better performance. The normal use of this is to separate your journal receivers onto different disk units from the data being journaled by placing the journal receivers in a secondary disk pool. However, you might also separate other parts of your application onto different disk units providing that they are in different libraries and the following journaling dependency is satisfied.
  • Objects being journaled and the journal for those objects must be on the same disk pool.