ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzaiu_5.4.0.1/rzaiurzaiu365.htm

129 lines
8.8 KiB
HTML
Raw Normal View History

2024-04-02 14:02:31 +00:00
<?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="Considerations for recovery procedures after eliminating save-outage time" />
<meta name="DC.Relation" scheme="URI" content="rzaiurzaiu348.htm" />
<meta name="DC.Relation" scheme="URI" content="rzaiurzaiu348.htm" />
<meta name="DC.Relation" scheme="URI" content="rzaiurzaiu313.htm" />
<meta name="DC.Relation" scheme="URI" content="rzaiurzaiu358.htm" />
<meta name="DC.Relation" scheme="URI" content="rzaiurzaiu347.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="rzaiu365" />
<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>Considerations for recovery procedures after eliminating save-outage
time</title>
</head>
<body id="rzaiu365"><a name="rzaiu365"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Considerations for recovery procedures after eliminating save-outage
time</h1>
<div><p>In general, the server cannot preserve application boundaries because they
are defined by the application. It is left up to you to provide for any of
the appropriate recovery procedures when you use the save-while-active function
to eliminate your save-outage time.</p>
<p>This topic discusses some of the considerations for save-while-active recovery
procedures. Additional recovery procedures are needed to bring the objects
to a consistent state in relationship to each other after the restore operation
is completed. You must determine the exact steps that are required for these
recovery procedures at the time the objects are being saved. The recovery
procedures must be performed after the objects from the save-while-active
media are restored, but before the objects are used by any application.</p>
<p>You need to consider these recovery procedures if you are using the save-while-active
function to eliminate your save-outage time:</p>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzaiurzaiu348.htm" title="Use the save-while-active function to eliminate your save-outage time.">Eliminate your save-outage time</a></div>
</div>
<div class="relconcepts"><strong>Related concepts</strong><br />
<div><a href="rzaiurzaiu313.htm" title="This information tells you what happens when you use the save-while-active function to eliminate your save-outage time.">Eliminating save-outage time: Overview</a></div>
<div><a href="rzaiurzaiu347.htm">Example: Restore libraries after reducing save-outage time</a></div>
</div>
<div class="reltasks"><strong>Related tasks</strong><br />
<div><a href="rzaiurzaiu358.htm">Recommended recovery procedures after eliminating save-outage time</a></div>
</div>
<div class="relref"><strong>Related reference</strong><br />
<div><a href="rzaiurzaiu348.htm" title="Use the save-while-active function to eliminate your save-outage time.">Eliminate your save-outage time</a></div>
</div>
</div><div class="nested1" xml:lang="en-us" id="conceptSunDec051619142004"><a name="conceptSunDec051619142004"><!-- --></a><h2 class="topictitle2">If you use commitment control within your application, force one checkpoint
during the save operation, and wait for transaction boundaries</h2>
<div><p>If you specify SAVACT(*SYNCLIB) for the save operation, then all the data
is saved with one common checkpoint. If you use commitment control to define
all of the application boundaries and wait for transaction boundaries during
the save operation, the recovery procedure is a basic restore of your objects.</p>
</div>
</div>
<div class="nested1" xml:lang="en-us" id="waitfortransactionboundaries"><a name="waitfortransactionboundaries"><!-- --></a><h2 class="topictitle2">If you use commitment control within your application, allow multiple
checkpoints during the save operation, and wait for transaction boundaries</h2>
<div><p>If you specify SAVACT(*SYSDFN) or SAVACT(*LIB) for the save operation,
then the data is saved with multiple checkpoints. If you use commitment control
to define all of the application boundaries and wait for transaction boundaries
during the save operation, the recovery procedure requires you to apply or
remove journaled changes to reach a common application boundary. </p>
</div>
</div>
<div class="nested1" xml:lang="en-us" id="donotwaitfortransaction"><a name="donotwaitfortransaction"><!-- --></a><h2 class="topictitle2">If you use commitment control within your application, force one checkpoint
during the save operation, and do not wait for transaction boundaries</h2>
<div><p>If you specify SAVACT(*SYNCLIB) for the save operation, then the data is
saved with one common checkpoint. If you use commitment control and specify
*NOCMTBDY on the SAVACTWAIT parameter for the save operation, the recovery
procedure requires you to apply or remove journaled changes to complete or
rollback your partial transactions and reach commit boundaries. </p>
</div>
</div>
<div class="nested1" xml:lang="en-us" id="ifyouusecommitmentcontrolwithinyourapplicationallowmultiplecheckpoints"><a name="ifyouusecommitmentcontrolwithinyourapplicationallowmultiplecheckpoints"><!-- --></a><h2 class="topictitle2">If you use commitment control within your application, allow multiple
checkpoints</h2>
<div><p>If you specify SAVACT(*SYSDFN) or SAVACT(*LIB) for the save operation,
then the data is saved with multiple checkpoints. If you use commitment control
and specify *NOCMTBDY on the SAVACTWAIT parameter for the save operation,
the recovery procedure requires you to apply or remove journaled changes to
complete partial transactions and bring them to a common application boundary. </p>
</div>
</div>
<div class="nested1" xml:lang="en-us" id="objectsjournaled"><a name="objectsjournaled"><!-- --></a><h2 class="topictitle2">If you do not use commitment control but all objects are journaled</h2>
<div><p>If all application-dependent objects are journaled but commitment control
is not used, then you can apply or remove journaled changes. These commands
can bring all of the objects to an application boundary after restoring them
from the save-while-active media. However, application boundaries are not
recorded in the journal so you will need to determine where the boundaries
are on an object by object basis. When the journaled object reaches a checkpoint,
the journal receiver gets an additional journal entry in conjunction with
the object saved journal entry. The journal entry notes that you used the
save-while-active function to save the object and is used by the APYJRNCHG
and RMVJRNCHG commands as the location to start the operation when the FROMENT(*LASTSAVE)
parameter is used. It is critical that the currently attached journal receiver
be saved along with the objects being journaled. If more than one journal
is being used to journal the objects, then all attached receivers must be
saved. Include the request to save the receiver in the same save request as
that for the journaled objects. Or save the receiver in a separate save request
after the save of the journaled objects. This save is necessary because the
attached journal receiver will contain the entries that may be required by
any apply or remove journaled changes operation that is part of the recovery
when using the save-while-active media. </p>
</div>
</div>
<div class="nested1" xml:lang="en-us" id="objectsnotjournaled"><a name="objectsnotjournaled"><!-- --></a><h2 class="topictitle2">If commitment control is not used and objects are not journaled</h2>
<div><p>If you do not define your application boundaries you will have to do a
restore and do a recovery from an abnormal end. If you do not know what procedures
are required for recovering an abnormal end, then use the method to Example:
Restore libraries after reducing save-outage time.</p>
</div>
</div>
</body>
</html>