Oracle Cloud Infrastructureドキュメント

自律型AIデータベースでProxySQLを有効にして効率的な文ルーティングを使用

ProxySQLは、DMLおよび問合せの文をルーティングすることで、複数の自律型AIデータベースへの統合アクセスを可能にし、すべてのデータを1つのデータベースに物理的に統合する必要性を排除します。

自律型AIデータベース上のProxySQLを使用した効率的な文のルーティングについて

自律型AIデータベース上のProxySQLを使用すると、複数の自律型AIデータベース・インスタンスを使用でき、1つの場所に格納されたかのように、データへのアクセスと分析を簡単に行うことができます。

ProxySQLは、複数のAutonomous AI Databaseを含む大規模な設定で作業する必要がある場合に使用できます。ProxySQLを使用すると、様々なデータベースへの統合アクセスが可能になり、データを1つの場所に物理的に移動する必要がなくなります。

ProxySQLを有効にする場合、1つのAutonomous AI Databaseインスタンスをルーター・インスタンスとして、1つ以上のAutonomous AI Databaseインスタンスをターゲット・インスタンスとして指定します。ルーター・インスタンスには、文を1つ以上のターゲット・インスタンスに分散(マップ)する方法を決定するルーティング表が含まれます。ターゲット・インスタンスには、受入れ表が含まれます。受入れテーブルはルーティングテーブルに似ており、インスタンスがルーターからのステートメントリダイレクトを受け入れることを指定するエントリが含まれています。

選択したルーティング方法に応じて、ステートメントはルーターインスタンスから1つ以上のターゲットインスタンスに自動的にマップされます。アプリケーションはルーター・インスタンスに接続し、ルーター・インスタンスで実行し、Autonomous AI Databaseは1つ以上のターゲット・インスタンスに文をリダイレクトします。

1つの非常に大規模なAutonomous AI Databaseを使用する場合と比較して、ProxySQLを有効にする利点の一部を次に示します:

  • ProxySQLは、ライフサイクル管理や管理タスクなどの操作のためのデータベースの自律性と独立性を提供します。たとえば、ProxySQLを使用すると、バックアップとリストアなどのデータベース操作、およびAutonomous Data Guardなどの機能は、各Autonomous AI Databaseインスタンスで個別に管理されます。

  • ProxySQLを使用すると、複数のAutonomous AI Databaseインスタンスにデータを分割して、非常に大規模なデータベースを効率的に管理できます。

ProxySQLの操作時に知っておく必要がある用語がいくつかあります。

ルーター・インスタンス: ProxySQLを有効にすると、ルーター・インスタンスが指定されます。ルーティング表は、文を1つ以上のターゲット・インスタンスに分散(マップ)する方法を決定します。指定されたルーティング方法に応じて、ルーターインスタンスからのステートメントは自動的に1つ以上のターゲットインスタンスにマップされます。

ターゲット・インスタンス: ターゲット・インスタンスは、ルーター・インスタンスにマッピングを作成するときに指定されます。各ターゲット・インスタンスに受入れ表が追加されます。

ルーティング表: ルーティング表には、文が自動的にルーティングされるインスタンスを指定するターゲット・マッピング・エントリが含まれます。

受入表: 受入表には、インスタンスがルーターからの文リダイレクトを受け入れることを指定するエントリが含まれます。

ProxySQLを使用するための要件

ProxySQLの要件は次のとおりです。

  • ProxySQLの有効化は、エラスティック・プールにあるAutonomous AI Databaseインスタンスでのみサポートされています。ルーター・インスタンスとすべてのターゲット・インスタンスは、同じエラスティック・プールのメンバーである必要があります。

  • ルーター・インスタンスとすべてのターゲット・インスタンスが同じリージョンにある必要があります。

  • ルーティングするオブジェクトのメタデータは、ルーターインスタンスとターゲットインスタンスで一致する必要があります。アプリケーション設計者は、ターゲット・インスタンスに存在するオブジェクトのメタデータもルーター・インスタンスに存在する必要があります。たとえば、ターゲット・インスタンスにEMPLOYEESという名前の表がある場合、ルーター・インスタンスにはEMPLOYEESという名前のメタデータと一致する表も必要です。ルーター・インスタンスの表は空である必要はありません(メタデータのみ)。

