98 lines
6.2 KiB
HTML
98 lines
6.2 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
|
<!DOCTYPE html
|
||
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html lang="en-us" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow" />
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<meta name="DC.Type" content="topic" />
|
||
|
|
<meta name="DC.Title" content="Recommended structure for independent disk pools" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzalyconcepts.htm" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2002, 2006" />
|
||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2002, 2006" />
|
||
|
|
<meta name="DC.Format" content="XHTML" />
|
||
|
|
<meta name="DC.Identifier" content="rzalystructure" />
|
||
|
|
<meta name="DC.Language" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
|
<title>Recommended structure for independent disk pools</title>
|
||
|
|
</head>
|
||
|
|
<body id="rzalystructure"><a name="rzalystructure"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Recommended structure for independent disk pools</h1>
|
||
|
|
<div><p id="rzalystructure__para1"><a name="rzalystructure__para1"><!-- --></a>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.</p>
|
||
|
|
<p>Other advantages of this structure are:</p>
|
||
|
|
<ul><li>No library in the system disk pool is switchable. </li>
|
||
|
|
<li>Since a database network cannot span an independent disk pool boundary,
|
||
|
|
entire database networks are contained within disk pool groups. </li>
|
||
|
|
<li>Coding of application transactions are simplified since all data libraries
|
||
|
|
are contained within a single disk pool group. </li>
|
||
|
|
<li>Library names can be duplicated across disk pool groups, but not between
|
||
|
|
a disk pool group and the libraries in SYSBAS. </li>
|
||
|
|
</ul>
|
||
|
|
<p id="rzalystructure__para2"><a name="rzalystructure__para2"><!-- --></a>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. </p>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Structuring disk pool groups</h4><p>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.</p>
|
||
|
|
<div class="p">Consider the following factors when planning
|
||
|
|
the placement of your data in disk pools: <ul><li>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.</li>
|
||
|
|
<li> 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 <a href="rzalysingle-systemiasps.htm">Dedicated independent disk pools</a> for an example of this scenario.</li>
|
||
|
|
<li>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. </li>
|
||
|
|
<li>If you have multiple applications with interdependent data objects, the
|
||
|
|
data for those applications should be combined into a single disk pool group. </li>
|
||
|
|
<li>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. </li>
|
||
|
|
<li>Objects being journaled and the journal for those objects must be on the
|
||
|
|
same disk pool.</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzalyconcepts.htm">Independent disk pools</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|