Oracle Active Data Guard DMLリダイレクト: Read-Mostlyワークロードのチューニング

この記事はGlen Hawkinsによる"Oracle Active Data Guard DML Redirect: Tuning Read-Mostly Workloads"の日本語翻訳記事です。

2025年1月6日

※この記事は2020年に公開された記事です。

ゲスト著者：Pieter Van Puymbroeck

2019年、私はOracle Data Guardを特集したブログでOracle Database19cのDMLリダイレクト機能とFar Sync機能との動作について小さなブログ記事を書きました。

新機能は常にエキサイティングですが、その性能はどうなのでしょうか？良い提案をするためには、その機能を掘り下げてどのように機能するかを説明する必要があります。すべてのステップについてよく理解できれば、なぜ特定の推奨がなされるのかを理解しやすくなるでしょう。

まず、DMLリダイレクト機能とは一体何なのかを明確にしましょう。この機能を理解するためには、製品の歴史を掘り下げる必要があります。初期の頃は、Data Guardはマウント・モードで通常の物理スタンバイ・データベースを提供しており、データを保護するもの以上のものではありませんでした。

データを保護すること！それこそが本来のData Guardの重要な機能なのですが、私たちは当初から、この主要な製品の機能をさらに拡大するつもりでした。

そこで利用可能なリソースをさらに活用するために、私たちはActive Data Guardを開発しました。Active Data Guardが利用できるようになった時点で、DBAはスタンバイ・データベースを読み取り専用モードで開き、プライマリ・データベースからのREDOを適用し続けることができるようになりました。これは非常に便利で、プライマリ・データベースの代わりにスタンバイ・データベースに対してレポーティング・アプリケーションを実行できるようになり、Data Guardのメリットが二倍になりました。

1. プライマリの負荷が軽減
2. スタンバイのリソースも使用されるため、リソースの無駄が減る

これでみんなハッピーになったでしょうか？

レポーティング・ツールはしばしば、レポートが実行されたかどうかを登録する必要があります。つまり、簡単なDMLを実行することがあるということです。DBAはクリエイティブな人間なので、DBリンクを導入すれば問題ありません。あまり効率的ではありませんが、機能しますし、通常はうまく動きます。

もう1つの使用例は、データベースで物事を調べ、いくつかのデータを確認し、それを「完了」としてフラグを立てる必要がある場合です。これは「read-mostly (ほとんど読み込み) 」の作業です。

読み込めるデータはすべて、スタンバイ・データベースにオフロードする候補になり得えます。時折、小さなレコードをデータベースに登録する必要があるだけなら、このActive Data Guardの機能を使って問題ないでしょう。

ともあれ、プロダクト・マネージャーの重要な仕事は、人々の声に耳を傾け、製品の改善点を見出すことです。そこで、Oracle Database 19cの導入に伴い、スタンバイ・データベースに対して「時折」DMLを発行できるようにしました。

これは次のように動作します：

DMLリダイレクションのプロセスは5つのステップに分かれます：

1. クライアントが読み取り専用のスタンバイデータベースに対してDMLを発行
2. スタンバイがDMLであることに気づき、内部的なDBリンクを使用してプライマリデータベースにDMLを送信
3. プライマリがDMLを実行（その後、REDOが生成される）
4. このREDOは通常のREDOストリームとなり、通常のREDOストリームとともにスタンバイ・データベースに送信される
5. スタンバイデータベースは受信したREDOストリームを適用し、セッションのロックを解放

ですから、もしあなたが注意深くついてきているのであれば、上記のステップのいくつかが、潜在的にパフォーマンスのオーバーヘッドをもたらす可能性があることがわかるでしょう。 これが、先ほどの 「read-mostly (ほとんど読み込み) 」と 「occasion-only (時折) 」アプリケーションのコメントの理由であり、パフォーマンスへの影響を避けるためにこの機能を適切に使うことの成功の鍵です。

そこで質問です：

DMLリダイレクトにおいて、「時折の更新 」の本当の意味をどのように定量化すればよいのでしょうか？

このようなものに数字を貼り付けることは常に理想的ですが、実際に機能するのは（データを含む）正確なコンフィギュレーションがテストされた設定においてのみです。もちろん、私たちは新機能を導入する前には膨大な量のテストを行っています。しかし、このような方向性を掘り下げても、あなたのデータは「あなたのデータ」であり、あなたの環境で実行する予定のDMLのタイプは、あなたの「ほとんど読み取り」のアプリケーションに固有であることが多いため、誰もが望むガイダンスを提供することはできないでしょう。
ガイダンスの観点からは、DMLリダイレクションの活用に関して、成功への正しい道を歩むための経験則を提供することができます。

DMLリダイレクションの性質上、性能は主に以下に依存します：

• 発生するREDOの割合
• プライマリとスタンバイ間の帯域幅/レイテンシー
• プライマリの現在の負荷
• 両システムのCPUリソース
• I/Oストレージ・サブシステムの負荷/スループット

では、私たちが推奨するのは？

1. あなたのアプリケーションでとにかくテストをして、ReadとDMLの負荷率を比較してみてください！
2. 先に述べた私たちの経験則からは、DML updates/insertsを作業負荷の3～5%以下に維持させることをおすすめしますが、状況によっては、作業負荷の10%までをupdates/insertsとしてこの機能を検討し、それでもパフォーマンスが許容できるかどうかを確認することもできます。

DMLリダイレクションの結論は、スタンバイ・データベースを最大限に活用してread-mostly (ほとんど読み込み) 」のアプリケーションをオフロードするために必要な柔軟性を提供するという点で、大きな飛躍を遂げたということです。 私たちActive Data Guardの開発チームは、このソリューションをより良いものにするための方法を常に考えています。 

参考情報

• Oracle.com/goto/dataguard
• Oracle.com/goto/maa