※当サイトの記事には、広告・プロモーションが含まれます。

ORA-00257 アーカイブ・エラーです。って言われてもね...

f:id:ts0818:20200808123243j:plain

アーカイブ (archive) とは、重要記録を保存・活用し、未来に伝達することをいう。日本では一般的に書庫保存記録と訳されることが多いが、元来は公記録保管所、または公文書の保存所、履歴などを意味し、記録を保存しておく場所である(公文書館も参照のこと)。

アーカイブ - Wikipedia

⇧ 保存場所だったんですね。

 

いや~、Oracle Database のエラーが頻繁に出ること出ること。

f:id:ts0818:20200808105423p:plain

 

リクエストされた操作の実行中にエラーが発生しました:

ORA-00257: アーカイブ・エラーです。解除されるまでAS SYSDBAにのみ接続してください。
00257. 00000 -  "Archiver error. Connect AS SYSDBA only until resolved."
*Cause:    The archiver process received an error while trying to archive
           a redo log.  If the problem is not resolved soon, the database
           will stop executing transactions. The most likely cause of this
           message is that the destination device is out of space to store the
           redo log file. Another possible cause is that a destination marked
           as MANDATORY has failed.
*Action:   Check the alert log and trace files for detailed error
           information.
ベンダー・コード257
    

ってな感じで、「redo logを保存するためのデバイスの空き容量が不足してるんじゃないの?」ってことらしい。

『「alert log」か「trace files」を確認してくれ 』ってことらしいんだけど、ファイルの場所は教えてくれない、安定の不親切さ、流石はOracleさん。

 

調べてみた

まずは、「alert log」はどこかを確認ですと。

qiita.com

アラート・ログを含むすべての診断データがADRに格納されている。
各種ログの配置先やADRのベースディレクトリを確認したい場合は、v$diag_info を確認する。
※製品やインスタンスIDで内容は異なる。

Oracle 12cR1 環境でのログ出力先の確認 - Qiita

⇧ ということらしいですと。

とりあえず、エラーが解消されるまでは「AS SYSDBA」でしか接続できないらしいので、

f:id:ts0818:20200808111754p:plain

で、確認。

f:id:ts0818:20200808112022p:plain

ちなみに、

インスタンスごとに存在するアラートログファイルを共有して使用しているため、
cdbのアラートログにpdbに関する情報が出力されている。

Oracle 12cR1 環境でのログ出力先の確認 - Qiita

⇧ ということみたいなので、CDBのアラートログを確認すれば良さ気っぽい。

f:id:ts0818:20200808112614p:plain

で、「アラートログ」を確認したところ、

2020-08-07T23:04:27.552450+09:00
************************************************************************
You have following choices to free up space from recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
   then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
   BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
   reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
   system command was used to delete files, then use RMAN CROSSCHECK and
   DELETE EXPIRED commands.
************************************************************************
2020-08-07T23:04:27.575404+09:00
Errors in file C:\APP02\APP\TS0818\diag\rdbms\orcldb\orcldb\trace\orcldb_tt00_10420.trc:
ORA-19809: リカバリ・ファイルの制限を超えています
ORA-19804: 209715200バイトのディスク領域を13350469632バイト制限から再利用できません

...省略

>>> WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! pid=28
System State dumped to trace file C:\APP02\APP\TS0818\diag\rdbms\orcldb\orcldb\trace\orcldb_mmon_1312.trc
2020-08-07T23:21:51.294529+09:00
ORA-12751: CPU時間または実行時のポリシー違反
2020-08-07T23:21:57.406248+09:00
Suspending MMON action 'AWR Auto Flush Task' for 104400 seconds
2020-08-07T23:22:27.735088+09:00
Errors in file C:\APP02\APP\TS0818\diag\rdbms\orcldb\orcldb\trace\orcldb_tt00_10420.trc:
ORA-19815: 警告: db_recovery_file_dest_size(13350469632バイト)は99.86%バイトが使用され、残り18825216バイトが使用可能です。


って 感じですと。

どうやら、アーカイブログを削除すれば良いんだと。

www.ashisuto.co.jp

アーカイブログは一般的に世代管理/N日分を保存といったポリシーを設定し、バックアップ取得時に削除する運用をされているケースが多く見られます。

アーカイブログの削除方法まとめ(ORA-00257対処方法) | アシスト

しかし、「繁忙期で更新処理が大量に行われ想定以上のアーカイブログが出力された」、「バックアップジョブが何かしらの理由により動作していなかった」といった理由でアーカイブログの出力先空き容量が枯渇すると「ORA-00257:アーカイブ・エラーです。解除されるまでAS SYSDBAにのみ接続してください。」などのエラーが発生し一般ユーザでの新規接続ができない/既存の更新処理がハングするといった状態になります。

アーカイブログの削除方法まとめ(ORA-00257対処方法) | アシスト

⇧ ということみたい。

なので、対策としては、

  • ディスクの容量自体を増やす
  • アーカイブログなどを削除して空き容量を増やす

のどちらかになるってことみたいね。

で、削除する場合は「RMAN」って言うツールを使えば良いらしいですと。

ふと思い出したのが、

ts0818.hatenablog.com

⇧ 過去の記事で、「ORA-03113: 通信チャネルでend-of-fileが検出されました」ってエラーが発生して、『フラッシュ・リカバリ領域』の空き容量無いよ問題がありまして、そこでも「RMAN」使えってことだったかと。

Oracle Database にほとんどデータ入れてないのに、空き容量がすぐ枯渇するのが気になって仕方ないんだが...

 

RMANで削除

というわけで、「RMAN」でデータベースに接続。普通に、「rman target sys/[sysユーザのパスワード]」でも接続できます。 

"[ORACLE_HOME]\bin\rman.exe" target sys/[sysユーザのパスワード]   

f:id:ts0818:20200808115823j:plain

RMANでアーカイブログ全削除

DELETE ARCHIVELOG ALL;    

f:id:ts0818:20200808120114p:plain

f:id:ts0818:20200808120238p:plain


削除されました。

f:id:ts0818:20200808120415p:plain

RMANは、普通に、exit で終了できるっぽい。

f:id:ts0818:20200808225235p:plain

よく分からんけど、

f:id:ts0818:20200808121934p:plain

フォルダは残るみたいね...

f:id:ts0818:20200808122238p:plain

 

リカバリカタログを使用していない場合、アーカイブログの情報は制御ファイルで保持されます。制御ファイルでのアーカイブログ情報の保証期間は control_file_record_keep_time で設定されておりデフォルトでは7日です。そのため、8日以上前のアーカイブログの情報は上書きされる可能性があります。※時間経過後即上書きされるわけではありません。

アーカイブログの削除方法まとめ(ORA-00257対処方法) | アシスト

制御ファイル上で上書きされたアーカイブログは"RMAN> list archivelog all;"に出力されず、"RMAN> delete archivelog all;"でも削除されません。ディスク上にこのようなアーカイブログが存在する場合、ファイルシステムの場合はOSコマンドで削除して問題ありません。

アーカイブログの削除方法まとめ(ORA-00257対処方法) | アシスト

⇧ 「RMAN」でも削除できないものがあるらしい...「RMAN」以外で削除するなって言ったり、「RMAN」以外で削除しろって言ったり、Oracleさん統一が取れてないすね。


ちなみに、「RMAN」で「アーカイブログ」を全削除したところ、無事接続できるようになりました。

f:id:ts0818:20200808121115p:plain


相変わらず、Oracleさんはモヤモヤすることが多いですかね...

今回はこのへんで。