RMAN バックアップが ORA-19809 で失敗する…FRA 満杯の原因切り分けと復旧手順

公開日 2026/6/21 最終更新日 2026/6/21

「毎晩 2:00 に動いていた RMAN バックアップが、昨夜から失敗するようになった」という連絡が来た。
バックアップ設定は先週から何も変えていないし、先週までは正常に完了していた。
ログを見ると、次の2つのエラーが出ている。

ORA-19809: リカバリ・ファイルの制限を超えています
ORA-19804: 524062720バイトのディスク領域を838860800バイト制限から再利用できません

このエラーは FRA（高速リカバリ領域）の満杯を示すサインです。
今回は「FRA 満杯で RMAN が失敗する」症状の調査・復旧を実機ログとともに解説します。
さらに、現場で見落としやすい 「DELETE OBSOLETE したのに FRA が減らない」＝保証付きリストアポイント（GRP）の罠 まで踏み込みます。

1. 症状

毎晩のオンラインバックアップ（BACKUP DATABASE PLUS ARCHIVELOG）が、次のエラーで失敗します。

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
backupを開始しています
現在のログがアーカイブされました。
チャネルORA_DISK_1: アーカイブ・ログ・バックアップ・セットを開始しています
チャネルORA_DISK_1: ピース1を起動します
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: backup plus archivelogコマンドが失敗しました
ORA-19809: リカバリ・ファイルの制限を超えています
ORA-19804: 524062720バイトのディスク領域を838860800バイト制限から再利用できません

エラーは2行セットで読みます。

エラー	意味
ORA-19809	リカバリ・ファイル（FRA 内のファイル）の上限を超えた
ORA-19804	再利用できる領域を使い切ってもなお N バイト足りない

ORA-19804 の「838860800バイト制限」は FRA の上限（今回は 800MB）、「524062720バイト」は新たに必要だが確保できない量（約 500MB）です。
この2行が並んだら FRA 満杯、とまず判断できます。

なお、DB 自体はまだ動いています。

FRA が満杯でもアーカイバが完全に詰まる前なら通常業務は継続でき、まずバックアップだけが失敗します。
これが「満杯の予兆」段階です。
これを放置するとアーカイバが書けなくなり、最終的に DB が新規トランザクション不可（ハング）に至る恐れがあります。

2. 原因の仕組み

FRA（高速リカバリ領域）とは

FRA は、Oracle がバックアップ関連ファイルを1か所にまとめて自動管理する領域です。
ここには複数の種類のファイルが同居します。

FRA に入るもの	例
アーカイブログ	ARCHIVELOG モードで生成される REDO の保管分
RMAN バックアップピース	バックアップの実体
制御ファイル自動バックアップ	controlfile autobackup
フラッシュバックログ	Flashback Database / 保証付きリストアポイント用

FRA を使うメリットは「容量さえ決めれば、あとは Oracle が自動でやりくりしてくれる」ことです。
DB_RECOVERY_FILE_DEST_SIZE で上限を決めておくと、Oracle は保持ポリシーに従って不要になった古いファイルを自動で再利用し、上限内に収めようとします。
ファイルを個別にパス管理する手間がなく、リカバリ領域がディスクを食い尽くすのも防げます。
（この上限は物理ディスクの空きとは別で、「この DB が FRA に使ってよい量」を宣言する論理的な値です）

裏を返すと、この「自動やりくり」が回らなくなったとき（上限が小さすぎる、または削除できないファイルが溜まったとき）に上限到達＝ORA-19809 が起きます。
今回はまさにこれです。

空きを作る「再利用可能領域」

FRA が満杯になっても、Oracle は不要なファイル（バックアップ済みで保持ポリシー的に消してよいもの）を自動で再利用して空きを作ろうとします。
この再利用できる量が、ビューの SPACE_RECLAIMABLE（再利用可能領域）です。

ORA-19804（実機メッセージも「…制限から再利用できません」）は、この自動再利用を試みてもなお不足している状態を指します。
つまり「消せるものを消しても空かない」。

ここが調査の起点になります。

アーカイブログの削除をブロックするもの

アーカイブログを削除できるのは、それを必要とする処理・機能が1つも残っていないときだけです。
逆に、何か1つでも必要としている間は削除できません。
ブロックする要因は、大きく「状態」と「機能」の2つに分けられます。

種類	ブロックするもの	理由
状態	まだアーカイブログがバックアップされていない	消すと唯一のコピーが消える＝復旧不能になる
機能	保証付きリストアポイント（GRP）	その時点に Flashback で戻すのに必要
機能	Data Guard スタンバイ	スタンバイがまだ適用していない
機能	GoldenGate Extract	Extract がまだ読み取っていない

「DELETE したのに FRA が減らない」ときは、これらのどれかが保護していると疑います。
本記事では「未バックアップ」（第3章）と「GRP」（第5章）を実機で見ます。

