ORA-00257 発生:FRA フルとアーカイブ停止の仕組みと解消手順

Oracle DB に接続しようとしたら「ORA-00257: archiver error. Connect internal only, until freed.」で一般ユーザーが接続できず、SYSDBA のみ接続できる状態になっていませんか?

原因は FRA(高速リカバリ領域)のアーカイブログがあふれていることです。
この記事では、ORA-00257 が発生する仕組みと、RMAN を使った解消手順を実機ログつきで解説します。


1. 症状

一般ユーザーが Oracle DB に接続しようとすると、以下のエラーが返ってきます。

$ sqlplus system/oracle
ERROR:
ORA-00257: アーカイブ・エラーです。解除されるまでAS SYSDBAにのみ接続してください。

SYSDBA では接続できます。

$ sqlplus / as sysdba
SQL>

alert log を確認すると、ORA-00257 は記録されておらず、代わりに以下のエラーが記録されています。

$ tail -f $ORACLE_BASE/diag/rdbms/*/*/trace/alert_*.log
警告: db_recovery_file_dest_size(209715200バイト)は100.00%バイトが使用され、残り0バイトが使用可能です。
ORA-19809: リカバリ・ファイルの制限を超えています
ORA-19804: 151256064バイトのディスク領域を209715200バイト制限から再利用できません
ARC0 (PID:1944135): Stuck archiver condition declared
ORA-16038: ログ2、順序番号44をアーカイブできません

ORA-00257 はクライアント側に返るエラーです。
alert log には ORA-19815(FRA の残量警告)・ORA-19809(アーカイブ失敗)が記録されます。


2. ORA-00257 が発生する仕組み

なぜ、このようなエラーが発生するのでしょうか。
原因を理解するには、Oracle のアーカイブログと FRA の仕組みを知る必要があります。

用語種別意味
LGWRプロセスredo ログへの書き込みを担当するバックグラウンドプロセス
ARCnプロセスonline redo log をアーカイブログとしてコピーするプロセス
FRA領域アーカイブログやバックアップを保存する高速リカバリ領域

Oracle はトランザクションをまず online redo log に書き込み、ログがフルになると ARCn がアーカイブログとして FRA にコピーします(ログスイッチ)。

FRA の残り容量が次のアーカイブログ 1 本を収められない大きさを下回ると、ARCn がアーカイブに失敗します。すると LGWR がログスイッチ先を失い、DB への書き込みが停止します。この状態になると一般ユーザーの接続が遮断され、ORA-00257 が返されます。

FRA 使用率が 100% でなくても発生します。「次の 1 本が収まらない」時点でアーカイブが失敗するため、今回の検証では使用率 66.8%(134MB / 200MB)で発生しました。残り 66MB に対して次のアーカイブ対象ログが約 144MB あったためです。


3. 調査手順(実機ログ)

それでは実際に実機で調査の流れを確認していきましょう。

Step 1:alert log でエラーを確認する

まず alert log を確認し、ORA-19815 が記録されているタイミングを特定します。

$ tail -f $ORACLE_BASE/diag/rdbms/*/*/trace/alert_*.log
警告: db_recovery_file_dest_size(209715200バイト)は100.00%バイトが使用され、残り0バイトが使用可能です。
************************************************************************
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.
************************************************************************
ORA-19809: リカバリ・ファイルの制限を超えています
ORA-19804: 151256064バイトのディスク領域を209715200バイト制限から再利用できません
ARC0 (PID:1944135): Error 19809 Creating archive log file to '...o1_mf_1_44_%u_.arc'
ARC0 (PID:1944135): Stuck archiver condition declared
ORA-16038: ログ2、順序番号44をアーカイブできません。

ORA-19804 の「151256064バイト」が「次のアーカイブ対象ログのサイズ」です。このサイズが FRA の残り容量(66MB)を超えたためアーカイブに失敗しています。

Step 2:V$RECOVERY_FILE_DEST で FRA 使用量を確認する

SYSDBA で接続し、V$RECOVERY_FILE_DEST で FRA の使用量を確認します。

SQL> SELECT NAME,
  2         SPACE_LIMIT/1024/1024     AS limit_MB,
  3         SPACE_USED/1024/1024      AS used_MB,
  4         SPACE_RECLAIMABLE/1024/1024 AS reclaimable_MB,
  5         NUMBER_OF_FILES
  6  FROM V$RECOVERY_FILE_DEST;

NAME                                    LIMIT_MB    USED_MB RECLAIMABLE_MB NUMBER_OF_FILES
--------------------------------------- ---------- ---------- -------------- ---------------
/u01/app/oracle/fast_recovery_area           200    133.62              0               2

RECLAIMABLE_MB = 0 は回収可能な空きがない状態を示しています。2 本のアーカイブログが FRA に滞留しており、いずれもバックアップ未取得のため自動削除できない状態です。

SPACE_LIMITSPACE_USED の単位はバイトです。/1024/1024 で MB に変換しています。FRA が大きい本番環境では /1024/1024/1024 で GB 変換する方が見やすい場合があります。


4. 解消手順

RMAN でアーカイブログを削除する

FRA 管理下のアーカイブログは rm で直接削除してはいけません。RMAN カタログとの整合性が崩れ、Oracle が FRA を正しく管理できなくなります。必ず RMAN 経由で削除します。

削除前に対象のアーカイブログ一覧を確認します。

