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

127 lines
8.4 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="task" />
<meta name="DC.Title" content="Recovery for journal management after abnormal system end" />
<meta name="abstract" content="This topic describes the recovery actions that take place in the event of an abnormal system end." />
<meta name="description" content="This topic describes the recovery actions that take place in the event of an abnormal system end." />
<meta name="DC.Relation" scheme="URI" content="rzakijrnrecovery.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakirecovrcvdmg.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakirecovjrndmg.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="rzakirecvabnend" />
<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>Recovery for journal management after abnormal system end</title>
</head>
<body id="rzakirecvabnend"><a name="rzakirecvabnend"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Recovery for journal management after abnormal system end</h1>
<div><p>This topic describes the recovery actions that take place in the
event of an abnormal system end.</p>
<div class="section">If the system abnormally ends while you are journaling objects, the
system does the following:</div>
<ol><li class="stepexpand"><span>Brings all journals, journal receivers, and objects you are journaling
to a usable and predictable condition during the IPL or vary on of an independent
disk pool, including any access paths being journaled and in use at the time
the system abnormally ended.</span></li>
<li class="stepexpand"><span>Checks all recently recorded entries in the journal receivers that
were attached to a journal.</span></li>
<li class="stepexpand"><span>Places an entry in the journal to indicate that an abnormal system
end occurred. When the system completes the IPL or vary on of an independent
disk pool, all entries are available for processing.</span></li>
<li class="stepexpand"><span><img src="./delta.gif" alt="Start of change" />Checks that the journal receivers attached
to journals can be used for normal processing of the journal entries. If some
of the objects you are journaling could not be synchronized with the journal,
the system sends message CPF3172 to the history log (QHST) that identifies
the journals that could not be synchronized. If a journal or a journal receiver
is damaged, the system sends a message to the history log identifying the
damage that occurred (message CPF3171 indicates that the journal is damaged,
and messages CPF3173 or CPF3174 indicate that the journal receiver is damaged).
If a journal or journal receiver is found to no longer exist within a library,
the system sends message CPI70EE to the history log.<img src="./deltaend.gif" alt="End of change" /></span></li>
<li class="stepexpand"><span>Recovers each object that was in use at the time the system ended
abnormally, using the normal system recovery procedures for objects.</span> <p>In addition, if an object being journaled was opened for output,
update, or delete operations, the system performs the following functions
so changes to that object will not be lost:</p>
<ol type="a"><li><span>Ensures that the changes appear in the object. Changes that
do not appear in the journal receiver are not in the object.</span></li>
<li><span>Places an entry in the journal receiver that indicates whether
the object was synchronized with the journal. For database files, if the file
could not be synchronized with the journal, the system places message CPF3175
in the history log identifying the failure, and you must correct the problem.
For other journaled objects, the system places message CPF700C in the history
log identifying the failure, and you must correct the problem.</span></li>
</ol>
<p>A synchronization failure can occur if the data portion of the object
is damaged, a journal receiver required to perform the synchronization is
damaged, or the journal is inoperable.</p>
</li>
</ol>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzakijrnrecovery.htm" title="Provides tasks that show you how to use journaling to recover data on your iSeries server.">Recovery operations for journal management</a></div>
</div>
<div class="reltasks"><strong>Related tasks</strong><br />
<div><a href="rzakirecovrcvdmg.htm" title="If a journal receiver becomes damaged, the system sends message CPF8136 or message CPF8137 to the system operator and the job log.">Recover a damaged journal receiver</a></div>
<div><a href="rzakirecovjrndmg.htm" title="If a journal becomes damaged, the system sends message CPF8135 to the system operator and to the job log.">Recover a damaged journal</a></div>
</div>
</div><div class="nested1" xml:lang="en-us" id="recovabnormsysend"><a name="recovabnormsysend"><!-- --></a><h2 class="topictitle2">Recover after abnormal system end</h2>
<div><div class="section">After an abnormal system end, perform the following steps:</div>
<ol><li><span>Perform a manual IPL.</span></li>
<li><span>Check the history log to determine if there are any damaged objects,
objects that are not synchronized, or any damaged journals or journal receivers.</span></li>
<li><span>If necessary, recover the damaged journals or journal receivers
as described in Recover a damaged journal receiver and Recover a damaged
journal.</span></li>
<li><span>If there is a damaged object:</span><ol type="a"><li><span>Delete the object.</span></li>
<li><span>Restore the object from the latest saved version.</span></li>
<li><span>Allocate the object so no one else can access it.</span></li>
<li><span>Restore the needed journal receivers if they are not online.
Journal receivers do not need to be restored in a particular sequence. The
system establishes the receiver chains correctly when they are restored.</span></li>
<li><span>Use the APYJRNCHG or APYJRNCHGX command to apply the changes
to the object.</span></li>
<li><span>Deallocate the object.</span></li>
</ol>
</li>
<li><span>If an object could not be synchronized, use the information in
the history log and in the journal to determine why the object could not be
synchronized and how to proceed with recovery. For example, you may need to
use the DFU or a user-written program to bring a database file to a usable
condition.</span></li>
<li><span>Determine which applications or programs were active, and determine
where to restart the applications from the information in the history log
and in the journal.</span></li>
</ol>
<div class="section"><p>If a journaled access path is in use during an abnormal system
end, that access path does not appear on the Edit Rebuild Access Path display.</p>
<p>If
the maintenance for the access path is immediate or delayed, the system automatically
recovers the access path during IPL or vary on of an independent disk pool.
A status message is displayed for each access path whose maintenance is immediate
or delayed as it is being recovered during an IPL or vary on of an independent
disk pool. The system places message CPF3123 in the system history log for
each access path that is recovered through the journal during the IPL or vary
on of an independent disk pool. This message appears for access paths that
are explicitly journaled and for access paths that are protected by SMAPP.</p>
</div>
</div>
</div>
</body>
</html>