183 lines
13 KiB
HTML
183 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="Plan which objects to journal" />
|
||
<meta name="abstract" content="When you plan which objects to journal, consider the following:" />
|
||
<meta name="description" content="When you plan which objects to journal, consider the following:" />
|
||
<meta name="DC.Relation" scheme="URI" content="rzakiplnjrn.htm" />
|
||
<meta name="DC.Relation" scheme="URI" content="rzakijrnap.htm" />
|
||
<meta name="DC.Relation" scheme="URI" content="rzakijrnbi.htm" />
|
||
<meta name="DC.Relation" scheme="URI" content="../rzahf/rzahftrigcontable.htm" />
|
||
<meta name="DC.Relation" scheme="URI" content="rzakiiasp.htm" />
|
||
<meta name="DC.Relation" scheme="URI" content="rzakisndjrne.htm" />
|
||
<meta name="DC.Relation" scheme="URI" content="../rzakj/rzakjcommitkickoff.htm" />
|
||
<meta name="DC.Relation" scheme="URI" content="rzakijklprod.htm" />
|
||
<meta name="DC.Relation" scheme="URI" content="rzakijkldev.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="rzakiplnobjrn" />
|
||
<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>Plan which objects to journal</title>
|
||
</head>
|
||
<body id="rzakiplnobjrn"><a name="rzakiplnobjrn"><!-- --></a>
|
||
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
<h1 class="topictitle1">Plan which objects to journal</h1>
|
||
<div><p>When you plan which objects to journal, consider the following:</p>
|
||
<ul><li>What types of objects you can journal.</li>
|
||
<li>What makes an object a good candidate for journaling.</li>
|
||
<li>What rules for journaling apply to those objects.</li>
|
||
<li>Whether or not to send journal entries for objects the system does not
|
||
journal.</li>
|
||
</ul>
|
||
<div class="section"><h4 class="sectiontitle">Types of objects that are eligible for journaling</h4><p>You
|
||
can journal the following object types:</p>
|
||
<ul><li>Database physical files</li>
|
||
<li>Access paths</li>
|
||
<li>Data areas</li>
|
||
<li>Data queues</li>
|
||
<li>Integrated file system objects (stream files, directories, and symbolic
|
||
links)</li>
|
||
</ul>
|
||
</div>
|
||
<div class="section"><h4 class="sectiontitle">General characteristics that make objects good candidates
|
||
for journaling</h4><ul><li>An object with a high volume of transactions between save operations is
|
||
a good candidate for journaling.</li>
|
||
<li>An object that is difficult to reconstruct the changes made to it, such
|
||
as an object that receives many changes without physical documentation. For
|
||
example, an object used for telephone order entry is more difficult to reconstruct
|
||
than an object used for orders that arrive in the mail on order forms.</li>
|
||
<li>An object that contains critical information. For example, if you restore
|
||
an object back to the last save operation, and the delay from reconstructing
|
||
changes to that object has a negative effect on your operation: that object
|
||
is a good candidate for journaling.</li>
|
||
<li>Objects that relate to other objects on the system. Although the information
|
||
in a particular object may not change often, that object may be critical to
|
||
other, more dynamic objects on the system. For example, many files may depend
|
||
on a customer master file. If you are reconstructing orders, the customer
|
||
master file must include new customers or changes in credit limits.</li>
|
||
<li>Objects that require that all the actions on it be replicated.</li>
|
||
<li>An object, that, after a crash, has a requirement to be recovered to a
|
||
consistent state and have a journal entry show what actions completed.</li>
|
||
<li>An object that can cause a negative consequence to your operation if a
|
||
crash damages that object while the system is in the process of updating it.</li>
|
||
<li>An object for which you want to have an audit trail of changes.</li>
|
||
</ul>
|
||
</div>
|
||
<div class="section"><h4 class="sectiontitle">Considerations for journaling database physical files</h4><ul><li>If you journal one file that participates in a referential constraint,
|
||
you must journal all the related files. Referential constraints are not enforced
|
||
when you apply or remove journaled changes, but the referential integrity
|
||
of those constraints is verified.</li>
|
||
<li>If you journal all related files, the process for applying and removing
|
||
journaled changes keeps the relationships between your database files valid.
|
||
If you do not journal all related files, your referential constraint may show
|
||
a status of <span class="uicontrol">check pending</span> after you apply or remove
|
||
journaled changes. For some types of referential constraints, the system requires
|
||
that you journal all of the related files.</li>
|
||
<li>For a file that has a trigger program, if the trigger program only performs
|
||
processing on object types which can be journaled and applied, you must journal
|
||
all of the objects processed by the trigger program. If the trigger programs
|
||
do additional work that must be reconstructed during a recovery, consider
|
||
using the API support for sending journal entries.</li>
|
||
<li>In general, database source files must not be journaled. If you use the
|
||
Start Source Entry Utility (STRSEU) command to update a member, every record
|
||
in that member is considered changed and every record is journaled to the
|
||
journal. However, if changes to a source file are critical, you can journal
|
||
the file in the same manner as data files.</li>
|
||
</ul>
|
||
</div>
|
||
<div class="section"><h4 class="sectiontitle">Considerations for journaling integrated file system objects</h4><ul><li>When you start journaling on a symbolic link, the link is not followed.
|
||
Therefore if you want to protect the actual object with journaling, you have
|
||
to journal the actual object separately.</li>
|
||
<li>If you want to automatically protect all objects which are created in
|
||
a directory which itself is journaled, consider the use and impacts of the
|
||
inherit journaling attribute that you can associate with a journaled directory.</li>
|
||
<li>Do you want to protect the structure of the directory tree, or just the
|
||
data stored in stream files within that directory structure? If you just want
|
||
to protect the data stored in stream files, then for performances reasons,
|
||
it may be best to only journal the stream files themselves instead of journaling
|
||
changes to each directory in the directory tree. You must consider this question
|
||
when you use the subtree and inherit journaling attributes options on the
|
||
start journaling interfaces.</li>
|
||
<li>You cannot journal objects on a user-defined file system (UDFS) independent
|
||
disk pool. If you want to journal objects in a UDFS, you must use a library
|
||
capable independent disk pool. Journal management and independent disk pools
|
||
has more information about journaling and independent disk pools.</li>
|
||
</ul>
|
||
</div>
|
||
<div class="section"><h4 class="sectiontitle">System objects</h4><p>It is recommended that you do not
|
||
journal changes to IBM™-supplied objects. The system sometimes creates
|
||
and manages these objects differently than user-created objects. The system
|
||
does not assure the recovery of these files even though all recovery activity
|
||
normally succeeds.</p>
|
||
</div>
|
||
<div class="section"><h4 class="sectiontitle">Journal entries for objects the system does not journal</h4><p>Some
|
||
applications depend on information in objects that the server does not journal.
|
||
For example, an application programming interface (API) might use a user space
|
||
to pass data between two jobs.</p>
|
||
<p>You can use the Send Journal Entry (SNDJRNE)
|
||
command or the Send Journal Entry (QJOSJRNE) API to write journal entries
|
||
for these resources. See Send your own journal entries for instructions. If
|
||
you need to perform recovery, you can use a program to retrieve these journal
|
||
entries and make sure these application objects are synchronized with the
|
||
objects you are journaling.</p>
|
||
<p>If you are using commitment control, you
|
||
can use APIs to register these objects as committable resources.</p>
|
||
</div>
|
||
<div class="section"><h4 class="sectiontitle">Before images and access paths</h4><ul><li>Reasons to journal access paths has detailed information about whether
|
||
or not to journal access paths.</li>
|
||
<li>Reasons to journal before-images discusses whether or not to journal before-images</li>
|
||
</ul>
|
||
</div>
|
||
<div class="section"><img src="./delta.gif" alt="Start of change" /><h4 class="sectiontitle">Journaled object limit</h4><p>The journaled
|
||
object limit is the maximum number of objects that can be journaled to one
|
||
journal. You can set the journal object limit to either 250,000
|
||
or 10,000,000. Use the <span class="cmdname">Journal Object Limit (JRNOBJLMT)</span> parameter
|
||
on the <span class="cmdname">Create Journal (CRTJRN)</span> or <span class="cmdname">Change Journal
|
||
(CHGJRN)</span> command to set the maximum number of journaled objects.</p>
|
||
<img src="./deltaend.gif" alt="End of change" /></div>
|
||
<div class="section"><img src="./delta.gif" alt="Start of change" /><h4 class="sectiontitle">Journal recovery count</h4><p>On the CHGJRN
|
||
command, you can use the Journal Recovery Count (JRNRCYCNT) parameter to indicate
|
||
how many journal entries can exist between the last deposited entry and the
|
||
oldest forced entry for a journaled object. A value between 10,000 and 2,000,000,000
|
||
will be allowed. A value of *SYSDFT will also be allowed to reset the journal’s
|
||
recovery count to the system default journal recovery count.</p>
|
||
<img src="./deltaend.gif" alt="End of change" /></div>
|
||
</div>
|
||
<div>
|
||
<ul class="ullinks">
|
||
<li class="ulchildlink"><img src="./delta.gif" alt="Start of change" /><strong><a href="rzakijrnap.htm">Reasons to journal access paths</a></strong><img src="./deltaend.gif" alt="End of change" /><br />
|
||
If you journal access paths, the system can use the journal entries to recover access paths instead of rebuilding them completely.</li>
|
||
<li class="ulchildlink"><img src="./delta.gif" alt="Start of change" /><strong><a href="rzakijrnbi.htm">Reasons to journal before-images</a></strong><img src="./deltaend.gif" alt="End of change" /><br />
|
||
When you journal an object, the system always writes an after-image for every change that is made. You can request that the system write before-image journal entries for database files and data areas. All other object types only journal after-images. This significantly increases the auxiliary storage requirements for journaling.</li>
|
||
</ul>
|
||
|
||
<div class="familylinks">
|
||
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzakiplnjrn.htm" title="This topic provides you with the information you need to ensure you have enough disk space, to plan what objects to journal, and to plan which journaling options to use.">Plan for journal management</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="rzakisndjrne.htm" title="Use the Send Journal Entry (SNDJRNE) command or the Send Journal Entry (QJOSJRNE) API to add your own entries to a journal. The system places these entries in the journal's attached journal receiver along with the system-created journal entries.">Send your own journal entries</a></div>
|
||
<div><a href="../rzakj/rzakjcommitkickoff.htm">Commitment control</a></div>
|
||
<div><a href="rzakijklprod.htm" title="JKLPROD is the system that JKL uses for all of their customer orders and where their business applications are installed (inventory control, customer orders, contracts and pricing, accounts receivable). The information about this server is extremely critical to their business and changes often.">JKLPROD</a></div>
|
||
<div><a href="rzakijkldev.htm" title="JKLDEV is JKL's development server. Though it does not require 24x7 availability, the data on it represent many person hours of work by the developers. Therefore it is important that in the event of a crash, the system be brought to a current state. Also, since it is a development server, changes to the data occur often.">JKLDEV</a></div>
|
||
</div>
|
||
<div class="relref"><strong>Related reference</strong><br />
|
||
<div><a href="../rzahf/rzahftrigcontable.htm">Work with triggers and contraints</a></div>
|
||
</div>
|
||
</div>
|
||
</body>
|
||
</html> |