この記事はLudovico CaldaraによるOffload more than Read-Only Workloads to Your Standby Databaseを日本語に翻訳したものです。

2024年3月23日


 

どの企業も(できれば!)本番データの災害復旧計画を持っています。ビジネス上重要かどうかにかかわらず、本番データベースに対する最も一般的な保護策は、ローカルまたはリージョナルな障害が発生した場合に、本番のワークロードを引き継ぐことができる完全で使用可能なコピーを提供するために、リアルタイムのデータレプリカをセットアップすることです。

ただし、災害復旧と事業継続への投資により IT 支出が増加するため、可能な限り多くの価値を提供するために資産を最適化することが戦略になります。 言い換えれば、スタンバイ・データベースを “受動的な” データ保護のためだけでなく、アプリケーション・アーキテクチャのアクティブなコンポーネントとして使用することが必然になります。

この要件に応えるために、ほとんどのデータベース・ベンダーはスタンバイ・データベースへの読み取り専用アクセスを提供しています。 アプリケーションが適切に設計されていれば、読み取り専用のワークロードをスタンバイ・データベースにオフロードできます。 また、必要に応じて、スタンバイ・データベースをスケールアウトできます。

それにもかかわらず、読み取り専用ワークロードをスケールアウトするのは簡単な作業ではありません。 これには、適切なアーキテクチャ、専用のデータ・ソース、またはもともと読み取り専用のアプリケーション(レポート・アプリケーションなど)が必要です。

このように、Oracle Active Data Guardは多くの理由から競合他社より際立っています。非常にスケーラブルで、高性能な読み取り専用レプリカを提供し、いくつか例を挙げると、アプリケーションは結果整合性(外部一貫性とも呼ばれる)、順序および一時表のサポート、インメモリ列ストアなどから利益を得ることができます。

 

Oracle DMLリダイレクトにより、アプリケーションはスタンバイ・データベースからデータ操作が可能

Oracle Database 19c以降、Oracle Active Data Guardは、スタンバイ・データベースに接続した状態でアプリケーションがデータ(DML文)を操作できることで、競合他社をさらに圧倒しています。 内部では、Oracle DMLリダイレクトがDMLをプライマリ・データベースにリダイレクトします。 つまり、トランザクションはスタンバイ・データベース上で実行されているように見えますが、プライマリ・データベースで実行されています。 DMLリダイレクトはACIDを保証します。トランザクションがアクティブな間は、トランザクションをコミットするまでスタンバイ・データベース上のセッションだけが変更されたデータを見ることができます。

以下の画像に示す通り

  1. スタンバイ・データベースに接続されたセッションがDML文を発行
  2. DMLリダイレクトによって透過的に作成されたデータベース・リンクを使用してプライマリ・データベースにDMLをリダイレクト
  3. DMLがプライマリ・データベースに適用
  4. 変更は通常のData Guardレプリケーションでスタンバイ・データベースに送信
  5. DMLの結果は、トランザクションを開始したセッションでのみ表示
  6. セッションがトランザクションをコミットするとプライマリ・データベースとスタンバイ・データベース上の他のセッションからも変更データを確認可能

A DML executed by a session on the standby database is transparently redirected to the primary database

 

DMLリダイレクトはDML文に限定されません。 読み取り専用トランザクションでスタンバイ・データベース上のグローバル一時表や順序を使用する利点を保ちつつ、PL/SQLコールもリダイレクトできます。

DMLリダイレクトはスタンバイ・データベースの使用量を増やし、最終的に費用対効果(ROI)が向上

DMLリダイレクトはなぜ画期的なのか?

これまで大量の読み取りワークロードを実行しているが、一部データの書き込みが必要なアプリケーションはプライマリ・サービスに接続しなければなりませんでした。 現在では、同じアプリケーションがスタンバイ・データベース・サービスにのみ接続し、すべての読み取り処理をオフロードし、トランザクションの一部の書き込み処理のみを効果的にプライマリ・データベースで実行できます。これにより、複数のデータソースを持つアプリケーションの設計するために必要な複雑さが暗黙的に解消されます。

スタンバイ・データベースからプライマリ・データベースにリダイレクトできる書き込みワークロードの量はどれくらいですか?

  • 19cでは、OracleはリダイレクトされるDMLをワークロードの10%未満に保つことを推奨しています(低いほど良い)。
  • 21cでは、さらに最適がが行われ、スタンバイ・セッションが認識されるトランザクションの経過時間が1桁向上しました。これにより、スタンバイ・データベース上で、より書き込み比率の高い(80%読み取り、20%書き込み)ワークロードを実行できるようになります。いつものように、最終的なアプリケーションのパフォーマンスとプライマリ・データベースのメリットは、アプリケーションのワークロードとアーキテクチャによって異なるため、アプリケーションをスタンバイ・データベースにオフロードした場合の影響を評価するには、アプリケーションを十分にテストする必要があります。

一般的に、読み取りが主なアプリケーション(またはアプリケーション・モジュールやマイクロサービス)は、スタンバイ・データベースに直接接続し、時々発生する書き込み処理にDMLリダイレクトを活用する優秀な候補です。

 

大手金融機関を含む多くのお客様がDMLリダイレクトを上手に活用して、スタンバイ・データベースに対してレポート・アプリケーション、マイクロサービス、その他のアプリケーションを実行しています。 今すぐオンプレミスまたはOracle Cloud Infrastructure(Exadata Database ServiceまたはBase Database Service)でお試しください!