RMANで表単位リカバリをする際の注意点（RMAN-06024）

この記事は、 JPOUG Advent Calendar 2024 20日目の記事です。

早いものでクリスマスまで残り5日です。データベース管理者が欲しいものと言えば有事の際にリカバリできるバックアップです。

データベースを運用する上でバックアップの取得は必須とも言えますが、取得したバックアップの管理方針や正常にリストア／リカバリできるかの確認も重要です。

Oracle Recovery Manager（以降、RMAN）で表単位のリカバリ時に、「RMAN-06024: 制御ファイルをリストアするためのバックアップまたはコピーが見つかりません。」というエラーに遭遇することがあります。

このエラーは、表単位リカバリのUNTILE TIMEで指定したリカバリポイントが最も古い制御ファイルのバックアップよりも前の時刻だった場合に発生しますが、バックアップを世代管理している場合には、意図せずエラーの発生条件を満たしてしまうことがあります。

本記事では、まず前提となるRMANの表単位リカバリと、バックアップの世代管理を簡単に紹介してから、本題の「RMAN-06024」エラーがなぜ発生するのか、発生した場合の対処方法を解説します。

Index

表単位リカバリ

表単位リカバリは、バックアップおよびリカバリ・ユーザーズ・ガイドの「表および表パーティションのリカバリ」の項目に記載されており、12c R1で追加された機能です。

バックアップおよびリカバリ・ユーザーズ・ガイド_{（※オラクル社のサイトに移動します）}
22 表および表パーティションのリカバリ

RMANで取得したバックアップをソースに、補助インスタンスと呼ばれるクローンDBを一時的に作成。指定した時刻まで不完全リカバリを実施した後にData Pump EXPORTで表を抜き出し、IMPORTを行うことで特定の表を指定した時刻の状態にリカバリできます。

表を誤ってTRUNCATEしてしまった場合など、UNTILE TIMEで当該操作よりも前の時刻を指定することで表単位で復旧できるため、非常に便利な機能です。

バックアップの世代管理

RMANでは「RETENTION POLICY TO REDUNDANCY <n>」のパラメータを使用することで、取得したバックアップを世代管理できます。

たとえば、以下のように「RETENTION POLICY TO REDUNDANCY 2」と設定されていれば、2世代を残すという保存方針です。

　
RMAN> show RETENTION POLICY;
db_unique_name V19EEのデータベースにおけるRMAN構成パラメータ:
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;

指定した世代数を超えたバックアップはすぐ削除されるわけではなく、2世代を残す方針であれば、バックアップが3世代取られた状態で"DELETE OBSOLETE"コマンドを実行したときに、最初に取得した1世代目のバックアップが削除されます。

表単位リカバリ実行時のRMAN-06024

ここからが本題です。

前項でお伝えした世代管理の"世代"ですが、制御ファイルのバックアップはデータベースのバックアップとは別に世代が考慮されます。つまり、データベースと制御ファイルの”世代“は、それぞれ異なるということを理解しておく必要があります。

RMANのパラメータ"CONTROLFILE AUTOBACKUP ON"で制御ファイルのバックアップを自動取得している場合は、RMANでBACKUPコマンドが実行されるたびに制御ファイルのバックアップが取得されます。

例えば、"CONTROLFILE AUTOBACKUP ON"、"RETENTION POLICY TO REDUNDANCY 2"の設定で日曜日、水曜日にベースバックアップ（BACKUP INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG DELETE INPUT）、それ以外の曜日は累積増分バックアップ（BACKUP INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG DELETE INPUT）を行っているような環境では、下図のようにグレーの枠が“世代“として認識されます。

この状態で"DELETE OBSOLETE"を実行すると、データベースのバックアップは2世代分保持するためすべて残りますが、制御ファイルは直近の2つを残して削除されます。

冒頭でお伝えしたとおり、表単位リカバリのUNTILE TIMEで「最も古い制御ファイルのバックアップよりも前の時刻」を指定した場合にRMAN-06024が発生します。上図のような状況では、12月18日（水）のバックアップ取得時刻よりも前を指定して表単位リカバリを行おうとすると、12月15日（日）に取得したLEVEL 0以降のデータベースのバックアップがあったとしても、その時点の制御ファイルのバックアップは既に削除されているために、RMAN-06024が発生してリカバリに失敗します。

　
-- 制御ファイルのバックアップを確認
RMAN> list backupset of controlfile;
バックアップ・セットのリスト
===================
BS Key  Type LV Size       Device Type Elapsed Time 終了時間
------- ---- -- ---------- ----------- ------------ -------------------
109     Full    18.30M     DISK        00:00:00     2024-12-18 00:00:59
        BPキー: 109   ステータス: AVAILABLE  圧縮: NO  タグ: TAG20241218T123037
        ピース名: C:\APP\ORACLE\PRODUCT\19C\DB_HOME\DATABASE\C-464258922-20241218-04
  含まれている制御ファイル: Ckp SCN: 5608534      Ckp時間: 2024-12-18 00:00:59
