日本語PDF

32 分散データベースの管理

分散データベースの管理には、グローバル名の管理、データベース・リンクの管理、位置および文の透過性の作成などのタスクが含まれます。

32.1 分散システムでのグローバル名の管理

分散データベース・システムでは、各データベースが一意のグローバル・データベース名を持ちます。グローバル・データベース名は、システム内のデータベースを一意に識別します。分散データベースでの主な管理作業として、グローバル・データベース名の作成と変更の管理があります。

32.1.1 グローバル・データベース名の書式の理解

グローバル・データベース名は、データベース名とドメインの2つの構成要素から構成されます。

データベース名とドメイン名は、データベースの作成時に次の初期化パラメータによって決まります。

コンポーネント パラメータ 要件

データベース名

DB_NAME

30文字以下である必要があります。

sales

データベースが存在するドメイン

DB_DOMAIN

インターネットの標準規則に従う必要があります。ドメイン名のレベルはドットで区切る必要があり、ドメイン名の順序は、左から右に向かってリーフからルートの順になります。

us.example.com

次に、有効なグローバル・データベース名の例を示します。

DB_NAME DB_DOMAIN グローバル・データベース名

sales

example.com

sales.example.com

sales

us.example.com

sales.us.example.com

mktg

us.example.com

mktg.us.example.com

payroll

example.org

payroll.example.org

DB_DOMAIN初期化パラメータが重要になるのは、データベースの作成時に、この初期化パラメータを(DB_NAMEパラメータと一緒に)使用して、データベースのグローバル名を構成するときだけです。この時点で、データベースのグローバル名はデータ・ディクショナリに格納されます。グローバル名を変更するには、初期化パラメータ・ファイル内のDB_DOMAINパラメータを変更するのではなくALTER DATABASE 文を使用する必要があります。ただし、次回のデータベースの起動を行う前にDB_DOMAINパラメータを変更してドメイン名の変更を反映することをお薦めします。

32.1.2 グローバル・ネーミング施行の判断

ローカル・データベースのリンクに付ける名前は、ローカル・データベースがグローバル・ネーミングを施行するかどうかによって異なります。

ローカル・データベースがグローバル・ネーミングを施行する場合は、リモート・データベースのグローバル・データベース名をリンクの名前として使用する必要があります。たとえば、ローカルのhqサーバーに接続していて、リモートのmfgデータベースへのリンクを作成する場合は、ローカル・データベースがグローバル・ネーミングを施行していれば、mfgのグローバル・データベース名をリンク名として使用する必要があります。

データベース・リンク名の一部としてサービス名を使用することもできます。たとえば、サービス名sn1およびsn2を使用してデータベースhq.example.comに接続する場合、グローバル・ネーミングが施行されていれば、次のようなhqへのリンク名を作成できます。

グローバル・ネーミングがデータベースで施行されているかどうかを判断するには、データベースの初期化パラメータ・ファイルを調べるか、またはV$PARAMETERビューを問い合せます。たとえば、mfgでグローバル・ネーミングが施行されているかどうかを判断するには、mfgのセッションを開始して、次のglobalnames.sqlスクリプトを作成し、実行できます(出力例も含まれています)。

COL NAME FORMAT A12
COL VALUE FORMAT A6
SELECT NAME, VALUE FROM V$PARAMETER
   WHERE NAME = 'global_names'
/

SQL> @globalnames

NAME         VALUE
------------ ------
global_names FALSE

32.1.3 グローバル・データベース名の参照

データベースのグローバル名を参照するには、データ・ディクショナリ・ビューGLOBAL_NAMEを使用します。

たとえば、次の文を発行します。

SELECT * FROM GLOBAL_NAME;

GLOBAL_NAME
-------------------------------------------------------------------------------
SALES.EXAMPLE.COM

32.1.4 グローバル・データベース名のドメインの変更

データベースのグローバル名のドメインを変更するには、ALTER DATABASE文を使用します。

データベースを作成した後に初期化パラメータDB_DOMAINを変更しても、グローバル・データベース名やデータベース・リンク名の解決には効果がありません。

次の例は、名前変更文の構文を示しています。ここで、databaseはデータベース名、domainはネットワーク・ドメインを表します。

ALTER DATABASE RENAME GLOBAL_NAME TO database.domain;

グローバル・データベース名のドメインを変更するには、次の手順を実行します。

  1. 現行のグローバル・データベース名を確認します。たとえば、次のように入力します。
    SELECT * FROM GLOBAL_NAME;
    
    GLOBAL_NAME
    ----------------------------------------------------------------------------
    SALES.EXAMPLE.COM
    
  2. ALTER DATABASE文を使用して、グローバル・データベース名を変更します。たとえば、次のように入力します。
    ALTER DATABASE RENAME GLOBAL_NAME TO sales.us.example.com;
    
  3. GLOBAL_NAME表を問い合せて、新しい名前を確認します。たとえば、次のように入力します。
    SELECT * FROM GLOBAL_NAME;
    
    GLOBAL_NAME
    ----------------------------------------------------------------------------
    SALES.US.EXAMPLE.COM

32.1.5 グローバル・データベース名の変更: 使用例

グローバル・データベース名の変更を示すシナリオです。

この例では、ローカル・データベースのグローバル・データベース名のドメイン部分を変更します。また、部分指定のグローバル名を使用してデータベース・リンクを作成し、Oracle Databaseがその名前をどのように解決するのかを調べます。データベースは、初期化パラメータDB_DOMAINの値ではなく、ローカル・データベースの現行のグローバル・データベース名のドメイン部分を使用して部分名を解決することがわかります。

  1. SALES.US.EXAMPLE.COMに接続してGLOBAL_NAMEデータ・ディクショナリ・ビューを問い合せ、現行のデータベース・グローバル名を確認します。
    CONNECT SYSTEM@sales.us.example.com
    SELECT * FROM GLOBAL_NAME;
    
    GLOBAL_NAME
    ---------------------------------------------------------------------------- 
    SALES.US.EXAMPLE.COM
    
  2. V$PARAMETERビューを問い合せ、DB_DOMAIN初期化パラメータの現在の設定を調べます。
    SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME = 'db_domain'; 
    
    NAME       VALUE
    ---------  -----------
    db_domain  US.EXAMPLE.COM 
    
  3. 部分指定のグローバル名のみを使用して、hqデータベースへのデータベース・リンクを作成します。
    CREATE DATABASE LINK hq USING 'sales'; 
    

    データベースは、リンクで指定されたデータベース名にローカル・データベースのグローバル・データベース名のドメイン部分を追加して、このリンクのグローバル・データベース名を拡張します。

  4. USER_DB_LINKSを問い合せて、データベースが部分指定のグローバル・データベース名を解決するために使用したドメイン名を確認します。
    SELECT DB_LINK FROM USER_DB_LINKS; 
    
    DB_LINK
    ------------------
    HQ.US.EXAMPLE.COM
    

    この結果は、ローカル・データベースのグローバル・データベース名のドメイン部分がus.example.comであることを示しています。データベースは、データベース・リンク作成時の部分的なデータベース・リンク名を解決するために、このドメインを使用します。

  5. salesデータベースが日本に移動するという通知を受けたので、salesデータベースをsales.jp.example.comに変更します。
    ALTER DATABASE RENAME GLOBAL_NAME TO sales.jp.example.com;
    SELECT * FROM GLOBAL_NAME; 
    
    GLOBAL_NAME
    ---------------------------------------------------------------------------- 
    SALES.JP.EXAMPLE.COM
    
  6. 再度V$PARAMETERを問い合せて、グローバル・データベース名のドメイン部分の名前を変更しても、DB_DOMAINの値が変更されていないことを確認します。
    SELECT NAME, VALUE FROM V$PARAMETER 
      WHERE NAME = 'db_domain'; 
    
    NAME       VALUE
    ---------  -----------
    db_domain  US.EXAMPLE.COM 
    

    この結果は、DB_DOMAIN初期化パラメータの値がALTER DATABASE RENAME GLOBAL_NAME文とは関係がないことを示しています。ALTER DATABASE文は、DB_DOMAIN初期化パラメータではなく、グローバル・データベース名のドメインを決定します(それでも、新しいドメイン名が反映されるようにDB_DOMAINを変更することには意味があります)。

  7. データベースsupplyへの別のデータベース・リンクを作成してから、USER_DB_LINKSを問い合せて、データベースがsupplyのグローバル・データベース名のドメイン部分をどのように解決するのかを確認します。
    CREATE DATABASE LINK supply USING 'supply'; 
    SELECT DB_LINK FROM USER_DB_LINKS; 
    
    DB_LINK
    ------------------
    HQ.US.EXAMPLE.COM 
    SUPPLY.JP.EXAMPLE.COM
    

    この結果は、データベースがドメインjp.example.comを使用して、部分指定のリンク名を解決していることを示しています。このドメインは、ローカル・データベースのグローバル・データベース名のドメイン部分であることから、リンクを作成するときに使用されています。データベースは部分的なリンク名を解決するときに、DB_DOMAIN初期化パラメータの設定は使用しません

  8. 次に、前の情報が誤りで、salesjp.example.comドメインではなくasia.jp.example.comドメインにあるという通知を受けました。そのため、グローバル・データベース名を次のように変更します。
    ALTER DATABASE RENAME GLOBAL_NAME TO sales.asia.jp.example.com; 
    SELECT * FROM GLOBAL_NAME; 
    
    GLOBAL_NAME
    ---------------------------------------------------------------------------- 
    SALES.ASIA.JP.EXAMPLE.COM
    
  9. 再びV$PARAMETERを問い合せて、パラメータDB_DOMAINの設定を確認します。
    SELECT NAME, VALUE FROM V$PARAMETER 
      WHERE NAME = 'db_domain'; 
    
    NAME        VALUE
    ----------  -----------
    db_domain   US.EXAMPLE.COM 
    

    この結果は、パラメータ・ファイル内のドメイン設定が、2つのALTER DATABASE RENAME文の発行前の時点の設定と同じであることを示しています。

  10. 最後に、warehouseデータベースへのリンクを作成し、再度USER_DB_LINKSを問い合せて、データベースが部分指定のグローバル名をどのように解決するのかを調べます。
    CREATE DATABASE LINK warehouse USING 'warehouse'; 
    SELECT DB_LINK FROM USER_DB_LINKS; 
    
    DB_LINK
    ------------------
    HQ.US.EXAMPLE.COM 
    SUPPLY.JP.EXAMPLE.COM
    WAREHOUSE.ASIA.JP.EXAMPLE.COM
    

    ここでもデータベースは、リンクの作成時にローカル・データベースのグローバル・データベース名のドメイン部分を使用して、部分的なリンク名を拡張していることがわかります。

    ノート:

    supplyデータベース・リンクを訂正するには、必ずこのデータベース・リンクを削除してから再作成してください。

    関連項目:

