はじめに
Recovery Manager(以下、RMAN)は、Oracle Databaseで標準で利用できる、Oracle社純正のバックアップ、リカバリツールです。
オンラインバックアップ、差分(Oracle用語だと累積増分)バックアップ、増分(Oracle用語だと差分増分)バックアップ、オフラインバックアップの実行や、リストア、リカバリの実行の他、障害の自動検知と通知および復旧手順のアドバイス機能といったものもあります。
Oracleのオンラインバックアップを取得する(障害発生直前まで復旧させたい)場合、第一に利用を検討すべきツールですが、意外と存在と有用性が知られていないように思います。
RMANを利用せずにOracleのオンラインバックアップを取得したり、障害時にリカバリするには、Oracleに対する知見がそれなりに必要なのですが、RMANを使う事で、そのかなりの部分をRMANがよしなに対処してくれます。
とは言え、RMANのメリットと使い方については、色々なサイトや資料がWeb上にアップされているので、本記事では、RMANによるバックアップについて簡単に触れた後、Oracleの障害発生時にRMANによるバックアップからどのように復旧させるのか、その具体的な手段を中心に記載したいと思います。
Oracleのマニュアルや資料を見ると、「差分増分バックアップ」、「累積増分バックアップ」という見慣れない用語が出てきます。
一般的なIT用語では、「差分増分バックアップ」=「増分バックアップ」、「累積増分バックアップ」=「差分バックアップ」になるのですが、とても分かりにくく混乱しやすいので、本記事では一般的な意味合いでの用語として、増分バックアップ、差分バックアップという記述をします。
RMANのマニュアルについては、以下を参照ください。
前提
本記事はOracle19c前提で記載します。
RMANのコマンドなど、古いOracleバージョンでは構文エラー(ALTER文など)になり動作しない記述もありますので注意ください。
RMANによるバックアップ
RPOが障害発生直前という前提で、RMANによるオンラインバックアップを取得する事にします。
また、Oracle Databaseはアーカイブログモードになっているものとします。
(参考)アーカイブログモードへの変更方法
$ sqlplus / as sysdba
SQL> -- ログモードの確認
SQL> archive log list
データベース・ログ・モード 非アーカイブ・モード
自動アーカイブ 使用禁止
アーカイブ先 /opt/app/oracle/product/19.0.0/dbhome_1/dbs/arch
最も古いオンライン・ログ順序 13
現行のログ順序 15
SQL>
SQL> -- インスタンスをシャットダウン
SQL> shutdown immediate
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
SQL>
SQL> -- mountモードで起動
SQL> startup mount
ORACLEインスタンスが起動しました。
Total System Global Area 1073738488 bytes
Fixed Size 9143032 bytes
Variable Size 285212672 bytes
Database Buffers 775946240 bytes
Redo Buffers 3436544 bytes
データベースがマウントされました。
SQL>
SQL> -- アーカイブログモードに変更
SQL> alter database archivelog;
データベースが変更されました。
SQL> -- ログモードの確認
SQL> archive log list
データベース・ログ・モード アーカイブ・モード
自動アーカイブ 有効
アーカイブ先 /opt/app/oracle/product/19.0.0/dbhome_1/dbs/arch
最も古いオンライン・ログ順序 13
アーカイブする次のログ順序 15
現行のログ順序 15
SQL>
SQL> -- データベースをOpenに
SQL> alter database open;
データベースが変更されました。
RMAN設定とバックアップ
RMAN設定とフルバックアップをディスクに出力する例を記載します。
■RMAN設定例
以下を実行する事により、
RMAN> configure retention policy to redundancy 3;
RMAN> configure controlfile autobackup on;
RMAN> configure backup optimization on;
- バックアップセットを3世代分保管
- バックアップセットにSPファイルおよび制御ファイルのバックアップを含める
- バックアップの最適化を有効化
が指定されます。
RMAN設定は、configureコマンドで行います。
バックアップの出力先(DEVICE TYPE)には、DISKとTAPE(SBT_TAPE)が選択できます(デフォルトはDISK)。
また、Oracle Database Cloud Backup Module(ODCBM)を利用すると(要OCI CLI)、RMANによるバックアップデータをOCIのオブジェクトストレージに出力する事もできます。
■バックアップスクリプトの例
以下のようなコマンドをスクリプト化したものをcronやジョブ管理ソフトなどからRMANで実行すると、実行する度にformatで指定した場所にフルバックアップ(アーカイブログ、SPファイル、制御ファイルも含むバックアップセット)が出力され、不要なアーカイブログが削除されます。
また、制御ファイルはバックアップ・リカバリ時に重要なファイルであるため、例としては若干過剰ではありますが、更に3パターンでバックアップを出力しています。
最後に、不要となるバックアップデータを削除しています。
$ rman target /
Recovery Manager: Release 19.0.0.0.0 - Production on 金 4月 14 15:14:55 2023
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
ターゲット・データベース: ORCL (DBID=1644198456)に接続されました
RMAN># formatで指定した場所にフルバックアップ(level 0)を圧縮して出力し、
# 不要となるアーカイブログを削除
# バックアップセットには、制御ファイルおよびSPファイルのバックアップも含まれる
RMAN> backup as compressed backupset incremental level 0 database
format '/mnt/backupset/FullBackup_%n_dbid_%I_%T_%t'
plus archivelog delete all input;
# 制御ファイルのバックアップを更に3パターンで取得
RMAN> alter database backup controlfile to trace;
RMAN> backup current controlfile format '/mnt/backupset/ctl_%n_dbid_%I_%T_%t';
RMAN> copy current controlfile to '/mnt/backupset/control.bk';
# カタログとファイルシステム上のファイル情報が一致しているかをチェックし、
# 差異がある場合はカタログ情報を更新
RMAN> crosscheck backup;
RMAN> delete expired backup;
RMAN> crosscheck archivelog all;
RMAN> delete expired archivelog all;
# 不要となるバックアップデータを削除
RMAN> delete noprompt obsolete;
この例では、RMAN設定で3世代分のバックアップを保管するよう設定している(configure retention policy to redundancy 3;)ので、delete obsolete;コマンドでバックアップセットが消されるのは4回目のバックアップのタイミングになります。
バックアップスクリプト実行結果例
$ rman target /
Recovery Manager: Release 19.0.0.0.0 - Production on 金 3月 10 11:42:37 2023
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
ターゲット・データベース: ORCL (DBID=XXXXXXXXXX)に接続されました
RMAN> configure retention policy to redundancy 3;
新しいRMAN構成パラメータ:
CONFIGURE RETENTION POLICY TO REDUNDANCY 3;
新しいRMAN構成パラメータが格納できました
RMAN> configure controlfile autobackup on;
新しいRMAN構成パラメータ:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
新しいRMAN構成パラメータが格納できました
RMAN> configure backup optimization on;
新しいRMAN構成パラメータ:
CONFIGURE BACKUP OPTIMIZATION ON;
新しいRMAN構成パラメータが格納できました
RMAN> backup as compressed backupset incremental level 0 database
format '/mnt/backupset/FullBackup_%n_dbid_%I_%T_%t'
plus archivelog delete all input;
2> 3>
backupを23-03-10で開始しています
現在のログがアーカイブされました。
チャネルORA_DISK_1の使用
チャネルORA_DISK_1: 圧縮型アーカイブ・ログ・バックアップ・セットを開始しています
チャネルORA_DISK_1: バックアップ・セットにアーカイブ・ログを指定しています
入力アーカイブ・ログ・スレッド=1 順序=26 レコードID=12 スタンプ=1131131786
チャネルORA_DISK_1: ピース1 (23-03-10)を起動します
チャネルORA_DISK_1: ピース1 (23-03-10)が完了しました
ピース・ハンドル=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/191mncsa_1_1 タグ=TAG20230310T191626 コメント=NONE
チャネルORA_DISK_1: バックアップ・セットが完了しました。経過時間: 00:00:01
チャネルORA_DISK_1: アーカイブ・ログを削除しています
アーカイブ・ログ・ファイル名=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/arch1_26_1116417720.dbf レコードID=12 スタンプ=1131131786
backupを23-03-10で終了しました
backupを23-03-10で開始しています
チャネルORA_DISK_1の使用
チャネルORA_DISK_1: 圧縮型増分レベル0のデータファイル・バックアップ・セットを開始しています
チャネルORA_DISK_1: バックアップ・セットにデータファイルを指定しています
入力データファイル ファイル番号=00001 名前=/opt/app/oracle/oradata/ORCL/system01.dbf
入力データファイル ファイル番号=00003 名前=/opt/app/oracle/oradata/ORCL/sysaux01.dbf
入力データファイル ファイル番号=00005 名前=/opt/app/oracle/oradata/ORCL/undotbs01.dbf
入力データファイル ファイル番号=00007 名前=/opt/app/oracle/oradata/ORCL/users01.dbf
チャネルORA_DISK_1: ピース1 (23-03-10)を起動します
チャネルORA_DISK_1: ピース1 (23-03-10)が完了しました
ピース・ハンドル=/mnt/backupset/FullBackup_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131131787 タグ=TAG20230310T191627 コメント=NONE
チャネルORA_DISK_1: バックアップ・セットが完了しました。経過時間: 00:00:25
チャネルORA_DISK_1: 圧縮型増分レベル0のデータファイル・バックアップ・セットを開始しています
チャネルORA_DISK_1: バックアップ・セットにデータファイルを指定しています
入力データファイル ファイル番号=00012 名前=/opt/app/oracle/oradata/ORCL/orclpdb1/perfstat01.dbf
入力データファイル ファイル番号=00010 名前=/opt/app/oracle/oradata/ORCL/orclpdb1/undotbs01.dbf
入力データファイル ファイル番号=00008 名前=/opt/app/oracle/oradata/ORCL/orclpdb1/system01.dbf
入力データファイル ファイル番号=00009 名前=/opt/app/oracle/oradata/ORCL/orclpdb1/sysaux01.dbf
入力データファイル ファイル番号=00011 名前=/opt/app/oracle/oradata/ORCL/orclpdb1/users01.dbf
チャネルORA_DISK_1: ピース1 (23-03-10)を起動します
チャネルORA_DISK_1: ピース1 (23-03-10)が完了しました
ピース・ハンドル=/mnt/backupset/FullBackup_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131131812 タグ=TAG20230310T191627 コメント=NONE
チャネルORA_DISK_1: バックアップ・セットが完了しました。経過時間: 00:00:15
チャネルORA_DISK_1: 圧縮型増分レベル0のデータファイル・バックアップ・セットを開始しています
チャネルORA_DISK_1: バックアップ・セットにデータファイルを指定しています
入力データファイル ファイル番号=00006 名前=/opt/app/oracle/oradata/ORCL/pdbseed/undotbs01.dbf
入力データファイル ファイル番号=00002 名前=/opt/app/oracle/oradata/ORCL/pdbseed/system01.dbf
入力データファイル ファイル番号=00004 名前=/opt/app/oracle/oradata/ORCL/pdbseed/sysaux01.dbf
チャネルORA_DISK_1: ピース1 (23-03-10)を起動します
チャネルORA_DISK_1: ピース1 (23-03-10)が完了しました
ピース・ハンドル=/mnt/backupset/FullBackup_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131131827 タグ=TAG20230310T191627 コメント=NONE
チャネルORA_DISK_1: バックアップ・セットが完了しました。経過時間: 00:00:15
backupを23-03-10で終了しました
backupを23-03-10で開始しています
現在のログがアーカイブされました。
チャネルORA_DISK_1の使用
チャネルORA_DISK_1: 圧縮型アーカイブ・ログ・バックアップ・セットを開始しています
チャネルORA_DISK_1: バックアップ・セットにアーカイブ・ログを指定しています
入力アーカイブ・ログ・スレッド=1 順序=27 レコードID=13 スタンプ=1131131842
チャネルORA_DISK_1: ピース1 (23-03-10)を起動します
チャネルORA_DISK_1: ピース1 (23-03-10)が完了しました
ピース・ハンドル=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/1d1mncu2_1_1 タグ=TAG20230310T191722 コメント=NONE
チャネルORA_DISK_1: バックアップ・セットが完了しました。経過時間: 00:00:01
チャネルORA_DISK_1: アーカイブ・ログを削除しています
アーカイブ・ログ・ファイル名=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/arch1_27_1116417720.dbf レコードID=13 スタンプ=1131131842
backupを23-03-10で終了しました
Control File and SPFILE Autobackupを23-03-10で開始しています
ピース・ハンドル=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/c-XXXXXXXXXX-20230310-0b コメント=NONE
Control File and SPFILE Autobackupを23-03-10で終了しました
RMAN>
RMAN> alter database backup controlfile to trace;
文が処理されました
RMAN> backup current controlfile format '/mnt/backupset/ctl_%n_dbid_%I_%T_%t';
backupを23-03-10で開始しています
チャネルORA_DISK_1の使用
チャネルORA_DISK_1: フル・データファイル・バックアップ・セットを開始しています
チャネルORA_DISK_1: バックアップ・セットにデータファイルを指定しています
現行の制御ファイルをバックアップ・セットに組み込んでいます
チャネルORA_DISK_1: ピース1 (23-03-10)を起動します
チャネルORA_DISK_1: ピース1 (23-03-10)が完了しました
ピース・ハンドル=/mnt/backupset/ctl_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131131845 タグ=TAG20230310T191725 コメント=NONE
チャネルORA_DISK_1: バックアップ・セットが完了しました。経過時間: 00:00:01
backupを23-03-10で終了しました
Control File and SPFILE Autobackupを23-03-10で開始しています
ピース・ハンドル=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/c-XXXXXXXXXX-20230310-0c コメント=NONE
Control File and SPFILE Autobackupを23-03-10で終了しました
RMAN> copy current controlfile to '/mnt/backupset/control.bk';
backupを23-03-10で開始しています
チャネルORA_DISK_1の使用
チャネルORA_DISK_1: データファイルのコピーを開始しています
現行の制御ファイルをコピー中です
出力ファイル名=/mnt/backupset/control.bk タグ=TAG20230310T191728 レコードID=4 スタンプ=1131131848
チャネルORA_DISK_1: データファイルのコピーが完了しました。経過時間: 00:00:01
backupを23-03-10で終了しました
Control File and SPFILE Autobackupを23-03-10で開始しています
ピース・ハンドル=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/c-XXXXXXXXXX-20230310-0d コメント=NONE
Control File and SPFILE Autobackupを23-03-10で終了しました
RMAN>
RMAN> crosscheck backup;
チャネルORA_DISK_1の使用
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/mnt/backupset/FullBackup_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131130143 レコードID=11 スタンプ=1131130143
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/mnt/backupset/FullBackup_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131130168 レコードID=12 スタンプ=1131130168
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/mnt/backupset/FullBackup_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131130183 レコードID=13 スタンプ=1131130183
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/0f1mnbam_1_1 レコードID=14 スタンプ=1131130198
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/0l1mnbj1_1_1 レコードID=19 スタンプ=1131130465
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/mnt/backupset/FullBackup_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131130466 レコードID=20 スタンプ=1131130466
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/mnt/backupset/FullBackup_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131130491 レコードID=21 スタンプ=1131130491
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/mnt/backupset/FullBackup_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131130506 レコードID=22 スタンプ=1131130506
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/0p1mnbkp_1_1 レコードID=23 スタンプ=1131130521
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/0v1mnbnj_1_1 レコードID=28 スタンプ=1131130611
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/mnt/backupset/FullBackup_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131130613 レコードID=29 スタンプ=1131130613
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/mnt/backupset/FullBackup_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131130638 レコードID=30 スタンプ=1131130638
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/mnt/backupset/FullBackup_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131130653 レコードID=31 スタンプ=1131130653
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/131mnbpm_1_1 レコードID=32 スタンプ=1131130678
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/c-XXXXXXXXXX-20230310-08 レコードID=33 スタンプ=1131130679
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/c-XXXXXXXXXX-20230310-09 レコードID=35 スタンプ=1131130684
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/c-XXXXXXXXXX-20230310-0a レコードID=36 スタンプ=1131130686
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/191mncsa_1_1 レコードID=37 スタンプ=1131131786
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/mnt/backupset/FullBackup_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131131787 レコードID=38 スタンプ=1131131787
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/mnt/backupset/FullBackup_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131131812 レコードID=39 スタンプ=1131131814
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/mnt/backupset/FullBackup_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131131827 レコードID=40 スタンプ=1131131827
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/1d1mncu2_1_1 レコードID=41 スタンプ=1131131842
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/c-XXXXXXXXXX-20230310-0b レコードID=42 スタンプ=1131131844
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/mnt/backupset/ctl_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131131845 レコードID=43 スタンプ=1131131846
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/c-XXXXXXXXXX-20230310-0c レコードID=44 スタンプ=1131131847
バックアップ・ピースがクロスチェックされました: 'AVAILABLE'が検出されました
バックアップ・ピース・ハンドル=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/c-XXXXXXXXXX-20230310-0d レコードID=45 スタンプ=1131131849
26オブジェクトをクロスチェックしました
RMAN> delete expired backup;
チャネルORA_DISK_1の使用
指定がリポジトリ内のどのバックアップとも一致しません
RMAN> crosscheck archivelog all;
チャネル: ORA_DISK_1がリリースされました
チャネル: ORA_DISK_1が割り当てられました
チャネルORA_DISK_1: SID=425 デバイス・タイプ=DISK
指定がリポジトリ内のどのアーカイブ・ログとも一致しません
RMAN> delete expired archivelog all;
チャネル: ORA_DISK_1がリリースされました
チャネル: ORA_DISK_1が割り当てられました
チャネルORA_DISK_1: SID=425 デバイス・タイプ=DISK
指定がリポジトリ内のどのアーカイブ・ログとも一致しません
RMAN>
RMAN> delete noprompt obsolete;
Recovery Manager保存ポリシーがコマンドに適用されます。
Recovery Manager保存ポリシーが冗長性3に設定されます。
チャネルORA_DISK_1の使用
次の不要なバックアップおよびコピーが削除されます:
Type Key Completion Time Filename/Handle
-------------------- ------ ------------------ --------------------
バックアップ・セット 11 23-03-10
バックアップ・ピース 11 23-03-10 /mnt/backupset/FullBackup_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131130143
バックアップ・セット 12 23-03-10
バックアップ・ピース 12 23-03-10 /mnt/backupset/FullBackup_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131130168
バックアップ・セット 13 23-03-10
バックアップ・ピース 13 23-03-10 /mnt/backupset/FullBackup_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131130183
バックアップ・セット 14 23-03-10
バックアップ・ピース 14 23-03-10 /opt/app/oracle/product/19.0.0/dbhome_1/dbs/0f1mnbam_1_1
バックアップ・セット 19 23-03-10
バックアップ・ピース 19 23-03-10 /opt/app/oracle/product/19.0.0/dbhome_1/dbs/0l1mnbj1_1_1
バックアップ・セット 33 23-03-10
バックアップ・ピース 33 23-03-10 /opt/app/oracle/product/19.0.0/dbhome_1/dbs/c-XXXXXXXXXX-20230310-08
バックアップ・セット 35 23-03-10
バックアップ・ピース 35 23-03-10 /opt/app/oracle/product/19.0.0/dbhome_1/dbs/c-XXXXXXXXXX-20230310-09
バックアップ・セット 36 23-03-10
バックアップ・ピース 36 23-03-10 /opt/app/oracle/product/19.0.0/dbhome_1/dbs/c-XXXXXXXXXX-20230310-0a
バックアップ・セット 43 23-03-10
バックアップ・ピース 43 23-03-10 /mnt/backupset/ctl_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131131845
バックアップ・ピースが削除されました
バックアップ・ピース・ハンドル=/mnt/backupset/FullBackup_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131130143 レコードID=11 スタンプ=1131130143
バックアップ・ピースが削除されました
バックアップ・ピース・ハンドル=/mnt/backupset/FullBackup_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131130168 レコードID=12 スタンプ=1131130168
バックアップ・ピースが削除されました
バックアップ・ピース・ハンドル=/mnt/backupset/FullBackup_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131130183 レコードID=13 スタンプ=1131130183
バックアップ・ピースが削除されました
バックアップ・ピース・ハンドル=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/0f1mnbam_1_1 レコードID=14 スタンプ=1131130198
バックアップ・ピースが削除されました
バックアップ・ピース・ハンドル=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/0l1mnbj1_1_1 レコードID=19 スタンプ=1131130465
バックアップ・ピースが削除されました
バックアップ・ピース・ハンドル=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/c-XXXXXXXXXX-20230310-08 レコードID=33 スタンプ=1131130679
バックアップ・ピースが削除されました
バックアップ・ピース・ハンドル=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/c-XXXXXXXXXX-20230310-09 レコードID=35 スタンプ=1131130684
バックアップ・ピースが削除されました
バックアップ・ピース・ハンドル=/opt/app/oracle/product/19.0.0/dbhome_1/dbs/c-XXXXXXXXXX-20230310-0a レコードID=36 スタンプ=1131130686
バックアップ・ピースが削除されました
バックアップ・ピース・ハンドル=/mnt/backupset/ctl_ORCLxxxx_dbid_XXXXXXXXXX_20230310_1131131845 レコードID=43 スタンプ=1131131846
9オブジェクトを削除しました
RMAN>
なお、増分バックアップ、差分バックアップをする場合は、以下のように指定します。
# 増分(差分増分)バックアップ
RMAN> backup as compressed backupset incremental level 1 database;
# 差分(累積増分)バックアップ
RMAN> backup as compressed backupset incremental level 1 cumulative database;
※incremental level 0 を指定すると、フルバックアップが実行される。
また、以下のようなコマンドを実行する事で、増分更新バックアップを取得する事もできます(スクリプトで実行する場合はRUNブロックで囲って実行)。
RMAN> RECOVER COPY OF DATABASE WITH TAG 'incr_update';
RMAN> BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE;
増分更新バックアップを行うと、増分バックアップを取得後、最初に取得したフルバックアップに増分バックアップデータを適用(RECOVER COPY OF ・・・の部分)し、増分バックアップの度にフルバックアップを最新の状態に更新する事ができます。
※上記コマンドを実行した場合、フルバックアップに増分バックアップが適用されるのは3回目の実行からになります。
増分バックアップは、バックアップに必要となるディスク容量やバックアップの取得時間を削減できるメリットがありますが、リストアには時間がかかるというデメリットがあります。
増分更新バックアップとする事で、ディスク容量もリストアの時間の削減も期待する事ができるため、増分更新バックアップは非常に有効な手段になります。
RMANを利用したバックアップについては、ここまでとし、次のセクションからは障害発生時にリカバリ方法について記載していきます。
障害の種類と対応策
まず、障害の種類とその対応策について記載します。
| 障害が発生した場所 | 障害による影響 | 対応策 |
|---|---|---|
| 制御ファイルの破損または消失 | データベースが停止する。起動できない。 | 多重化した制御ファイルのうち、正常な制御ファイルが残っている場合は、その制御ファイルをコピーし、制御ファイルを復旧。 制御ファイルが全て破損した場合は、制御ファイルをバックアップからリストア後、復旧を行う(オンラインREDOログが使用可能な場合は完全リカバリ、そうでない場合は不完全リカバリ) |
| オンラインREDOログファイルの破損または消失 | 多重化された全てのオンラインREDOログファイルが破損した場合、データベースが停止。 | clear logfileの後不完全リカバリ。もしくはロググループメンバーの再作成など。 |
| SYSTEM表領域、UNDO表領域の破損または消失 | SYSTEM表領域またはUNDO表領域に対する、読取りまたは書込み要求に対し、エラーが返された後、データベースが停止。 | 破損したデータファイル(SYSTEM表領域、またはUNDO表領域)をバックアップからリストア後、アーカイブREDOログファイルおよびオンラインREDOログファイルを適用し、障害発生直前の状態まで復旧を行う。 |
| ユーザー表領域、SYSAUX表領域の破損または消失 | 読取または書込み要求に対しエラーが戻される。データベース自体は稼動した状態だが、影響を受けたデータファイルがオフライン状態となる。 | 障害が発生して表領域をオフラインにした後、破損したデータファイル(ユーザー表領域、またはSYSAUX表領域)をバックアップからリストアする。 その後、表領域に対してアーカイブREDOログファイルおよびオンラインREDOログファイルを適用し、障害発生直前の状態まで復旧を行う。 |
| 全てのデータファイルが破損または消失 | データベースが停止する。起動できない。 | データベース全体のリストア後、アーカイブREDOログファイルおよびオンラインREDOログファイルを適用し、障害発生直前の状態まで復旧を行う。 制御ファイルやオンラインREDOログファイルも破損している場合は、不完全回復となる。 |
| データブロック障害 | 破損したデータブロックに対する読取りまたは書込み要求に対し、エラーが返される。ユーザー表領域のブロックが破損した場合は、アプリケーションの特定の機能が、SYSTEM表領域などのデータブロックが破損した場合はデータベースが停止する場合もある。 | 破損したデータブロックの特定後、RECOVERコマンドでブロックメディアリカバリを行う。 |
| ディスク障害などのハードウェア障害 | DBサーバーにアクセスできない。 | ハードウェア障害の解消もしくは別サーバーを用意した後、Oracleの再セットアップを行い、バックアップからリストア・リカバリ(不完全回復)を行う。 代わりのサーバーを用意し、そのサーバーにリストアして切り替える。 バックアップをイメージコピー形式で取得している場合は、SWITCHコマンドでデータファイルをバックアップ先のものに切り替える。 |
| 一時表領域の破損 | 一時表領域を使用するような要求(大量データのソートや一時表を利用する処理など)に対しエラーが返される。 | 一時表領域の再作成。 |
Oracleのどこに障害が発生しているか調べる方法
まず確認するのは、アラートログです。
制御ファイル、オンラインREDOログファイルの破損もしくは消失については、アラートログとOracle起動時のエラーメッセージを確認します(データファイルの破損もしくは消失についても基本は同じ)。
アラートログやアプリケーションからのSQL実行時のエラーなどからデータファイルに障害がありそうな場合は、v$recover_fileで確認する事ができます。
例)
> sqlplus / as sysdba
SQL> select * from v$recover_file;
ONLINE_
FILE# ONLINE STATUS ERROR CHANGE# TIME
-------- --------- ------- -------------------------------- --------- -------
1 ONLINE ONLINE FILE NOT FOUND 0
上記SQLで結果が0件の場合、障害が発生しているデータファイルが存在していない事を示します。
結果が返ってきた場合、FILE#列のデータファイル番号のデータファイルが、ERROR列の内容が原因でリカバリが必要である事を確認できます。
その他に、後述する「自動復旧アドバイザ」を利用する方法があります(おすすめ)。
障害に対するリストア、リカバリ方法
ここからは、前のセクションで紹介した障害毎の対応方法について、具体的な内容を記載していきます。
これ以降、インスタンスを停止する際のコマンドとして、SQL> shutdown immediateと記載していきます。
しかし障害発生時には、shutdown immediateではインスタンスが停止しない場合があります。
そのような場合、SQL> shutdown abortで停止させる事になりますが、abortでの停止はあくまでインスタンスが停止できない場合の緊急対応的な位置付けになるため、どうしようもない場合を除き、shutdown immediateでインスタンスを停止するようにします。
1. 制御ファイルの破損または消失
制御ファイルは通常複数ファイルで構成され、それぞれのファイルに同一の情報が書き込まれています。これらの制御ファイルのうち、1つでもファイルが破損または消失すると、Oracleが起動できない状態になります。
制御ファイルが破損または消失した場合、アラートログに対象の制御ファイル名と共に「ORA-00202」などのエラーが出力されます。
以下では、制御ファイルのうち一部が破損または消失し、正常なファイルが残っている場合、全ての制御ファイルが破損または消失した場合とに分け、対応例を記述します。
1-1. 一部の制御ファイルが残っている場合
1-1-1. インスタンスが起動している場合は、シャットダウン
> sqlplus / as sysdba
SQL> shutdown immediate
1-1-2. 障害が発生したファイルを退避後、正しい状態のファイルをコピーしてRENAME
例えば、CONTROL01.CTL、CONTROL02.CTLの2つの制御ファイルが存在し、CONTROL02.CTLが破損した場合は、CONTROL02.CTLを退避した後、CONTROL01.CTLをコピーし、コピーしたファイルをCONTROL02.CTLにRENAMEします。
1-1-3. データベースを起動
SQL> startup
1-2. 全ての制御ファイルが破損または消失した場合
1-2-1. インスタンスが起動している場合は、シャットダウン
> sqlplus / as sysdba
SQL> shutdown immediate
1-2-2. nomountモードでインスタンスを起動
SQL> startup nomount
SQL> exit;
1-2-3. RMANでSYSで接続後、DBIDをセットし、制御ファイルをリストア
DBIDをセット後、制御ファイルをリストアし、リストアが完了したらmountモードに切り替えます。
> RMAN target /
RMAN> set DBID XXXXXXXXX ※DBIDは数字
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;
RMAN> alter database mount;
DBID(データベース識別子)はv$databaseで確認する事ができますが、制御ファイルが破損した場合DBIDを確認する事ができません。
その為、バックアップ取得時にDBIDをテキストなどに出力しておくか、バックアップセット出力時にFormatに%Iオプションを付け、データベースにアクセスしなくてもDBIDが分かるようにしておく必要があります。
DBIDが分からなくなってしまった場合は、backup current controlfile句やcopy current controlfile to '制御ファイルのバックアップ先パス'句でバックアップした制御ファイルを元の場所にリストアするようにします。
※制御ファイルの配置場所は、pfileのCONTROL_FILESパラメータか、アラートログのインスタンス起動時のログに出力されているCONTROL_FILESパラメータの値を確認します。
1-2-4. アーカイブREDOログおよびオンラインREDOログ(使用可能な場合)を適用してリカバリ
RMAN> recover database using backup controlfile until cancel;
リカバリ時に必要なアーカイブREDOログファイルがないと、以下のようなメッセージが表示される場合があります。
ORA-00279: 変更27525255(02/18/2021 20:06:03で生成)にはスレッド1が必要です
ORA-00289:
検討すべきログファイル:/opt/app/oracle/arch/ARC0000000001_1064865857.0001
ORA-00280: 変更27525255(スレッド1)は順序番号1に存在します
ログの指定: {<RET>=suggested | filename | AUTO | CANCEL}
このような場合、オンラインREDOログファイルに適用が必要な変更情報が含まれている為、オンラインREDOログファイル(のフルパス)を指定してEnterキーを押下し、リカバリできるか確認します。
※ロググループメンバーのファイルを指定し、違っている場合は他のロググループメンバーのファイルを指定します。
1-2-5. リカバリが完了後、RESETLOGSオプションを指定してデータベースをオープン(不完全回復)
RMAN> alter database open resetlogs;
上記対応では不完全回復となるため、リカバリ完了後、必ずフルバックアップを取得するようにします。
2. オンラインREDOログファイルの破損または消失
オンラインREDOログは、通常複数のロググループに分かれ、各ロググループにはログメンバーとして複数のログファイル(内容はミラーリングされ同一)が存在します。
ロググループ内の一部のメンバーファイルが破損または消失した場合は、ログメンバーの再作成によりリカバリ可能ですが、ロググループの全てのメンバーファイルが破損または消失すると、データベースは起動できなくなります。
また、ロググループの全てのメンバーファイルが破損または消失した場合でも、対象のロググループがアクティブか非アクティブかで復旧方法が異なります。
その為まずは、オンラインREDOログファイルの状況確認から始めます。
2-1. インスタンスが停止している場合は、mountモードで起動
ロググループの一部メンバーファイルが破損または消失した場合、インスタンスは停止せず起動した状態であるため、この手順は実行不要です。
> sqlplus / as sysdba
SQL> startup mount
2-2. v$logfileを確認しstatus列がinvalidでないかを確認
以下の例では、ロググループ2の全てのメンバーファイルが破損または消失した状態
SQL> select group#, status, member from v$logfile;
GROUP# STATUS MEMBER
---------- ------- ---------------------------------------------
1 /opt/app/oracle/oradata/ORCL/redo0101.log
1 /opt/app/oracle/oradata/ORCL/redo0102.log
2 INVALID /opt/app/oracle/oradata/ORCL/redo0201.log
2 INVALID /opt/app/oracle/oradata/ORCL/redo0202.log
3 /opt/app/oracle/oradata/ORCL/redo0301.log
3 /opt/app/oracle/oradata/ORCL/redo0302.log
2-3. v$logを確認しロググループのstatusの状態を確認
v$logで、STATUSが「ACTIVE」または「CURRENT」のグループがアクティブなロググループで、「INACTIVE」のグループは非アクティブなロググループ。
ARCHIVED列が「YES」のグループは、アーカイブログファイルとして変更情報が出力済みのロググループで、「NO」のグループはアーカイブログファイルに変更情報が出力されていないロググループ。
SQL> select group#, members, status, archived from v$log;
GROUP# MEMBERS STATUS ARC
---------- ---------- ---------------- ---
1 2 INACTIVE YES
2 2 CURRENT NO
3 2 INACTIVE YES
この例では、ロググループ2の全メンバーファイルが破損または消失しており、そのロググループはアクティブなロググループ(アーカイブログファイルに未出力)である事を意味します。
これ以降は、オンラインREDOログの破損状況によりリカバリ状況が変わります。
2-4. ロググループの一部のメンバーファイルが破損または消失した場合
この状況の場合、データベースは停止せずに動作している状態ですが、生き残っているメンバーファイルが破損した場合、データベースが停止します。
メンバーファイルが破損または消失した場合は、メンバーファイルの再作成を行います。
2-4-1. v$logで破損しているREDOログファイルのSTATUSがCURRENTの場合、ログスイッチする
以下の例では、ロググループ2のメンバー「redo0202.log」のファイルが破損しており、ロググループ2がアクティブになっている。
SQL> select group#, status, member from v$logfile;
GROUP# STATUS MEMBER
---------- ------- ---------------------------------------------
1 /opt/app/oracle/oradata/ORCL/redo0101.log
1 /opt/app/oracle/oradata/ORCL/redo0102.log
2 /opt/app/oracle/oradata/ORCL/redo0201.log
2 INVALID /opt/app/oracle/oradata/ORCL/redo0202.log
3 /opt/app/oracle/oradata/ORCL/redo0301.log
3 /opt/app/oracle/oradata/ORCL/redo0302.log
SQL> select group#, members, status, archived from v$log;
GROUP# MEMBERS STATUS ARC
---------- ---------- ---------------- ---
1 2 INACTIVE YES
2 2 CURRENT NO
3 2 INACTIVE YES
このような状況の場合、以下のSQLを実行し、別のロググループにログスイッチする。
SQL> alter system switch logfile;
SQL> alter system checkpoint;
上記実施後、v$logのSTATUSがINACTIVE(この例ではGROUP#2)になっていることを確認し、次の手順に進む。
2-4-2. 破損しているメンバーを再作成
SQL> -- 破損しているメンバーを削除
SQL> alter database drop logfile member '/opt/app/oracle/oradata/ORCL/redo0202.log';
SQL>
SQL> -- 破損していたメンバーを再作成
SQL> alter database add logfile member '/opt/app/oracle/oradata/ORCL/redo0202.log' reuse to group 2;
その後、再作成したREDOロググループのSTATUSが「CURRENT」になるまでログスイッチし、再作成したログメンバーのSTATUSが「INVALID」でなくなることを確認します。
2-5. 非アクティブなロググループの全てのメンバーファイルが破損または消失した場合
非アクティブなロググループの全てのメンバーファイルが破損または消失した場合、v$logで、破損したロググループのarchived列の値が「YES」になっている事を確認します。
archived列の値が「NO」になっている場合は、2-6の手順に進みます。
2-5-1. 破損したロググループの再作成(clear logfileコマンドの実行)
アーカイブログに出力済みのロググループは再作成する事によりリカバリします。
以下のSQLを実行する事により、破損したロググループの再作成が行われます。
※この例ではGROUP#2のロググループの再作成を実施
SQL> alter database clear logfile group 2;
2-5-2. データベースをオープン
ロググループの再作成が完了したらデータベースをオープンします。
SQL> alter database open;
2-6. アクティブなロググループの全てのメンバーファイルが破損または消失した場合
アクティブな(archived列の値が「NO」になっている)ロググループが破損または消失した場合、変更情報がアーカイブログファイルに出力されていない状態であるため、不完全回復を行います。
2-6-1. 破損したロググループのクリア
SQL> alter database clear unarchived logfile group 2;
2-6-2. データベースをオープン(resetlogsオプション)
ロググループの再作成が完了したらデータベースをresetlogsオプションでオープンします。
SQL> alter database open resetlogs;
上記対応では不完全回復となるため、リカバリ完了後、必ずフルバックアップを取得するようにします。
また、この場合アーカイブログファイルも全て無効(リカバリに利用できなくなる)になるため、必要に応じてアーカイブログの削除を行います。
3. SYSTEM表領域、UNDO表領域の破損または消失
3-1. インスタンスが起動している場合は、シャットダウン
> sqlplus / as sysdba
SQL> shutdown immediate
3-2. mountモードでインスタンスを起動
SQL> startup mount;
SQL> exit;
3-3. RMANでSYSで接続後、データベース全体をリストア・リカバリ
> RMAN target /
RMAN> restore database;
リストアが正常に完了したら、リカバリを実行。
RMAN> recover database;
メディアリカバリが完了したら、データベースをオープン。
RMAN> alter database open;
SYSTEM表領域、UNDO表領域を、restore tablespace、recover tablespaceで個別にリストア・リカバリする事も可能です。
4. ユーザー表領域、SYSAUX表領域の破損または消失
アプリケーションで利用しているユーザー表領域、SYSAUX表領域が破損または消失した場合は、データベースが動作した状態で復旧作業が可能です。
4-1. 破損した表領域をオフラインにする
以下は、USERS表領域が破損した場合の例です。
> sqlplus / as sysdba
SQL> alter tablespace users offline;
上記コマンドでオフラインにできない場合は、alter tablespace users offline immediate;を試してみてください。
4-2. 破損した表領域のリストア・リカバリ
> rman target /
RMAN> restore tablespace users;
リストアが完了したら、リカバリを実施。
RMAN> recover tablespace users;
4-3. リカバリした表領域をオンラインにする
SQL> alter tablespace users online;
5. 全てのデータファイルが破損または消失(不完全回復)
制御ファイル、オンラインREDOログファイル以外の全てのデータファイルが破損または消失した場合は、「3. SYSTEM表領域、UNDO表領域の破損または消失」に記載したデータベース全体のリストア、リカバリを行います。
制御ファイル、オンラインREDOログファイルおよび全てのデータファイルが破損または消失した場合は、不完全回復を行います。
5-1. インスタンスが起動している場合は、シャットダウン
> sqlplus / as sysdba
SQL> shutdown immediate
5-2. nomountモードでインスタンスを起動
SQL> startup nomount
SQL> exit;
5-3. RMANでSYSで接続後、DBIDをセットし、制御ファイルをリストアし、mountモードに変更
> RMAN target /
RMAN> set DBID XXXXXXXXX ※DBIDは数字
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;
RMAN> alter database mount;
5-4. データベース全体をリストア・リカバリ(不完全回復)
RMAN> restore database;
リストアが正常に完了したら、リカバリを実行。
RMAN> recover database noredo;
※このパターンでは、オンラインREDOログファイルが存在しないため、障害直前までの状態には戻せず、不完全回復となる。
メディアリカバリが完了したら、データベースをresetlogsオプションでオープンします。
SQL> alter database open resetlogs;
上記対応では不完全回復となるため、リカバリ完了後、必ずフルバックアップを取得するようにします。
また、この場合アーカイブログファイルも全て無効(リカバリに利用できなくなる)になるため、必要に応じてアーカイブログの削除を行います。
6. データブロック障害
Oracleのデータブロック障害は、瞬停などでディスクI/Oエラーが発生した場合などに発生する事があります。
以下の方法は、Enterprise Editionでしか利用できませんが、障害が発生したブロックを復旧する手段を参考までに記載します。
Standard Edition2の環境では、表領域やデータベース全体のリストア・リカバリが必要です。
6-1. データブロック障害が発生しているデータファイルとデータブロックの確認
以下のSQLで障害が発生しているデータファイルとデータブロックを特定します。
> sqlplus / as sysdba
SQL> select * from v$database_block_corruption;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
------ -------- ------- ------------------ ---------
6 108 1 0 CHECKSUM
6-2. データブロック障害が発生しているデータブロックの修復
修復が必要なブロックを特定して修復する場合は、以下のコマンドを実行します。
> rman target /
RMAN> recover datafile 6 block 108;
v$database_block_corruptionに記録されている全てのデータブロックを修復する場合は、以下のコマンドを実行します。
RMAN> recover corruption list;
7. ディスク障害などのハードウェア障害
ディスク障害などのハードウェア障害やOSの障害により、Oracleおよびデータが全て利用できなくなった場合、ハードウェアの修理や交換を行った後、システムバックアップなどからOSやOracleを再設定した後、バックアップからデータベース全体のリストア・リカバリ(不完全回復)を行う事になります(もしくは、予備機にバックアップデータをリストア・リカバリする)。
しかし、バックアップ先をハードウェア障害発生時に切り替え可能(スペック的に本番利用可能)な予備サーバーにしておき、RMANのイメージコピーによるバックアップ(BACKUP AS COPYコマンド)と増分更新バックアップを利用しておく事で、ハードウェア障害時には、SWITCHコマンドでバックアップ先(予備機)にバックアップしているデータファイルにデータベースを切替え、早い時間で復旧する手段をとる事も可能です。
その他、NEWNAMEコマンドで、元の場所とは別のディスクにリストアする事も可能です。
詳細は、以下などを確認ください。
8. 一時表領域の破損または消失
一時表領域を再作成する事でリカバリ可能です。
自動復旧アドバイザ
Oracle11g以降利用できるようになった、RMANのアドバイザ機能がとても有用です。
Oracleの障害対応知識が無くても、以下3つのコマンドを知っていれば、ある程度対応ができてしまいます。
## データベースの障害リストを参照
RMAN> list failure;
## 障害に対するアドバイスを取得
RMAN> advise failure all;
## 自動修復スクリプトの内容を確認
RMAN> repair failure preview;
## 自動修復スクリプトの実行
RMAN> repair failure;
list failureコマンドで、どのような障害が発生しているかを確認し、それぞれの障害に対して取り得るアドバイスをadvise failureコマンドで確認でき、更にrepair failure previewコマンドでリカバリの為に実行するスクリプトの内容を確認後、repair failureコマンドで自動復旧まで実施してくれます。
ただし、アドバイザを有効活用するためには、様々な障害に対応できる為の十分なバックアップが取得されている必要があり、また、リカバリの方法についても理解しておく必要があります。
しかし、本番環境などで障害が発生した場合、色々な方面から突っつかれ、バタバタしていて、慌ててしまう場合もあるかと思います。
そのような場合に自動復旧アドバイザを活用する事で、迅速な対応ができる事が期待できると思います。
おわりに
RMANを利用したバックアップ・リカバリについてまとめてみました。
様々な障害パターンに対して、どのように復旧させることができるのか、知識として理解しつつ、ただそれだけでは実際に障害が発生した際には、十分な対応速度では対応できない事が多いため、一度ご自身で、Oracleデータベースに障害を発生させ、リカバリするまでの検証を行い、手順を整理しておく事をお勧めします。