$ rman target /

RMAN> LIST ARCHIVELOG ALL;

アーカイブ・ログのリスト
Key     Thrd Seq     S Low時間
------- ---- ------- - -------------------
13      1    42      A 2026-05-31 09:08:55
14      1    43      A 2026-05-31 09:34:59

直近 5 分以内のアーカイブログを残して削除します。

RMAN> DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-5/1440';

2オブジェクトを削除しました

SYSDATE-1 で「1 日以上前」、SYSDATE-30/1440 で「30 分以上前」を意味します(1 日 = 1440 分)。
今回は検証直後のログのため SYSDATE-5/1440 を使用しましたが、本番環境ではバックアップ保持ポリシーに合わせて閾値を決めてください。
緊急時は DELETE ARCHIVELOG ALL で全削除も可能です。

削除後、archiver が詰まっていたログを自動的に再アーカイブします。

RMAN> LIST ARCHIVELOG ALL;

アーカイブ・ログのリスト
Key     Thrd Seq     S Low時間
------- ---- ------- - -------------------
16      1    44      A 2026-05-31 09:36:01
15      1    45      A 2026-05-31 09:39:01

seq 44、45 が A(アーカイブ済み)になり、archiver が回復したことを確認できました。

空き容量の回復と接続確認

FRA 使用量と一般ユーザーの接続を確認します。

SQL> SELECT SPACE_USED/1024/1024 AS used_MB,
  2         SPACE_LIMIT/1024/1024 AS limit_MB,
  3         ROUND(SPACE_USED/SPACE_LIMIT*100, 1) AS pct
  4  FROM V$RECOVERY_FILE_DEST;

   USED_MB   LIMIT_MB        PCT
---------- ---------- ----------
144.414551        200       72.2

SQL> conn system/oracle
接続されました。

削除後も FRA 使用率が 72.2% と高めですが、これは seq 44、45 が残っているためです。
archiver が回復しているため一般ユーザーは接続できます。
恒久対応として ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE で FRA 上限を拡張することを検討してください。


5. よくある Q&A

Q: FRA 使用率が 66% でも ORA-00257 が発生するのはなぜか?

次にアーカイブしようとする online redo log 1 本のサイズが、FRA の残り容量を超えると発生します。使用率が低くても残り容量が小さければ発生します。今回は残り 66MB に対して次のログが約 144MB でした。

Q: rm で直接削除してしまったらどうなるか?

Oracle は FRA 内のファイルを RMAN カタログで管理しています。rm で削除するとカタログとの整合性が崩れ、V$RECOVERY_AREA_USAGE の値がずれたまま残ります。この場合は CROSSCHECKDELETE EXPIRED でカタログを修正します。

RMAN> CROSSCHECK ARCHIVELOG ALL;
RMAN> DELETE EXPIRED ARCHIVELOG ALL;

V$RECOVERY_AREA_USAGE はコントロールファイルが認識しているファイルをもとに集計しています。
rm で削除するとファイルシステム上のファイルは消えても、コントロールファイルには「存在する」という記録が残ったままになります。
CROSSCHECK でファイルシステムと照合して存在しないファイルを EXPIRED 状態に更新し、DELETE EXPIRED でそのレコードを削除することで、カタログと実態が一致します。

Q: FRA を使っていない環境でアーカイブ先ディスクがフルになった場合も同じ動作か?

はい、ARCn がアーカイブに失敗 → LGWR がスイッチ先を失う → ORA-00257 という流れは同じです。ただし、調査と解消の手順が異なります。

FRA(この記事)通常ファイルシステム(LOG_ARCHIVE_DEST_n
alert log の記録ORA-19815 / ORA-19809ORA-00257 も alert log に記録される
使用量確認V$RECOVERY_FILE_DESTdf -h でアーカイブ先ディスクを確認
ログ削除RMAN 経由(rm は NG)RMAN 管理外なら rm で直接削除可

RMAN でアーカイブログを管理している環境では、通常ファイルシステムの場合も RMAN CROSSCHECKDELETE EXPIRED でカタログと実態を一致させてから削除することを推奨します。

Q: ORA-00257 は alert log に記録されないのか?

アーカイブ先が FRA(db_recovery_file_dest)の場合は、alert log には ORA-19815 / ORA-19809 が記録され、ORA-00257 はクライアント側にのみ返ります。アーカイブ先が通常のファイルシステム(LOG_ARCHIVE_DEST_n)の場合は alert log にも ORA-00257 が記録されます。


6. まとめ

ORA-00257 の原因と確認先

  • alert log → ORA-19815(FRA 残量警告)・ORA-19809(アーカイブ失敗)を確認
  • V$RECOVERY_FILE_DEST → FRA の使用量・回収可能容量を確認

対応フロー

ORA-00257 発生
    ↓
alert log で ORA-19815 / ORA-19809 を確認
    ↓
V$RECOVERY_FILE_DEST で FRA 使用量・RECLAIMABLE を確認
    ↓
RMAN> DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-N';
    ↓
LIST ARCHIVELOG ALL で archiver 回復を確認 → 一般ユーザー接続を確認

注意点

  • FRA 管理下のファイルは rm ではなく RMAN で削除する
  • 削除範囲はバックアップ保持ポリシーに合わせて決める
  • 恒久対応として FRA 上限(DB_RECOVERY_FILE_DEST_SIZE)の拡張も検討する