3. 調査手順

Step 1: FRA の使用状況を確認する（V$RECOVERY_FILE_DEST / V$RECOVERY_AREA_USAGE）

まず FRA の使用状況を種別ごとに確認します。

SQL> SELECT name,
            space_limit/1024/1024       AS limit_mb,
            space_used/1024/1024        AS used_mb,
            space_reclaimable/1024/1024 AS reclaimable_mb,
            number_of_files
       FROM v$recovery_file_dest;

NAME                                LIMIT_MB    USED_MB RECLAIMABLE_MB NUMBER_OF_FILES
----------------------------------- -------- ---------- -------------- ---------------
/u01/app/oracle/fast_recovery_area       800 499.775879              0               4

used（499.8MB）が limit（800MB）に張り付き、reclaimable が 0＝再利用できる領域がない（＝消せるものがない）、と読めます。
さらに種別の内訳を見ます。

SQL> SELECT file_type, percent_space_used, percent_space_reclaimable, number_of_files
       FROM v$recovery_area_usage ORDER BY file_type;

FILE_TYPE               PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
----------------------- ------------------ ------------------------- ---------------
ARCHIVED LOG                         62.47                         0               4
（他種別はすべて 0）

犯人は ARCHIVED LOG（62.47%）、しかも reclaimable 0 で消せない状態だと分かります。

Step 2: アラートログを確認する

FRA 満杯のときは、アラートログに対処法が出力されます。

$ adrci
adrci> show homes
adrci> set home diag/rdbms/<sid>/<sid>
adrci> show alert -tail 30

CDB/PDB 構成では ADR home が複数あるため、set home で対象 DB の home を指定しないと DIA-48449: Tail alert can only apply to single ADR home になります。

ORA-19815: 警告: db_recovery_file_dest_size(838860800バイト)は100.00%バイトが使用され、残り0バイトが使用可能です。
************************************************************************
You have following choices to free up space from recovery area:
1. Consider changing RMAN RETENTION 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 ...
4. Delete unnecessary files using RMAN DELETE command ...
************************************************************************
Reclaimable space = 0
Available space = 0

アラートログには「空きを作る4つの方法」が出力されます。

選択肢	内容	いつ効くか
① 保持ポリシー見直し	RETENTION POLICY（DG なら ARCHIVELOG DELETION POLICY）	古い世代が溜まっている
② テープ等へ退避	`BACKUP RECOVERY AREA`	ディスクを増やせない
③ ディスク追加＋上限拡張	`db_recovery_file_dest_size` を拡張	物理ディスクに余裕がある
④ RMAN DELETE	不要ファイル削除	消せるファイルがある場合のみ

今回は reclaimable 0 なので、④（削除）は効きません。
このことを次の Step で実証します。

Step 3: 削除を試す（今回は1ファイルも消えない）

正しい順序（CROSSCHECK → DELETE）で削除を試みます。

RMAN> CROSSCHECK ARCHIVELOG ALL;
4オブジェクトをクロスチェックしました

RMAN> DELETE NOPROMPT EXPIRED ARCHIVELOG ALL;
指定がリポジトリ内のどのアーカイブ・ログとも一致しません

RMAN> DELETE NOPROMPT OBSOLETE;
古いバックアップはありません。

RMAN> DELETE NOPROMPT ARCHIVELOG ALL BACKED UP 1 TIMES TO DISK;
RMAN-08138: 警告: アーカイブ・ログは削除されていません - 追加のバックアップを作成する必要があります

4つのコマンドすべてで、1ファイルも消えませんでした。
理由は RMAN-08138 が示すとおり、アーカイブログが一度もバックアップされていない＝消すと復旧不能になる唯一のコピーだからです。
Oracle が安全のために削除を拒否しています。

ここで分かるのは、このケースでは削除では空けられないということです。
打てる手は、FRA の上限を拡張するか、先にバックアップを取って退避するか、のどちらかになります。

4. 復旧手順（基本：上限拡張）

物理ディスクに空きがあることを確認し、FRA の上限を拡張します。

SQL> !du -sh /u01/app/oracle/fast_recovery_area
528M    /u01/app/oracle/fast_recovery_area

SQL> ALTER SYSTEM SET db_recovery_file_dest_size=5G SCOPE=MEMORY;
システムが変更されました。

SQL> SHOW PARAMETER db_recovery_file_dest_size
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest_size           big integer 5G

SCOPE=MEMORY は稼働中のインスタンスにのみ反映する一時変更です。恒久化するときは SCOPE=BOTH、本番では物理ディスクの空きを df -h で必ず確認してから拡張します。