32.2 データベース・リンクの作成

アプリケーションによるデータおよびスキーマ・オブジェクトへのアクセスを分散データベース・システム全体にわたってサポートするために、必要なデータベース・リンクをすべて作成する必要があります。

32.2.1 データベース・リンクの作成に必要な権限の取得

データベース・リンクは、リモート・データベースのオブジェクトへのアクセスを可能にするローカル・データベース内のポインタです。プライベート・データベース・リンクを作成するには、あらかじめ適切な権限が付与されている必要があります。

次の表は、どのリンク・タイプのデータベースに対してどの権限が必要なのかを示しています。

権限 データベース この権限を必要とする操作

CREATE DATABASE LINK

ローカル

プライベート・データベース・リンクの作成。

CREATEPUBLICDATABASELINK

ローカル

パブリック・データベース・リンクの作成。

CREATE SESSION

リモート

任意タイプのデータベース・リンクの作成。

現在使用可能な権限を確認するには、ROLE_SYS_PRIVSを問い合せます。たとえば、次のprivs.sqlスクリプトを作成し、実行できます(出力例も含まれています)。

SELECT DISTINCT PRIVILEGE AS "Database Link Privileges"
FROM ROLE_SYS_PRIVS
WHERE PRIVILEGE IN ( 'CREATE SESSION','CREATE DATABASE LINK',
                     'CREATE PUBLIC DATABASE LINK')
/

SQL> @privs

Database Link Privileges
----------------------------------------
CREATE DATABASE LINK
CREATE PUBLIC DATABASE LINK
CREATE SESSION

32.2.2 リンク・タイプの指定

データベース・リンクを作成するときは、そのデータベース・リンクにアクセスするユーザーを決める必要があります。

32.2.2.1 プライベート・データベース・リンクの作成

プライベート・データベース・リンクを作成するには、CREATE DATABASE LINK文を使用します。

プライベート・データベース・リンクを作成するには、次の文を指定します。ここで、link_nameはグローバル・データベース名または任意のリンク名を表します。

CREATE DATABASE LINK link_name ...;

プライベート・データベース・リンクの例を次に示します。

SQL文 結果

CREATE DATABASE LINK supply.us.example.com;

リモートのsupplyデータベースへの、グローバル・データベース名を使用したプライベート・リンク。

リンクは、接続ユーザーのユーザーID/パスワードを使用します。そのため、scott(パスワード: password)が問合せの中でこのリンクを使用すると、リモート・データベースへの接続がscott/passwordとして確立されます。

CREATE DATABASE LINK link_2 CONNECT TO jane IDENTIFIED BY password USING 'us_supply';

サービス名us_supplyを持つデータベースへの、link_2という名前のプライベート固定ユーザー・リンク。このリンクは、接続ユーザーとは無関係に、jane/passwordというユーザーID/パスワードでリモート・データベースに接続します。

CREATE DATABASE LINK link_1 CONNECT TO CURRENT_USER USING 'us_supply';

サービス名us_supplyを持つデータベースへの、link_1という名前のプライベート・リンク。このリンクは、現行ユーザーのユーザーID/パスワードを使用してリモート・データベースにログインします。

ノート: 現行ユーザーと接続ユーザーは異なる場合があります。また、現行ユーザーは、リンクに関係している両方のデータベースのグローバル・ユーザーであることが必要です(「データベース・リンクのユーザー」を参照)。現行ユーザー・リンクは、Oracle Advanced Securityオプションの一部です。

関連項目:

CREATE DATABASE LINKの構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

32.2.2.2 パブリック・データベース・リンクの作成

パブリック・データベース・リンクを作成するには、CREATE PUBLIC DATABASE LINK文を使用します。

パブリック・データベース・リンクを作成するには、キーワードPUBLICを使用します。ここで、link_nameはグローバル・データベース名または任意のリンク名を表します。

CREATE PUBLIC DATABASE LINK link_name ...;

パブリック・データベース・リンクの例を次に示します。

SQL文 結果

CREATE PUBLIC DATABASE LINK supply.us.example.com;

リモートのsupplyデータベースへのパブリック・リンク。リンクは、接続ユーザーのユーザーID/パスワードを使用します。そのため、scott(パスワード: password)が問合せの中でこのリンクを使用すると、リモート・データベースへの接続がscott/passwordとして確立されます。

CREATE PUBLIC DATABASE LINK pu_link CONNECT TO CURRENT_USER USING 'supply';

サービス名supplyを持つデータベースへの、pu_linkという名前のパブリック・リンク。このリンクは、現行ユーザーのユーザーID/パスワードを使用してリモート・データベースにログインします。

ノート: 現行ユーザーと接続ユーザーは異なる場合があります。また、現行ユーザーは、リンクに関係している両方のデータベースのグローバル・ユーザーであることが必要です(「データベース・リンクのユーザー」を参照)。

CREATE PUBLIC DATABASE LINK sales.us.example.com CONNECT TO jane IDENTIFIED BY password;

リモートのsalesデータベースへのパブリック固定ユーザー・リンク。このリンクは、jane/passwordというユーザーID/パスワードでリモート・データベースに接続します。

関連項目:

CREATE PUBLIC DATABASE LINKの構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

32.2.2.3 グローバル・データベース・リンクの作成

データベースがネット・サービス名によって識別されるディレクトリ・サーバーを使用できます。このマニュアルでは、ディレクトリ・サーバーでのネット・サービス名によるデータベースの識別をグローバル・データベース・リンクと呼びます。

グローバル・データベース・リンクとして動作するディレクトリ・エントリの作成方法を学習するには、『Oracle Database Net Services管理者ガイド』を参照してください。

32.2.3 リンク・ユーザーの指定

