111 lines
8.4 KiB
HTML
111 lines
8.4 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="Recovery support for a distributed relational database" />
|
||
|
<meta name="abstract" content="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." />
|
||
|
<meta name="description" content="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." />
|
||
|
<meta name="DC.subject" content="database recovery, failure types, recovery, error recovery, relational database, database recovery, methods, uninterruptible power supply" />
|
||
|
<meta name="keywords" content="database recovery, failure types, recovery, error recovery, relational database, database recovery, methods, uninterruptible power supply" />
|
||
|
<meta name="DC.Relation" scheme="URI" content="rbal1recover.htm" />
|
||
|
<meta name="DC.Relation" scheme="URI" content="rbal1datarecov.htm" />
|
||
|
<meta name="DC.Relation" scheme="URI" content="rbal1rcvjrn.htm" />
|
||
|
<meta name="DC.Relation" scheme="URI" content="rbal1rcvtrn.htm" />
|
||
|
<meta name="DC.Relation" scheme="URI" content="rbal1saverestore.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="rbal1recovsupp" />
|
||
|
<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>Recovery support for a distributed relational database</title>
|
||
|
</head>
|
||
|
<body id="rbal1recovsupp"><a name="rbal1recovsupp"><!-- --></a>
|
||
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
<h1 class="topictitle1">Recovery support for a distributed relational database</h1>
|
||
|
<div><p>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.</p>
|
||
|
<div class="section"><p>If the relational database is critical to daily business activities
|
||
|
at other locations, enterprise operations across the entire network can be
|
||
|
disrupted for the duration of one server's recovery time. Clearly, planning
|
||
|
for data protection and recovery after a failure is particularly important
|
||
|
in a distributed relational database.</p>
|
||
|
</div>
|
||
|
<div class="section"><p>Each server in a distributed relational database is responsible
|
||
|
for backing up and recovering its own data. Each server in the network also
|
||
|
handles recovery procedures after an abnormal server end. However, backup
|
||
|
and recovery procedures can be done by the distributed relational database
|
||
|
administrator using display station pass-through for those servers with an
|
||
|
inexperienced operator or no operator at all.</p>
|
||
|
</div>
|
||
|
<div class="section"><p>The most common type of loss is the loss of an object or group
|
||
|
of objects. An object can be lost or damaged due to several factors, including
|
||
|
power failure, hardware failures, system program errors, application program
|
||
|
errors, or operator errors. The <span class="keyword">iSeries™ server</span> provides
|
||
|
several methods for protecting the server programs, application programs,
|
||
|
and data from being permanently lost. Depending on the type of failure and
|
||
|
the level of protection chosen, most of the programs and data can be protected,
|
||
|
and the recovery time can be significantly reduced. </p>
|
||
|
</div>
|
||
|
<div class="section"><p>You can use the following methods to protect your
|
||
|
data and programs: </p>
|
||
|
<blockquote><strong>Writing data to auxiliary storage</strong><p>The
|
||
|
Force-Write Ratio (FRCRATIO) parameter on the <span class="cmdname">Create File</span> command
|
||
|
can be used to force data to be written to auxiliary storage. A force-write
|
||
|
ratio of one causes every add, update, and delete request to be written to
|
||
|
auxiliary storage immediately for the table in question. However, choosing
|
||
|
this option can reduce server performance. Therefore, saving your tables and
|
||
|
journaling tables should be considered the primary methods for protecting
|
||
|
the database. </p>
|
||
|
</blockquote>
|
||
|
<blockquote><strong>Physical protection</strong> <p>Making sure your
|
||
|
system is protected from sudden power loss is an important part of ensuring
|
||
|
that your application server (AS) is available to an application requester
|
||
|
(AR). An uninterruptible power supply, which can be ordered separately,
|
||
|
protects the server from loss because of power failure, power interruptions,
|
||
|
or drops in voltage, by supplying power to the server devices until power
|
||
|
can be restored. Normally, an uninterruptible power supply does not provide
|
||
|
power to all workstations. With the <span class="keyword">iSeries server</span>,
|
||
|
the uninterruptible power supply allows the server to: </p>
|
||
|
<ul><li>Continue operations during brief power interruptions or momentary drops
|
||
|
in voltage.</li>
|
||
|
<li>End operations normally by closing files and maintaining object integrity.</li>
|
||
|
</ul>
|
||
|
</blockquote>
|
||
|
</div>
|
||
|
</div>
|
||
|
<div>
|
||
|
<ul class="ullinks">
|
||
|
<li class="ulchildlink"><strong><a href="rbal1datarecov.htm">Data recovery after disk failures for distributed relational databases</a></strong><br />
|
||
|
Recovery is not possible for recently entered data if a disk failure occurs and all objects are not saved on tape or disk immediately before the failure. After previously saved objects are restored, the server is operational, but the database is not current.</li>
|
||
|
<li class="ulchildlink"><strong><a href="rbal1rcvjrn.htm">Journal management for distributed relational databases</a></strong><br />
|
||
|
Journal management can be used as a part of the backup and recovery strategy for relational databases and indexes.</li>
|
||
|
<li class="ulchildlink"><strong><a href="rbal1rcvtrn.htm">Transaction recovery through commitment control</a></strong><br />
|
||
|
Commitment control is an extension of the journal management function
|
||
|
on the <span class="keyword">iSeries server</span>. The server
|
||
|
can identify and process a group of relational database changes as a single
|
||
|
unit of work (transaction).</li>
|
||
|
<li class="ulchildlink"><strong><a href="rbal1saverestore.htm">Save and restore processing for a distributed relational database</a></strong><br />
|
||
|
Saving and restoring data and programs allows recovery from a program or server failure, exchange of information between servers, or storage of objects or data offline. A sound backup policy at each server in the distributed relational database network ensures that a server can be restored and made available to network users quickly in the event of a problem.</li>
|
||
|
</ul>
|
||
|
|
||
|
<div class="familylinks">
|
||
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rbal1recover.htm" title="In a distributed relational database environment, data availability not only involves protecting data on an individual server in the network, but also ensuring that users have access to the data across the network.">Data availability and protection</a></div>
|
||
|
</div>
|
||
|
</div>
|
||
|
</body>
|
||
|
</html>
|