この記事はLudovico Caldaraによる”Why Is Flashback Often Better Than Backups?“の日本語翻訳版記事です。

※翻訳元の記事は2020年に公開されたものです。

2024年4月15日

データベースの高可用性（HA）について考えるとき、インスタンス障害やノード障害、データセンターの障害などを考える人が多いでしょう。しかし同様に悲惨ではあるものの、一般的に見落とされがちな「障害」のカテゴリーの1つとして、「論理破損」つまり、アプリケーションまたは人的エラーがあることを忘れてはいけません。

どんな間違ったデータ変更はどんなに小さく単純なものでも、論理破損を引き起こします。人的ミスによって引き起こされる極端な例としては、update文で誤ってwhere句を省略したために、人事システム内のすべての従業員を副社長に昇進させてしまうことだって発生する可能性があります。この場合、通常データベースを停止して回復し、データに対する依存性のさらなる破損を防ぐ必要があります。これにより、データベースとアプリケーションに顕著なダウンタイムが発生するするケースがほとんどです。

table1

この種の人的エラーは、最善の注意を払っていても時折発生するものです。しかし、これはアプリケーションやデータの変更が短期間で要求されることが多い、めまぐるしく変化する現代社会では避けられないことです。では、このような障害から復旧する方法は何がベストなのでしょうか？

この疑問に対する答えのひとつは、データベースが最初にどのように保護されたか（バックアップのみ、レプリケーション、またはそれらの組み合わせなど）によって決まります。

Oracle Databaseの観点で総合的なHAとDRの視点でデータベースを適切に保護する方法を掘り下げることは、このブログ記事ではしません（ご興味のある方は、MAAのウェブキャスト・シリーズをご覧ください）。その代わりに、この記事では人的エラーやアプリケーション・エラーによる論理データの破損を解決するという課題に焦点を当てていきます。

論理的破損に対する従来の復旧方法は苦痛を伴う

上記のような論理破損を考えると、更新されたデータはSQLトランザクションの観点からは有効です。この状態のままだと、その後のステートメントが論理的に破損したデータに基づいている可能性があるため、さらなる損害が発生する可能性があります。論理破損のレベルや深刻さに関係なくこれは正常な操作であるため、データベースの観点からはエラーは発生しません。しかし、アプリケーションの視点やビジネスからは同じことは言えず、間違いなくこの論理破損を深刻な問題とみなされるでしょう。

その結果、リストアとリカバリの操作は、おそらく一連の異なるデータベース・オブジェクトにまたがる非常に粒度の細かいデータの断片に対して行う必要があります。残念ながら、一般的なリカバリ・ソリューションの多くは、このようなケースでは理想的ではありません。他のデータベース技術のリカバリの例をいくつか見てみましょう。今回は、Google Spannerのアプローチを使用して、機能ギャップをよりよく理解し、Oracleのソリューションとの比較対照を行います。

例1： レプリケーション – 保護のためのレプリケーションの背後にある考え方は、データが常に残りのレプリカの1つからリストアできるということです。Oracle (Active) Data GuardはOracle Databaseのレプリケーションを提供しますが、それは高可用性とディザスタ・リカバリのためのより総合的なソリューションの一部に過ぎません。

レプリケーションの概念に詳しい方にとっては、このアプローチでは上述のような論理的な破損が発生した場合、簡単に復旧できないことは明らかかもしれません。実のところ、このアプローチは問題を複雑にする可能性さえあります。というのも、「間違った更新」（論理的な破損）がコミット用にサブミットされると、レプリケーションベースの保護を使用している分散データベースは、大多数のレプリカが更新を受信した時点で初めてコミットを確認するからです。そのため、コミットが確認される頃には、論理的な破損はすでに拡大し、データを保護するはずだったすべてのレプリカに影響を及ぼしていることになります。

例2：バックアップ＆リカバリー – この種の破損からデータを復元するためにレプリカが実際に機能しないことがわかったので、このような論理破損から復元するための代替アプローチとして、通常バックアップ＆リカバリーが思い浮かぶと思います。これは有効なアプローチだと思う人も多いかもしれませんが、現実的には面倒になることがあります。データベース技術の例としてGoogle Spannerを再び使ってみると、Googleがデータの各コピー（レプリカのコピーも含む）のバックアップを導入したのはごく最近（2020年当時）のことです。したがって、Google Spannerのデータベースを完全に復元するには、そもそも論理破損の影響を受けたレプリカの数だけ、ローカルでの復元・復旧作業を行わなければならない。

