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 SYSBAS, which is the
system disk pool and all configured basic disk pools. The system disk pool
and basic user disk pools (SYSBAS) would 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
The iSeries™ server
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.