ノーアーカイブログモードでのリストア・リカバリOracleバックアップ/リカバリ講座(13)(3/3 ページ)

» 2007年04月12日 00時00分 公開
[荒井智也株式会社アゲハ]
前のページへ 1|2|3       

制御ファイルの障害時におけるリストア・リカバリ方法

 一部の制御ファイルが破損・損失した場合には、そのほかの正常な制御ファイルをコピーしたり、初期化パラメータcontrol_filesから破損・損失した制御ファイルを除外したりすることでリカバリできます。しかし、全損してしまった場合には、バックアップから制御ファイルをリストアする必要があります。

RMANリポジトリを別データベースのリカバリ・カタログに保持している場合

1.nomountモードで起動する

 制御ファイルをリストアする場合には、nomountモードでデータベースを起動する必要があります。すでにデータベースが起動している場合には、abortオプションを使用してデータベースを強制的に停止します(リスト9)。

RMAN> startup nomount;
ターゲット・データベースに接続しました(起動していません)。
Oracleインスタンスが起動しました
システム・グローバル領域の合計は、    213909504バイトです。
Fixed Size                     1260008バイト
Variable Size                104859160バイト
Database Buffers             104857600バイト
Redo Buffers                   2932736バイト
RMAN>
リスト9 nomountモードでのデータベース起動

2.制御ファイルをリストアする

 リカバリ・カタログを使用している場合は、制御ファイルを自動でバックアップする方法、明示的にバックアップする方法にかかわらず、リカバリ・カタログ内にバックアップ情報を保持しているため、restore controlfileコマンドで最新の制御ファイルがリストア可能です。リストア時のログは、「リスト3 制御ファイルとデータファイル全体のリストア」と重複するので省略します。

3.mountモードにする

 リストアが完了したら、ターゲット・データベースをマウントします。

4.リカバリを実行する

 マウントが完了したら、RMANでデータベースのリカバリを行います(リスト10)。

RMAN> recover database;
recoverが開始されました(開始時間: 07-03-16)
  …… 途中省略 ……
メディア・リカバリが完了しました。経過時間: 00:00:06
recoverが完了しました(完了時間: 07-03-16)
RMAN>
リスト10 ターゲット・データベースのリカバリ

5.resetlogsオプション付きでオープンする

 リカバリが完了したら、resetlogsオプションを指定してターゲット・データベースをオープンし、データの損失などがないか確認します(リスト11)。

RMAN> alter database open resetlogs;
データベースがオープンしました。
データベースの新しいインカネーションがリカバリ・カタログに登録されました
リカバリ・カタログの完全再同期を開始しています
完全再同期が完了しました
RMAN>
リスト11 resetlogsオプションを使用したデータベースのオープン

 RMANからresetlogsオプションを使用してデータベースをオープンすると、自動的にインカネーション注1の登録とリカバリ・カタログの完全同期注2が実施されます。

注1:リカバリ・カタログを使用してバックアップを取得した場合のターゲット・データベースの管理番号。resetlogsオプションを使用してデータベースをオープンすると、ログ番号がリセットされ、新規のデータベースとしてバックアップするために管理番号が更新される。

注2:resetlogsオプションを使用してデータベースをオープンしたため、ターゲット・データベースの制御ファイルの内容が変更される。これによりリカバリ・カタログの情報が以前の制御ファイルの内容の状態になっているため、最新の制御ファイルの内容に合わせるため同期を行う。


RMANリポジトリをターゲット・データベースの制御ファイルに保持している場合

 RMANリポジトリをターゲット・データベースの制御ファイルに保持している場合、制御ファイルのバックアップを明示的に取得している場合と、自動で取得している場合ではリストア方法が異なります。この違いを含めて、以下では制御ファイルのリストア・リカバリ方法を説明していきます。なお、制御ファイルをリストアする前にnomountモードでインスタンスを起動している前提になります。

 明示的に制御ファイルのバックアップを取得している場合

 明示的にBACKUPコマンドで制御ファイルのバックアップを取得している場合には、制御ファイルのリストア時にバックアップセット名を明示的に指定する必要があります。しかし、RMANリポジトリを制御ファイルに保持している場合、制御ファイル自体をリストアするのでRMANリポジトリからバックアップセット名を確認することが不可能です。そのため、バックアップ取得時のログファイルからバックアップセット名を特定します。

 リスト12では、制御ファイルのバックアップセット名を「V10R2xxx-617460721-20070316-51_1jiddan4_1_1.ctl」として、リストアを行います。リストアを実施する前には、念のためDBIDの設定を行います。