ProxySQLを有効にするための推奨事項

ルーターおよびターゲットとして追加するインスタンスは、任意のAutonomous AI Databaseワークロード・タイプにできます。ルーティング(マッピング)表にエントリがある場合、それらのエントリで指定されたオブジェクトに対する文は、ターゲットのワークロード・タイプに関係なく、対応するターゲット・インスタンスにルーティングされます。Oracleでは、すべてのAutonomous AI Databaseインスタンスでレイクハウスのワークロード・タイプを使用することをお薦めします。

ProxySQLを有効にした自動文ルーティング

ProxySQLを使用すると、サポートされているルーティング方法のいずれかを使用して、ターゲット間で文を分散できます。

ノート

ノート:使用することを決定したルーティング方法(マッピング)に関係なく、アプリケーション・スキーマ設計者は、ターゲット・インスタンスに配置されたオブジェクトのメタデータもルーター・インスタンスで使用できるようにする必要があります。たとえば、ターゲット・インスタンスにEMPLOYEESという名前の表がある場合、ルーター・インスタンスにはEMPLOYEESという名前のメタデータと一致する表も必要です。ルータインスタンスのテーブルを空にする必要はありません。

  • スキーマ・レベルのルーティング: スキーマのすべてのオブジェクトは、単一のターゲット・インスタンスにマップされます。複数のスキーマを1つのターゲット・インスタンスにマッピングできます。ただし、1つのスキーマの文を複数のターゲット・インスタンスにマッピングすることはできません。つまり、同じスキーマをスキーマとオブジェクトの両方のルーティングに使用することはできません。

    スキーマ・レベルのルーティングを指定するには、object_nameパラメータの値を「*」に設定してDBMS_PROXY_SQL.ADD_MAPPINGプロシージャをコールします。

    proxysql_schema.pngの説明が続きます

    図proxysql_schema.pngの説明

    この例では、スキーマAのオブジェクトのメタデータは、ターゲットAutonomous AI Database 1とルーター・インスタンスの両方に存在し、スキーマBのオブジェクトのメタデータは、ターゲットAutonomous AI Database 2とルーター・インスタンスの両方に存在します。

  • オブジェクト・レベルのルーティング: スキーマ内のオブジェクトは、複数のターゲット・インスタンスにマッピングされます。

    オブジェクト・レベルのルーティングを指定するには、object_nameパラメータを表名に設定してDBMS_PROXY_SQL.ADD_MAPPINGプロシージャをコールします。

    proxysql_object.pngの説明が続きます

    図proxysql_object.pngの説明

    この例では、表Aのメタデータがターゲット1とルーター・インスタンスの両方に存在し、表Bのメタデータがターゲット2とルーター・インスタンスの両方に存在します。

  • ハイブリッド・ルーティング: スキーマのオブジェクトは、スキーマ・レベルのルーティングとオブジェクト・レベルのルーティングの組合せを使用してルーティングされます。

    proxysql_hybrid.pngの説明が続きます

    図proxysql_hybrid.pngの説明

    この例では、スキーマAのメタデータがターゲットAutonomous AI Database 1とルーター・インスタンスの両方に存在し、表Bのメタデータ(スキーマB)がターゲットAutonomous AI Database 2とルーター・インスタンスの両方に存在します。

ProxySQLが有効な場合の自動文ルーティングによるサービス・マッピング

ルーティングテーブルがターゲットデータベースへのマッピングを示している場合、ルータデータベースに接続しているサービスと同じサービスがターゲットデータベースのデータアクセスに使用されます。

