112 lines
7.9 KiB
HTML
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>
|