ここではSYSTEM表領域に障害が発生した場合を例に挙げ、リカバリの手順を説明します。
SYSTEM表領域に障害が発生している場合には、ターゲット・データベースをマウントモードで起動し直す必要があります。ターゲット・データベースが起動している場合は一度強制停止してからマウントモードに変更します(リスト2)。
RMAN> shutdown abort;
Oracleインスタンスがシャットダウンしました
RMAN> startup mount;
ターゲット・データベースに接続しました(起動していません)。
Oracleインスタンスが起動しました
データベースがマウントされました。
システム・グローバル領域の合計は、 167772160バイトです。
Fixed Size 1218316バイト
Variable Size 62916852バイト
Database Buffers 100663296バイト
Redo Buffers 2973696バイト |
リスト2 ターゲット・データベースをマウントモードにする |
「restore tablespace」コマンドでリストア対象のSYSTEM表領域を指定します。表領域単位でリストアを行った場合は、該当する表領域に属しているすべてのデータファイルがリストアされるので、データベースの物理的な配置を気にすることなくリストアが可能です(リスト3)。
RMAN> restore tablespace system;
restoreが開始されました(開始時間: 2007/03/04 16:56:19)
チャネル: ORA_DISK_1が割り当てられました
チャネルORA_DISK_1: sid=157 devtype=DISK
チャネルORA_DISK_1: データファイル・バックアップ・セットのリストアを開始しています。
チャネルORA_DISK_1: バックアップ・セットからリストアするデータファイルを指定しています
データファイル00001を/opt/app/oracle/oradata/system01.dbfへリストア
チャネルORA_DISK_1: バックアップ・ピース/opt/app/oracle/oraback/full_db_0vibpc7q_1_1から読取り中です
チャネルORA_DISK_1: バックアップ・ピース1がリストアされました
ピース・ハンドル=/opt/app/oracle/oraback/full_db_0vibpc7q_1_1 タグ=TAG20070304T151050
チャネルORA_DISK_1: リストアが完了しました。経過時間: 00:00:55
restoreが完了しました(完了時間: 2007/03/04 16:57:15) |
リスト3 SYSTEM表領域をバックアップからリストアする |
リカバリについても表領域単位で指定します。出力を見るとアーカイブREDOログファイル、オンラインREDOログが適用されているのが分かります(リスト4)。
RMAN> recover tablespace system;
recoverが開始されました(開始時間: 2007/03/04 17:01:58)
チャネルORA_DISK_1の使用
メディア・リカバリを開始しています
アーカイブ・ログ・スレッド: 1、順序: 3は、ファイル: /opt/app/oracle/archive/1_3_616340345.dbfとしてディスクに存在します
……省略……
アーカイブ・ログ・スレッド: 1、順序: 104は、ファイル: /opt/app/oracle/archive/1_104_616340345.dbfとしてディスクに存在します
チャネルORA_DISK_1: デフォルトの宛先へのアーカイブ・ログのリストアを開始しています
チャネルORA_DISK_1: アーカイブ・ログをリストアしています
アーカイブ・ログ・スレッド=1 順序=2
チャネルORA_DISK_1: バックアップ・ピース/opt/app/oracle/oraback/full_db_14ibpcdr_1_1から読取り中です
チャネルORA_DISK_1: バックアップ・ピース1がリストアされました
ピース・ハンドル=/opt/app/oracle/oraback/full_db_14ibpcdr_1_1 タグ=TAG20070304T151403
チャネルORA_DISK_1: リストアが完了しました。経過時間: 00:00:02
アーカイブ・ログ・ファイル名=/opt/app/oracle/archive/1_2_616340345.dbf スレッド=1 順序=2
……省略……
アーカイブ・ログ・ファイル名=/opt/app/oracle/archive/1_102_616340345.dbf スレッド=1 順序=102
メディア・リカバリが完了しました。経過時間: 00:00:11
recoverが完了しました(完了時間: 2007/03/04 17:02:16) |
リスト4 SYSTEM表領域をリカバリする |
今回は完全リカバリであるため、最後はそのままデータベースをオープンします(リスト5)。
RMAN> alter database open;
データベースがオープンしました。 |
リスト5 ターゲット・データベースをオープンする |
これでSYSTEM表領域障害からの完全リカバリが完了です。
次に、USERS表領域が壊れたときのケースを見ていきましょう。
リストアを実施するため障害の発生した表領域をオフラインに変更します(リスト6)。
RMAN> sql 'alter tablespace users offline';
(SQL文:alter tablespace users offline) |
リスト6 障害対象の表領域をオフラインにする |
「restore tablespace」コマンドでリストア対象のUSERS表領域を指定します(リスト7)。
RMAN> restore tablespace users;
restoreが開始されました(開始時間: 2007/03/04 19:10:54)
チャネルORA_DISK_1の使用
チャネルORA_DISK_1: データファイル・バックアップ・セットのリストアを開始しています。
チャネルORA_DISK_1: バックアップ・セットからリストアするデータファイルを指定しています
データファイル00004を/opt/app/oracle/oradata/users01.dbfへリストア
チャネルORA_DISK_1: バックアップ・ピース/opt/app/oracle/oraback/full_db_1cibpnk6_1_1から読取り中です
チャネルORA_DISK_1: バックアップ・ピース1がリストアされました
ピース・ハンドル=/opt/app/oracle/oraback/full_db_1cibpnk6_1_1 タグ=TAG20070304T182510
チャネルORA_DISK_1: リストアが完了しました。経過時間: 00:00:26
restoreが完了しました(完了時間: 2007/03/04 19:11:21) |
リスト7 障害対象の表領域をバックアップからリストアにする |
こちらも今回は「recover tablespace」コマンドでUSERS表領域を指定します(リスト8)。
RMAN> recover tablespace users;
recoverが開始されました(開始時間: 2007/03/04 19:14:03)
チャネルORA_DISK_1の使用
メディア・リカバリを開始しています
アーカイブ・ログ・スレッド: 1、順序: 210は、ファイル: /opt/app/oracle/archive/1_210_616340345.dbfとしてディスクに存在します
……省略……
チャネルORA_DISK_1: デフォルトの宛先へのアーカイブ・ログのリストアを開始しています
チャネルORA_DISK_1: アーカイブ・ログをリストアしています
アーカイブ・ログ・スレッド=1 順序=209
チャネルORA_DISK_1: バックアップ・ピース/opt/app/oracle/oraback/full_db_1eibpnp8_1_1から読取り中です
チャネルORA_DISK_1: バックアップ・ピース1がリストアされました
ピース・ハンドル=/opt/app/oracle/oraback/full_db_1eibpnp8_1_1 タグ=TAG20070304T182752
チャネルORA_DISK_1: リストアが完了しました。経過時間: 00:00:02
アーカイブ・ログ・ファイル名=/opt/app/oracle/archive/1_209_616340345.dbf スレッド=1 順序=209
……省略……
アーカイブ・ログ・ファイル名=/opt/app/oracle/archive/1_258_616340345.dbf スレッド=1 順序=258
メディア・リカバリが完了しました。経過時間: 00:05:27
recoverが完了しました(完了時間: 2007/03/04 19:19:36) |
リスト8 障害対象の表領域をリカバリする |
最後にリカバリを行った表領域をオンラインに戻します。これでUSERS表領域障害からのオンラインリカバリが完了です(リスト9)。
RMAN> sql 'alter tablespace users online';
(SQL文:alter tablespace users online) |
リスト9 ターゲット・データベースをオープンする |
第9回「バックアップの所要時間を短縮するテクニック」の2ページ「増分バックアップの高速化」で説明したチェンジ・トラッキング・ファイルはRMANでバックアップを取得することができず、障害発生時には再作成で対応する必要があります。また、ターゲット・データベースの起動時にチェンジ・トラッキング・ファイルが存在しない場合は、これまでの場所に再作成を自動で行いますが、作成ができなかった場合は、ターゲット・データベースをオープンすることができません。
このようなときは一度、チェンジ・トラッキング・ファイルを無効(disable)にしてから、再作成を行う必要があります。また、チェンジ・トラッキング・ファイルが復旧されても高速増分バックアップを実施するには再度、フルバックアップを取得する必要がありますので、注意してください。