たとえば、セッションがルーター・インスタンスのHIGHサービスに接続されている場合、ターゲット・インスタンスにルーティングされる文または文のフラグメントもHIGHサービスを使用します。同様に、ルーター・インスタンス上のMEDIUMサービスにセッションが接続されている場合、ターゲット・インスタンスにルーティングされる文はMEDIUMサービスを使用します。

ルーター・インスタンスでの接続に使用されるサービスがターゲット・インスタンスで使用できない場合、ターゲット・インスタンスにルーティングされる文または文のフラグメントはMEDIUMサービスを使用します(使用可能なサービスは、Autonomous AI Databaseワークロード・タイプによって異なります)。

ルート問合せの現在のユーザー・セマンティクス

Autonomous AI Databaseでインスタンス間アクセス用のルーティング表を構成する場合、次の基準を満たす必要があります:

Autonomous AI Databaseでインスタンス間問合せルーティングを構成する場合は、異なるAutonomous AI Databaseインスタンスに存在する表またはビュー間のマッピングを定義します。これらのオブジェクトは、同じ名前で、ルーター・インスタンス(問合せが開始される場所)とターゲット・インスタンス(問合せが実行される場所)の両方で同じスキーマに属している必要があります。明確なマッピングと適切なユーザー権限は、一貫性のある予測可能なルーティング問合せに不可欠です。

パフォーマンスを維持するために、繰り返しのカーソル再コンパイルをトリガーしてパフォーマンスに影響を与える可能性があるため、ルーティング表への頻繁な変更を回避してください。ルーティングテーブルを変更する前に、次のことを考慮してください。

  • オブジェクト・コロケーション: 可能な場合は常に、頻繁に問い合せられるオブジェクトを同じAutonomous AI Databaseインスタンスに配置します。これにより、問合せのパフォーマンスが最適化され、インスタンス間のオーバーヘッドが削減されます。

  • データ移動: 必要なデータが適切なAutonomous AI Databaseインスタンスに存在することを確認します。エクスポート/インポート・ユーティリティまたはOracle GoldenGateを使用して、必要に応じて効率的なデータ移行を容易にします。

  • カーソルのコンパイル: ルーティング表でエントリを追加または削除すると、既存のカーソルが無効になり、再コンパイルが必要になる場合があります。無効化を最小限に抑えるために変更を計画します。

ルーティングでのユーザーおよびオブジェクトの存在に関する次の要件に注意してください。

ノート

注意:

  • この例では、DW_USERは、ルーターとターゲットのAutonomous AI Databaseインスタンスの両方に存在するスキーマです。
  • INVENTORY表は、両方のAutonomous AI DatabaseインスタンスのDW_USERスキーマに存在します。
  • ユーザーSCOTTは、Autonomous AI Databaseインスタンスのいずれかまたは両方に接続し、問合せを実行できる別のデータベース・ユーザーです。

  • オブジェクトの存在要件: ルーターとターゲットのAutonomous AIデータベース・インスタンスの両方に存在し、同じ名前で同じスキーマ内に存在する表またはビューのみをルーティング表に含めることができます。

    たとえば:

    BEGIN
    DBMS_PROXY_SQL.ADD_MAPPING (
        object_owner   => 'DW_USER',
        object_name    => 'INVENTORY',
        database_name  => 'IBUWLQ4MJQKEILS_DOLLDB'
    );
END;
/

    DW_USERスキーマのINVENTORY表がルーティング用にマップされていることに注意してください。INVENTORY表は、ルーターとターゲットの両方のAutonomous AI DatabaseインスタンスのDW_USERスキーマ内に存在する必要があります。

  • 現在のユーザー要件: マップされた表またはビューがルーターのAutonomous AI Databaseインスタンスで直接問い合せられると、問合せは現在のユーザーとしてターゲット・インスタンスで実行されます。このユーザーは、ルーターとターゲットの両方のインスタンスに存在する必要があります。

    たとえば:

    -- Connected as user SCOTT
