ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzaki_5.4.0.1/rzakidiskpoolrcv.htm

92 lines
7.6 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="concept" />
<meta name="DC.Title" content="Determine the type of disk pool in which to place journal receivers" />
<meta name="abstract" content="Use disk pools (auxiliary storage pool) to control which objects are allocated to which groups of disk units. If you are journaling many active objects to the same journal, the journal receiver can become a performance bottleneck. One way to minimize the performance impact of journaling is to put the journal receiver in a separate disk pool. This also provides additional protection because your objects are on different disk units from the journal receiver, which contains a copy of changes to the objects." />
<meta name="description" content="Use disk pools (auxiliary storage pool) to control which objects are allocated to which groups of disk units. If you are journaling many active objects to the same journal, the journal receiver can become a performance bottleneck. One way to minimize the performance impact of journaling is to put the journal receiver in a separate disk pool. This also provides additional protection because your objects are on different disk units from the journal receiver, which contains a copy of changes to the objects." />
<meta name="DC.Relation" scheme="URI" content="rzakiplnuseaux.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakiiasp.htm" />
<meta name="DC.Relation" scheme="URI" content="../rzaly/rzalymaintain.htm" />
<meta name="DC.Relation" scheme="URI" content="../rzaly/rzalyoverview.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakiobjassnjrn.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakirdiskpool.htm" />
<meta name="copyright" content="(C) Copyright IBM Corporation 2004, 2006" />
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2004, 2006" />
<meta name="DC.Format" content="XHTML" />
<meta name="DC.Identifier" content="rzakidiskpoolrcv" />
<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>Determine the type of disk pool in which to place journal receivers</title>
</head>
<body id="rzakidiskpoolrcv"><a name="rzakidiskpoolrcv"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Determine the type of disk pool in which to place journal receivers</h1>
<div><p>Use disk pools (auxiliary storage pool) to control which objects
are allocated to which groups of disk units. If you are journaling many active
objects to the same journal, the journal receiver can become a performance
bottleneck. One way to minimize the performance impact of journaling is to
put the journal receiver in a separate disk pool. This also provides additional
protection because your objects are on different disk units from the journal
receiver, which contains a copy of changes to the objects.</p>
<p>iSeries™ servers
have several types of disk pools:</p>
<dl><dt class="dlterm">System disk pool</dt>
<dd>The system disk pool contains the operating system. It can also contain
user libraries and objects. The system disk pool is always disk pool number
1.</dd>
<dt class="dlterm">Basic disk pool</dt>
<dd>Basic disk pools are disk pool numbers 2 through 32. A basic disk pool
can be a library or a non library disk pool. The differences are as follows:<ul><li>A library disk pool contains one or more user libraries or user-defined
file systems. It does not contain the operating system. This is the current
recommended method of configuring user disk pools.</li>
<li>A non library disk pool contains no user libraries or user-defined file
systems. It may contain journals, journal receivers, and save files. If you
place a journal receiver in a non library basic disk pool, the journal must
be in either the system disk pool or the same non library disk pool. The journaled
objects must be in the system disk pool.</li>
</ul>
</dd>
<dt class="dlterm">Independent disk pool</dt>
<dd>Independent disk pools are disk pools 33 through 255. If
you use independent disk pools, you can only put journals and journal receivers
on independent disk pools that are library capable. If you are going to place
the journal receiver in a switchable independent disk pool, the journal receiver,
the journal, and journaled object must be in the same disk pool group (though
they do not have to be in the same disk pool).</dd>
</dl>
<p>When disk pools were first introduced, they were called auxiliary storage
pools (ASPs). Only non library user ASPs were available. Many systems still
have this type of ASP. However, recovery steps are more complex for non library
user ASPs. Therefore, for systems implementing journaling for the first time,
library disk pools are recommended.</p>
<p>Journal management and independent disk pools has more specific information
about using journaling with independent disk pools. Manage disk units in disk
pools has specific information about disk pools. The Independent disk pools
topic has detailed information about setting up independent disk pools.</p>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzakiplnuseaux.htm" title="If you are journaling an object, journal management writes a copy of every object change to the journal receiver. It writes additional entries for object level activity, such as opening and closing the object, adding a member, or changing an object attribute. If you have a busy system and journal many objects, your journal receivers can quickly become very large.">Plan for journal use of auxiliary storage</a></div>
</div>
<div class="relconcepts"><strong>Related concepts</strong><br />
<div><a href="rzakiiasp.htm" title="Independent disk pools are disk pools 33 through 255. Independent disk pools can be user-defined file system (UDFS) independent disk pools or library-capable independent disk pools.">Journal management and independent disk pools</a></div>
<div><a href="../rzaly/rzalymaintain.htm">Manage disk units in disk pools</a></div>
<div><a href="../rzaly/rzalyoverview.htm">Independent disk pools</a></div>
<div><a href="rzakiobjassnjrn.htm" title="You can use one journal to manage all the objects you are journaling. Or, you can set up several journals if groups of objects have different backup and recovery requirements. Every journal has a single attached receiver. All journal entries for all objects being managed by the journal are written to the same journal receiver.">Object assignment to journals</a></div>
<div><a href="rzakirdiskpool.htm" title="The receiver configuration is the disk pool the receiver resides in, and how the data for the receiver is spread across the disk arms within that disk pool.">Journal receiver disk pool considerations</a></div>
</div>
</div>
</body>
</html>