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 2RECLAIMABLE_MB = 0 は回収可能な空きがない状態を示しています。2 本のアーカイブログが FRA に滞留しており、いずれもバックアップ未取得のため自動削除できない状態です。
SPACE_LIMITとSPACE_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:01seq 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 の値がずれたまま残ります。この場合は CROSSCHECK → DELETE 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-19809 | ORA-00257 も alert log に記録される |
| 使用量確認 | V$RECOVERY_FILE_DEST | df -h でアーカイブ先ディスクを確認 |
| ログ削除 | RMAN 経由(rm は NG) | RMAN 管理外なら rm で直接削除可 |
RMAN でアーカイブログを管理している環境では、通常ファイルシステムの場合も
RMAN CROSSCHECK→DELETE 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)の拡張も検討する