SELECT ITEM_ID, ITEM_DESCRIPTION FROM DW_USER.INVENTORY;

    SCOTTがDW_USER.INVENTORYに対して問合せを実行する場合、ルーティングされた問合せはターゲットAutonomous AI DatabaseインスタンスでSCOTTとして実行されます。したがって、SCOTTユーザーはルーター・インスタンスとターゲット・インスタンスの両方に存在する必要があります。

    両方のインスタンスに存在する以外に、現在のユーザー(たとえば、SCOTT)には、ルーターおよびターゲットのAutonomous AI Databaseインスタンスの両方で、マップされた表またはビューに対するSELECTなどの適切な権限が必要です。必要な権限が付与されていない場合、アクセス試行はエラーで失敗します。

  • ビュー所有者の要件: ルーティングされた問合せがビューを介して表またはビューにアクセスする場合、問合せはビュー所有者としてターゲット・インスタンスで実行されます。ビュー所有者はルーターとターゲットのAutonomous AI Databaseインスタンスの両方に存在する必要がありますが、問合せユーザーはルーター・インスタンスにのみ存在する必要があります。

    たとえば:

    CREATE OR REPLACE VIEW DW_USER.INVENTORY_VIEW AS
    SELECT ITEM_ID, ITEM_DESCRIPTION FROM DW_USER.INVENTORY;
    -- Connected as user SCOTT
SELECT ITEM_ID, ITEM_DESCRIPTION FROM DW_USER.INVENTORY_VIEW;

    この例では、SCOTTがDW_USER.INVENTORY_VIEWを問い合せると、問合せはターゲット・インスタンスでDW_USER (ビュー所有者)として実行されます。したがって、DW_USERは両方のインスタンスに存在する必要がありますが、SCOTTはルーター・インスタンスにのみ存在する必要があります。

  • ビュー所有者権限の要件: ビュー所有者(たとえば、DW_USER)は、ルート化された問合せがビュー所有者として正常に実行されるように、ルーターおよびターゲットのAutonomous AIデータベース・インスタンスの両方で、基礎となる表またはビューに対するSELECTなどの必要な権限を持っている必要があります。

コンテキスト認識のルーティング

ProxySQLルーティングでは、問合せ実行時に表のターゲットAutonomous AI Databaseインスタンスを動的に選択するメカニズムである、コンテキスト対応ルーティングがサポートされます。

表が複数のターゲットのAutonomous AI Databaseインスタンスにルーティングされる資格がある場合、最終的なルーティングの決定は、表の静的マッピングだけでなく、問合せの構造とコンテキストの影響も受けます。このような表が問合せの同じレベルで他のルーティング表とともに表示される場合(たとえば、同じ副問合せまたは結合句の場合) - ProxySQLルーティングでは、マッピング・ルールで許可されているかぎり、他の表と同じターゲットにルーティングすることをお薦めします。

これらのルールの適用後に、有効なターゲットAutonomous AI Databaseインスタンスがまだ複数存在する場合、ProxySQLルーティングでは、適格なターゲットの1つがランダムに選択されます。

たとえば、

SELECT e.name AS emp_name, d.name AS dept_name
FROM scott.emp e, scott.dept d
WHERE e.deptno = d.deptno;

この例では、SCOTT.EMPが複数のターゲットAutonomous AI DatabaseインスタンスT1にマップされ、T2.SCOTT.DEPTがターゲットAutonomous AI DatabaseインスタンスT2にのみマップされているとします。これは、SCOTT.EMPとSCOTT.DEPTが問合せの同じレベルで表示されるため、ProxySQLルーティングはSCOTT.EMPをT2にルーティングして、SCOTT.DEPTのルーティングと一致するようにします。SCOTT.EMPのこの動的ルーティングは、表が複数のターゲットに明示的にマップされている場合にのみ使用されます。SCOTT.EMPがどのターゲットAutonomous AI Databaseインスタンスにもマップされていない場合、ProxySQLルーティングは、ルーターAutonomous AI Databaseインスタンス自体でSCOTT.EMPの問合せを実行します。

