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

123 lines
9.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="Journal management and system performance" />
<meta name="abstract" content="Journal management prevents transactions from being lost if your system ends abnormally or has to be recovered. To do this, journal management writes changes to journaled objects immediately to the journal receiver in auxiliary storage. This increases the disk activity on your system and can have a noticeable affect on system performance. Journaling also increases the overhead associated with opening objects and closing objects." />
<meta name="description" content="Journal management prevents transactions from being lost if your system ends abnormally or has to be recovered. To do this, journal management writes changes to journaled objects immediately to the journal receiver in auxiliary storage. This increases the disk activity on your system and can have a noticeable affect on system performance. Journaling also increases the overhead associated with opening objects and closing objects." />
<meta name="DC.Relation" scheme="URI" content="rzakiconcepts.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakisizeoptions.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakijrncache.htm" />
<meta name="DC.Relation" scheme="URI" content="../cl/ovrdbf.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakidiskarm.htm" />
<meta name="DC.Relation" scheme="URI" content="../rzahx/rzahx1.htm" />
<meta name="DC.Relation" scheme="URI" content="../rzaly/rzalydmkickoff.htm" />
<meta name="DC.Relation" scheme="URI" content="http://www.redbooks.ibm.com/abstracts/sg246286.html?Open" />
<meta name="DC.Relation" scheme="URI" content="rzakiperform.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="rzakijrnsysperform" />
<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>Journal management and system performance</title>
</head>
<body id="rzakijrnsysperform"><a name="rzakijrnsysperform"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Journal management and system performance</h1>
<div><p>Journal management prevents transactions from being lost if your
system ends abnormally or has to be recovered. To do this, journal management
writes changes to journaled objects immediately to the journal receiver in
auxiliary storage. This increases the disk activity on your system and can
have a noticeable affect on system performance. Journaling also increases
the overhead associated with opening objects and closing objects.</p>
<p>As the number of objects you are journaling increases, the general performance
of the system can be slower. The time it takes to perform an IPL on your system
can also increase, particularly if your system ends abnormally.</p>
<p>The system takes measures to minimize the performance effect of using journaling
features. For example, the system packages before-images and after-images
and any access path changes for a record in a single write operation to auxiliary
storage. Therefore, journaling access paths and before-images, in addition
to after-images, usually does not cause additional performance overhead. However,
they do add to the auxiliary storage requirements for journaling.</p>
<p> The system also spreads journal receivers across multiple disk units to
improve performance. If you do not specify a maximum receiver-size option,
then the system can place the journal receiver on up to ten disk units in
a disk pool. If you specify a maximum receiver-size option, then the system
can place the journal receiver on up to 100 disk units in a disk pool. </p>
<p>You can take measures to minimize the effect of journaling on your system
performance:</p>
<ul><li>Consider using journal caching. Journal caching is a separately chargeable
feature that causes the system to write journal entries to memory in large
groups. When there are several journal entries in memory then the system writes
journal entries from memory to disk. If the application performs a large number
of changes, this can result in fewer synchronous disk writes resulting in
improved performance. However, when you use journal caching, you sacrifice
single system recovery because the entries that are still in the cache might
be lost on an abnormal IPL.</li>
<li>Do not set the force-write ratio (FRCRATIO) parameter for physical files
that you are journaling. You can let the system manage when to write records
for the physical file to disk because the journal receiver has a force-write
ratio of 1.</li>
<li>Isolate journal receivers in a disk pool that is not the system disk pool,
if the separate disk pool has at least two disk arms. This reduces contention
when accessing the disks. If the separate disk pool does not have at least
two disk arms, there is no performance benefit. For optimal performance, ensure
that your I/O processors have adequate write cache. Performance can be better
if the disk units in the disk pool are protected through device parity protection
rather than mirrored.</li>
<li>Consider using record blocking when a program processes a journaled file
sequentially (SEQONLY(*YES)). When you add or insert records to the file,
the records are not written to the journal receiver until the block is filled.
You can specify record blocking with the Override with Database File (OVRDBF)
command or in some high-level language programs. If you use the OVRDBF command,
do the following: <ul><li>Set the SEQONLY parameter to (*YES).</li>
<li>Use a large enough value for the NBRRCDS parameter to make the buffer
approach the optimal size of 128KB.</li>
</ul>
</li>
<li>Consider minimizing the fixed-length portion of the journal entry using
RCVSIZOPT(*MINFIXLEN) for the journal. When you specify this option, all of
the data that is selectable by the FIXLENDTA parameter is not deposited. Therefore,
that information does not have to be retrieved, benefiting journal performance.</li>
<li>Consider omitting information from the journal entry you do not need using
the OMTJRNE parameter. When you specify the OMTJRNE parameter for database
physical files you will not deposit the file open and close entries which
saves processing as well as disk storage space. Similarly, if you specify
the OMTJRNE parameter for directories and stream files, the object open, close,
and force entries are not deposited.</li>
<li>Ensure you have enough write cache for your I/O processor (IOP).</li>
</ul>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzakiconcepts.htm" title="This topic explains how journal management works, why to use it, and how it affects your system.">Journal management concepts</a></div>
</div>
<div class="relconcepts"><strong>Related concepts</strong><br />
<div><a href="rzakisizeoptions.htm" title="A journal receiver holds journal entries that you might use for recovery and entries that the system might use for recovery. For example, you might use record level entries, such as database record changes, and file level entries, such as the entry for opening or closing a file. Also, the system writes entries that you never see or use, such as entries for explicitly journaled access paths, for SMAPP, or for commitment control.">Receiver size options for journals</a></div>
<div><a href="rzakijrncache.htm" title="Journal caching is separately chargeable feature with which you can specify that the system cache journal entries in main storage, before writing them to disk. Journal caching is option 42 of the i5/OS operating system.">Journal cache</a></div>
<div><a href="rzakidiskarm.htm" title="Journaling affects the disk arms that store the journal receiver.">Frequently asked questions about journaling and disk arm usage</a></div>
<div><a href="../rzahx/rzahx1.htm">Performance</a></div>
<div><a href="../rzaly/rzalydmkickoff.htm">Disk management</a></div>
<div><a href="http://www.redbooks.ibm.com/abstracts/sg246286.html?Open" target="_blank">Striving for Optimal Journal Performance on DB2 Universal Database for iSeries</a></div>
</div>
<div class="reltasks"><strong>Related tasks</strong><br />
<div><a href="rzakiperform.htm" title="There are two main performance objectives for the remote journal function. To provide a timely delivery of journal entries to a target system and to minimize impacts to the journaling throughput on the source system.">Factors that affect remote journal performance</a></div>
</div>
<div class="relref"><strong>Related reference</strong><br />
<div><a href="../cl/ovrdbf.htm">Override with Database File (OVRDBF) command</a></div>
</div>
</div>
</body>
</html>