BS Key  Type LV Size       Device Type Elapsed Time 終了時間
------- ---- -- ---------- ----------- ------------ -------------------
115     Full    18.30M     DISK        00:00:00     2024-12-19 00:00:56
        BPキー: 115   ステータス: AVAILABLE  圧縮: NO  タグ: TAG20241219T123559
        ピース名: C:\APP\ORACLE\PRODUCT\19C\DB_HOME\DATABASE\C-464258922-20241219-05
  含まれている制御ファイル: Ckp SCN: 5609334      Ckp時間: 2024-12-19 00:00:56
-- もっとも古い制御ファイルバックアップ（12-18 00:00）より前を指定すると失敗
RMAN> RECOVER TABLE TAKASHI.RECO_TEST OF PLUGGABLE DATABASE PDB
2> UNTIL TIME "TO_DATE('2024-12-16 20:00:00', 'yyyy-mm-dd hh24:mi:ss')"
3> AUXILIARY DESTINATION 'C:\TEMP'
4> REMAP TABLE 'TAKASHI'.'RECO_TEST':'RECORCV';
：
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: recoverコマンドが12/19/2024 20:59:08で失敗しました
RMAN-03015: ストアド・スクリプトMemory Scriptにエラーが発生しました
RMAN-06026: 見つからないターゲットがあります - リストアを中止します
RMAN-06024: 制御ファイルをリストアするためのバックアップまたはコピーが見つかりません

最も古い制御ファイルのバックアップ以降の時刻をUNTILE TIMEで指定した場合は、問題なくリカバリできます。

　
-- もっとも古い制御ファイルバックアップ（12-18 00:00）より後を指定すると成功
RMAN> RECOVER TABLE TAKASHI.RECO_TEST OF PLUGGABLE DATABASE PDB
2> UNTIL TIME "TO_DATE('2024-12-18 20:00:00', 'yyyy-mm-dd hh24:mi:ss')"
3> AUXILIARY DESTINATION 'C:\TEMP'
4> REMAP TABLE 'TAKASHI'.'RECO_TEST':'RECORCV';
：
チャネルORA_AUX_DISK_1: 制御ファイルをリストア中です
チャネルORA_AUX_DISK_1: バックアップ・ピースC:\APP\ORACLE\PRODUCT\19C\DB_HOME\DATABASE\C-464258922-20241218-04から読取り中です
：
表のインポートを実行しています...
   IMPDP> マスター表"SYS"."TSPITR_IMP_oqpn_DcsB"は正常にロード/アンロードされました
   IMPDP> "SYS"."TSPITR_IMP_oqpn_DcsB"を起動しています:
   IMPDP> オブジェクト型TABLE_EXPORT/TABLE/TABLEの処理中です
   IMPDP> オブジェクト型TABLE_EXPORT/TABLE/TABLE_DATAの処理中です
   IMPDP> . . "TAKASHI"."RECORCV"                   5.546 KB       4行がインポートされました
   IMPDP> オブジェクト型TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICSの処理中です
   IMPDP> オブジェクト型TABLE_EXPORT/TABLE/STATISTICS/MARKERの処理中です
   IMPDP> ジョブ"SYS"."TSPITR_IMP_oqpn_DcsB"が日 12月 19 21:17:26 2024 elapsed 0 00:00:10で正常に完了しました
インポートが完了しました
：
recoverを2024-12-19 21:17:27で終了しました

初めてこのエラーに遭遇した際は、制御ファイルとデータベースのバックアップはあるのにリカバリができないのはなぜか？と少し焦ってしまいました。詳しく調べてみると、”RECOVER TABLE”時にUNTILE TIMEで指定した時刻以前の「制御ファイルとデータベースのバックアップ一式」をリストアするという動作であるために発生していることがわかりました。

なお、RMANで取得したバックアップを、さらに別のディスクやテープなどに2次バックアップを取得していれば、以下のようにCATALOGコマンドで戻したい時刻よりも前の制御ファイルのバックアップピースを追加することで、リカバリできます。

　
RMAN> catalog backuppiece 'C:\app\oracle\product\19c\db_home\database\C-464258922-20241216-02'
RMAN> list backupset of controlfile;
バックアップ・セットのリスト
===================
BS Key  Type LV Size       Device Type Elapsed Time 終了時間
------- ---- -- ---------- ----------- ------------ -------------------
109     Full    18.30M     DISK        00:00:00     2024-12-18 00:00:59
        BPキー: 109   ステータス: AVAILABLE  圧縮: NO  タグ: TAG20241218T123037
        ピース名: C:\APP\ORACLE\PRODUCT\19C\DB_HOME\DATABASE\C-464258922-20241218-04
  含まれている制御ファイル: Ckp SCN: 5608534      Ckp時間: 2024-12-18 00:00:59