別の例として、

WITH
  sub1 AS (
    SELECT a.c1 r1, b.c1 r2 FROM tab_dup a, tab2 b
  ),
  sub2 AS (
    SELECT a.c1 t1, b.c1 t2 FROM tab_dup a, tab1 b
  )
SELECT * FROM sub1, sub2 ORDER BY 1, 2, 3, 4;

前述の例では、TAB_DUPがT1にマップされ、T2.TAB2がT2.TAB1にのみルーティングされ、T1にのみルーティングされると想定します。副問合せサブ1では、TAB_DUPとTAB2が同じレベルで一緒に表示されるため、ProxySQLルーティングは、TAB_DUPをT2にルーティングして、TAB2と実行を同じ場所に配置します。サブクエリー・サブ2では、TAB_DUPはTAB1とともに表示され、T1にのみマップされるため、ProxySQLルーティングはTAB_DUPをT1にルーティングします。その結果、周囲の問合せコンテキストに応じて、TAB_DUPを同じ文の異なる部分の異なるターゲットにルーティングできます。

別の例として、

MERGE INTO tab1 t1
USING tab_dup t2
ON (t1.c1 = t2.c1)
WHEN MATCHED THEN
  UPDATE SET t1.c2 = t2.c2;

前述の例では、TAB_DUPがT1とT2の両方にマップされていると想定します。TAB1は、T1にのみマップされます。

ここで、AB1とTAB_DUPは、MERGE文で同じレベルで参照されます。したがって、ProxySQLルーティングは、TAB_DUPをT1にルーティングして、TAB1の場所と一致するようにします。T1に存在するTAB_DUPの行のみがMERGE操作に参加し、TAB1への更新はこれらの値に基づきます。

ProxySQLを使用した文ルーティングでアプリケーションの利点を提供できる場所

ProxySQLを使用した文のルーティングは、各SQL文がスキーマ・レベルまたはオブジェクト・レベルのマッピングを使用して単一のターゲットAutonomous AI Databaseインスタンスに決定的にマップできる場合に最も効果的です。

各SQL文を1つのターゲットに決定的にマップでき、文ルーティングを有効にすると、参照オブジェクトが存在する作業が実行されます。このパターンは、次のデータベース・アーキテクチャの問合せパフォーマンスに関して有益です。

  • スキーマごとのテナント/データベース・レイアウト

  • 地域パーティション

  • ドメイン境界をクリアします(たとえば、INVENTORYおよびBILLING)。

ProxySQLで文ルーティングを使用すると、データを物理的に統合することなく、単一のターゲットのAutonomous AI Databaseインスタンスの背後で非常に大規模なエステートをスケーリングできます。

分析で、異なるターゲット・データベースにマップされたオブジェクトを単一のアドホック問合せで結合する必要がある場合は、ProxySQLを使用した文のルーティングに依存するのではなく、補完的なアプローチを使用する必要があります。補完的な代替アプローチは次のとおりです。

  • 事前集計ビューまたはマテリアライズド・ビューの使用

  • マージ・ステップでのターゲットごとのジョブの使用

  • レポート・ストアの使用

次に、文ルーティングが適切であり、文ルーティングの使用が適切でないケースについて説明します。

  • 適切な例: アプリケーションにtenant_idが含まれ、各テナントのスキーマが独自のターゲットAutonomous AI DatabaseインスタンスにマップされるマルチテナントSaaSアプリケーション(object_name => '*'を使用したスキーマ・レベルのマッピング)。この場合、テナントに対するすべてのリクエストは、ルーターのマッピング表を介して透過的に右側のターゲットにルーティングされます。

  • 適切でない例: テナントが異なるターゲットにマップされるときに、「すべてのテナントを一度に結合」する1つのSQL文を発行するトップ・レベルのダッシュボード。文ルーティングでは文/オブジェクトが特定のターゲットにマップされるため、クロスターゲット結合を使用するアプリケーションまたはレポートは文のルーティングに適していません。このタイプのアプリケーションでは、複数のターゲットごとの問合せを実行し、結果をマージするか、かわりに統合レポート領域を提供する必要があります。