データベース・リンクは、あるデータベースから別のデータベースへの通信経路を定義します。アプリケーションがデータベース・リンクを使用してリモート・データベースに接続するとき、Oracle Databaseはローカル・アプリケーションの要求にかわってリモート・データベース内でデータベース・セッションを確立します。プライベートまたはパブリックのデータベース・リンクを作成する際、固定ユーザー、現行ユーザーおよび接続ユーザーのデータベース・リンクを作成することで、リモート・データベースのどのスキーマにリンクが接続を確立するのかを指定できます。

32.2.3.1 固定ユーザー・データベース・リンクの作成

アプリケーションで固定ユーザー・データベース・リンクを使用するとき、ローカル・サーバーは必ずリモート・データベース内の固定リモート・スキーマへの接続を確立します。また、ローカル・サーバーはアプリケーションがリンクを使用してリモート・データベースにアクセスするときに、ネットワークを介して固定ユーザーの資格証明を送信します。

固定ユーザー・データベース・リンクを作成するには、リモート・データベースへのアクセスに必要な資格証明(この場合はユーザー名とパスワード)をリンク定義に埋め込みます。

CREATE DATABASE LINK ... CONNECT TO username IDENTIFIED BY password ...;

固定ユーザー・データベース・リンクの例を次に示します。

SQL文 結果

CREATE PUBLIC DATABASE LINK supply.us.example.com CONNECT TO scott IDENTIFIED BY password;

リモートのsupplyデータベースへの、グローバル・データベース名を使用したパブリック・リンク。このリンクは、scott/passwordというユーザーID/パスワードでリモート・データベースに接続します。

CREATE DATABASE LINK foo CONNECT TO jane IDENTIFIED BY password USING 'finance';

サービス名financeを持つデータベースへの、fooという名前のプライベート固定ユーザー・リンク。このリンクは、jane/passwordというユーザーID/パスワードでリモート・データベースに接続します。

32.2.3.2 接続ユーザーおよび現行ユーザー・データベース・リンクの作成

接続ユーザーおよび現行ユーザー・データベース・リンクでは、リンク定義に資格証明が含まれません。リモート・データベースへの接続に使用する資格証明は、データベース・リンクを参照するユーザーや、アプリケーションが実行する操作によって異なります。

ノート:

多くの分散アプリケーションでは、ユーザーがリモート・データベースでの権限を持つ必要はありません。これを実現する簡単な方法の1つは、固定ユーザーまたは現行ユーザーのデータベース・リンクを含むプロシージャを作成することです。この方法では、プロシージャにアクセスするユーザーに対して第三者の権限が一時的に付与されます。

32.2.3.2.1 接続ユーザー・データベース・リンクの作成

接続ユーザー・データベース・リンクを作成するには、CREATE DATABASE LINK文のCONNECT TO句を省略します。

次の構文は、接続ユーザー・データベース・リンクを作成し、ここでdblinkはリンクの名前、net_service_nameはオプションの接続文字列を表します。

CREATE [SHARED] [PUBLIC] DATABASE LINK dblink ... [USING 'net_service_name'];

たとえば、接続ユーザー・データベース・リンクを作成するために、次の構文を使用します。

CREATE DATABASE LINK sales.division3.example.com USING 'sales';
32.2.3.2.2 現行ユーザー・データベース・リンクの作成

現行ユーザー・データベース・リンクを作成するには、CREATE DATABASE LINK文でCONNECT TO CURRENT_USER句を使用します。

現行ユーザー・リンクは、Oracle Advanced Securityオプションでのみ使用できます。

次の構文は、現行ユーザー・データベース・リンクを作成します。ここで、dblinkはリンクの名前、net_service_nameはオプションの接続文字列を表します。

CREATE [SHARED] [PUBLIC] DATABASE LINK dblink CONNECT TO CURRENT_USER 
[USING 'net_service_name'];

たとえば、salesデータベースへの現行ユーザー・データベース・リンクを作成するには、次の構文を使用します。

CREATE DATABASE LINK sales CONNECT TO CURRENT_USER USING 'sales';

ノート:

現行ユーザー・データベース・リンクを使用するには、リンクに関係している両方のデータベースで現行ユーザーがグローバル・ユーザーであることが必要です。

関連項目:

データベース・リンクの作成に関する構文情報の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

32.2.4 リンク名に含まれるサービス名を指定するための接続修飾子の使用

場合によっては、同じリモート・データベースを指すものの、異なる通信経路を使用してリモート・データベースへの接続を確立する同じタイプ(パブリックなど)のデータベース・リンクを複数作成する必要があります。

次のような場合に、この方法が役立ちます。

  • リモート・データベースがOracle Real Application Clusters構成の一部であり、そのためリモート・データベースの特定のインスタンスに接続を確立できるようにローカル・ノードで複数のパブリック・データベース・リンクを定義する場合。

  • Oracle Databaseサーバーへの接続に、TCP/IPを使用するクライアントと、DECNETを使用するクライアントがある場合。

このような機能を容易にするため、データベースでは、データベース・リンクにオプションのサービス名を付加したデータベース・リンク名を作成できます。データベース・リンクを作成するときに、サービス名を@記号で区切って(たとえば、@sales)、データベース・リンク名の末尾の部分として指定します。この文字列は接続修飾子と呼ばれます。

たとえば、リモート・データベースhq.example.comがOracle Real Application Clusters環境で管理されているとします。hqデータベースには、hq_1およびhq_2という名前の2つのインスタンスがあります。ローカル・データベースで次のパブリック・データベース・リンクを作成して、hqデータベースのリモート・インスタンスへの経路を定義できます。

CREATE PUBLIC DATABASE LINK hq.example.com@hq_1
  USING 'string_to_hq_1';
CREATE PUBLIC DATABASE LINK hq.example.com@hq_2
  USING 'string_to_hq_2';
CREATE PUBLIC DATABASE LINK hq.example.com
  USING 'string_to_hq';

最初の2つの例では、サービス名は単なるデータベース・リンク名の一部であることに注目してください。サービス名のテキストは必ずしも接続の確立方法を示しているわけではないため、この情報はUSING句のサービス名で指定されています。また、3番目の例では、サービス名がリンク名の一部として指定されていないことに注目してください。この場合も、サービス名がリンク名の一部として指定されたときと同じように、インスタンスはUSING文字列によって決定されます。

サービス名を使用して特定のインスタンスを指定するには、サービス名をグローバル・オブジェクト名の末尾に付けます。

SELECT * FROM scott.emp@hq.example.com@hq_1

この例では、2つのアットマーク(@)があることに注意してください。

32.3 共有データベース・リンクの使用

標準のデータベース・リンクを使用してリモート・サーバーを参照するアプリケーションはすべて、ローカル・データベースとリモート・データベースの間で接続を確立します。多くのユーザーがアプリケーションを同時に実行した場合、ローカル・データベースとリモート・データベースの間で多数の接続が発生する可能性があります。共有データベース・リンクを使用すると、ローカル・サーバーとリモート・サーバーの間で必要なネットワーク接続の数を制限できます。

関連項目:

共有データベース・リンクの概念の概要は、「共有データベース・リンクの概要」

32.3.1 共有データベース・リンクの使用の判断

アプリケーションおよび共有サーバーの構成を綿密に検討して、共有リンクを使用するかどうかを判断してください。簡単なガイドラインとして、データベース・リンクにアクセスするユーザー数がローカル・データベース内のサーバー・プロセス数よりもかなり多いと予測されるときは、共有データベース・リンクを使用します。

データベース・リンクに関して可能な3つの構成を次の表に示します。

リンク・タイプ サーバー・モード 影響

非共有

専用/共有サーバー

アプリケーションで標準のパブリック・データベース・リンクを使用していて、100人のユーザーが同時に接続を要求した場合は、リモート・データベースへの直接ネットワーク接続が100必要になります。

共有

共有サーバー

ローカルの共有サーバー・モード・データベースに10の共有サーバー・プロセスが存在している場合、同じデータベース・リンクを使用するユーザーが100人いるときに必要となるリモート・サーバーへのネットワーク接続数は10以下になります。ローカルの各共有サーバー・プロセスが必要とするリモート・サーバーへの接続は、それぞれ1つで済む場合があります。

共有

専用

10のクライアントがローカルの専用サーバーに接続していて、各クライアントが同じ接続のセッションを10持っており(したがって全部で100のセッションを確立している)、各セッションで同じリモート・データベースを参照している場合、必要な接続は10で済みます。非共有データベース・リンクでは、100の接続が必要になります。