加えて、必要とされるリストアとリカバリは非常に複雑です。それはなぜかというと、一般的にリストアとリカバリの操作は、データベース・エンティティの完全なセット、つまり完全なOracle Databaseをリストアするように設計されています。しかし、論理破損はそのように単純に復元することはできません。必要なのは、問題のある更新または挿入がコミットされる前のデータベースの状態への「ポイント・イン・タイム・リカバリ」（PITR）です。これは複雑なプロセスで、バックアップから補助データベースに復元し、必要なデータを本番データベースにエクスポート/インポートする必要があります。

例 論理的破損からの復旧方法

それでは、Oracle Databaseが論理破損をどのように解決するのかを考えてみましょう。具体的には、以下の段階とステップを含むシナリオに沿って説明します： 

  1. 状況を理解する – データが誤って更新される（論理破損が発生する）
  2. Oracle Backup and Recoveryによるデータのリストア（最適ではないアプローチ）
  3. オラクル・フラッシュバック・テクノロジーによる救済（理想的なアプローチ）

状況を理解する – データが誤って更新される

以下の表仮があると仮定します：

table2

表に対してアップデートが実行され、次のような「論理破損」が発生しました：

table3

これは重大な結果を招きかねない大きなミスでです。給与計算やCRMシステムでこのようなことが起こった場合を想像してみてください。さらに悪いことに、col-nがアクセス権の付与に使われた場合、深刻なセキュリティ侵害につながる可能性があります。

Oracle Backup and Recoveryによるデータの復元

Oracle Databaseを使用する場合でも、RMANアプローチはこの場合には理想的ではありません。Oracle 12.1以降RMANには1つの表に対してポイント・イン・タイム・リストア（PITR）操作を実行するRECOVER TABLEコマンドがあります。これにより 、自動的に補助イスタンスが作成、ポイント・イ ン・タ イ ム・リストアが実行され、破損したテーブルの影響を受けるデータベースへのインポート が自動的に実行されます。データを失う必要はなくさらにこの操作中もデータベースはオンラインのままです！ドキュメントには、テーブルを復元するすべての手順を説明するために、この方法を実行する例が記載されています。

Oracle Flashback Technologyによる復旧

上記のプロセスはやや複雑で、RMANを使用している場合でも表を保持している表領域のサイズに比例したリカバリ時間を必要とする可能性があります。しかしOracle Databaseには、データベースをリストアすることなく間違った更新を素早く解決できるユニークな機能があります。

Oracleでは、FLASHBACK TABLE操作を実行できます。この機能を利用するにはデータベースでフラッシュバック・ロギングが有効になっている必要があります。以下のクエリは、データベースの現在の状態を確認するのに役立ちます：

SELECT FLASHBACK_ON FROM V$DATABASE;

このクエリの出力が「No」の場合、以下のコマンドで簡単にフラッシュバックを有効にすることができます：

ALTER DATABASE FLASHBACK ON;

クエリを再度実行すると、データベースはFlashbackを使用する準備が整っていることを確認できます。バックグラウンドでは、フラッシュバックログの収集が開始されます。FlashbackはこれらのFlashbackログを使用して、アーカイブされたREDOログファイル内のいくつかのデータと組み合わせて、以前のバージョンのデータブロックにアクセスします。

表をフラッシュバックする際、FLASHBACK TABLEコマンドはフラッシュバック・ログの情報を調べ、論理破損が発生する前のデータの状態を確認します。これにより、データベースを停止したり、非常に大規模なデータベースでリソースの問題につながる可能性のある不要な補助インスタンスを起動したりすることなく、簡単で便利、かつ信頼性の高い方法で過去からデータを取り出すことができます。

例えば、破損がシステムを襲う1分前に表を巻き戻したい場合、それを呼び出すのは簡単です：

FLASHBACK TABLE <table_name> TO TIMESTAMP (SYSTIMESTAMP - INTERVAL '1' minute);

データベース全体をリストアすることなく、補助的なインスタンスも必要ありません。正しいデータを取得し、最新の状態に戻すだけです。簡単です。

これが、Oracle Flashbackが特に人的エラーやアプリケーション・エラーにより引き起こされたローカルの破損に対してバックアップよりも優れている理由です。実装が簡単で、Oracle Databaseに完全に統合されており、何よりもデータベースやアプリケーションのダウンタイムが必要ありません。Oracle Databaseは、あらゆる災害事象からデータを真に保護するためのディザスタ・リカバリに対するアプローチを兼ね備えています。