文のルーティングの有効化およびスキーマ・マッピングの定義

この項では、メイン・ルーターから1つ以上のターゲット・データベース・インスタンスへの自動文ルーティング用にProxySQLを設定する方法について説明します。

明細書ルーティングの有効化およびルーターからターゲット・インスタンスへのオブジェクト・マッピングの定義

文のルーティングを設定するには、ルーター・インスタンスでProxySQLを有効にし、文がターゲット・データベースにマップ(送信)されるスキーマを定義します。

自動明細書送付を有効にするための前提条件は次のとおりです。

  • ルーター・インスタンスに使用する予定のAutonomous AI Databaseインスタンスを作成するか、既存のAutonomous AI Databaseインスタンスをルーター・インスタンスとして識別します。

  • ターゲット・インスタンスを作成するか、既存のAutonomous AI Databaseインスタンスからターゲット・インスタンスを識別します。

  • ルーター・インスタンスと、問合せをリダイレクトするターゲット・インスタンスに、ルーターからターゲットにマッピングするオブジェクトと一致するメタデータがあることを確認します。

    使用するルーティング方法(マッピング)に関係なく、ターゲット・インスタンスに配置されたオブジェクトのメタデータもルーター・インスタンスで使用できるようにするのは、アプリケーション・スキーマ設計者の責任です。たとえば、ターゲット・インスタンスにEMPLOYEESという名前の表がある場合、ルーター・インスタンスにはEMPLOYEESという名前のメタデータと一致する表も必要です。ルータインスタンスのテーブルを空にする必要はありません。

  • 使用可能な選択肢から、使用する文ルーティングのタイプ(スキーマ・レベル・ルーティング、オブジェクト・レベル・ルーティングまたはハイブリッド・ルーティング)を決定します。

自動取引明細書送付を有効にし、ターゲット・マッピング・エントリをルーティング表に追加するには:

  1. Autonomous AI DatabaseインスタンスでDBMS_PROXY_SQL.ENABLE_ROUTINGを実行して、文の自動ルーティングを有効にします。

    たとえば:

    BEGIN
   DBMS_PROXY_SQL.ENABLE_ROUTING;
END;
/

    DBMS_PROXY_SQL.ENABLE_ROUTINGを実行するインスタンスがルーター・インスタンスになります。これにより、文の自動ルーティングが有効になり、ルーティング・テーブルが作成されます。

    詳細は、ENABLE_ROUTINGプロシージャを参照してください。

  2. DBMS_PROXY_SQL.ADD_MAPPINGを実行して、ルーターからターゲットへのマッピングを定義します。これにより、問合せが自動的にルーティングされるターゲット・インスタンスを指定するエントリがルーティング表に作成されます。

    オブジェクト・レベルのルーティングを有効にする例:

    BEGIN
 DBMS_PROXY_SQL.ADD_MAPPING (
    object_owner   => 'DW_USER',
    object_name    => 'INVENTORY',
    database_ocid  => '*TARGET1_DATABASE_OCID*');
END;
/

    スキーマ・レベルのルーティングを有効にする例:

    BEGIN
 DBMS_PROXY_SQL.ADD_MAPPING (
    object_owner   => 'DW_USER',
    object_name    => '*',
    database_ocid  => '*TARGET2_DATABASE_OCID*');