RMAN> set dbid= 176686030;
実行コマンド: SET DBID
RMAN> restore controlfile from 
'V10R2xxx-617460721-20070316-51_1jiddan4_1_1.ctl';
restoreが開始されました(開始時間: 07-03-16)
  …… 途中省略 ……
出力ファイル名=/pp/oracle/v10r2/ctl1/control01.ctl
出力ファイル名=/bkup1/oracle/v10r2/ctl2/control02.ctl
出力ファイル名=/bkup2/oracle/v10r2/ctl3/control03.ctl
restoreが完了しました(完了時間: 07-03-16)
RMAN>
リスト12 バックアップセットを指定した制御ファイルのリストア

 自動的に制御ファイルのバックアップを取得している場合

 制御ファイルが全損した場合、「DBID」と「自動バックアップで取得したデバイスタイプとファイルパス」をリストア前に設定する必要があります。これは、自動バックアップ先ディレクトリを変更していた場合、デフォルトの自動バックアップ先が参照されてしまうためです。明示的に自動バックアップ先のディレクトリを設定し、自動バックアップした制御ファイルをリストアします(リスト13)。この設定を行わない場合には、デフォルトの出力場所($ORACLE_HOME/dbs)に自動バックアップの制御ファイルが存在しないためエラーとなります。

RMAN> set dbid= 176686030;
実行コマンド: SET DBID
RMAN> set CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 
'/backup/autobackup/%F.ctl';

実行コマンド: SET CONTROLFILE AUTOBACKUP FORMAT
RMAN> restore controlfile from autobackup;
restoreが開始されました(開始時間: 07-03-16)
  …… 途中省略 ……
チャネルORA_DISK_1: 自動バックアップが見つかりました: /backup/autobackup/c-176686030-20070316-04.ctl
チャネルORA_DISK_1: 自動バックアップからの制御ファイルのリストアが完了しました
出力ファイル名=/pp/oracle/v10r2/ctl1/control01.ctl
出力ファイル名=/bkup1/oracle/v10r2/ctl2/control02.ctl
出力ファイル名=/bkup2/oracle/v10r2/ctl3/control03.ctl
restoreが完了しました(完了時間: 07-03-16)
RMAN>
リスト13 自動バックアップからの制御ファイルのリストア

 この後の作業は明示的な制御ファイルのバックアップ、自動バックアップからのリストア時も同様で、リカバリ・カタログを使用している場合と同じ手順になります。

 データベースのオープン後、データベース全体のフルバックアップの取得を推奨します。なお、ここではリカバリ・カタログを使用していないので、制御ファイルとの再同期は不要です。

連載の最後に

 約1年間にわたって、Oracleデータベースのバックアップに必要となる知識とテクニックを、具体的な例を交えながら紹介させていただきました。データベースのバックアップにはさまざまな方法があり、個々の要件に合ったバックアップ方法を選択することが重要です。しかし最も大事なことは「戻したいと考えている状態にデータベースをリカバリすることができる」ということです。

 一般的にバックアップを取得して満足してしまいがちですが、いざというときにバックアップしたデータが使用できず、リカバリが不可能になってしまうと、その影響は計り知れません。特にリストア・リカバリ作業は、ほかの作業とは異なり、実際に作業する機会が少なく、リカバリ手順が確立していても、ちょっとした手順ミスで混乱してしまうことがあります。可能であれば、開発環境でリストア・リカバリの障害復旧テストを行うことで、いざというときに慌てず、手順にのっとって作業ができるでしょう。

 これからバックアップの設計・運用を手掛けようとされている方々に、本連載の情報が少しでもお役に立てば幸いです。長い間ご愛読いただきましてありがとうございました。(連載完)

著者紹介

荒井 智也

株式会社アゲハ


前のページへ 1|2|3       

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。