RMANがASMからデータファイルを復元する理由と、ASMにバックアップを復元する方法
これが1つの出力です。テーブルスペースtriscaltbが/u01/app/Oracle/product/12.1.0/dbhome_1/dbs/MISSING00013
に復元されました
RMAN> report schema;
Report of database schema for database with db_unique_name TRISCALDB
List of Permanent Datafiles
===========================
File Size(MB) Tablespace RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1 780 SYSTEM YES +DATA/TRISCALDB/DATAFILE/system.258.1016190249
3 600 SYSAUX NO +DATA/TRISCALDB/DATAFILE/sysaux.257.1016190057
4 135 UNDOTBS1 YES +DATA/TRISCALDB/DATAFILE/undotbs1.260.1016190491
5 250 PDB$SEED:SYSTEM NO +DATA/TRISCALDB/FD9AC20F64D244D7E043B6A9E80A2F2F/DATAFILE/system.267.1016191021
6 5 USERS NO +DATA/TRISCALDB/DATAFILE/users.259.1016190489
7 510 PDB$SEED:SYSAUX NO +DATA/TRISCALDB/FD9AC20F64D244D7E043B6A9E80A2F2F/DATAFILE/sysaux.266.1016191021
8 260 TRISCALPDB:SYSTEM NO +DATA/TRISCALDB/FD9BD2B44413096FE043B6A9E80ABC28/DATAFILE/system.272.1016192445
9 520 TRISCALPDB:SYSAUX NO +DATA/TRISCALDB/FD9BD2B44413096FE043B6A9E80ABC28/DATAFILE/sysaux.271.1016192441
10 5 TRISCALPDB:USERS NO +DATA/TRISCALDB/FD9BD2B44413096FE043B6A9E80ABC28/DATAFILE/users.273.1016192445
11 1243 TRISCALPDB:EXAMPLE NO +DATA/TRISCALDB/FD9BD2B44413096FE043B6A9E80ABC28/DATAFILE/example.270.1016192435
13 0 TRISCALTB NO /u01/app/Oracle/product/12.1.0/dbhome_1/dbs/MISSING00013
List of Temporary Files
=======================
File Size(MB) Tablespace Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1 60 TEMP 32767 +DATA/TRISCALDB/TEMPFILE/temp.265.1016190837
2 20 PDB$SEED:TEMP 32767 +DATA/TRISCALDB/FD9AC20F64D244D7E043B6A9E80A2F2F/DATAFILE/pdbseed_temp012019-08-13_11-21-09-am.dbf
3 20 TRISCALPDB:TEMP 32767 +DATA/TRISCALDB/FD9BD2B44413096FE043B6A9E80ABC28/DATAFILE/triscalpdb_temp012019-08-13_11-47-56-am.dbf
以下を想像してみてください。
2019-08-19 18:00:00に、5分かかった完全なオンラインデータベースバックアップを開始しました。このバックアップには、上記のすべてのデータファイルが含まれていました。
この操作から作成されたバックアップピース:
その後、2019-08-19 18:10:00に誰かがTRISCTALTBテーブルスペースを削除しました。 2019-08-19 18:15:00スケジュールされたアーカイブログのバックアップが開始され、1分かかり、次のバックアップピースが作成されました:
2019-08-19 18:20:00に、TRICCALTBテーブルスペースが欠落していることに気付きました。アラートログを確認すると、2019-08-19 18:10:00にテーブルスペースが削除されていることがわかります。不完全なデータベースリカバリを実行し、テーブルスペースが削除される直前の時点を2019-08-19 18:09:59に指定することにしました。
次に、インスタンスを停止し、すべてのファイルを削除し、バックアップを確認し、インスタンスをnomountモードで起動し、最新の制御ファイルバックアップc2.bkpから制御ファイルを復元します。問題は、TRISCALTBが削除された後に制御ファイルのバックアップが取られたため、データファイルのリストにデータファイル13がないことです。
2019-08-19 18:09:59まで復元とリカバリを実行します。これにより、db1.bkpからデータファイル13を除くすべてのデータファイルが復元され、Arch2.bkpおよびArch3.bkpからのアーカイブログが復元および適用されます。リカバリが完了したら、alter database open resetlogs;
を使用してデータベースを開きます。
これが、名前にMISSING
が含まれるデータファイルエントリが作成されるポイントです。データファイル13は、復元された制御ファイルに存在しません。データファイル13は、復元されて復元された時点で、SYSTEMテーブルスペースのディクショナリに存在します。データベースを開くと、制御ファイルと辞書の間の不一致が認識され、デフォルトでMISSING
の名前とデータファイル番号(00013
)を使用して制御ファイルにオフラインデータファイルエントリが作成されます場所($Oracle_HOME/dbs
)。いいえ、RMANはデータファイル13をまったく復元しませんでした。ファイルシステムにはありません。データファイル13は、この時点では単なる制御ファイルのエントリです。
復元とリカバリ中にエラーが発生していなくても、まだ完了していません。これらのMISSING
データファイルが表示された場合は、それらを復元および回復する必要があります。
この時点で、RMANで以下を実行できます。
データファイルを復元します。
run
{
set newname for datafile 13 to '+DATA';
restore datafile 13;
}
復元されたコピーに切り替えます。
switch datafile 13 to copy;
復元されたデータファイルを回復します。
recover datafile 13;
最後にそれをオンラインにします:
alter database datafile 13 online;
制御ファイルはデータファイルが存在する必要があることを認識しているように見えますが、データファイルはバックアップの一部ではない可能性があります。最新のバックアップのログはありますか?このデータファイルがバックアップの一部であることを示していますか? RMANバックアップスクリプトはどのように見えますか? RMANバックアップスクリプトからテーブルスペースを除外していますか?