END;
/

    object_ownerパラメータは、オブジェクトの所有者を指定します。

    object_nameパラメータは、オブジェクトを指定します。

    database_ocidパラメータでは、ターゲット・インスタンスのOCIDを指定します。database_ocidパラメータ値は大文字にする必要があります。ターゲット・インスタンスのOCIDを確認するには、ADMINとしてターゲット・インスタンスに接続し、次の問合せを実行します。

    SELECT json_value(cloud_identity, '$.DATABASE_OCID') FROM v$pdbs;

    詳細は、テナンシ詳細の取得を参照してください。

    これにより、ルーティングテーブルにルーティングエントリが作成され、ターゲットインスタンスへのオブジェクトマッピングが定義されます。

    詳細は、ADD_MAPPINGプロシージャを参照してください。

  3. 必要に応じて、DBMS_PROXY_SQL.ADD_MAPPINGを実行してターゲット・マッピングを追加します。

    たとえば:

    BEGIN
 DBMS_PROXY_SQL.ADD_MAPPING (
    object_owner   => 'DW_USER_1',
    object_name    => 'CUSTOMERS',
    database_ocid  => '*TARGET3_DATABASE_OCID*');
END;
/

DBA_PROXY_SQL_MAPPINGSビューを問い合せて、ルーティング表内のレコードをリストできます。詳細は、DBA_PROXY_SQL_MAPPINGSビューを参照してください。

ターゲット・インスタンスでの文書ルーティングの受入

ルーター・インスタンスからのマッピングを許可するには、ターゲット・インスタンスで文ルーティングを受け入れる必要があります。

ルーター・インスタンスからターゲット・インスタンスへの(accept)文のリダイレクトを許可するには:

  1. ターゲット・インスタンスでDBMS_PROXY_SQL.ACCEPT_MAPPINGを実行します。

    次に例を示します。

    BEGIN
 DBMS_PROXY_SQL.ACCEPT_MAPPING (
    object_owner          => 'DW_USER',
    router_database_ocid  => '*ROUTER_DATABASE_OCID*');
 END;
/

    object_ownerは、ターゲットが文のルーティングを受け入れる所有者です。

    router_database_ocidは、ルーターのAutonomous AI DatabaseインスタンスのOCIDを指定します。これは、ターゲットが受信リダイレクトされた文リクエストを受け入れるインスタンスを指定します。

    受入れマッピングはオブジェクト所有者ごとに1つであるため、ルータインスタンス上の複数のオブジェクトマッピングに対応する受入れは1つだけ必要になる場合があります。

    文DBMS_PROXY_SQL_ACCEPTED_MAPPINGSビューを使用して、受入表のレコードをリストできます。詳細は、「DBA_PROXY_SQL_ACCEPTED_MAPPINGSビュー」を参照してください。

    詳細は、ACCEPT_MAPPINGプロシージャを参照してください。

  2. ルーター・マッピングに複数のターゲットが指定されている場合は、各ターゲットでDBMS_PROXY_SQL.ACCEPT_MAPPINGを実行します。

    詳細は、ACCEPT_MAPPINGプロシージャを参照してください。

ProxySQLを使用した文の発行

自動文ルーティングを利用するには、ProxySQLによって管理されるルーター・インスタンスに接続し、文を送信する必要があります。

ProxySQLを有効にして問合せおよびDMLを送信する場合は、自動文ルーティングを利用するためにルーター・インスタンスに接続する必要があります。

ターゲット・インスタンスへの文のルーティングの停止

ターゲットAutonomous AI Databaseで次のステップを実行して、ProxySQLルーターからのルーティングされた文の受入れを停止させます。

  1. ターゲット・インスタンスでDBMS_PROXY_SQL.REJECT_MAPPINGを実行して、指定した所有者の文ルーティングを拒否します。

    次に例を示します。

    BEGIN
 DBMS_PROXY_SQL.REJECT_MAPPING (
    object_owner          => 'DW_USER',
    router_database_ocid  => *'ROUTER_DATABASE_OCID'*);
 END;
