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

112 lines
7.9 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="Remote journal considerations when restarting the server" />
<meta name="abstract" content="This topic discusses the considerations for remote journaling when you restart the server." />
<meta name="description" content="This topic discusses the considerations for remote journaling when you restart the server." />
<meta name="DC.Relation" scheme="URI" content="rzakirmanage.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakiinactivate.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakiactiverep.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakirecovery.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="rzakiriplconsid" />
<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>Remote journal considerations when restarting the server</title>
</head>
<body id="rzakiriplconsid"><a name="rzakiriplconsid"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Remote journal considerations when restarting the server</h1>
<div><p>This topic discusses the considerations for remote journaling when
you restart the server.</p>
<p></p>
<div class="section"><h4 class="sectiontitle">Considerations for restarting replication of journal entries</h4><p><img src="./delta.gif" alt="Start of change" />The replication of journal entries to each of the associated remote
journals ends implicitly when the local system ends. To begin replicating
journal entries to the remote journal, you must restart the remote
journal on the target system. After an IPL or vary on operation, you are not
required to reassociate the remote journals with the journal on the source
system.<img src="./deltaend.gif" alt="End of change" /></p>
</div>
<div class="section"><h4 class="sectiontitle">Considerations for main storage preservation</h4><p>In
addition to unconfirmed I/O for journal entries, you also need to consider
the preservation of main storage for a failed system during recovery processing.
Given certain system failures, main storage might or might not be preserved
during the following IPL to recover from the system failure. Therefore, it
is possible for journal entries to survive in a local journal after a system
failure, even if the local or remote I/O was never performed for those journal
entries.</p>
<p>Therefore, IPL recovery on a primary system might preserve
changes that are not yet replicated to any of the remote journals, even the
remote journals that are synchronously maintained. Scenario: Recovery for
remote journaling demonstrates that you can use the remote journal function
to account for journal entries that survive a system failure in this manner.
These journal entries do not cause a total re-priming of the original data
when switching back from a backup system which took over the role of the primary
system.</p>
<p>In the scenario, when the system ends, the system does not return
control to the application programs that are in the process of generating
these surviving journal entries. Therefore, the application does not know
whether or not any of operations completed when the system ends. Also, the
application does not make dependencies or decisions on these operations. This
includes dependencies or decisions by the application performing the operation
or any other application that could be possibly dependent upon the data affected
by the operation.</p>
<p>Because of this consideration, it is recommended that
you journal both the before-images and after-images for any objects, if possible.
With the before-images, the work can then be backed out after the IPL or vary
on operation. If the data activity is not backed out after the IPL or vary
on operation, the alternative is to re-prime the primary system data completely
from the backup data which had assumed the role of the primary.</p>
</div>
<div class="section"><h4 class="sectiontitle">Considerations for when the target system ends</h4><p>When
remote journaling is active, neither a normal end nor an abnormal end of the
target system affects journaling on the source system. The local system continues
to deposit entries into the local journal without an error. The system sends
a message to the local journal's message queue to alert the operator that
remote journaling ended. When the target is again available, you can reactivate
remote journaling from the source system. When you activate remote journaling,
the default is for the local system to start sending journal entries starting
with the first entry the target system is missing.</p>
</div>
<div class="section"><h4 class="sectiontitle">Considerations for commitment control</h4><p>Commitment
control, especially two-phase commitment control, can cause some additional
considerations and potential complications. For example, if any of the entries
that were preserved but not yet confirmed were a commit or a rollback operation,
then the transaction will have to be reconciled accordingly between the primary
system, and the backup system.</p>
</div>
<div class="section"><h4 class="sectiontitle">Considerations for journal caching</h4><p><img src="./delta.gif" alt="Start of change" />Journal
caching affects remote journaling. Since journal entries are not sent to the
target system right away, the number of journal entries that are not confirmed
in a synchronous remote journal environment are always greater than if you
are not using journal caching.<img src="./deltaend.gif" alt="End of change" /></p>
</div>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzakirmanage.htm" title="Managing the remote journal function requires basic tasks such as:">Manage remote journals</a></div>
</div>
<div class="reltasks"><strong>Related tasks</strong><br />
<div><a href="rzakiinactivate.htm" title="When you end replication of journal entries to a remote journal, it is recommended that the replication of entries be ended from the source system whenever possible, rather than from the target system. Usually, ending replication from the target system for a remote journal is only necessary when the source system has failed, and the system has not ended the remote journal function.">Inactivate the replication of journal entries to a remote journal</a></div>
<div><a href="rzakiactiverep.htm" title="In order to activate the replication of journal entries to a given remote journal, the following must be true:">Activate the replication of journal entries to a remote journal</a></div>
</div>
<div class="relinfo"><strong>Related information</strong><br />
<div><a href="rzakirecovery.htm" title="This scenario describes a hot-backup environment in which the local system, JKLINT fails. It is necessary to restore the local system, and synchronize it with the remote system, JKLINT2.">Scenario: Recovery for remote journaling</a></div>
</div>
</div>
</body>
</html>