Recovery Managerによるリストア・リカバリの方法Oracleバックアップ/リカバリ講座(12)(1/3 ページ)

本記事では、Oracleデータベースのバックアップ/リストア/リカバリについて、そのアーキテクチャ、代表的なバックアップ手法、論理/物理バックアップ、RMANといった全般的な内容を解説していく。(編集部)

» 2007年03月16日 00時00分 公開
[渡辺学株式会社アゲハ]

主な内容

--Page 1--
▼RMANによるリストア・リカバリの流れ
--Page 2--
▼完全リカバリ ―― オフラインリカバリ
▼完全リカバリ ―― オンラインリカバリ
--Page 3--
▼不完全リカバリ


 前回「OSコマンドを使用したリストア・リカバリの方法」ではOSコマンドによるリストア・リカバリの方法を見ていきましたが、今回はRecovery Manager(以下、RMAN)によるリストア・リカバリの方法について説明していきます。また、RMANにはOSコマンドによるバックアップ/リストア/リカバリ方法と比べて便利な機能もありますので、こちらについても紹介していきたいと思います。以降の実行結果については、これまでと同様にLinux環境のOracle 10g Release 2で実行したものになります。

RMANによるリストア・リカバリの流れ

 RMANを使った場合も、リストア・リカバリの基本的な考え方、障害の検出、確認方法についてはOSコマンドの場合と同様に考えることができます。

 RMANでは、リストアやリカバリの実行時に、データベースや表領域など、処理対象を指定するだけで、必要なバックアップファイルやアーカイブREDOログファイルをRMANが自動選択し、リカバリ作業を行ってくれます。そのため、OSコマンドのように、リカバリに必要なバックアップファイルをユーザーが探してリストアを行う必要がないので、OSコマンドと比べて障害発生時の作業を簡略化させることができます。

 まずは、RMANによるリストア・リカバリの流れを簡単に説明します(図1)。実際に使用するコマンドについては後述する「リカバリ」の「完全リカバリ」「不完全リカバリ」の項目で併せて説明していきます。

図1 RMANによるリストア・リカバリの流れ 図1 RMANによるリストア・リカバリの流れ

1.障害発生個所の調査

 データベースの「リストア・リカバリを伴う障害」に限ったことではありませんが、アプリケーションにエラーが返された場合も、データベース管理者はアラートログファイル、ユーザープロセスのトレースファイルを必ず調査します。出力されたエラー内容やアラートログファイル、トレースファイルを調査した結果、データベース構成ファイルに障害が発生したことが確認できたときには、動的パフォーマンス・ビュー(v$recover_file、v$datafile_header)などを使用して、エラーの発生している以外のデータベース構成ファイルにもエラーがないか確認します。

2.ターゲット・データベースを復旧可能な状態にする

 障害が発生したファイルを確認できたらリストア・リカバリを行います。データベース全体でリストア、リカバリを行う際には、ターゲット・データベースをマウントモードにします。一方、表領域やデータファイルを単位にオンラインでリストア・リカバリを実行する際には、復旧対象の表領域をオフラインにする必要があります。

 リストア・リカバリ時に使うデータベースの起動/停止や一部のコマンドは、RMANから直接実行できます。表領域やデータファイルのオフラインやオンラインについてはRMANには直接実行するコマンドがありませんが、リスト1のようにSQLコマンドを使用することにより、RMAN上からでもSQLの実行が可能になります。

RMAN> sql 'alter tablespace users offline'
リスト1 RMANでUSERS表領域をオフラインにする例

3.バックアップファイルをリストアする

 RMANではRESTOREコマンドを用いてリストア対象を指定すると、必要なデータファイルをバックアップファイルからリストアできます。リストアの指定方法はデータベース、表領域、データファイルなどの単位です(そのほか、制御ファイル、SPFILE単位でのリストアも可能)。データベース単位や表領域単位でRESTOREコマンドを使用すると、RMANが自動的に必要なデータファイルをすべてリストアします。

 RMANではRESTOREコマンドが発行されると、初めにコマンドで指定された対象のデータファイルのヘッダにある情報を確認し、制御ファイル内の情報と一致しないものだけをリストアします。これにより、復旧に必要なリストア時間を最小限に抑えることができます。

 しかし、データファイルヘッダは正常で実データ部分のみが破損している場合は、逆にRMANではデータファイルヘッダは正常と認識してリストア対象から除外してしまいます。このような場合は、後述するように「force」句を追加してリストアを強制的に行う必要があります。

4.リカバリを行う

 リストアが終わったら、次はリカバリです。RMANではRECOVERコマンドを使用します。RESTOREコマンドと同様に、対象を指定すると必要なデータファイルに対してリカバリを行っていきます。リカバリが終了したら、最後にターゲット・データベースをオープンまたは対象の表領域をオンラインに戻して、作業完了になります。

【TOPIC】

リストアやリカバリの進ちょく状況について

RMANでリストアやリカバリを行っているときに、画面上には各チャネルの処理対象とするデータファイルやアーカイブREDOログファイルが表示されますが、実際どこまでリストアされているのか、どのくらいアーカイブREDOログファイルが適用されているかが判断しにくいことがあります。これらの情報についてはターゲット・データベースのアラートファイルに出力されていますので、実際にリストアやリカバリを行っている場合は、「tail -f」コマンドなどで監視する方法が有効です。なお、リストア状況については、第10回「Recovery Managerのチューニング・ポイント集」で紹介したTOPICにあるV$SESSION_LONGOPSでも確認可能です。

[データファイルのリストアが完了したときの出力例]
Sun Mar  4 16:57:10 2007
Full restore complete of datafile 1 /opt/app/oracle/oradata/
system01.dbf.  Elapsed time: 0:00:46
  checkpoint is 670527

[アーカイブREDOログファイルの適用が完了したときの出力例]
Sun Mar  4 17:02:11 2007
alter database recover logfile 
'/opt/app/oracle/archive/1_85_616340345.dbf'
Sun Mar  4 17:02:11 2007
Media Recovery Log /opt/app/oracle/archive/1_85_616340345.dbf
ORA-279 signalled during: alter database recover logfile 
'/opt/app/oracle/archive/1_85_616340345.dbf'...

 次ページからは、OSコマンドと同じ障害ケースを想定して、RMANによるリストア・リカバリの流れを具体的に説明していきます。ただし、障害個所の確認や復旧後の確認方法についてはこれまでと同様の方法になりますので、以降の手順では省略します。

 完全リカバリと不完全リカバリの例では、バックアップの運用として第8回「これだけでRecovery Managerは完全マスター」の4ページ「ディスク上にバックアップ・セットでデータベース全体の非一貫性バックアップを取得」で説明した、バックアップ(リスト4)を毎日行っているものとします。

       1|2|3 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

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

注目のテーマ

AI for エンジニアリング
「サプライチェーン攻撃」対策
1P情シスのための脆弱性管理/対策の現実解
OSSのサプライチェーン管理、取るべきアクションとは
Microsoft & Windows最前線2024
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

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

メールマガジン登録

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