共有データベース・リンクは、必ずしもすべての状況で役立つとはかぎりません。たとえば、リモート・サーバーに接続するユーザーが1人のみの場合を考えます。このユーザーが共有データベース・リンクを定義し、ローカル・データベースに10個の共有サーバー・プロセスが存在する場合、このユーザーはリモート・サーバーへのネットワーク接続を最大10個必要とする可能性があります。ユーザーは個々の共有サーバー・プロセスを使用できるため、各プロセスはそれぞれリモート・サーバーへの接続を確立できます。

この場合、ネットワーク接続は1つしか必要ないため、明らかに非共有データベース・リンクの方が適しています。シングルユーザー環境では、共有データベース・リンクの使用はネットワーク接続の増加につながるため、共有リンクは、複数のユーザーが同じリンクを使用する必要がある場合にのみ使用します。通常、共有リンクはパブリック・データベース・リンクに使用しますが、複数のクライアントが同じローカル・スキーマにアクセスする場合(その結果、同じプライベート・データベース・リンクにアクセスする場合)はプライベート・データベース・リンクにも使用できます。

ノート:

複数階層の環境では、共有データベース・リンクを使用してリモート・データベースに接続した場合、そのリモート・データベースは、移行不可能なデータベース・リンクを使用して別のデータベースにリンクできないという制約があります。このリンクには共有サーバーを使用するか、またはリンク自体が別の共有データベース・リンクである必要があります。

32.3.2 共有データベース・リンクの作成

共有データベース・リンクを作成するには、CREATE DATABASE LINK文でキーワードSHAREDを使用します。

共有データベース・リンクを作成するには、次の構文を使用します。

CREATE SHARED DATABASE LINK dblink_name
[CONNECT TO username IDENTIFIED BY password]|[CONNECT TO CURRENT_USER]
AUTHENTICATED BY schema_name IDENTIFIED BY password
[USING 'service_name'];

キーワードSHAREDを使用するときは、必ずAUTHENTICATED BY句が必要です。AUTHENTICATED BYで指定されたスキーマがリモート・データベースに存在し、少なくとも、CREATE SESSION権限が付与されている必要があります。このスキーマの資格証明は、ローカル・データベースとリモート・データベース間での認証方式と考えることができます。これらの資格証明は、データベース・リンクのユーザーになりすまして情報に不当にアクセスしようとするクライアントから、リモート共有サーバー・プロセスを保護するために必要です。

共有データベース・リンクとの接続後、リモート・データベース上での操作は、AUTHENTICATED BYスキーマではなく、CONNECT TOユーザー、またはCURRENT_USERの権限で実行されます。

次の例では、scottとして接続し、linkuserとして認証される、salesデータベースへの固定ユーザー共有リンクを作成しています。

CREATE SHARED DATABASE LINK link2sales
CONNECT TO scott IDENTIFIED BY password
AUTHENTICATED BY linkuser IDENTIFIED BY ostrich
USING 'sales';

関連項目:

CREATE DATABASE LINK文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

32.3.3 共有データベース・リンクの構成

共有データベース・リンクは、様々な方法で構成できます。

32.3.3.1 専用サーバーへの共有リンクの作成

ローカル・サーバーの共有サーバー・プロセスは、専用リモート・サーバー・プロセスを所有できます。

この構成の利点は、ローカルの共有サーバーとリモートの専用サーバーとの間に直接的なネットワーク・トランスポートが存在することです。ただし、余分なバックエンド・サーバー・プロセスが必要になるというデメリットもあります。

ノート:

リモート・サーバーは、共有サーバーまたは専用サーバーのどちらか一方にできます。ローカル・サーバーとリモート・サーバーの間には専用の接続が存在します。リモート・サーバーが共有サーバーのときは、サービス名の定義にSERVER=DEDICATED句を使用することで、専用サーバー接続を強制できます。

図32-1 専用サーバー・プロセスへの共有データベース・リンク

図32-1の説明が続きます
「図32-1 専用サーバー・プロセスへの共有データベース・リンク」の説明
32.3.3.2 共有サーバーへの共有リンクの作成

リモート・サーバー上の共有サーバー・プロセスを使用して共有リンクを作成できます。

この構成では、多数の専用サーバー・プロセスは必要ありませんが、リモート・サーバーのディスパッチャを経由する接続が必要になります。この場合、ローカル・サーバーとリモート・サーバーの両方を共有サーバーとして構成する必要があります。

図32-2 共有サーバーへの共有データベース・リンク

図32-2の説明が続きます
「図32-2 共有サーバーへの共有データベース・リンク」の説明

関連項目:

共有サーバー・オプションの詳細は、「共有サーバー・プロセス」

32.4 データベース・リンクの管理

データベース・リンクの管理には、クローズ、削除、およびアクティブな接続数の制限などのタスクが含まれます。

32.4.1 データベース・リンクのクローズ

あるセッションでデータベース・リンクにアクセスする場合、そのセッションをクローズするまでリンクはオープンしたままです。手動でデータベース・リンクをクローズするには、ALTER SESSION CLOSE DATABASE LINK文を使用します。

リンクがオープンしているということは、そのリンクを介してアクセスしている各リモート・データベースのプロセスがアクティブであることを意味します。この状況では、次のような結果が生じます。

  • 20人のユーザーがセッションをオープンしてローカル・データベースの同じパブリック・リンクにアクセスする場合、20のデータベース・リンク接続がオープンします。

  • 20人のユーザーがセッションをオープンして各ユーザーがプライベート・リンクにアクセスする場合、20のデータベース・リンク接続がオープンします。

  • 1人のユーザーがセッションを開始して20の異なるリンクにアクセスする場合、20のデータベース・リンク接続がオープンします。

セッションをクローズした後、セッションでアクティブだったリンクは自動的にクローズされます。ユーザーがリンクを手動でクローズする場合もあります。たとえば、次のようなときにリンクをクローズします。

  • リンクによって確立されたネットワーク接続がアプリケーションでそれほど頻繁に使用されないとき。

  • ユーザー・セッションを終了する必要があるとき。

リンクをクローズするには次の文を発行しますが、ここでlinknameはリンクの名前を表します。

ALTER SESSION CLOSE DATABASE LINK linkname;

この文は、現行セッションでアクティブなリンクのみをクローズします。

32.4.2 データベース・リンクの削除

データベース・リンクは、表やビューと同様に削除できます。リンクがプライベートの場合は、自分のスキーマ内に存在する必要があります。リンクがパブリックの場合は、DROP PUBLIC DATABASE LINKシステム権限が必要です。

構文は次のとおりです。ここで、dblinkはリンクの名前を表します。

DROP [PUBLIC] DATABASE LINK dblink; 
32.4.2.1 プライベート・データベース・リンクの削除

プライベート・データベース・リンクを削除するには、DROP DATABASE LINK文を使用します。

  1. SQL*Plusを使用して、ローカル・データベースに接続します。たとえば、次のように入力します。
    CONNECT scott@local_db
    
  2. USER_DB_LINKSを問い合せて、所有しているリンクを確認します。たとえば、次のように入力します。
    SELECT DB_LINK FROM USER_DB_LINKS;
    
    DB_LINK
    -----------------------------------
    SALES.US.EXAMPLE.COM
    MKTG.US.EXAMPLE.COM
    2 rows selected.
    
  3. DROP DATABASE LINK文を使用して、目的のリンクを削除します。たとえば、次のように入力します。
    DROP DATABASE LINK sales.us.example.com;
32.4.2.2 パブリック・データベース・リンクの削除

パブリック・データベース・リンクを削除するには、DROP PUBLIC DATABASE LINK文を使用します。

  1. ローカル・データベースにDROP PUBLIC DATABASE LINK権限を持つユーザーとして接続します。たとえば、次のように入力します。
    CONNECT SYSTEM@local_db AS SYSDBA
    
  2. DBA_DB_LINKSを問い合せて、パブリック・リンクを確認します。たとえば、次のように入力します。
    SELECT DB_LINK FROM DBA_DB_LINKS
      WHERE OWNER = 'PUBLIC';
    
    DB_LINK
    -----------------------------------
    DBL1.US.EXAMPLE.COM
    SALES.US.EXAMPLE.COM
    INST2.US.EXAMPLE.COM                            
    RMAN2.US.EXAMPLE.COM
    4 rows selected.
    
  3. DROP PUBLIC DATABASE LINK文を使用して、目的のリンクを削除します。たとえば、次のように入力します。
    DROP PUBLIC DATABASE LINK sales.us.example.com;

