188 lines
13 KiB
HTML
188 lines
13 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="Optimize performance for commitment control" />
|
||
|
|
<meta name="abstract" content="Using commitment control requires resources that can affect system performance. Several factors affect system performance regarding commitment control." />
|
||
|
|
<meta name="description" content="Using commitment control requires resources that can affect system performance. Several factors affect system performance regarding commitment control." />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakjmanagecom.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakjminimizelock.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakjsizetrans.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakjsoftcommi.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../rzaki/rzakikickoff.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakjokleaveout.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakjallowrdonly.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="rzakjoptimize" />
|
||
|
|
<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>Optimize performance for commitment control</title>
|
||
|
|
</head>
|
||
|
|
<body id="rzakjoptimize"><a name="rzakjoptimize"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Optimize performance for commitment control</h1>
|
||
|
|
<div><p> Using commitment control requires resources that can affect system
|
||
|
|
performance. Several factors affect system performance regarding commitment
|
||
|
|
control. </p>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Factor that does not affect performance</h4><dl><dt class="dlterm">Open a file</dt>
|
||
|
|
<dd>If you open a file without specifying the commit open option, no additional
|
||
|
|
system resource is used even if a commitment definition has been started.
|
||
|
|
For more information about specifying the commit open option, see the appropriate
|
||
|
|
high-level language reference manual.</dd>
|
||
|
|
</dl>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Factors that degrade performance</h4><dl><dt class="dlterm">Journal</dt>
|
||
|
|
<dd>Journaling a file requires system resources. However, in most cases journaling
|
||
|
|
performs better with commitment control than without commitment control. If
|
||
|
|
you specify only after-images, commitment control changes this to both before-images
|
||
|
|
and after-images while commitment control is in effect. Typically this is
|
||
|
|
a space, not a performance, consideration.</dd>
|
||
|
|
<dt class="dlterm">Commit operation</dt>
|
||
|
|
<dd>If any changes were made to journaled resources during the transaction,
|
||
|
|
each commit of a transaction adds two entries to each journal related to those
|
||
|
|
resources. The number of entries added can increase significantly for a large
|
||
|
|
volume of small transactions. You might want to place the journal receivers
|
||
|
|
in a separate disk pool from the journals.</dd>
|
||
|
|
<dt class="dlterm">Rollback operation</dt>
|
||
|
|
<dd>Because commitment control must roll back the pending changes recorded
|
||
|
|
in the database, additional system resources are required whenever a rollback
|
||
|
|
occurs. Also, if record changes are pending, a rollback operation causes additional
|
||
|
|
entries to be added to the journal.</dd>
|
||
|
|
<dt class="dlterm">Start Commitment Control (STRCMTCTL) and End Commitment Control (ENDCMTCTL)
|
||
|
|
commands</dt>
|
||
|
|
<dd>Additional overhead is incurred by the system each time a commitment definition
|
||
|
|
is started using the STRCMTCTL command and is ended using the ENDCMTCTL command.
|
||
|
|
Avoid using the STRCMTCTL and ENDCMTCTL commands for each transaction. Use
|
||
|
|
them only when necessary. You can establish a commitment definition at the
|
||
|
|
beginning of an interactive job and use it for the duration of the job.</dd>
|
||
|
|
<dt class="dlterm">Use more than one journal for commitment control transactions</dt>
|
||
|
|
<dd>With two-phase commit, files that are opened under commitment control
|
||
|
|
can be journaled to more than one journal. However, using more than one journal
|
||
|
|
takes additional system resources to manage the commitment definition. Using
|
||
|
|
more than one journal can also make recovery more complicated.</dd>
|
||
|
|
<dt class="dlterm">Record locking</dt>
|
||
|
|
<dd>Record locking can affect other applications. The number of records locked
|
||
|
|
within a particular job increases the overall system resources used for the
|
||
|
|
job. Applications needing to access the same record must wait for the transaction
|
||
|
|
to end.</dd>
|
||
|
|
<dt class="dlterm">Request SEQONLY(*YES)</dt>
|
||
|
|
<dd> If you request the SEQONLY(*YES) option (by using the OVRDBF command
|
||
|
|
or the application program implicitly attempts to use SEQONLY(*YES)) and the
|
||
|
|
file is opened for input only under commitment control with LCKLVL(*ALL),
|
||
|
|
the option is changed to SEQONLY(*NO). This option can affect the performance
|
||
|
|
of input files because records will not be blocked.</dd>
|
||
|
|
<dt class="dlterm">Request a record-level change for a database file when save-while-active
|
||
|
|
processing is active</dt>
|
||
|
|
<dd>A request to make a record-level change under commitment control for a
|
||
|
|
database file might be delayed if the commitment definition is at a commitment
|
||
|
|
boundary and a save-while-active operation is running in a different job.
|
||
|
|
This can happen when a file is journaled to the same journal as some of the
|
||
|
|
objects on the save request.<div class="note"><span class="notetitle">Note:</span> The Status column on the Work with Active
|
||
|
|
Jobs (WRKACTJOB command) display shows CMTW (commit wait) when a job is being
|
||
|
|
held due to save-while-active checkpoint processing.</div>
|
||
|
|
</dd>
|
||
|
|
<dt class="dlterm">Commit or roll back changes when save-while-active processing is active</dt>
|
||
|
|
<dd>A commit or rollback operation might be delayed at a commitment boundary
|
||
|
|
when a save-while-active operation is running in a different job. This can
|
||
|
|
happen when an API commitment resource was previously added to the commitment
|
||
|
|
definition, unless the API resource was added using the QTNADDCR API and the <var class="varname">Allow
|
||
|
|
normal save processing</var> field has a value of <samp class="codeph">Y</samp>.<p>Because
|
||
|
|
the job is held during the commit or rollback request, and because a commit
|
||
|
|
or rollback request can be performed only for a single commitment definition
|
||
|
|
at a time, jobs with more than one commitment definition with API commitment
|
||
|
|
resources added can prevent a save-while-active operation from completing.</p>
|
||
|
|
<div class="note"><span class="notetitle">Note:</span> If
|
||
|
|
you use the new save with partial transactions feature the object can be saved
|
||
|
|
without ending a commitment definition.</div>
|
||
|
|
</dd>
|
||
|
|
<dt class="dlterm">Request an object-level change when save-while-active processing is active</dt>
|
||
|
|
<dd>A request to make an object-level change under commitment control might
|
||
|
|
be delayed if the commitment definition is at a commitment boundary and a
|
||
|
|
save-while-active operation is running in a different job. This can happen
|
||
|
|
when an object-level change is made while the save-while-active operation
|
||
|
|
is running against the library the object is in. For example, the create SQL
|
||
|
|
table operation under commitment control for table MYTBL in library MYSQLLIB
|
||
|
|
might be delayed when a save-while-active operation is running against library
|
||
|
|
MYSQLLIB.<div class="note"><span class="notetitle">Note:</span> If the wait time exceeds 60 seconds, inquiry message CPA8351
|
||
|
|
is sent to ask the user whether to continue waiting or cancel the operation.</div>
|
||
|
|
</dd>
|
||
|
|
<dt class="dlterm">Add an API resource using the QTNADDCR API</dt>
|
||
|
|
<dd>A request to add an API commitment resource using the QTNADDCR API might
|
||
|
|
be delayed if all commitment definitions for the job are at a commitment boundary
|
||
|
|
and a save-while-active operation is running in a different job.<div class="note"><span class="notetitle">Notes:</span> <ol><li>If the wait time exceeds 60 seconds, inquiry message CPA8351 is sent to
|
||
|
|
ask the user whether to continue waiting or cancel the operation.</li>
|
||
|
|
<li>This does not apply to API resources that were added using the QTNADDCR
|
||
|
|
API if the <var class="varname">Allow normal save processing</var> field has a value
|
||
|
|
of <samp class="codeph">Y</samp>.</li>
|
||
|
|
</ol>
|
||
|
|
</div>
|
||
|
|
</dd>
|
||
|
|
</dl>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Factors that improve performance</h4><dl><dt class="dlterm">Use a default journal</dt>
|
||
|
|
<dd>Using a default journal can help performance if you close and reopen all
|
||
|
|
files under commitment control while the commitment definition is active.
|
||
|
|
However, using a default journal with OMTJRNE(*NONE) degrades the performance
|
||
|
|
of commit and rollback operations.</dd>
|
||
|
|
<dt class="dlterm">Select a last agent</dt>
|
||
|
|
<dd>Performance is enhanced when a last agent is selected because fewer interactions
|
||
|
|
between the system and the last agent are required during a commit operation.
|
||
|
|
However, if a communications failure occurs during a commit operation, the
|
||
|
|
commit operation will not complete until resynchronization completes, regardless
|
||
|
|
of the value of the wait for outcome option. Such a failure is rare but this
|
||
|
|
option allows the application writer to consider the negative impact of causing
|
||
|
|
the user to wait indefinitely for the resynchronization to complete when a
|
||
|
|
failure does occur. Weigh this against the performance enhancement that is
|
||
|
|
provided by last agent optimization during successful commit operations. This
|
||
|
|
consideration is generally more significant for interactive jobs than for
|
||
|
|
batch jobs.<p>The default is that a last agent is permitted to be selected
|
||
|
|
by the system but the user can modify this value using the QTNCHGCO API.</p>
|
||
|
|
</dd>
|
||
|
|
<dt class="dlterm">Not use the wait for outcome option</dt>
|
||
|
|
<dd>When remote resources are under commitment control, performance is improved
|
||
|
|
when the Wait for Outcome option is set to <samp class="codeph">N</samp> (No) and all
|
||
|
|
remote systems support presumed abort. The Wait for Outcome option is set
|
||
|
|
to N by the system for DRDA<sup>®</sup> and DDM application when the first connection is
|
||
|
|
made to a remote system. APPC applications must explicitly set the Wait for
|
||
|
|
Outcome option, or the default value of <samp class="codeph">Y</samp> will be used.</dd>
|
||
|
|
<dt class="dlterm">Select the OK to Leave Out option</dt>
|
||
|
|
<dd>Performance is improved when the OK to Leave Out option is selected.</dd>
|
||
|
|
<dt class="dlterm">Select the Vote Read Only option</dt>
|
||
|
|
<dd>Performance is improved when the Vote Read Only option is selected.</dd>
|
||
|
|
</dl>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<ul class="ullinks">
|
||
|
|
<li class="ulchildlink"><strong><a href="rzakjminimizelock.htm">Minimize locks</a></strong><br />
|
||
|
|
A typical way to minimize record locks is to release the record lock. (This technique does not work if LCKLVL(*ALL) has been specified.)</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="rzakjsizetrans.htm">Manage transaction size</a></strong><br />
|
||
|
|
Another way to minimize record locks is to manage the size of the transaction.</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="rzakjsoftcommi.htm">Soft commit</a></strong><br />
|
||
|
|
You can improve the performance of database transactions with soft commit. Soft commit limits the number of times that the system writes journal entries associated with a transaction to disk.</li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzakjmanagecom.htm" title="Manage a system with commitment control by using these instructions.">Manage transactions and commitment control</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relconcepts"><strong>Related concepts</strong><br />
|
||
|
|
<div><a href="../rzaki/rzakikickoff.htm">Journal management</a></div>
|
||
|
|
<div><a href="rzakjokleaveout.htm" title="Normally, the transaction manager at every location in the transaction program network participates in every commit or rollback operation. To improve performance, you can set up some or all locations in a transaction to allow the transaction manager to indicate OK to leave out.">Commitment definition for two-phase commit: Indicate OK to leave out</a></div>
|
||
|
|
<div><a href="rzakjallowrdonly.htm" title="Normally, a transaction manager participates in both phases of commit processing. To improve the performance of commit processing, you can set up some or all locations in a transaction to allow the transaction manager to vote read-only.">Commitment definition for two-phase commit: Allow vote read-only</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|