1 問題の内容
お客様が RAC 環境を使用してデータファイルを追加する際、誤ってローカルディスクにデータファイルが追加され、エラーが見つかった後にオフラインデータファイル操作が実行され、データファイルのステータスが回復ではなく回復になります。オンライン。発見が間に合わず、アーカイブされたログは削除されました。
次の復元 SQL を実行して
データベースを復元すると、次のようなエラーが報告されます。
2. トラブルシューティング
このデータ ファイルのステータスをチェックし、通常の ONLINE ではなく、RECOVER であることを確認します。
set line222
col name for a60
SQL> SELECT a.FILE#,a.NAME,a.RECOVER,a.CHECKPOINT_CHANGE#,status FROM v$datafile_header a;
FILE# NAME REC CHECKPOINT_CHANGE# STATUS
---------- ------------------------------------------------------------ --- ------------------ -------
34 /u01/app/oracle/oradata/orcl/iemr_df04.dbf 1.2727E+13 ONLINE
35 /u01/app/oracle/oradata/orcl/system01.dbf 1.2707E+13 RECOVER
SQL> select file#,name,status from v$datafile;
FILE# NAME STATUS
---------- ------------------------------------------------------------ -------
34 /u01/app/
oracle/oradata/orcl/iemr_df04.dbf ONLINE
35 /u01/app/oracle/oradata/orcl/system01.dbf RECOVER
この問題が原因であると推測されます。
その理由は、ソース データベース上のデータ ファイルのステータスが RECOVER であるためです。
SQL> select file#,name,status from v$datafile;
FILE# NAME STATUS
---------- ------------------------------------------------------------ -------
34 /u01/app/oracle/oradata/orcl/iemr_df04.dbf ONLINE
35 /u01/app/oracle/oradata/orcl/system01.dbf RECOVER
ソース ライブラリでオフライン データファイル操作を実行します。
alter database datafile 35 offline drop;
アップグレードは成功しましたが、動作しませんでした
データ ファイルにデータがあるかどうかをクエリし、データ ファイルが空かどうかを判断します
SELECT distinct b.owner, b.segment_name
FROM dba_data_files a,
dba_extents b
WHERE a.file_id = b.file_id
AND a.tablespace_name ='SYSTEM'
AND a.file_name ='+DATA/orcl/datafile/system01.dbf';
空であることが判明した。
データファイル削除コマンド (削除しないことをお勧めします)
alter tablespace system drop datafile '+DATA/orcl/datafile/system01.dbf';
対処する必要がある場合は、bbed を使用して修復し、削除できます。
rman バックアップにスキップを追加する必要がある3 つの解決策
(バックアップ データベース スキップにアクセスできないなど)。
オフライン・データファイル操作は、rman のリストア時に実行されます。
SQL> alter database datafile 35 offline drop;
Database altered.
SQL> set line222
SQL> col name for a60
SQL> SELECT a.FILE#,a.NAME,a.RECOVER,a.CHECKPOINT_CHANGE#,status FROM v$datafile_header a;
FILE# NAME REC CHECKPOINT_CHANGE# STATUS
---------- ------------------------------------------------------------ --- ------------------ -------
34 /u01/app/oracle/oradata/orcl/iemr_df04.dbf 1.2727E+13 ONLINE
35 /u01/app/oracle/oradata/orcl/system01.dbf 1.2707E+13 RECOVER
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 4593921 generated at 07/09/2022 12:48:34 needed for thread 1
ORA-00289: suggestion : /home/oracle/1_41_1104664055.dbf
ORA-00280: change 4593921 for thread 1 is in sequence #41
Specify log: {
<RET>=suggested | filename | AUTO | CANCEL}
AUTO
ORA-00279: change 4593946 generated at 07/09/2022 12:48:50 needed for thread 1
ORA-00289: suggestion : /home/oracle/1_42_1104664055.dbf
ORA-00280: change 4593946 for thread 1 is in sequence #42
ORA-00278: log file '/home/oracle/1_41_1104664055.dbf' no longer needed for
this recovery
ORA-00308: cannot open archived log '/home/oracle/1_42_1104664055.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
結論: 35 日に削除されたアーカイブ ログはリカバリに必要なくなり、リカバリ操作は正常に完了しました。
4. まとめ
リカバリのケースによっては、奇妙な問題が発生することがよくあります。その一部は不規則なソース データ ファイルによって引き起こされ、リカバリ プロセスでエラーが発生します。より一般的なエラーは、データ ファイルのステータスがオンラインではなくリカバリであることです。ソースライブラリのステータスを注意深く確認してください。また、リカバリログもよく読む必要があり、中にはエラーレポートに見えないものもあるので注意が必要です。