32.4.3 アクティブ・データベース・リンクの接続数の制限

静的な初期化パラメータOPEN_LINKSを使用すると、ユーザー・プロセスからリモート・データベースへの接続数を制限できます。

このパラメータは、分散トランザクションにおいて1つのユーザー・セッションが同時に使用できるリモート接続数を制御します。

このパラメータを設定する際は、次の点を考慮してください。

  • 設定値は、複数のデータベースを参照する1つのSQL文によって参照されるデータベースの数以上にします。

  • 複数の分散データベースに継続してアクセスする場合は、設定値を大きくします。たとえば、3つのデータベースに定期的にアクセスする場合は、OPEN_LINKSを3以上に設定します。

  • OPEN_LINKSのデフォルト値は4です。OPEN_LINKSを0(ゼロ)に設定した場合、分散トランザクションは許可されません。

    関連項目:

    OPEN_LINKS初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

32.5 データベース・リンク情報の表示

各データベースのデータ・ディクショナリには、そのデータベース内にあるデータベース・リンクの定義がすべて格納されています。データ・ディクショナリ表およびビューを使用して、リンクに関する情報を取得できます。

32.5.1 データベース内のリンクの判断

ローカル・データベースに定義され、データ・ディクショナリに格納されているデータベース・リンクは、ビュー・セットに表示されます。

:

ビュー 用途

DBA_DB_LINKS

データベース内のデータベース・リンクがすべてリストされます。

ALL_DB_LINKS

接続ユーザーがアクセス可能なデータベース・リンクがすべてリストされます。

USER_DB_LINKS

接続ユーザーが所有しているデータベース・リンクがすべてリストされます。

これらのデータ・ディクショナリ・ビューには、データベース・リンクに関する同じ基本情報が含まれていますが、いくつか例外もあります。

対象になるビュー 説明

OWNER

USER_*を除くすべて

データベース・リンクを作成したユーザー。リンクがパブリックの場合、ユーザーはPUBLICとしてリストされます。

DB_LINK

すべて

データベース・リンクの名前。

USERNAME

すべて

リンク定義に固定ユーザーが含まれている場合、この列には固定ユーザーのユーザー名が表示されます。固定ユーザーが含まれていない場合、この列はNULLになります。

PASSWORD

USER_*のみ

使用されません。下位互換性のためにのみ維持されています。

HOST

すべて

リモート・データベースへの接続に使用されるネット・サービス名。

CREATED

すべて

データベース・リンクの作成日時。

どのユーザーでもUSER_DB_LINKSを問い合せることで、そのユーザーが使用できるデータベース・リンクを判断できます。ALL_DB_LINKSビューまたはDBA_DB_LINKSビューを使用できるのは、追加の権限を持つユーザーのみです。

次のスクリプトは、DBA_DB_LINKSビューを問い合せて、リンク情報にアクセスします。

COL OWNER FORMAT a10
COL USERNAME FORMAT A8 HEADING "USER"
COL DB_LINK FORMAT A30
COL HOST FORMAT A7 HEADING "SERVICE"
SELECT * FROM DBA_DB_LINKS
/

ここでスクリプトが起動され、その出力結果が表示されます。

SQL>@link_script

OWNER      DB_LINK                        USER     SERVICE CREATED
---------- ------------------------------ -------- ------- ----------
SYS        TARGET.US.EXAMPLE.COM             SYS      inst1   23-JUN-99
PUBLIC     DBL1.UK.EXAMPLE.COM               BLAKE    ora51   23-JUN-99
PUBLIC     RMAN2.US.EXAMPLE.COM                       inst2   23-JUN-99
PUBLIC     DEPT.US.EXAMPLE.COM                        inst2   23-JUN-99
JANE       DBL.UK.EXAMPLE.COM                BLAKE    ora51   23-JUN-99
SCOTT      EMP.US.EXAMPLE.COM                SCOTT    inst2   23-JUN-99
6 rows selected.

32.5.2 オープンしているリンク接続の判断

自分のセッションで現在オープンしているデータベース・リンク接続がわかれば役に立つ場合があります。

しかし、SYSDBAとして接続している場合には、ビューを問い合せてすべてのセッションでオープンしているすべてのリンクを判断することはできず、現在作業中のセッションのリンク情報にアクセスすることしかできません。

次のビューには、現行セッションで現在オープンしているデータベース・リンク接続が表示されます。

ビュー 用途

V$DBLINK

自分のセッションでオープンしているすべてのデータベース・リンク、つまり、IN_TRANSACTION列がYESに設定されているすべてのデータベース・リンクがリストされます。

GV$DBLINK

自分のセッションでオープンしているすべてのデータベース・リンクと対応するインスタンスがリストされます。このビューは、Oracle Real Application Clusters構成の使用時に役立ちます。

これらのデータ・ディクショナリ・ビューには、データベース・リンクに関する同じ基本情報が含まれていますが、1つ例外があります。

対象になるビュー 説明

DB_LINK

すべて

データベース・リンクの名前。

OWNER_ID

すべて

データベース・リンクの所有者。

LOGGED_ON

すべて

データベース・リンクが現在ログインされているかどうか。

HETEROGENEOUS

すべて

データベース・リンクが同機種間(NO)と異機種間(YES)のどちらであるか。

PROTOCOL

すべて

データベース・リンクの通信プロトコル。

OPEN_CURSORS

すべて

データベース・リンクでカーソルがオープンされているかどうか。

IN_TRANSACTION

すべて

コミットまたはロールバックがまだ完了していないトランザクションで、データベース・リンクがアクセスされているかどうか。

UPDATE_SENT

すべて

データベース・リンクで更新があったかどうか。

COMMIT_POINT_STRENGTH

すべて

データベース・リンクを使用しているトランザクションのコミット・ポイント強度。

INST_ID

GV$DBLINKのみ

ビュー情報が取得されたインスタンス。

たとえば、次のスクリプトを作成し、実行することで、オープンされているリンクを判断できます(出力例も含まれています)。

COL DB_LINK FORMAT A25
COL OWNER_ID FORMAT 99999 HEADING "OWNID"
COL LOGGED_ON FORMAT A5 HEADING "LOGON"
COL HETEROGENEOUS FORMAT A5 HEADING "HETER"
COL PROTOCOL FORMAT A8
COL OPEN_CURSORS FORMAT 999 HEADING "OPN_CUR"
COL IN_TRANSACTION FORMAT A3 HEADING "TXN"
COL UPDATE_SENT FORMAT A6 HEADING "UPDATE"
COL COMMIT_POINT_STRENGTH FORMAT 99999 HEADING "C_P_S"

SELECT * FROM V$DBLINK
/

SQL> @dblink

DB_LINK                   OWNID LOGON HETER PROTOCOL OPN_CUR TXN UPDATE  C_P_S
------------------------- ------ ----- ----- -------- ------- --- ------ ------
INST2.EXAMPLE.COM                 0 YES   YES    UNKN          0 YES YES       255

32.5.3 送信データベース・リンクのホストの確認

送信データベース・リンクのホスト名を判断するには、DBMS_TNSパッケージのRESOLVE_TNSNAMEファンクションを使用できます。

送信データベース・リンクでは、ネットワーク・サービス名などの接続識別子によってデータベース・リンクが作成されている場合、DBA_DB_LINKSビューのHOST列の値は、接続データを解決しません。結果的に、ホスト名などの接続データの一部を必要とするツールは、情報を見つけるためにtnsnames.oraファイルをチェックする必要があります。ただし、ツールがtnsnames.oraファイルにアクセスできない場合もあります。

  1. DBMS_TNSパッケージ内のサブプログラムを実行できるユーザーとして送信データベース・リンクが含まれるデータベースに接続します。
  2. DBA_DB_LINKSビューを問い合せます。

例32-1 送信データベース・リンクのホストの確認

この問合せ結果には、各送信データベース・リンクのホスト名を含む接続データが表示されます。

SELECT DB_LINK, DBMS_TNS.RESOLVE_TNSNAME(HOST) FROM DBA_DB_LINKS;