上限を広げて、第1章で失敗したバックアップ（BACKUP DATABASE PLUS ARCHIVELOG）をもう一度実行すると、今度はエラーなく完了します。

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
（アーカイブログ → データファイル[CDB$ROOT/PDB/pdbseed] → 末尾アーカイブ → 制御ファイル自動バックアップ）
backupを終了しました

FRA の空き領域を作ったことで、日次バックアップの処理は実行できるようになりました。
ただし上限拡張は「空きを足しただけ」の暫定対処です。
第2章「アーカイブログの削除をブロックするもの」で挙げた要因を解消しないことには、根本的な解決にはなりません。
次章では、そのブロック要因のうち、現場で見落としやすい保証付きリストアポイント（GRP）を取り上げます。

5. 見落としパターン：「DELETE OBSOLETE したのに減らない」＝ GRP の罠

保証付きリストアポイント（GRP）は、日常的に使う機能ではありません。
パッチ適用やアップグレードの前に「失敗したらここに戻す」ための保険として作る、一時的なものです。
問題になるのは、作業が終わったあとに削除し忘れたときです。
GRP が残っていると、それが必要とするアーカイブログを削除できず、数日後に FRA が満杯になってバックアップが失敗することがあります。
やっかいなのは、GRP を作ってから症状が出るまでに数日のタイムラグがあることです。
「最近とくに変わった作業はしていないのに FRA の使用サイズだけ増加していく」ように見えるため、原因が GRP だと気づきにくいのです。
この見落としを実機で再現します。

状況設定

「パッチ適用前に保証付きリストアポイント（GRP）を作り、消し忘れたまま運用が続いた」ケースを再現します。

GRP は「この時点に戻れる」ように Oracle が状態を保全する仕組みで、VMware のスナップショットに近い概念です。
イメージしやすいように、VMware のスナップショットと並べて比較します。

	VMware スナップショット	保証付きリストアポイント（GRP）
目的	パッチ前・変更前の保全	パッチ前・変更前の保全
戻す仕組み	デルタディスクを巻き戻す	アーカイブログ＋フラッシュバックログで Flashback Database
消し忘れると	デルタが肥大化	アーカイブログ・フラッシュバックログが削除不可で蓄積
消し方	スナップショット削除	`DROP RESTORE POINT <name>`

GRP を作る

GRP は CREATE RESTORE POINT <名前> GUARANTEE FLASHBACK DATABASE で作成します。
GUARANTEE FLASHBACK DATABASE を付けると「この時点に必ず戻せる」ことが保証され、その代わり戻すのに必要なアーカイブログが削除されなくなります（これが後の罠の正体です）。
ここではパッチ前を想定し、日付入りの名前で作成して v$restore_point で確認します。

SQL> CREATE RESTORE POINT before_patch_20260614 GUARANTEE FLASHBACK DATABASE;
リストア・ポイントが作成されました。

SQL> SELECT name, scn, guarantee_flashback_database, time FROM v$restore_point;

NAME                       SCN GUA TIME
-------------------------- ---------- --- ---------------------------
BEFORE_PATCH_20260614      5102641 YES 26-06-14 20:43:02

これ以降に生成されるアーカイブログのうち、この GRP の SCN（5102641）に戻すのに必要な分が保護されます。

バックアップ済みなのに削除できない

アーカイブログを生成し、BACKUP ARCHIVELOG ALL でバックアップ済みにしてから削除を試みます。
通常、バックアップ済みのアーカイブは削除できます。
ところが…

RMAN> DELETE NOPROMPT ARCHIVELOG ALL BACKED UP 1 TIMES TO DISK;
RMAN-08139: 警告: アーカイブREDOログは削除されていません。保証付きリストア・ポイント用に必要です
  順序=65   ← GRP の SCN を含む＝保護され残る
アーカイブ・ログを削除しました（順序=66）   ← GRP より後＝戻すのに不要なので削除される
アーカイブ・ログを削除しました（順序=67）
アーカイブ・ログを削除しました（順序=68）

ここが核心です。

第3章で消せなかったときの警告は RMAN-08138（バックアップ不足）でした。
今回は RMAN-08139（保証付きリストア・ポイント用に必要）。エラーコードで真因が名指しされています。
保護されたのは seq 65（GRP の SCN を含むアーカイブ）だけで、それより後の 66〜68 は「戻すのに不要」なので削除できています。

RMAN-08138 と RMAN-08139 を区別できると、「バックアップを足せばいいのか／GRP を消すべきなのか」が一目で分かります。

真因を特定して DROP する

原因の切り分けでは、v$restore_point で GRP が残っていないかを確認します。
作成時に使ったビューと同じですが、ここでは storage_size 列も加えて、その GRP が FRA をどれだけ抱えているかまで見るのがポイントです。

SQL> SELECT name, scn, guarantee_flashback_database, time,
            storage_size/1024/1024 AS storage_mb
       FROM v$restore_point
      WHERE guarantee_flashback_database = 'YES';