/

    object_ownerパラメータは、所有者名を指定します。

    router_database_ocidパラメータでは、ルーター・インスタンスのOCIDを指定します。

    このプロシージャを実行するターゲットAutonomous AI Databaseインスタンスは、指定されたオブジェクト所有者の指定されたルーター・インスタンスからのルーティング・リクエストを要求しなくなりました。

  2. 必要に応じて、追加のターゲットでDBMS_PROXY_SQL.REJECT_MAPPINGを実行します。

詳細は、REJECT_MAPPINGプロシージャを参照してください。

ルーター・インスタンスからのスキーマまたはオブジェクト・マッピングの削除

ProxySQLによって管理されるルーター・データベースから特定のマッピングを削除するステップを示します。

  1. DBMS_PROXY_SQL.REMOVE_MAPPINGプロシージャを使用して、指定したオブジェクトの以前に追加されたマッピング・エントリを削除できます。次に例を示します。

    次の表の例:

    BEGIN
 DBMS_PROXY_SQL.REMOVE_MAPPING (
    object_owner   => 'DW_USER',
    object_name    => 'INVENTORY');
 END;
/

    この例では、ルーティング表からINVENTORY表のマッピング・エントリを削除します。このプロシージャの実行後、INVENTORY表に対する問合せは、どのターゲットAutonomous AIデータベースにもルーティングされません。

    例: スキーマの場合:

    BEGIN
 DBMS_PROXY_SQL.REMOVE_MAPPING (
    object_owner   => 'DW_USER',
    object_name    => '*');
 END;
/

    この例では、DW_USERスキーマのマッピング・エントリをルーティング表から削除します。このプロシージャを実行すると、DW_USERスキーマに対する問合せは、どのターゲットAutonomous AIデータベースにもルーティングされません。

    object_ownerパラメータは、所有者を指定します。

    object_nameパラメータは、表名を指定します。

    詳細は、REMOVE_MAPPINGプロシージャを参照してください。

取引明細書送付の無効化

ProxySQLを無効にして文を自動ルーティングするステップを示します。

ルーター・インスタンスでDBMS_PROXY_SQL.DISABLE_ROUTINGを実行して、ProxySQLを無効にし、ターゲット・インスタンスへの自動文ルーティングを無効にします。

次に例を示します。

BEGIN
 DBMS_PROXY_SQL.DISABLE_ROUTING;
END;
/

これにより、ProxySQLが無効になり、ルーターの自動文ルーティングが無効になります。

ProxySQLを無効にしても、ルーター・インスタンスのルーティング表内の文マッピング・エントリは削除されません。これは、ProxySQLを再度有効にし、ルーティング表に既存のエントリがある場合、ルーティング表で指定されているように、文の自動ルーティングによって文がターゲット・インスタンスにルーティングされることを意味します。ProxySQLを再度有効にする前に既存のルーティング表エントリを削除する場合は、プロシージャDBMS_PROXY_SQL.REMOVE_MAPPINGを使用します。

詳細は、DISABLE_ROUTINGプロシージャを参照してください。

ProxySQLノートによる自動文ルーティング

ProxySQLが有効な場合の自動文のルーティングに関する制限事項と重要なノートを示します。

  • ADMINユーザーには、ProxySQLを管理する権限があります。別のユーザーを有効にする場合は、次の権限を付与する必要があります。

    • DBMS_PROXY_SQLパッケージに対するEXECUTE権限。

    • DBA_PROXY_SQL_MAPPINGSビューに対するREAD権限。

    • DBA_PROXY_SQL_ACCEPTED_MAPPINGSビューに対するREAD権限。

  • 自動明細書送付は、次の場合にシームレスに再開されます。

    • ターゲットAutonomous AI Databaseインスタンスは、ローカルのAutonomous Data Guardスタンバイにフェイルオーバーします。

    • ターゲットAutonomous AI DatabaseインスタンスのローカルAutonomous Data Guardスタンバイへのスイッチオーバーを実行します。

    ただし、クロス・リージョンAutonomous Data Guardスタンバイ・データベースへのフェイルオーバーまたはスイッチオーバー後に、自動文のルーティングが停止します。