関連項目:

32.5.4 受信データベース・リンクについての情報の確認

受信データベース・リンクに関する情報を判断するには、DBA_DB_LINK_SOURCESビューを使用できます。

データベースは、受信データベース・リンクの一意の接続に関する詳細を永続表およびDBA_DB_LINK_SOURCESビューに記録します。このビューに問い合せると、データベース・リンクに対する受信接続に関する情報を取得できます。

  1. DBA_DB_LINK_SOURCESビューの問合せを実行できるユーザーとしてデータベースに接続します。
  2. DBA_DB_LINK_SOURCESビューを問い合せます。

例32-2 DBA_DB_LINK_SOURCESビューの問合せ

この例は、各受信データベース・リンクのデータベース名、ホスト名を返します。また、データベース・リンクによる現在のデータベースへの最初と最後のログイン時間も返します。

SELECT DB_NAME, HOST_NAME, FIRST_LOGON_TIME, LAST_LOGON_TIME 
   FROM DBA_DB_LINK_SOURCES;

32.5.5 受信データベース・リンクのSCNの高アクティビティの原因の確認

受信データベース・リンクで高いシステム変更番号(SCN)アクティビティのソースを判断するには、次のビューを使用できます: DBA_EXTERNAL_SCN_ACTIVITYDBA_DB_LINK_SOURCESおよびDBA_DB_LINK

分散データベース環境での分散トランザクションと分散読取りの一貫性を実現するために、データベース・リンクを介して呼出しが行われた場合、データベースはSCNを同期します。SCNの増加率が高いと、データベースがエラーを返す可能性があります。

多くの場合、分散データベース操作から生じるSCNの異常な増加の原因を判別するのは困難です。DBA_EXTERNAL_SCN_ACTIVITYビューにより、過剰なSCNの増加を引き起こしているデータベースまたはクライアントを見つけ出すことができます。問合せでこのビューをDBA_DB_LINK_SOURCES およびDBA_DB_LINKビューと結合することにより、情報が返されます。

  1. DBA_EXTERNAL_SCN_ACTIVITYDBA_DB_LINK_SOURCESおよびDBA_DB_LINKビューの問合せを実行できるユーザーとしてデータベースに接続します。
  2. 最近のSCN増加の履歴とそれらのソースを表示するために、次の問合せを実行します。
    (SELECT RESULT, OPERATION_TIMESTAMP, EXTERNAL_SCN, SCN_ADJUSTMENT, HOST_NAME, DB_NAME, SESSION_ID, SESSION_SERIAL#
       FROM DBA_EXTERNAL_SCN_ACTIVITY a, DBA_DB_LINK_SOURCES s
       WHERE a.INBOUND_DB_LINK_SOURCE_ID = s.SOURCE_ID)
    UNION
    (SELECT RESULT, OPERATION_TIMESTAMP, EXTERNAL_SCN, SCN_ADJUSTMENT, dbms_tns.resolve_tnsname(HOST) HOST_NAME, NULL DB_NAME, SESSION_ID, SESSION_SERIAL#
       FROM DBA_EXTERNAL_SCN_ACTIVITY a, DBA_DB_LINKS o
       WHERE a.OUTBOUND_DB_LINK_NAME = o.DB_LINK AND
             a.OUTBOUND_DB_LINK_OWNER = o.OWNER)
    UNION
    (SELECT RESULT, OPERATION_TIMESTAMP, EXTERNAL_SCN,   SCN_ADJUSTMENT,  s.MACHINE HOST_NAME, NULL DB_NAME, SESSION_ID, SESSION_SERIAL#
       FROM DBA_EXTERNAL_SCN_ACTIVITY a, V$SESSION s
       WHERE a.SESSION_ID = s.SID AND  
             a.SESSION_SERIAL#=s.SERIAL# AND
             INBOUND_DB_LINK_SOURCE_ID IS NULL AND
             OUTBOUND_DB_LINK_NAME IS NULL AND
             OUTBOUND_DB_LINK_OWNER IS NULL);
    

ノート:

高SCNアクティビティがDBA_EXTERNAL_SCN_ACTIVITYビューに記録されていない場合、この問合せは結果を返しません。

32.6 位置の透過性の作成

必要なデータベース・リンクの構成が完了した後、各種のツールを使用してデータベース・システムの分散的な性質をユーザーから隠すことができます。言い換えれば、ユーザーはリモート・オブジェクトに対してあたかもローカル・オブジェクトであるかのようにアクセスできるようになります。

32.6.1 ビューを使用した位置の透過性の作成

ローカル・ビューは、分散データベース・システムにおいてローカルおよびリモートの表に対する位置の透過性を提供できます。

たとえば、emp表がローカル・データベースに、dept表がリモート・データベースに、それぞれ格納されているとします。システムのユーザーに対してこれらの表を透過的にするために、ローカル・データとリモート・データを結合するビューをローカル・データベースに作成できます。

CREATE VIEW company AS
   SELECT a.empno, a.ename, b.dname 
   FROM scott.emp a, jward.dept@hq.example.com b 
   WHERE a.deptno = b.deptno; 

図32-3 ビューと位置の透過性

図32-3の説明が続きます
「図32-3 ビューと位置の透過性」の説明

ユーザーはこのビューにアクセスするときに、データが物理的に格納されている場所や、複数の表のデータにアクセスしているかどうかについて知る必要はありません。したがって、ユーザーは必要な情報をより簡単に取得できます。たとえば、次の問合せは、ローカルおよびリモートの両方のデータベース表からのデータを提供します。

SELECT * FROM company; 

ローカル・ビューの所有者は、リモート・ユーザーによってすでに付与されているローカル・ビューのオブジェクト権限のみを付与できます。(リモート・ユーザーはデータベース・リンクのタイプによって示されます)。これは、ローカル・データを参照するビューの権限の管理と似ています。

32.6.2 シノニムを使用した位置の透過性の作成

シノニムは、分散データベース・システム内での位置など、基礎になるオブジェクトの個別情報を隠すため、分散環境と非分散環境の両方で役立ちます。基礎になるオブジェクトを名前変更または移動する必要がある場合でも、シノニムを再定義するだけで済み、シノニムをベースとするアプリケーションは引き続き通常どおり動作します。また、分散データベース・システムのユーザーが使用するSQL文も、シノニムによって単純化されます。

32.6.2.1 シノニムの作成

シノニムはすべて、作成するデータベースのデータ・ディクショナリに格納されるスキーマ・オブジェクトです。シノニムでは、データベース・リンクを介したリモート表へのアクセスを簡単にするために、単一ワードでリモート・データにアクセスでき、それによって特定のオブジェクト名や位置をシノニムのユーザーから隠すことができます。

次のもののシノニムを作成できます。

  • タイプ

  • ビュー

  • マテリアライズド・ビュー

  • 順序

  • プロシージャ

  • ファンクション

  • パッケージ

シノニムを作成するための構文は、次のとおりです。

CREATE [PUBLIC] SYNONYM synonym_name 
FOR [schema.]object_name[@database_link_name]; 

ここで:

  • PUBLICは、すべてのユーザーがこのシノニムを使用できることを指定するキーワードです。このパラメータを省略するとシノニムがプライベートになり、作成者のみ使用可能になります。パブリック・シノニムは、CREATE PUBLIC SYNONYMシステム権限を持つユーザーのみが作成できます。

  • synonym_nameには、ユーザーおよびアプリケーションが参照する代替オブジェクト名を指定します。

  • schemaには、object_nameで指定されたオブジェクトのスキーマを指定します。このパラメータを省略すると、オブジェクトのスキーマとして作成者のスキーマが使用されます。

  • object_nameには、表、ビュー、順序、マテリアライズド・ビュー、型、プロシージャ、ファンクションまたはパッケージのいずれかを適宜指定します。

  • database_link_nameには、object_nameで指定されたオブジェクトが存在するリモート・データベースおよびスキーマを識別するデータベース・リンクを指定します。

シノニムには、そのスキーマ内に存在するオブジェクトの中で一意の名前を付ける必要があります。スキーマにスキーマ・オブジェクトがあり、同じ名前のパブリック・シノニムが存在する場合、データベースはスキーマを所有しているユーザーがその名前を参照するときに、常にスキーマ・オブジェクトの方を検索します。