BS Key  Type LV Size       Device Type Elapsed Time 終了時間
------- ---- -- ---------- ----------- ------------ -------------------
115     Full    18.30M     DISK        00:00:00     2024-12-19 00:00:56
        BPキー: 115   ステータス: AVAILABLE  圧縮: NO  タグ: TAG20241219T123559
        ピース名: C:\APP\ORACLE\PRODUCT\19C\DB_HOME\DATABASE\C-464258922-20241219-05
  含まれている制御ファイル: Ckp SCN: 5609334      Ckp時間: 2024-12-19 00:00:56
BS Key  Type LV Size       Device Type Elapsed Time 終了時間
------- ---- -- ---------- ----------- ------------ -------------------
116     Full    18.30M     DISK        00:00:00     2024-12-16 00:00:58
        BPキー: 116   ステータス: AVAILABLE  圧縮: NO  タグ: TAG20241216T122556
        ピース名: C:\APP\ORACLE\PRODUCT\19C\DB_HOME\DATABASE\C-464258922-20241216-02
  含まれている制御ファイル: Ckp SCN: 5607823      Ckp時間: 2024-12-16 00:00:56
--先ほど失敗した（12-16 20:00）のUNTILE TIMEが成功する
RMAN> RECOVER TABLE TAKASHI.RECO_TEST OF PLUGGABLE DATABASE PDB
2> UNTIL TIME "TO_DATE('2024-12-16 20:00:00', 'yyyy-mm-dd hh24:mi:ss')"
3> AUXILIARY DESTINATION 'C:\TEMP'
4> REMAP TABLE 'TAKASHI'.'RECO_TEST':'RECORCV';
：
チャネルORA_AUX_DISK_1: 制御ファイルをリストア中です
チャネルORA_AUX_DISK_1: バックアップ・ピースC:\APP\ORACLE\PRODUCT\19C\DB_HOME\DATABASE\C-464258922-20241216-02から読取り中です
：
recoverを2024-12-19 21:37:25で終了しました

まとめ

今回は制御ファイルのバックアップ取得タイミングとDELETE OBSOLETEの実行タイミングによっては、表単位リカバリでリカバリできる範囲はかなり限定的になる可能性があるという点を紹介しました。

ちなみにRMANの”DUPLICATE”でも同じように制御ファイルのリストアが行われるため、”UNTILE TIME”を指定する場合は同様の注意が必要です。

バックアップの取得は非常に大事ですが、取得されているバックアップで想定しているリストア／リカバリが可能か、万が一に備えた復旧試験を実施いただけるようお願いします。

なお、今回のケースに遭遇して表単位リカバリがRMAN-06024で失敗、制御ファイルの2次バックアップがない場合でも、データベース単位の不完全リカバリは可能です。

表単位のリカバリと同じ手順を手動で行う（別環境にバックアップをリストア→データベース単位で不完全リカバリ→特定の表をData Pump Exportで抜き出す）ことでご対応ください。

明日は Hiroshi Sekiguchi さんです。毎年恒例の癖のあるSQLシリーズを楽しみにしています！

執筆者のご紹介

アシスト大野高志

大野高志
サポートサービス技術本部データベースサポート部

2007年入社。Oracle Databaseのテクニカルサポート部隊に配属。顧客のサポート業務を行う傍ら、サポートセンターに蓄積されたナレッジを使用した有償セミナー、技術ブログなどの立ち上げに従事。現在は「アシストの超サポ」を広めるエバンジェリストとして、カスタマーサポートとカスタマーサクセスのCS二刀流で活動中。　...show more

ページトップへ戻る

■本記事の内容について
　本記事に示した定義及び条件は変更される場合があります。あらかじめご了承ください。

■商標に関して
　・Oracle®、Java、MySQL及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
　・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
　　文中の社名、商品名等は各社の商標または登録商標である場合があります。

Autonomous Database 23ai 新機能！Select AIでSQLやデータを自動生成！

Oracle Database 23aiでは生成AIに関連する新機能が多く追加。特にAutonomous Database 23aiの「Select AI」機能は大規模言語モデル（LLM）を使用して、自然言語による問い合わせやテストデータの自動生成が可能に。本記事では、Select AIの機能について検証結果を交えて紹介します。

Oracle Cloud
Oracle Database

2024.12.17

Oracle Cloud VMware SolutionでVMware HCXを利用するための準備

前回の記事では、HCXの概要をお伝えしました。今回はOCVSでHCXを利用するための検討ポイントや前提事項を説明します！

AWS
Oracle Cloud
Oracle Database
Exadata

2024.12.13

全オラクルユーザー待望のあのサービス！Oracle Database@AWS解析白書①

今年9月にラスベガスで開催された「Oracle CloudWorld 2024」。その中で発表されたニュースの中でも一番の注目を集めたのが「Oracle Database@AWS」。今後大注目の『Oracle Database@AWS』に関して、これまでのオラクル社のマルチクラウド対応の歴史なども踏まえてご紹介します。