夏真っ盛りのある日、下記のエラーが毎日01:30頃発生していますとの連絡を受けました。
Wed Aug 14 01:27:39 2019
datafilecopy header validation failure for file +DATA/ORCL/DATAFILE/undotbs2.650.993582787
本番移行を目前に控えた新本番環境で、構成は以下の通りです。
ORA-xxxxのようなエラー番号がつていないので、これはOracle的にはエラーではなくwarningだと思いますが、ともかくMOS(MyOracleSupport)で調べてみます。早速以下のドキュメントがヒットしました。
カスタマ推奨RMAN Delete Obsolete Wants to Delete Live Datafile After File is Copied via RMAN and Renamed via SqlPlus (ドキュメントID 460365.1)
RMANでcopyを取得し、それをsqlplusからリネームした時に発生するメッセージで、RMANのカタログ情報が更新されない為に不整合が発生するのが原因です。
もう少し詳しく言うと、RMANでcopyを取得した時にカタログ情報(rc_datafile_copy)が更新されますが、そのコピーをsqlplusからリネームしてもカタログ情報が更新されない為の不整合です。
コピー取得後にRMANのSWITCHコマンドを実行すると、新しいファイルがデータファイルとして認識され、元のファイルがコピーと認識されるようになります。
一方、sqlplusからリネームするとコピーからデータファイルへの切り替えが行われないので、同じファイルがコピーかつデータファイルとして認識されてしまうので、不整合となる、という現象です。
「RMANでcopyを取得」も、「それをsqlplusからリネーム」も実行してはいなさそうですが、一応、担当者に確認すると共に、以下の情報の取得を依頼しました。
※この環境ではRMANのカタログ・インスタンスは作成していないので、カタログ情報はターゲットDBの制御ファイル(v$datafile_copy)になります。
SQL> select name,CREATION_TIME,STATUS from v$datafile where name like '%undo%';
SQL> select name,CREATION_TIME,STATUS from v$datafile_copy;
結果は以下の通りです。
SQL> col name format a50
SQL> select name, creation_time, status from v$datafile where name like '%undo%';
（略）
NAME CREATION_TIME STATUS
-------------------------------------------------- ------------------- -------
+DATA/ORCL/DATAFILE/undotbs2.633.992144987 2018/11/14 03:50:10 ONLINE
+DATA/ORCL/DATAFILE/undotbs2.650.993582787 2018/11/28 20:55:32 ONLINE
+DATA/ORCL/DATAFILE/undotbs2.641.993417341 2018/11/28 21:16:07 ONLINE
+DATA/ORCL/DATAFILE/undotbs2.642.993417371 2018/11/28 21:16:52 ONLINE
+DATA/ORCL/DATAFILE/undotbs2.643.993417417 2018/11/28 21:17:36 ONLINE
+DATA/ORCL/DATAFILE/undotbs2.644.993417465 2018/11/28 21:19:28 ONLINE
+DATA/ORCL/DATAFILE/undotbs2.645.993417577 2018/11/28 21:20:35 ONLINE
+DATA/ORCL/DATAFILE/undotbs2.646.993417639 2018/11/28 21:21:2 8 ONLINE
+DATA/ORCL/DATAFILE/undotbs2.647.993417693 2018/11/28 21:22:15 ONLINE
+DATA/ORCL/DATAFILE/undotbs2.648.993417741 2018/11/28 21:23:31 ONLINE
+DATA/ORCL/DATAFILE/undotbs2.649.993417877 2018/11/28 21:25:53 ONLINE
44行が選択されました。
SQL> select name,CREATION_TIME,STATUS from v$datafile_copy;
NAME CREATION_TIME S
-------------------------------------------------- ------------------- -
（略）
+DATA/ORCL/DATAFILE/undotbs2.650.993582787 2018/11/28 20:55:32 X
276行が選択されました。
問題のファイルは有効なデータファイルとして実在している一方、カタログ上はコピーとして記録され、statusは期限切れ(expired)です。
毎日01:30頃というのはバックアップ処理が動いている時間で、以下のようにクロスチェックを行っています。
RMAN> crosscheck archivelog all;
2> delete noprompt expired archivelog all;
3> crosscheck backup;
4> delete noprompt expired backup;
5> crosscheck copy;
6> delete noprompt expired copy;
コピーとしては実態が存在しないのでクロスチェックの結果、expiredとなったのですが、それならばdelete noprompt expired copyでカタログ上の情報が削除される筈です。
検証環境でテストしたところ消えてくれたのですが、新本番環境ではなぜか消えないようです。
問題のファイルが作成されたのは半年以上前の事なので、今までも同様のエラー(warning?)が発生していたかどうか確認したところ、ずっと発生していたとの事。
また、「RMANでcopyを取得」も、「それをsqlplusからリネーム」も実行した認識は無いそうですが、問題のファイルが作成された時間帯で複数のデータファイルが追加されている為、その作業時になんらかのミスがあったと思われます。
カタログ情報上、コピーである筈のファイルをクロスチェックした所、実際にはデータファイルなのでヘッダ情報がコピーとは異なり、その結果、datafilecopy header validation failureとなったのでしょう。
データファイル追加時に何があったのかは不明ですが、ドキュメントID 460365.1に記載の回避策を実行します。
コピーのKeyを確認
RMAN> list copy of database;
データファイル・コピーのリスト
=======================
Key File S 終了時間 Ckp SCN Ckp時間
------- ---- - -------- ---------- --------
84 368 X 18-11-30 365946252 18-11-30
名前: +DATA/ORCL/DATAFILE/undotbs2.650.993582787
確認したKeyを指定して、カタログから削除
RMAN> change datafilecopy 84 uncatalog;
削除された事の確認
RMAN> list copy of database;
リカバリ・カタログのかわりにターゲット・データベース制御ファイルを使用しています指定がリポジトリ内のどのデータファイル・コピーとも一致しません
上記手順を新本番環境で実行してもらった所、翌日からエラーの発生は無くなったとの事です。