例: パブリック・シノニムの作成

分散データベース・システム内のすべてのデータベースにおいて、hqデータベースに格納されているscott.emp表のパブリック・シノニムが定義されているとします。

CREATE PUBLIC SYNONYM emp FOR scott.emp@hq.example.com; 

scott.emp@hq.example.comの位置はパブリック・シノニムによって隠されているので、使用場所に依存しない従業員管理アプリケーションを設計できます。アプリケーション内のSQL文は、パブリック・シノニムempを参照して表にアクセスできます。

また、emp表をhqデータベースからhrデータベースに移動する場合も、システムのノードでパブリック・シノニムを変更するだけで済みます。従業員管理アプリケーションは、すべてのノードで引き続き正常に動作します。

32.6.2.2 権限とシノニムの管理

シノニムは、実際のオブジェクトへの参照です。特定のスキーマ・オブジェクトのシノニムにアクセスするユーザーは、元のスキーマ・オブジェクトそのものに対する権限を持っている必要があります。

たとえば、ユーザーがシノニムにアクセスしようとして、そのシノニムが識別する表に対してユーザーが権限を持っていなければ、表またはビューが存在しないというエラーが発生します。

scottが、リモート・オブジェクトscott.emp@sales.example.comの別名としてローカル・シノニムempを作成したとします。scottは、このシノニムのオブジェクト権限を別のローカル・ユーザーに付与できません。この操作はsalesデータベースのリモートのemp表の権限の付与に相当しますが、これは許可されていないので、scottはこのシノニムのローカル権限を付与することはできません。この動作は、ローカルの表またはビューの別名であるシノニムの権限管理とは異なります。

したがって、シノニムを位置の透過性のために使用する場合、ローカル権限は管理できません。ベース・オブジェクトのセキュリティは、リモート・ノードですべて管理されます。たとえば、ユーザーadminはemp_synシノニムのオブジェクト権限を付与することはできません。

ビューやプロシージャの定義で参照されるデータベース・リンクとは異なり、シノニムで参照されるデータベース・リンクを解決する際は、シノニムへの参照が解析される時点で有効なスキーマが所有しているプライベート・リンクが最初に検索されます。したがって、オブジェクトの適切な解決を保証するには、基礎になるオブジェクトのスキーマをシノニムの定義の中で指定することが特に重要になります。

32.6.3 プロシージャを使用した位置の透過性の作成

プロシージャと呼ばれるPL/SQLプログラム・ユニットは、位置の透過性を提供できます。

32.6.3.1 ローカル・プロシージャを使用したリモート・データの参照

プロシージャおよびファンクションには、スタンドアロンとパッケージのどちらの場合でも、リモート・データを参照するSQL文を含めることができます。

たとえば、次の文で作成されるプロシージャを考えます。

CREATE PROCEDURE fire_emp (enum NUMBER) AS 
BEGIN 
  DELETE FROM emp@hq.example.com 
  WHERE empno = enum;
END; 

ユーザーまたはアプリケーションがfire_empプロシージャをコールするときに、リモート表が変更されようとしていることは見かけ上わかりません。

プロシージャ内の文でローカルのプロシージャ、ビューまたはシノニムを使用して間接的にリモート・データを参照するときは、2層目の位置の透過性が可能です。たとえば、次の文はローカル・シノニムを定義します。

CREATE SYNONYM emp FOR emp@hq.example.com; 

このシノニムがあれば、次の文を使用してfire_empプロシージャを作成できます。

CREATE PROCEDURE fire_emp (enum NUMBER) AS 
BEGIN 
  DELETE FROM emp WHERE empno = enum; 
END; 

emp@hq.acme.comを名前変更または移動した場合でも、表を参照するローカル・シノニムを変更するだけで済みます。このプロシージャをコールするプロシージャやアプリケーションを変更する必要はありません。

32.6.3.2 ローカル・プロシージャを使用したリモート・プロシージャのコール

ローカル・プロシージャを使用してリモート・プロシージャをコールできます。リモート・プロシージャでは、要求されたデータ操作言語(DML)を実行できます。

たとえば、scottlocal_dbに接続して次のプロシージャを作成したとします。

CONNECT scott@local_db

CREATE PROCEDURE fire_emp (enum NUMBER) 
AS 
BEGIN 
  EXECUTE term_emp@hq.example.com;
END; 

ここで、scottは、リモート・データベースに接続して次のリモート・プロシージャを作成するとします。

CONNECT scott@hq.example.com

CREATE PROCEDURE term_emp (enum NUMBER) 
AS 
BEGIN 
  DELETE FROM emp WHERE empno = enum;
END;

ユーザーまたはアプリケーションがlocal_dbに接続してfire_empプロシージャをコールすると、このプロシージャはさらにhq.example.comにあるリモートのterm_empプロシージャをコールします。

32.6.3.3 ローカル・シノニムを使用したリモート・プロシージャの参照

ローカル・シノニムを使用してリモート・プロシージャを参照できます。

たとえば、scottがローカルのsales.example.comデータベースに接続して次のプロシージャを作成したとします。

CREATE PROCEDURE fire_emp (enum NUMBER) AS 
BEGIN 
DELETE FROM emp@hq.example.com 
WHERE empno = enum; 
END; 

この後、ユーザーpeggysupply.example.comデータベースに接続し、scottがリモートのsalesデータベースで作成したプロシージャに対する次のシノニムを作成します。

SQL> CONNECT peggy@supply
SQL> CREATE PUBLIC SYNONYM emp FOR scott.fire_emp@sales.example.com; 

supplyのローカル・ユーザーは、このシノニムを使用してsalesのプロシージャを実行できます。

32.6.3.4 プロシージャと権限の管理

ローカル・プロシージャに、リモート表またはリモート・ビューを参照する文が含まれているとします。ローカル・プロシージャの所有者はexecute権限をすべてのユーザーに付与できるため、任意のユーザーがプロシージャを実行して間接的にリモート・データにアクセスできるようにすることができます。

一般に、プロシージャはセキュリティの面で役に立ちます。プロシージャの中で参照されるオブジェクトの権限を明示的にコール側のユーザーに付与する必要はありません。

32.7 文の透過性の管理

分散データベースでは、いくつかのSQL文がリモートの表を参照できます。

データベースでは、次に示す標準のDML文でリモート表を参照することが可能です。

  • SELECT (問合せ)

  • INSERT

  • UPDATE

  • DELETE

  • SELECT...FOR UPDATE(異機種間システムでは常にサポートされるとはかぎらない)

  • LOCK TABLE

結合、集計、副問合せおよびSELECT...FOR UPDATEを含む問合せでは、ローカルおよびリモートの表およびビューをいくつでも参照できます。たとえば、次の問合せは2つのリモート表の情報を結合します。

SELECT e.empno, e.ename, d.dname 
  FROM scott.emp@sales.division3.example.com e, jward.dept@hq.example.com d 
  WHERE e.deptno = d.deptno; 

同機種環境では、UPDATEINSERTDELETEおよびLOCK TABLE文は、ローカルおよびリモートの両方の表を参照できます。リモート・データを更新するためのプログラミングは不要です。たとえば、次の文はローカル・データベースのjwardスキーマのemp表から行を選択して、scott.salesスキーマのリモート表empに新しい行を挿入します。

INSERT INTO scott.emp@sales.division3.example.com 
  SELECT * FROM jward.emp;

文の透過性に関する制限事項

