機械翻訳について

Autonomous AI DatabaseでProxySQLを有効にして効率的な文ルーティングを使用

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

トピック

親トピック: Autonomous AI Databaseのエラスティック・プールによるコストの最適化

Autonomous AI DatabaseでのProxySQLを使用した効率的な文のルーティングについて

Autonomous AI Database上のProxySQLを使用すると、複数のAutonomous AI Databaseインスタンスを使用でき、1つの場所に格納されたかのように、データに簡単にアクセスして分析できます。

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

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

選択したルーティング・メソッドに応じて、ステートメントはルーター・インスタンスから1つ以上のターゲット・インスタンスに自動的にマップされます。 アプリケーションはルーター・インスタンスに接続し、ルーター・インスタンスで実行し、Autonomous AI Databaseは文を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つのスキーマの文は複数のターゲット・インスタンス間でマップできません。つまり、同じスキーマをスキーマ・ルーティングとオブジェクト・ルーティングの両方に使用することはできません。

    スキーマ・レベルのルーティングを指定するには、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 Databaseインスタンスに存在し、同じ名前で同じスキーマ内にある表またはビューのみをルーティング表に含めることができます。

    たとえば:
    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 Databaseインスタンスの両方で、基礎となる表またはビューに対するSELECTなどの必要な権限を持っている必要があります。これにより、ルーティングされた問合せがビュー所有者として正常に実行されるようになります。

親トピック: Autonomous AI DatabaseでProxySQLを有効にして効率的な文ルーティングを使用

コンテキスト対応ルーティング

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のみであると想定します。 副問合せsub1では、TAB_DUPとTAB2は同じレベルで一緒に表示されるため、ProxySQLルーティングは、TAB_DUPをT2にルーティングして、TAB2と同時に実行を検索します。 副問合せsub2では、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への更新はこれらの値に基づきます。

親トピック: Autonomous AI DatabaseでProxySQLを有効にして効率的な文ルーティングを使用

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

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

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

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

  • リージョナル・パーティション

  • ドメイン境界のクリア(INVENTORYやBILLINGなど)

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

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

  • 事前集計ビューまたはマテリアライズド・ビューの使用
  • マージ・ステップでのターゲットごとのジョブの使用
  • レポート・ストアの使用

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

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

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

親トピック: Autonomous AI DatabaseでProxySQLを有効にして効率的な文ルーティングを使用

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

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

親トピック: Autonomous AI Databaseで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を有効にして効率的な文ルーティングを使用

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

ターゲットの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プロシージャ」を参照してください。

親トピック: Autonomous AI DatabaseでProxySQLを有効にして効率的な文ルーティングを使用

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

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 Databaseにもルーティングされません。

    例: スキーマの場合:

    BEGIN
 DBMS_PROXY_SQL.REMOVE_MAPPING ( 
    object_owner   => 'DW_USER',
    object_name    => '*');
 END;
/
    この例では、ルーティング表からDW_USERスキーマのマッピング・エントリを削除します。 このプロシージャを実行すると、DW_USERスキーマに対する問合せは、どのターゲットAutonomous AI Databaseにもルーティングされません。

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

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

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

親トピック: Autonomous AI DatabaseでProxySQLを有効にして効率的な文ルーティングを使用

文のルーティングの無効化

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プロシージャ」を参照してください。

親トピック: Autonomous AI DatabaseでProxySQLを有効にして効率的な文ルーティングを使用

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スタンバイ・データベースへのフェイルオーバーまたはスイッチオーバー後に停止します。

親トピック: Autonomous AI DatabaseでProxySQLを有効にして効率的な文ルーティングを使用