106 lines
8.0 KiB
HTML
106 lines
8.0 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="Index recovery" />
|
||
|
|
<meta name="abstract" content="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." />
|
||
|
|
<meta name="description" content="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." />
|
||
|
|
<meta name="DC.subject" content="journal management, indexes, index, journaling, database recovery, rebuilding indexes, rebuilding, recovering, view, starting journaling, journal management, starting index journaling, command, STRJRNAP (Start Journal Access Path), Start Journal Access Path (STRJRNAP), command, CL, STRJRNAP (Start Journal Access Path), journal access path, starting, SAVLIB (Save Library), Save Library (SAVLIB), Save Library (SAVLIB), library, saving, SAVOBJ (Save Object), Save Object (SAVOBJ), command, CL, Save Object (SAVOBJ), object, journaling restrictions" />
|
||
|
|
<meta name="keywords" content="journal management, indexes, index, journaling, database recovery, rebuilding indexes, rebuilding, recovering, view, starting journaling, journal management, starting index journaling, command, STRJRNAP (Start Journal Access Path), Start Journal Access Path (STRJRNAP), command, CL, STRJRNAP (Start Journal Access Path), journal access path, starting, SAVLIB (Save Library), Save Library (SAVLIB), Save Library (SAVLIB), library, saving, SAVOBJ (Save Object), Save Object (SAVOBJ), command, CL, Save Object (SAVOBJ), object, journaling restrictions" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rbal1rcvjrn.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../cl/strjrnap.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../cl/savobj.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../cl/savlib.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="rbal1indexrec" />
|
||
|
|
<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>Index recovery</title>
|
||
|
|
</head>
|
||
|
|
<body id="rbal1indexrec"><a name="rbal1indexrec"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Index recovery</h1>
|
||
|
|
<div><p>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.</p>
|
||
|
|
<div class="section"><p>When you journal tables, images of changes to the rows in the
|
||
|
|
table are written to the journal. These row images are used to recover the
|
||
|
|
table if the server, or independent ASP, ends abnormally. However, after an
|
||
|
|
abnormal end, the server might find that indexes built over the table are
|
||
|
|
not synchronized with the data in the table. If an access path and its data
|
||
|
|
are not synchronized, the server must rebuild the index to ensure that the
|
||
|
|
two are synchronized and usable.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>When indexes are journaled, the server records images of the index
|
||
|
|
in the journal to provide known synchronization points between the index and
|
||
|
|
its data. By having that information in the journal, the server can recover
|
||
|
|
both the data and the index, and ensure that the two are synchronized. In
|
||
|
|
such cases, the lengthy time to rebuild the indexes can be avoided. </p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>The <span class="keyword">iSeries™ server</span> provides
|
||
|
|
several functions to assist with index recovery. All indexes on the server
|
||
|
|
have a maintenance option that specifies when the index is maintained. SQL
|
||
|
|
indexes are created with an attribute of *IMMED maintenance.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>In the event of a power failure or abnormal server failure, indexes
|
||
|
|
that are in the process of change might need to be rebuilt to make sure they
|
||
|
|
agree with the data. All indexes on the server have a recovery option that
|
||
|
|
specifies when the index should be rebuilt if necessary. All SQL indexes with
|
||
|
|
an attribute of UNIQUE are created with a recovery attribute of *IPL, which
|
||
|
|
means these indexes are rebuilt before the <span class="keyword">i5/OS™</span> licensed
|
||
|
|
program has been started. All other SQL indexes are created with the *AFTIPL
|
||
|
|
recovery attribute, which means they are rebuilt after the operating system
|
||
|
|
has been started or after the independent ASP has varied on. During an IPL
|
||
|
|
or vary on of an independent ASP, you can see a display showing indexes that
|
||
|
|
need to be rebuilt and their recovery options, and you can override these
|
||
|
|
recovery options.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>SQL indexes are not journaled automatically. You can use the <span class="cmdname">Start
|
||
|
|
Journal Access Path (STRJRNAP)</span> command to journal any index created
|
||
|
|
by SQL operations. The server save and restore functions allow you to save
|
||
|
|
indexes when a table is saved by using ACCPTH(*YES) on the <span class="cmdname">Save Object
|
||
|
|
(SAVOBJ)</span> or <span class="cmdname">Save Library (SAVLIB)</span> command.
|
||
|
|
If you must restore a table, there is no need to rebuild the indexes. Any
|
||
|
|
indexes not previously saved and restored are automatically and asynchronously
|
||
|
|
rebuilt by the database.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>Before journaling indexes, you must start journaling for the tables
|
||
|
|
associated with the index. In addition, you must use the same journal for
|
||
|
|
the index and its associated table.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>Index journaling is designed to minimize additional output operations.
|
||
|
|
For example, the server writes the journal data for the changed row and the
|
||
|
|
changed index in the same output operation. However, you should seriously
|
||
|
|
consider isolating your journal receivers in user ASPs when you start journaling
|
||
|
|
your indexes. Placing journal receivers in their own user ASP provides the
|
||
|
|
best journal management performance, while helping to protect them from a
|
||
|
|
disk failure.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rbal1rcvjrn.htm" title="Journal management can be used as a part of the backup and recovery strategy for relational databases and indexes.">Journal management for distributed relational databases</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relinfo"><strong>Related information</strong><br />
|
||
|
|
<div><a href="../cl/strjrnap.htm">Start Journal Access Path (STRJRNAP) command</a></div>
|
||
|
|
<div><a href="../cl/savobj.htm">Save Object (SAVOBJ) command</a></div>
|
||
|
|
<div><a href="../cl/savlib.htm">Save Library (SAVLIB) command</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|