文の透過性には、いくつかの制限事項が適用されます。

  • リモートのOracle Database以外のシステム上のオブジェクトを更新するデータ操作言語文では、ローカルのOracle Databaseのオブジェクトを参照できません。たとえば、次のような文を実行するとエラーになります。

    INSERT INTO remote_table@link as SELECT * FROM local_table;
    
  • 1つのSQL文において、参照されるすべてのLONGおよびLONG RAWの列、順序、更新済の表およびロック済の表は、同じノードに存在する必要があります。

  • データベースでは、同機種システムにおけるリモートのデータ定義言語(DDL)文(CREATEALTERDROPなど)は使用できません。ただし、次の例のようにDBMS_SQLパッケージのプロシージャのリモート実行を使用する場合を除きます。

    DBMS_SQL.PARSE@link_name(crs, 'drop table emp', v7);
    

    異機種間システムでは、パススルー機能によってDDLの実行が可能です。

  • ANALYZE文のLIST CHAINED ROWS句は、リモート表を参照できません。

  • 分散データベース・システムでは、SYSDATEUSERUIDUSERENVなどの環境に依存したSQLファンクションは、データベースによって、その文(または文の一部)が実行される場所にかかわらず、常にローカル・サーバーについて評価されます。

    ノート:

    Oracle Databaseは、USERENVファンクションを問合せの用途でのみサポートしています。

  • リモート・オブジェクトのアクセスに関連して、次のようなパフォーマンス上の制限事項があります。

    • リモート・ビューは統計データを持ちません。

    • パーティション表に対する問合せは、最適化されない場合があります。

    • リモート表で考慮される索引の数は20以下です。

    • コンポジット索引で使用される列の数は20以下です。

  • Oracle Databaseの分散読込み一貫性の実装には制限があり、これによってあるノードが別のノードに対して古い状態になる可能性があります。問合せを実行したときに、読込み一貫性に従ってデータが取得されているにもかからわず、そのデータが古い場合があります。この問題の管理方法を学習するには、「読込み一貫性の管理」を参照してください。

    関連項目:

    DBMS_SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

32.8 分散データベースの管理: 例

データベース・リンクの管理の例を示します。

32.8.1 例1: パブリック固定ユーザーのデータベース・リンクの作成

パブリック固定ユーザーのデータベース・リンクの作成を示す例です。

次の文では、ローカル・データベースにjaneとして接続し、データベースsalesに対してパブリック固定ユーザーscottのデータベース・リンクを作成しています。データベースには、ネット・サービス名sldbを介してアクセスします。

CONNECT jane@local

CREATE PUBLIC DATABASE LINK sales.division3.example.com
  CONNECT TO scott IDENTIFIED BY password
  USING 'sldb';

この文の実行後は、ローカル・データベースに接続する任意のユーザーが、sales.division3.example.comデータベース・リンクを使用してリモート・データベースに接続できます。各ユーザーは、リモート・データベースのスキーマscottに接続します。

ユーザーは、次のSQL問合せを発行して、scottのリモート・スキーマの表empにアクセスできます。

SELECT * FROM emp@sales.division3.example.com;

各アプリケーションまたはユーザー・セッションは、サーバーの共通アカウントへの接続をそれぞれ別々に作成します。リモート・データベースへの接続は、アプリケーションの実行中またはユーザー・セッションの継続期間中オープンしたままです。

32.8.2 例2: パブリック固定ユーザーの共有データベース・リンクの作成

パブリック固定ユーザーの共有データベース・リンクの作成を示す例です。

次の例では、ローカル・データベースにdanaとして接続し、ネット・サービス名sldbを使用してsalesデータベースへのパブリック・リンクを作成しています。このリンクによって、リモート・データベースにscottとして接続でき、このユーザーがscottとして認証されます。

CONNECT dana@local

CREATE SHARED PUBLIC DATABASE LINK sales.division3.example.com
  CONNECT TO scott IDENTIFIED BY password 
  AUTHENTICATED BY scott IDENTIFIED BY password
  USING 'sldb';

ローカルの共有サーバーに接続する任意のユーザーがこのデータベース・リンクを使用し、共有サーバー・プロセスを介してリモートのsalesデータベースに接続できます。その後ユーザーは、scottスキーマの表を問い合せることができます。

前述の例では、ローカルの共有サーバーはリモート・サーバーへの接続を1つずつ確立できます。ローカルの共有サーバー・プロセスでsales.division3.example.comデータベース・リンクを介したリモート・サーバーへのアクセスが必要になると、そのたびにローカルの共有サーバー・プロセスは確立済のネットワーク接続を再利用します。

32.8.3 例3: パブリック接続ユーザーのデータベース・リンクの作成

パブリック接続ユーザーのデータベース・リンクの作成を示す例です。

次の例では、ローカル・データベースにlarryとして接続し、ネット・サービス名sldbを使用してデータベースへのパブリック・リンクを作成しています。

CONNECT larry@local

CREATE PUBLIC DATABASE LINK redwood
  USING 'sldb';

ローカル・データベースに接続する任意のユーザーが、redwoodデータベース・リンクを使用できます。データベース・リンクを使用するローカル・データベースの接続ユーザーによって、リモート・スキーマが決まります。

接続ユーザーscottがデータベース・リンクを使用した場合、データベース・リンクはリモート・スキーマscottに接続します。接続ユーザーfoxがデータベース・リンクを使用した場合、データベース・リンクはリモート・スキーマfoxに接続します。

リモート・スキーマfoxempスキーマ・オブジェクトを解決できない場合は、ローカル・データベースでローカル・ユーザーfoxが次の文を実行すると失敗します。つまり、sales.division3.example.comfoxスキーマにempが表、ビューまたは(パブリック)シノニムとして存在しない場合は、エラーが返されます。

CONNECT fox@local

SELECT * FROM emp@redwood;

32.8.4 例4: パブリック接続ユーザーの共有データベース・リンクの作成

パブリック接続ユーザーの共有データベース・リンクの作成を示す例です。

次の例では、ローカル・データベースにneilとして接続し、ネット・サービス名sldbを使用してsalesデータベースへの共有パブリック・リンクを作成しています。ユーザーは、crazy/horseというユーザーID/パスワードによって認証されます。次の文は、パブリック接続ユーザーの共有データベース・リンクを作成します。

CONNECT neil@local

CREATE SHARED PUBLIC DATABASE LINK sales.division3.example.com 
  AUTHENTICATED BY crazy IDENTIFIED BY horse
  USING 'sldb';

ローカル・サーバーに接続する各ユーザーは、この共有データベース・リンクを使用してリモート・データベースに接続し、対応するリモート・スキーマの表を問い合せることができます。

ローカルの共有サーバー・プロセスは、それぞれリモート・サーバーへの接続を1つずつ確立します。ローカルのサーバー・プロセスでsales.division3.example.comデータベース・リンクを介したリモート・サーバーへのアクセスが必要になると、たとえ接続ユーザーが異なるユーザーであっても、そのたびにローカルの共有サーバー・プロセスは確立済のネットワーク接続を再利用します。

このデータベース・リンクが頻繁に使用されると、最終的にローカル・データベースのすべての共有サーバーがリモート接続を持つことになります。この時点で、新しいユーザーがこの共有データベース・リンクを使用しても、リモート・サーバーへの物理的な接続は新たに確立されません。

32.8.5 例5: パブリック現行ユーザーのデータベース・リンクの作成

パブリック現行ユーザーのデータベース・リンクの作成を示す例です。

次の例では、ローカル・データベースに接続ユーザーとして接続し、ネット・サービス名sldbを使用してsalesデータベースへのパブリック・リンクを作成しています。次の文は、パブリック現行ユーザーのデータベース・リンクを作成します。

CONNECT bart@local

CREATE PUBLIC DATABASE LINK sales.division3.example.com
  CONNECT TO CURRENT_USER
  USING 'sldb';

ノート:

このリンクを使用するには、現行ユーザーがグローバル・ユーザーであることが必要です。

このデータベース・リンクの結果は、次のとおりです。

scottがリモートのemp表から1行を削除するローカル・プロシージャfire_empを作成し、fire_empの実行権限をfordに付与したとします。

CONNECT scott@local_db

CREATE PROCEDURE fire_emp (enum NUMBER) 
AS
BEGIN
   DELETE FROM emp@sales.division3.example.com
   WHERE empno=enum;
END;

GRANT EXECUTE ON fire_emp TO ford;

ここで、fordはローカル・データベースに接続してscottのプロシージャを実行したとします。

CONNECT ford@local_db

EXECUTE PROCEDURE scott.fire_emp (enum 10345);

fordがプロシージャscott.fire_empを実行するとき、プロシージャはscottの権限のもとで実行されます。現行ユーザー・データベース・リンクが使用されているため、接続はfordのリモート・スキーマではなく、scottのリモート・スキーマに確立されます。scottはグローバル・ユーザーである必要がありますが、fordはグローバル・ユーザーでなくてもかまいません。

ノート:

かわりに接続ユーザー・データベース・リンクが使用された場合、接続はfordのリモート・スキーマに確立されます。実行者権限と権限の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

scottのリモート・スキーマへの固定ユーザー・データベース・リンクを使用しても、同じ結果を得ることができます。