NAME                       SCN GUA TIME                      STORAGE_MB
-------------------------- ---------- --- ------------------------- ----------
BEFORE_PATCH_20260614      5102641 YES 26-06-14 20:43:02            200

GRP 1つで storage 200MB を確保しています（storage_size＝GRP が抱えるフラッシュバックログ等の容量）。
消し忘れたまま放置すると、この値が日々膨らんで FRA を圧迫していきます。
事故を防ぐため、GRP を使うときは、目的の作業が終わったら必ず削除しましょう。

それでは、GRP を削除していきます。

SQL> DROP RESTORE POINT before_patch_20260614;
リストア・ポイントが削除されました。

GRP 削除後、先ほど消せなかった seq 65 が削除できるようになります。

RMAN> DELETE NOPROMPT ARCHIVELOG ALL BACKED UP 1 TIMES TO DISK;
アーカイブ・ログを削除しました
  順序=65
1オブジェクトを削除しました

先ほど RMAN-08139 で守られていた seq 65 が、GRP を削除したことで消えました。
これで、FRA が減らなかった真因は GRP だったと確定できます。

6. Q&A

Q: ORA-19809 と ORA-19804 の違いは？

A: ORA-19809 は「リカバリファイルの上限を超えた」という事実、ORA-19804 は「自動で再利用を試みてもなお N バイト足りない」という補足です。
2行セットで「消せるものを消しても空かない＝FRA 満杯」と読みます。

Q: DELETE OBSOLETE したのに FRA が減りません。なぜ？

A: アーカイブログを必要としている処理が保護しているからです。
今回の記事で扱った 未バックアップ と 保証付きリストアポイント（GRP） のほかにも、Data Guard・GoldenGate などが保護要因になります。
どれが保護しているかは、RMAN の警告コードで切り分けられます。

RMAN-08138 … バックアップ不足（バックアップを取れば消せる）
RMAN-08139 … GRP が保護（不要なら DROP RESTORE POINT）
RMAN-08137 … 上記以外で必要（Data Guard 未適用・GoldenGate 未処理など）

Q: FRA 満杯（ORA-19809）が出たとき、まず何から調べればいい？

A: 次の2手です。

SELECT * FROM v$recovery_area_usage; で何の種別が FRA を食っているかを見る
減らせない／原因が分からないときは SELECT name, guarantee_flashback_database, storage_size FROM v$restore_point; で GRP を疑う

加えて、アラートログ（ORA-19815）に対処4択が出力されるので、困ったら必ず alert log を見ます。

Q: 上限（DB_RECOVERY_FILE_DEST_SIZE）を拡張すれば解決では？

A: 一時的には解決します。ただし「論理上限」と「物理ディスクの空き」は別物で、両方そろって初めて拡張が効きます。
論理上限を上げても、FRA を置いているファイルシステムに実際の空きが無ければ書けません（拡張前に df -h で物理空きを見るのはこのため）。
逆に、物理ディスクだけ増やしても、論理上限を上げなければ FRA 満杯は解消しません。
なお拡張はあくまで暫定対処です（詳しくは第4章）。

Q: GRP はバックアップ処理そのものを止める？

A: いいえ。GRP はバックアップ処理そのものを止めるわけではありません。
ただし、バックアップ済みアーカイブログの「削除」処理は、設定後すぐに止まります。
しばらくの間はバックアップは成功しますが、FRA が満杯になった時点で、初めてバックアップが失敗して止まる、というシナリオです。
GRP の影響はすぐには出ず、時間差で効いてくるのが厄介な点です。

7. まとめ

RMAN バックアップが ORA-19809 + ORA-19804 で失敗したら、FRA 満杯をまず疑う。
v$recovery_area_usage で犯人の種別を特定し、アラートログ（ORA-19815）の4択で方針を決める。
DELETE しても減らないときは、警告コード（RMAN-08138＝未バックアップ／RMAN-08139＝GRP）で真因を切り分けるのが最短ルートです。

対応フロー

RMAN バックアップが ORA-19809 + ORA-19804 で失敗
        │
        ▼
v$recovery_area_usage で何の種別が食っているか確認（reclaimable も見る）
        │
        ▼
アラートログ（ORA-19815）の対処4択を確認
        │
        ▼
DELETE を試す
  ├─ RMAN-08138（未バックアップ）→ 退避 or 上限拡張
  └─ RMAN-08139（GRP 保護）→ v$restore_point で GRP 特定
                                    │
                                    ▼
                         DROP RESTORE POINT で解放 → DELETE が効く
        │
        ▼
（共通）物理空きがあれば db_recovery_file_dest_size 拡張で即時復旧 → 真因を潰して再発防止

タグ

FRA

ORA-19809

Oracle Database

RMAN