【ITニュース解説】DataGuard DML Redirection(Oracle 19c and 18c)

Oracle Data Guardは、データベースの信頼性と継続的な運用を支える重要な技術である。これは、本番環境で稼働する「プライマリデータベース」と、そのプライマリの完璧なコピーとして常に最新の状態を保つ「スタンバイデータベース」で構成される。スタンバイデータベースは、プライマリに何か問題が発生した場合に、その役割を迅速に引き継ぐことで、システムの停止時間を最小限に抑える役割を担っている。特に「Active Data Guard（ADG）」という形態では、スタンバイデータベースがプライマリからの変更をリアルタイムで適用しながら、同時に読み取り専用のアクセスを許可するため、プライマリの負荷を分散させたり、レポート作成などの用途で活用したりすることが可能となる。

しかし、従来のADG環境には、重要な制約があった。それは、データの追加、変更、削除といった「DML（Data Manipulation Language）」操作が、原則として許可されていなかった点である。具体的には、データベースに永続的に保存される一般的なシステム表やアプリケーション表に対しては、DMLを実行することができなかった。唯一、セッションの間だけ一時的にデータが保持される「グローバル一時表」に対してはDML操作が許可されていたが、これはデータ保護と一貫性を重視するADGの設計思想によるものだった。この制限は、ADGの利便性を損なう場面も少なくなかった。例えば、ADG側で読み取り専用の処理を行う際に、一時的なデータ加工を行いたい場合などには不便を感じることがあった。

この状況に変化をもたらしたのが、Oracle 18cの登場だった。このバージョンでは、まだ公式にはサポートされていなかったものの、「_enable_proxy_adg_redirect」と「_ADG_REDIRECT_FLAGS」という二つの「隠しパラメータ」を設定することで、ADG環境でもDML操作を実行することが可能になった。隠しパラメータとは、通常はOracleの内部的な動作を制御するために使われるもので、利用には注意が必要である。この設定により、ADGデータベース側でデータを追加するINSERT文などを実行できるようになり、その変更はプライマリデータベースにもリアルタイムで反映されるようになった。しかし、これはあくまで非公式な機能であり、本番環境での利用は推奨されなかった。

そしてOracle 19cでは、このDML操作の機能が「ADG REDIRECT DML」として正式に導入され、完全にサポートされるようになった。18cのように隠しパラメータを設定する必要はなく、「ADG_REDIRECT_DML=TRUE」という公開されたパラメータをADGデータベース側で設定するだけで、DML操作が可能になる。この公式サポートは、ADGの運用における柔軟性を大きく向上させる画期的な変更であった。

この機能の具体的な動作は次のようになる。まず、プライマリデータベースで新しい表を作成する。次に、ADGデータベース側で「ALTER SYSTEM SET ADG_REDIRECT_DML=TRUE」コマンドを実行し、DMLリダイレクト機能を有効にする。ADGデータベースが読み取り専用モード（READ ONLY WITH APPLY）であることを確認した上で、ADG側から先ほどプライマリで作成した表に対してINSERT文でデータを挿入する。データが正常に挿入され、コミット操作が完了すると、実際にデータが書き込まれるのはプライマリデータベースである。そして、その結果はプライマリデータベース側から問い合わせを行うことで確認できる。つまり、ADG側でDMLを実行しても、その操作は裏でプライマリデータベースに転送（リダイレクト）されて実行されるという仕組みになっている。

DMLがリダイレクトされる際のロックの挙動も理解しておくべき点である。ADG側でUPDATE文を実行し、特定の行のデータを変更しようとすると、その操作はプライマリデータベースに転送され、プライマリデータベース上の該当する行がロックされる。例えば、ADG側で特定の行を更新している最中に、プライマリデータベース側から全く同じ行を更新しようとすると、プライマリ側のセッションは、ADG側からの操作によるロックが解放されるまで待機状態となる。これは、同じデータに対して同時に複数の変更が加えられることを防ぎ、データの一貫性を保つためのデータベースの標準的なロック機能が、リダイレクトされたDML操作でも適用されることを示している。

障害発生時の動作も確認しておく必要がある。もしADG側でDMLを実行中にプライマリデータベースが利用不能になった場合、ADG側では「ORA-16397: statement redirection from Oracle Active Data Guard standby database to primary database failed」といったエラーが発生し、DML操作は失敗する。また、ADG側でデータを挿入した後、コミット操作を実行しようとした瞬間にプライマリデータベースが停止してしまった場合、ADG側では「ORA-03150: end-of-file on communication channel for database link」や「ORA-02063: preceding line from ADGREDIRECT」といったエラーが発生し、コミットも失敗する。これは、DML操作が最終的にプライマリデータベースで実行されるため、プライマリデータベースが正常に稼働していることが前提となることを意味している。

最後に、DMLリダイレクト機能のパフォーマンスをプライマリデータベースでのDMLと比較してみよう。大量のデータを挿入する操作（INSERT文）を実行した場合、ADG側から実行しても、プライマリデータベースから直接実行しても、データの挿入自体にかかる時間はほぼ同等である。しかし、コミット操作にかかる時間を見ると、ADG側からのコミットはプライマリ側からのコミットに比べてわずかに時間がかかる傾向がある。これは、ADG側からプライマリへの通信オーバーヘッドや、プライマリでの処理結果がADGにフィードバックされるまでの時間などが影響しているためと考えられる。ただし、この時間差はシステムの基盤環境（ネットワークの速度やストレージ性能など）によっても大きく変動する可能性があるため、注意が必要である。

このように、Oracle 19cで正式に導入されたADG REDIRECT DML機能は、Active Data Guardの活用範囲を大きく広げる画期的な機能である。これにより、データベースの読み取りだけでなく書き込みも可能な、より柔軟な高可用性データベース環境の構築が可能になる。ただし、パフォーマンスや障害時の挙動、ロックの特性を十分に理解した上で、適切にこの機能を活用することが求められる。