【ITニュース解説】Resolving Missing Log Gaps in Data Guard

システムエンジニアを目指す皆さんにとって、データベースの安定稼働とデータ保護は、学習する上で非常に重要なテーマだ。特に大規模なシステムでは、たとえ本番環境で障害が発生しても業務が停止しないように、複数のデータベースを連携させておくことが一般的だ。そのための強力な機能の一つが、Oracleデータベースの「Data Guard」だ。Data Guardは、実際にシステムが稼働している「プライマリデータベース」と、そのプライマリデータベースの複製である「スタンバイデータベース」を常に同期させておく仕組みを指す。プライマリデータベースで行われたすべてのデータ変更は、「REDOログ」という形で記録され、このREDOログはスタンバイデータベースに継続的に転送され、適用されることで、プライマリとスタンバイのデータが常に同じ状態に保たれる。REDOログが特定のサイズに達すると、「アーカイブREDOログ」として保存される。

しかし、このアーカイブREDOログの転送や、スタンバイデータベースへの適用プロセスにおいて問題が発生すると、「ログギャップ」と呼ばれる状況が発生する。ログギャップとは、スタンバイデータベースがプライマリデータベースから受け取るべきアーカイブREDOログの一部が欠落している、あるいはまだ適用されていない状態を指す。たとえば、ネットワーク障害でログの転送が一時的に途切れたり、スタンバイデータベースがなんらかの理由で停止していたりする間に、プライマリデータベースで新しいアーカイブREDOログが次々と生成され、場合によっては古いログがシステムによって削除されてしまうことがある。こうなると、スタンバイデータベースは、プライマリデータベースから必要なログデータを受け取ることができなくなり、両者の同期が取れなくなってしまう。このログギャップを解消し、スタンバイデータベースを再びプライマリと同期した最新の状態に戻すことは、システムの災害対策や高可用性を維持するために非常に重要な作業となる。

過去のOracleデータベースのバージョンでは、このログギャップの解消作業は非常に手間がかかるものだった。Oracle 10gの時代には、ログギャップを埋めるための「増分バックアップ」という技術が存在したものの、そのプロセスは完全に手動で行う必要があった。具体的には、どの時点のデータが欠落しているかを特定する「SCN番号」を調べ、そのSCN番号に基づいてプライマリデータベースから増分バックアップを取得し、そのバックアップファイルをスタンバイサーバーへ手動で転送し、さらにスタンバイデータベースに手動で適用するという、多くのステップを踏まなければならなかったのだ。これは運用管理者にとって大きな負担であり、操作ミスによるリスクも決して小さくなかった。

Oracle 12cR1になると、このプロセスは一部改善され、自動化された部分も登場した。しかし、それでもなお、複数の手動ステップが残されていた。例えば、スタンバイデータベースをマウントモードで起動し、RMAN（Oracle Recovery Manager）というツールを使ってプライマリサービスからリカバリを実行するコマンド、コントロールファイルをリストアするコマンド、データベースを再度オープンするコマンド、そしてマネージドリカバリを開始するコマンドといった具合に、一連のコマンドを運用担当者が順番に実行する必要があった。完全に自動でギャップが解消されるわけではなかったため、運用の手間がゼロになったわけではなかった。

しかし、Oracle 18cの登場により、このログギャップ解消プロセスは劇的に簡素化された。このバージョンでは、これまでの複雑で複数の手動ステップを必要としたギャップ解消作業が、たった一つのコマンドで自動的に実行されるようになったのだ。その画期的なコマンドが「RMAN> RECOVER STANDBY DATABASE FROM SERVICE tns_fal_server;」というものだ。このコマンドを実行するだけで、必要なコントロールファイルのリストアから、欠落している増分バックアップの取得、そしてスタンバイデータベースへの適用まで、一連の複雑な作業が裏側で自動的に処理される。これにより、運用担当者の負担は大幅に軽減され、ヒューマンエラーのリスクも最小限に抑えられるようになった。

では、このOracle 18cの新機能が実際にどのように動作し、ログギャップを解消するのか、具体的なシミュレーションを通して見てみよう。まずステップ1では、プライマリデータベースとスタンバイデータベースが現状で同期しているかを確認する。それぞれのデータベースでアーカイブREDOログの最大シーケンス番号を問い合わせると、両方で「128」という同じ値が確認でき、さらにスタンバイ側ではそれが「APPLIED（適用済み）」となっていることから、この時点では両者が完全に同期していることがわかる。

次に、ステップ2では意図的にログギャップを発生させる。まず、スタンバイデータベースを緊急停止させる。その間に、プライマリデータベースではデータ変更を伴う操作（ログファイルの切り替え）を2回行い、新しいアーカイブREDOログファイル（シーケンス番号129と130）を生成させる。そして、そのうちの一つ、シーケンス番号129のアーカイブREDOログファイルをすぐにプライマリ側から手動で削除してしまう。この状態でスタンバイデータベースを再起動し、マネージドリカバリを開始すると、スタンバイは削除されたはずのログファイル129をプライマリから取得しようと試みるが、見つからないため「Media Recovery Waiting for T-1.S-129」というメッセージを表示し、ログギャップが発生したことを確認できる状態となる。

ステップ3では、Oracle 18cの新機能を使ってこのログギャップを解消する。まずは、スタンバイデータベースで現在実行されているマネージドリカバリプロセスを一時的に停止する。その次に、RMANプロンプトで「RMAN> recover standby database from service prim;」という、Oracle 18cで導入された新しいコマンドを実行する。このコマンドが実行されると、システムは自動的にプライマリサービスに接続し、不足しているスタンバイコントロールファイルのリストア、さらにはプライマリデータベースから欠落しているログデータを補うための増分バックアップの取得と適用まで、複数の内部処理を一連の流れとして自動的に実行していく。RMANの出力ログからは、コントロールファイルのリストアが行われ、その後、ネットワーク経由でプライマリサービスからデータファイルの増分バックアップが取得・適用され、メディアリカバリが完了する一連のプロセスが確認できる。すべてのギャップ解消プロセスが完了したら、再度スタンバイデータベースでマネージドリカバリを開始する。

最後のステップ4では、ログギャップが正しく解消されたことを確認する。再度スタンバイデータベースのアーカイブREDOログの状態を問い合わせると、最大シーケンス番号が「130」となり、それが「APPLIED（適用済み）」になっていることが確認できる。これは、削除されたログファイル129と、その後に生成されたログファイル130が、Oracle 18cの新コマンドによって自動的にスタンバイデータベースに適用され、プライマリデータベースとの同期が再び完全に確立されたことを明確に示している。このように、Oracle 18c以降のバージョンでは、データ保護の要であるData Guardにおけるログギャップという複雑な問題に対して、たった一つのコマンドで、より簡単かつ迅速に対応できるようになった。これは、システム運用における手間を大幅に削減し、システムの可用性と信頼性を高める上で、システムエンジニアにとって非常に強力な進化と言えるだろう。