140 lines
10 KiB
HTML
140 lines
10 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="reference" />
|
||
|
|
<meta name="DC.Title" content="Journal management for distributed relational databases" />
|
||
|
|
<meta name="abstract" content="Journal management can be used as a part of the backup and recovery strategy for relational databases and indexes." />
|
||
|
|
<meta name="description" content="Journal management can be used as a part of the backup and recovery strategy for relational databases and indexes." />
|
||
|
|
<meta name="DC.subject" content="database recovery, journal management, recovery, journal management, overview, journal receiver, journal receiver, stopping, commitment control, independent ASP, vary on/off, database recovery, converting journal receiver entries, command, DSPJRN (Display Journal), Display Journal (DSPJRN), command, CL, Display Journal (DSPJRN), journal, displaying, saving, journal receivers" />
|
||
|
|
<meta name="keywords" content="database recovery, journal management, recovery, journal management, overview, journal receiver, journal receiver, stopping, commitment control, independent ASP, vary on/off, database recovery, converting journal receiver entries, command, DSPJRN (Display Journal), Display Journal (DSPJRN), command, CL, Display Journal (DSPJRN), journal, displaying, saving, journal receivers" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rbal1recovsupp.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rbal1indexrec.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rbal1tblindex.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rbal1smapp2.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../cl/chgjrn.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../cl/dspjrn.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../rzaki/rzakikickoff.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../cl/strjrnpf.htm" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="DC.Format" content="XHTML" />
|
||
|
|
<meta name="DC.Identifier" content="rbal1rcvjrn" />
|
||
|
|
<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>Journal management for distributed relational databases</title>
|
||
|
|
</head>
|
||
|
|
<body id="rbal1rcvjrn"><a name="rbal1rcvjrn"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Journal management for distributed relational databases</h1>
|
||
|
|
<div><p>Journal management can be used as a part of the backup and recovery
|
||
|
|
strategy for relational databases and indexes.</p>
|
||
|
|
<div class="section"><p><span class="keyword">iSeries™</span> journal
|
||
|
|
support provides an audit trail and forward and backward recovery. Forward
|
||
|
|
recovery can be used to take an older version of a table and apply changes
|
||
|
|
logged in the journal to the table. Backward recovery can be used to remove
|
||
|
|
changes logged in the journal from the table.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>When a collection is created, a journal and an object called a
|
||
|
|
journal receiver are created in the collection. Improved performance is gained
|
||
|
|
when the journal receiver is on a different ASP from the tables.
|
||
|
|
Placing the collection on a user ASP places the tables and journal and journal
|
||
|
|
receivers all in the same user ASP. There is no gain in performance there.
|
||
|
|
Creating a new journal receiver in a different ASP (used just for this journal's
|
||
|
|
journal receivers) and attaching it with the <span class="cmdname">Change Journal (CHGJRN)</span> command
|
||
|
|
will get the next server generated journal receivers all in the other user
|
||
|
|
ASP, and then the user will see improved performance.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>When a table is created, it is automatically journaled to the
|
||
|
|
journal SQL created in the collection. You are then responsible for using
|
||
|
|
the journal functions to manage the journal, journal receivers, and the journaling
|
||
|
|
of tables to the journal. For example, if a table is moved into a collection,
|
||
|
|
no automatic change to the journaling status occurs. If a table is restored,
|
||
|
|
the normal journal rules apply. That is, if a table is journaled when it is
|
||
|
|
saved, it is journaled to the same journal when it is restored on that server.
|
||
|
|
If the table is not journaled at the time of the save, it is not journaled
|
||
|
|
at restore time. You can stop journaling on any table using the journal functions,
|
||
|
|
but doing so prevents SQL operations from running under commitment control.
|
||
|
|
SQL operations can still be performed if you have specified COMMIT(*NONE),
|
||
|
|
but this does not provide the same level of integrity that journaling and
|
||
|
|
commitment control provide.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>With journaling active, when changes are made to the database,
|
||
|
|
the changes are journaled in a journal receiver before the changes are made
|
||
|
|
to the database. The journal receiver always has the latest database information.
|
||
|
|
All activity is journaled for a database table regardless of how the change
|
||
|
|
was made.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>Journal receiver entries record activity for a specific row (added,
|
||
|
|
changed, or deleted), and for a table (opened, table or member saved, and
|
||
|
|
so on). Each entry includes additional control information identifying the
|
||
|
|
source of the activity, the user, job, program, time, and date.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>The server journals some file-level changes, including moving
|
||
|
|
a table and renaming a table. The server also journals member-level changes,
|
||
|
|
such as initializing a physical file member, and server-level changes, such
|
||
|
|
as initial program load (IPL). You can add entries to a journal receiver to
|
||
|
|
identify significant events (such as the checkpoint at which information about
|
||
|
|
the status of the job and the server can be journaled so that the job step
|
||
|
|
can be restarted later) or to help in the recovery of applications.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>For changes that affect a single row, row images are included
|
||
|
|
following the control information. The image of the row after a change is
|
||
|
|
made is always included. Optionally, the row image before the change is made
|
||
|
|
can also be included. You control whether to journal both before and after
|
||
|
|
row images or just after row images by specifying the IMAGES parameter on
|
||
|
|
the <span class="cmdname">Start Journal Physical File (STRJRNPF)</span> command.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>All journaled database files are automatically synchronized with
|
||
|
|
the journal when the server is started (IPL time) or during the vary on of
|
||
|
|
an independent ASP. If the server ended abnormally, or the independent ASP
|
||
|
|
varied off abnormally, some database changes might be in the journal, but
|
||
|
|
not yet reflected in the database itself. If that is the case, the server
|
||
|
|
automatically updates the database from the journal to bring the tables up
|
||
|
|
to date.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>Journaling can make saving database tables easier and faster.
|
||
|
|
For example, instead of saving entire tables every day, you can save the journal
|
||
|
|
receivers that contain the changes to the tables. You can still save the entire
|
||
|
|
tables on a regular basis. This method can reduce the amount of time it takes
|
||
|
|
to perform your daily save operations.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>The <span class="cmdname">Display Journal (DSPJRN)</span> command can be
|
||
|
|
used to convert journal receiver entries to a database file. Such a file can
|
||
|
|
be used for activity reports, audit trails, security, and program debugging.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<ul class="ullinks">
|
||
|
|
<li class="ulchildlink"><strong><a href="rbal1indexrec.htm">Index recovery</a></strong><br />
|
||
|
|
An index describes the order in which rows are read from a table. When indexes are recorded in the journal, the server can recover the index to avoid spending a significant amount of time rebuilding indexes during the IPL that follows an abnormal server end or during the vary on of an independent ASP after an abnormal vary off.</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="rbal1tblindex.htm">Design tables to reduce index rebuilding time</a></strong><br />
|
||
|
|
Table design can also help reduce index recovery time.</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="rbal1smapp2.htm">System-managed access-path protection</a></strong><br />
|
||
|
|
System-managed access-path protection (SMAPP) provides automatic protection for access paths.</li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rbal1recovsupp.htm" title="Failures that can occur on a computer server are a server failure (when the entire server is not operating); a loss of the site due to fire, flood, or similar catastrophe; or the damage or loss of an object. For a distributed relational database, a failure on one server in the network prevents users across the entire network from accessing the relational database on that server.">Recovery support for a distributed relational database</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relconcepts"><strong>Related concepts</strong><br />
|
||
|
|
<div><a href="../rzaki/rzakikickoff.htm">Journal management</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relinfo"><strong>Related information</strong><br />
|
||
|
|
<div><a href="../cl/chgjrn.htm">Change Journal (CHGJRN) command</a></div>
|
||
|
|
<div><a href="../cl/dspjrn.htm">Display Journal (DSPJRN) command</a></div>
|
||
|
|
<div><a href="../cl/strjrnpf.htm">Start Journal Physical File (STRJRNPF) command</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|