web-dev-qa-db-ja.com

バックアップで大量のスペースが使用されるのはなぜですか？ ORA-19804

次のように失敗するバックアップジョブがありました。

_RMAN-03002: failure of backup plus archivelog command at 10/20/2016 01:16:23
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 67108864 bytes disk space from 107374182400 limit
_

そこで、他の場所で見つかったいくつかのアドバイスに従って、_db_recovery_file_dest_size_を増やし（100Gから200Gに倍増）、エラーが発生しなくなりました。

今、1か月も経たないうちに、それは再び起こっています。

_RMAN-03002: failure of backup plus archivelog command at 04/14/2017 01:16:08
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 67108864 bytes disk space from 214748364800 limit
_

データベースはそれほど大きくありません。完全なデータポンプのエクスポートは5G未満です。そして、私はそれが非常に急速に変化しているので、1か月のバックアップが実際にはそれほど多くの追加情報を含む必要があるとは信じられません。

データベースとバックアップスクリプトは、より大きなアプリケーションの一部としてインストールされました。私はこれをすべて手動で設定していませんが、変更する権限は持っています。スクリプトは次のようになります。

_run {
configure controlfile autobackup on;
configure controlfile autobackup format for device type disk to '%F';
configure retention policy to recovery window of  31 days;
allocate channel d1 type disk maxpiecesize=5G;
backup as compressed backupset incremental level 0 cumulative tag 'L0'database
plus archivelog delete all input;
restore database validate;
release channel d1;
delete noprompt obsolete;
restore database check logical validate;
backup validate database;
restore archivelog from time 'SYSDATE-14' validate;
Host 'copy E:\Oracle\product\12.1.0\dbhome_1\NETWORK\ADMIN\tnsnames.ora E:\oradata\fast_recovery_area\';
Host 'copy E:\Oracle\product\12.1.0\dbhome_1\NETWORK\ADMIN\sqlnet.ora E:\oradata\fast_recovery_area\';
Host 'copy E:\Oracle\product\12.1.0\dbhome_1\NETWORK\ADMIN\listener.ora E:\oradata\fast_recovery_area\';
Host 'copy E:\Oracle\product\12.1.0\dbhome_1\database\pwd*.ora E:\oradata\fast_recovery_area\';
}
list incarnation of database;
list backup summary;
list backup by file;
list recoverable backup of database;
report schema;
report need backup redundancy=3;
report need backup recovery window of 3 days;
_

毎週実行されます。 _level 1_と_tag L1_があることを除いて同一の日次スクリプトがありますが、週次スクリプトには_level 0_と_tag L0_があります。

このスクリプトからの完全な出力があるので、必要に応じて他の詳細を入力できます。

Fast_recovery_areaを見ると、最大のサブディレクトリはARCHIVELOGで、516Gが含まれています。ファイルは4か月前に遡ります。これは、スクリプトで言及されている3日および31日のウィンドウよりもはるかに長いものです。古いファイルが削除されていない理由がわかりません。 200Gの制限に達したことについて不満を言っているのであれば、そもそもどうして516Gに成長したのか理解できません。明らかに、私は_db_recovery_file_dest_size_に関する基本的なことを逃しました。

BACKUPSETサブディレクトリはそれほど大きくありませんが、2年前の非常に古いファイルがいくつか含まれています。それらも削除されなかった理由がわかりません。

すべてを最も混乱させるのは、バックアップスクリプトの最後のコマンドです。

_report need backup recovery window of 3 days;
_

出力は空のリストです。正しく理解できれば、3日前の状態にすべてを回復できるということです。バックアップスクリプトからこれらのエラーが2〜3日間発生しているので、これは既に驚くべきことです。これはさらに驚くべきことです。

_report need backup recovery window of 9999 days;
_

私が望んでいたことは、「9999日前から何かを回復することはできません、あなたはとんでもない人です。しかし、それは何も言わなかった。これをどう解釈すればよいかわかりません。

古いジャンクを取り除き、バックアップを適切に動作させるにはどうすればよいですか？

追加情報

_RMAN> report obsolete;
RMAN retention policy will be applied to the command
RMAN retention policy is set to recovery window of 31 days
no obsolete backups found
_

追加2

_RMAN> list expired archivelog all;
specification does not match any archived log in the repository
_

追加

この質問が投稿されてから、ディスクはいっぱいになり、rmanはまだ何も削除していませんでした。最も古いファイルを手動で削除する以外に選択肢はありませんでした。 rmanはこれに気づかなかったようです。それはまだ言います

_ORA-19804: cannot reclaim 67108864 bytes disk space from 214748364800 limit
_

fast_recovery_areaが使用している実際のスペース量は200Gの制限をはるかに下回っています（約127Gが使用されているため、残りの73Gが必要ですが、64Mが見つからないと表示されています！何が起こっているのですか？）

他の場所で_control_file_record_keep_time_を増やして_catalog recovery area_を実行するように提案されました。結果は：

_RMAN> alter system set control_file_record_keep_time = 39;
Statement processed
RMAN> catalog recovery area;
List of files in Recovery Area not managed by the database
==========================================================
_

（... fast_recovery_area/ARCHIVELOGディレクトリ内のすべてのファイルのリスト...）

_number of files not managed by recovery area is 175, totaling 55.28GB
_

これが何を意味するのかはわかりませんが、次のバックアップ試行時にORA-19804が再び表示されるのを防ぐことはできませんでした。

oracleoracle-12crmanarchive-log
2
user41720

バックアップの最後にRMANで次のコマンドを使用します。

delete noprompt archivelog until time 'SYSDATE-1' backed up 1 times to device type 'SBT-TAPE';

テープにバックアップされ、1日以上経過したすべてのファイルがディレクトリから削除され、db_recovery_file_destが解放されます。

リストアを実行すると、テープストレージによって、RMANが必要とするアーカイブログが配信されます。

1
Marco

少なくとも今のところ、エラーを解消することができました。ここでは結論をコミュニティWikiの回答として取り上げます。

Rmanをバイパスして最も古いファイルを手動で削除した後、次のことを行う必要がありました。

crosscheck archivelog all;
crosscheck backup;
delete expired archivelog all;
delete expired backupset;

これにより、rmanは再び作業を開始するのに十分な空き領域があると確信しました。そのクリーンアップ後にレベル0のバックアップが正常に完了し、翌朝にレベル1のバックアップが正常に完了しました。

このソリューションの注目すべき機能は次のとおりです。

report need backup;

それでも31日の期間を使用していると言われ、バックアップが必要なファイルはリストされません。私が理解した方法では、削除されたファイルは実際には時代遅れでした。

control_file_record_keep_timeも、推奨される式に従って39に更新されました。うまくいけば、これが問題の根本的な原因であり、自動削除がこれから機能するようになります。

1
user41720

RMANは自動的に何も削除しません。 http://docs.Oracle.com/cd/B28359_01/backup.111/b28270/rcmconfb.htm#BRADV84

古いバックアップをパージするには、最初にリカバリウィンドウで何が古いかを定義してから、RMAN内でDELETE OBSOLETEを一定の間隔で実行する必要があります。

0
Jonathan Briggs