あるECサイトで、午前11時ごろからアプリケーションの不具合が起きて一部の注文に間違った割引額が記録されるようになったとします。
ただし、サイト全体は動いていますし、同じ時間帯にも正常な注文が入り、在庫が減り、決済も進んでいたとしましょう。
すると、午後3時ごろ、利用者から問い合わせが入りました。
注文金額がおかしいのですが……
この時、不具合の起きた午前11時より前へ戻せば、誤った割引額が入る前の状態を作れます。その代わり、11時以降の正常な注文、在庫更新、決済処理も巻き戻ってしまいます。
そこで正常な注文を保とうと、午後3時に近い状態を残せば、正常な処理を多く維持できますが、その中には、当然誤更新された注文も残ってしまっています。
さて、この状況、どう戻すのが正解でしょうか？
Oracle AI Databaseには、FlashbackやPoint-in-Time Recovery（PITR）といった、過去の状態を確認したり、データを以前の時点へ戻したりする機能があります。
今回は「FlashbackかPITRか」という機能名から入るのではなく、何を残し、どこまで戻し、何を直すかという観点で考えてみようと思います。
Oracleの巻き戻し機能、Flashback Technology
「Flashback」と聞くと、データベース全体を過去へ戻す機能を想像するかもしれません。
実際のOracle Flashback Technologyは、過去のデータを見る機能、行やトランザクションの変更を調べる機能、表を戻す機能、データベース全体を戻す機能などを含む機能群です。多くのFlashback機能はUNDOデータを使い、Flashback Databaseは専用のFlashback Logを使います。
そのため、今回のような誤更新では、いきなりデータを戻すよりも、まず過去の状態を調べるところから始められます。
まず、11時から15時の間に何が変わったかを見る
Flashback Queryを使うと、表の現在値を変更せずに、指定した時点のデータを参照できます。
たとえば、架空のorders表について、午前11時直前の状態を確認するイメージは次のようになります。
SELECT
order_id,
discount_amount,
total_amount
FROM orders
AS OF TIMESTAMP
TO_TIMESTAMP('2026-07-28 10:59:00', 'YYYY-MM-DD HH24:MI:SS');
また、Flashback Version Queryでは、一定期間に存在した行のバージョンを確認できます。
これは、11時から15時の間に、どの注文が、いつ、どのように変わったかを追う材料になります。どちらも過去の状態を参照する機能で、現在の表をその場で巻き戻す処理ではありません。
誤更新された注文を十分な精度で特定できれば、午後3時に近い状態を残しながら、対象の注文だけを補正する方針が選べます。
ここで確認するのは割引額だけではありません。
割引額から計算された請求額、税額、付与ポイント、返金の要否など、関連するデータも追います。
Flashback Queryは、過去を眺めるためだけの機能というより、現在の状態をどこまで残せるか判断するための調査手段として使えます。
表を戻すと、正常な注文も一緒に戻る
Flashback Tableは、指定した表を過去のSCNや時刻の状態へ戻す機能です。UNDOデータを使うため、対象時点までのUNDOが残っていること、表の構造が途中で変更されていないこと、行移動が有効になっていることなどの条件があります。この時、関連する表をどこまで一緒に戻すかも確認します。
今回のorders表を午前11時前へ戻した場合、誤更新された注文と一緒に、11時以降に入った正常な注文も戻ります。
Flashback Tableが時間を境界に表を戻すのに対し、「この注文は正常だから残す」「この注文だけ誤っているから直す」という分類には、注文ID、更新条件、処理ログなどの業務上の情報を使います。
ここで、影響が特定の表に集中し、対象時点以降の正常な更新を再構築できるなら、Flashback Tableが候補になります。
同じ表の中に正常な注文と誤更新された注文が多く混ざっている場合は、過去の状態を参照しながら対象行を補正する方法や、別の環境へ過去の表を復旧して比較する方法も検討できます。
※Flashback Tableはデータベース全体を停止せずに実行できますが、処理中は対象表に排他的DMLロックが取得されます。注文表のように更新が続く表では、アプリケーションからの書込み停止やサービス切替を含めて計画する必要があります。また、Flashback Table自体は通常のROLLBACKでは取り消せないため、実行前に現在のSCNを記録しておきます。
広い範囲を戻すなら、Flashback DatabaseかPITR
不具合の影響が複数の表や業務へ広がり、正しいデータと誤ったデータを切り分けにくい場合は、データベース全体を午前11時前へ戻す方針が候補になります。
Oracle AI Databaseでデータベース全体を特定の過去へ戻す代表的な方法が、Flashback DatabaseとデータベースのPoint-in-Time Recoveryです。
なお、RMANのリカバリ方式として整理する場合、PITRと対になるのは完全リカバリです。完全リカバリは利用可能なREDOを適用して最新時点まで進める方法で、PITRは指定した過去の時点で適用を止める方法です。今回のような誤更新では、最新時点まで進めると問題の更新も再現されます。そのため、ここでは過去へ戻す手段として、Flashback DatabaseとDatabase PITRを比較しています。
| 方法 | 戻す範囲 | 主に使う情報 | 選ぶときの条件 |
|---|---|---|---|
| Flashback Query | 変更しない | UNDO | 過去の値や変更範囲を調べたい |
| Flashback Table | 指定した表 | UNDO | 表単位で戻せて、必要なUNDOと前提条件がそろっている |
| Flashback Database | データベース全体、または条件を満たすPDB | Flashback LogとREDO | 事前にFlashbackを構成し、対象時点がFlashback Window内にある |
| Database PITR | データベース全体、または対象PDB | バックアップとREDO | バックアップから指定時点まで復旧する |
| RMANの表リカバリ | 指定した表・パーティション | バックアップとREDO | 過去の表を別領域へ取り出し、現在のデータと比較・統合する |
Flashback Database
Flashback Databaseは、データファイルをバックアップからリストアせず、データベースを以前の状態へ戻す機能です。
利用するには、事前にFast Recovery AreaやFlashback Logを構成しておく必要があります。また、Flashback Retention Targetは保持したい期間の目標値であり、その期間への復旧を常に保証する設定ではありません。確実に特定地点へ戻したい計画作業では、Guaranteed Restore Pointも選択肢になります。
※Guaranteed Restore Pointは必要なFlashback Logの再利用を抑止するため、長期間残すとFast Recovery Areaを圧迫するので注意が必要です。
Flashback Databaseは、現在のデータファイルが存在する状態で、論理的な変更を巻き戻す用途に向いています。データファイルの消失や破損から戻す処理には、バックアップを使ったリストアとリカバリを選びます。
今回のケースで午前11時前へFlashback Databaseを実行すると、データベース全体がその時点へ戻ります。その後に発生した正常な注文、在庫更新、決済処理も復旧先には残らないため、11時以降の正常な処理を、アプリケーションログ、外部決済の記録などから再構築できるかを先に確認します。
Point in Time Recovery(PITR)
PITRでは、バックアップからデータファイルをリストアし、REDOを指定した時刻やSCNまで適用します。
前回の記事で扱った「バックアップを目的の時点まで連れていく」仕組みを、今回は午前11時前で止めるイメージです。
Flashback Databaseで届く期間を超えている場合や、Flashback Logを利用できない場合にも、必要なバックアップとREDOがそろっていればPITRを検討できます。復旧後はOPEN RESETLOGSを伴うため、復旧手順、バックアップ方針、後続システムへの影響まで含めた準備が必要です。
PITRも時間やSCNで更新を区切ります。午前11時前へ戻せば、その後の正常な注文と誤更新の両方が復旧先から外れます。
データベース全体を戻さず、過去の表だけ取り出す
正常な注文をできるだけ残したいときは、現在のデータベースをそのまま維持し、バックアップから過去の表を別の場所へ取り出す方法もあります。
RMANの表リカバリでは、指定した時点の表や表パーティションを、補助データベースを使って復旧でき、復旧した表はData Pumpのダンプとして取り出したり、名前を変えて現在のデータベースへインポートしたりもできます。
今回なら、午前11時前のorders表を別名で取り出し、午後3時時点のorders表と比較します。
この方法なら、現在の状態を維持したまま、過去に正しい行バージョンが存在した注文については更新前の値を確認できます。
※ただし、注文作成時から誤った値が記録されていた場合、正しい値はFlashbackからは取得できません。価格表、キャンペーン条件、アプリケーションログなどを基に再計算する必要があります。
また、注文金額が在庫、請求、ポイントなど複数の表にまたがっている場合は、orders表だけを取り出しても復旧は完成しません。どの表を比較し、どの順番で補正し、どのデータを正として扱うかを決めます。
時刻より細かい境界を示すSCN
ここまで「午前11時前」と書いてきましたが、データベース内部の変更はSCN（System Change Number）によって順序づけられています。
SCNは、Oracle AI Database内の変更位置を表す番号です。FlashbackやPITRでは、時刻だけでなくSCNを復旧先として指定できます。
時刻は人が状況を整理しやすく、SCNはデータベース上の境界を具体的に示しやすい、という違いがあります。
Restore Pointは、Flashback Database、Flashback Table、RMANによるリカバリで利用できる時点のブックマークのようなものです。
今回のように問題があとから見つかったケースでは、アプリケーションログやFlashback Queryなどを使って、誤更新が始まる直前の時刻やSCNを探します。
Oracle MAAで見ると、復旧手段は「戻る範囲」で分かれる
Oracle MAAでは、人やアプリケーションによる論理的なエラーへの回復手段として、Flashback Query、Flashback Table、Flashback Database、UNDOなどの技術を挙げています。
機能をたくさん有効にすることより、それぞれがどの範囲を守るのかを整理しておくことが重要になります。
今回のケースなら、判断は次のようになります。
- 誤更新された注文を特定できるなら、過去の値を調べて対象データを補正する
- 表単位で戻せて、正常な更新を再構築できるなら、Flashback Tableを検討する
- 影響が広く、データベース全体を安全な状態へ戻すなら、Flashback DatabaseまたはPITRを検討する
- 現在の正常な注文を残したいなら、バックアップから過去の表を別環境へ取り出して比較する
どの方法でも、時点を決めたあとに業務上の確認が残ります。
どの注文を再投入するのか。すでに完了した決済をどう扱うのか。在庫をどの記録と照合するのか。利用者への請求や返金をどう確定するのか。
Flashback Queryは、過去の状態や変更履歴を調べるための機能ですが、Flashback Table、Flashback Database、PITRは、対象範囲と時点を決めてデータを戻すための手段であり、その境界から、正常な更新を再構築し、誤更新を補正し、関連データの整合性を確認することで、復旧方針が完成します。
時計の上で一つの正解を探すより、どこまで戻し、何を残し、何を作り直すかを先に決める。その判断に合わせてFlashbackとPITRを使い分けるのが、今回のシナリオでのOracle MAAの読み方だと思います。
免責
本記事は筆者個人の見解であり、所属組織の公式見解ではありません。筆者はOracleに所属していますが、本記事は公開情報をもとに、可用性設計の観点で整理したものです。製品・サービスの仕様は変更される可能性があるため、最終的な判断は公式ドキュメントをご確認ください。