11gリリース1（11.1）
E05760-03
 目次 |
 索引 |
| Oracle Database 管理者ガイド 11gリリース1（11.1） E05760-03 |
|
この章の内容は次のとおりです。
分散データベース・システムでは、各データベースが一意のグローバル・データベース名を持ちます。グローバル・データベース名は、システム内のデータベースを一意に識別します。分散データベースでの主な管理作業として、グローバル・データベース名の作成と変更の管理があります。
この項の内容は、次のとおりです。
グローバル・データベース名は、データベース名とドメインの2つの構成要素から構成されます。データベース名とドメイン名は、データベースの作成時に次の初期化パラメータによって決まります。
| 構成要素 | パラメータ | 要件 | 例 |
|---|---|---|---|
|
データベース名 |
|
文字数は必ず8文字以内です。 |
|
|
データベースが存在するドメイン |
|
必ず標準のインターネット表記規則に従います。ドメイン名の各レベルは必ずドットで区切ります。ドメイン名の順序はリーフ（葉）からルート（根）、左から右です。 |
|
次に、有効なグローバル・データベース名の例を示します。
| DB_NAME | DB_DOMAIN | グローバル・データベース名 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
DB_DOMAIN初期化パラメータはデータベースの作成時にのみ重要であり、DB_NAMEパラメータとともに使用してデータベースのグローバル名を構成します。データベースのグローバル名は、この時点でデータ・ディクショナリに格納されます。グローバル名を変更する際は、初期化パラメータ・ファイルのDB_DOMAINパラメータを変更するのではなく、ALTER DATABASE文を使用する必要があります。しかし、ドメインの変更が反映されるように、次回データベースを起動する前にDB_DOMAINパラメータを変更しておくことには意味があります。
ローカル・データベースのリンクに付ける名前は、アクセスするリモート・データベースがグローバル・ネーミングを施行するかどうかによって異なります。リモート・データベースがグローバル・ネーミングを施行する場合は、そのリモート・データベースのグローバル・データベース名をリンクの名前として使用する必要があります。たとえば、ローカルのhqサーバーに接続していて、リモートのmfgデータベースへのリンクを作成する場合は、mfgがグローバル・ネーミングを施行していれば、そのmfgのグローバル・データベース名をリンク名として使用する必要があります。
データベース・リンク名の一部としてサービス名を使用することもできます。たとえば、サービス名sn1とsn2を使用してデータベースhq.acme.comに接続している場合、hqがグローバル・ネーミングを施行していれば、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
データベースのグローバル名を参照するには、データ・ディクショナリ・ビューGLOBAL_NAMEを使用します。たとえば、次の文を発行します。
SELECT * FROM GLOBAL_NAME; GLOBAL_NAME ------------------------------------------------------------------------------- SALES.AU.ORACLE.COM
データベースのグローバル名のドメインを変更するには、ALTER DATABASE文を使用します。データベースを作成した後に初期化パラメータDB_DOMAINを変更しても、グローバル・データベース名やデータベース・リンク名の解決には効果がありません。
次の例は、名前変更文の構文を示しています。ここで、databaseはデータベース名、domainはネットワーク・ドメインを表します。
ALTER DATABASE RENAME GLOBAL_NAME TO database.domain;
グローバル・データベース名のドメインを変更するには、次の手順を実行します。
SELECT * FROM GLOBAL_NAME; GLOBAL_NAME ---------------------------------------------------------------------------- SALES.AU.ORACLE.COM
ALTER DATABASE文を使用して、グローバル・データベース名を変更します。たとえば、次のように入力します。
ALTER DATABASE RENAME GLOBAL_NAME TO sales.us.oracle.com;
GLOBAL_NAME表を問い合せて、新しい名前を確認します。たとえば、次のように入力します。
SELECT * FROM GLOBAL_NAME; GLOBAL_NAME ---------------------------------------------------------------------------- SALES.US.ORACLE.COM
この例では、ローカル・データベースのグローバル・データベース名のドメイン部分を変更します。また、部分指定のグローバル名を使用してデータベース・リンクを作成し、Oracle Databaseがその名前をどのように解決するのかを調べます。データベースは、初期化パラメータDB_DOMAINの値ではなく、ローカル・データベースの現行のグローバル・データベース名のドメイン部分を使用して部分名を解決することがわかります。
SALES.US.ACME.COMに接続してGLOBAL_NAMEデータ・ディクショナリ・ビューを問い合せ、現行のデータベース・グローバル名を確認します。
CONNECT SYSTEM@sales.us.acme.com SELECT * FROM GLOBAL_NAME; GLOBAL_NAME ---------------------------------------------------------------------------- SALES.US.ACME.COM
V$PARAMETERビューを問い合せ、DB_DOMAIN初期化パラメータの現在の設定を調べます。
SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME = 'db_domain'; NAME VALUE --------- ----------- db_domain US.ACME.COM
hqデータベースへのデータベース・リンクを作成します。
CREATE DATABASE LINK hq USING 'sales';
データベースは、ローカル・データベースのグローバル・データベース名のドメイン部分を、リンクで指定されたデータベースの名前の後に追加して、このリンクのグローバル・データベース名を拡張します。
USER_DB_LINKSを問い合せて、データベースが部分指定のグローバル・データベース名を解決するために使用したドメイン名を確認します。
SELECT DB_LINK FROM USER_DB_LINKS; DB_LINK ------------------ HQ.US.ACME.COM
この結果は、ローカル・データベースのグローバル・データベース名のドメイン部分がus.acme.comであることを示しています。データベースは、データベース・リンク作成時の部分的なデータベース・リンク名を解決するために、このドメインを使用します。
salesデータベースが日本に移動するという通知を受けたので、salesデータベースをsales.jp.acme.comに変更します。
ALTER DATABASE RENAME GLOBAL_NAME TO sales.jp.acme.com; SELECT * FROM GLOBAL_NAME; GLOBAL_NAME ---------------------------------------------------------------------------- SALES.JP.ACME.COM
V$PARAMETERを問い合せると、グローバル・データベース名のドメイン部分を変更しても、DB_DOMAINの値は変更されていないことがわかります。
SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME = 'db_domain'; NAME VALUE --------- ----------- db_domain US.ACME.COM
この結果は、DB_DOMAIN初期化パラメータの値がALTER DATABASE RENAME GLOBAL_NAME文とは関係がないことを示しています。ALTER DATABASE文は、DB_DOMAIN初期化パラメータではなく、グローバル・データベース名のドメインを決定します（それでも、新しいドメイン名が反映されるようにDB_DOMAINを変更することには意味があります）。
supplyへの別のデータベース・リンクを作成してから、USER_DB_LINKSを問い合せて、データベースがsupplyのグローバル・データベース名のドメイン部分をどのように解決するのかを確認します。
CREATE DATABASE LINK supply USING 'supply'; SELECT DB_LINK FROM USER_DB_LINKS; DB_LINK ------------------ HQ.US.ACME.COM SUPPLY.JP.ACME.COM
この結果は、データベースがドメインjp.acme.com.を使用して、部分指定のリンク名を解決したことを示しています。このドメインは、リンクの作成時に使用されます。これは、このドメインがローカル・データベースのグローバル・データベース名のドメイン部分であるためです。データベースは、部分的なリンク名を解決するときに、DB_DOMAIN初期化パラメータの設定を使用しません。
salesはjp.acme.comドメインではなくasia.jp.acme.comドメインにあるという通知を受けました。そのため、グローバル・データベース名を次のように変更します。
ALTER DATABASE RENAME GLOBAL_NAME TO sales.asia.jp.acme.com; SELECT * FROM GLOBAL_NAME; GLOBAL_NAME ---------------------------------------------------------------------------- SALES.ASIA.JP.ACME.COM
V$PARAMETERを問い合せて、パラメータDB_DOMAINの設定を確認します。
SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME = 'db_domain'; NAME VALUE ---------- ----------- db_domain US.ACME.COM
この結果は、パラメータ・ファイルのドメイン設定が、2つのALTER DATABASE RENAME文を発行する前と変わっていないことを示しています。
warehouseデータベースへのリンクを作成し、再度USER_DB_LINKSを問い合せて、データベースが部分指定のグローバル名をどのように解決するのかを調べます。
CREATE DATABASE LINK warehouse USING 'warehouse'; SELECT DB_LINK FROM USER_DB_LINKS; DB_LINK ------------------ HQ.US.ACME.COM SUPPLY.JP.ACME.COM WAREHOUSE.ASIA.JP.ACME.COM
ここでもデータベースは、リンクの作成時にローカル・データベースのグローバル・データベース名のドメイン部分を使用して、部分的なリンク名を拡張していることがわかります。
アプリケーションによるデータおよびスキーマ・オブジェクトへのアクセスを分散データベース・システム全体にわたってサポートするために、必要なデータベース・リンクをすべて作成する必要があります。この項の内容は、次のとおりです。
データベース・リンクは、リモート・データベースのオブジェクトへのアクセスを可能にするローカル・データベース内のポインタです。プライベート・データベース・リンクを作成するには、あらかじめ適切な権限が付与されている必要があります。次の表は、どのリンク・タイプのデータベースに対してどの権限が必要なのかを示しています。
| 権限 | データベース | この権限を必要とする操作 |
|---|---|---|
|
|
ローカル |
プライベート・データベース・リンクの作成 |
|
|
ローカル |
パブリック・データベース・リンクの作成 |
|
|
リモート |
任意タイプのデータベース・リンクの作成 |
現在使用可能な権限を確認するには、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
データベース・リンクを作成するときは、そのデータベース・リンクにアクセスするユーザーを決める必要があります。ここでは、3種類の基本的なリンク・タイプの作成方法について説明します。
プライベート・データベース・リンクを作成するには、次の文を指定します。ここで、link_nameはグローバル・データベース名または任意のリンク名を表します。
CREATE DATABASE LINK link_name ...;
プライベート・データベース・リンクの例を次に示します。
| SQL文 | 結果 |
|---|---|
|
|
リモートの
リンクは、接続ユーザーのユーザーID/パスワードを使用します。そのため、 |
|
|
サービス名us_supplyを持つデータベースへの、link_2という名前のプライベート固定ユーザー・リンク。このリンクは、接続ユーザーとは無関係に、jane/doeというユーザーID/パスワードでリモート・データベースに接続します。 |
|
|
サービス名 注意: 現行ユーザーと接続ユーザーは異なる場合があります。また、現行ユーザーは、リンクに関係している両方のデータベースのグローバル・ユーザーであることが必要です（「データベース・リンクのユーザー」を参照）。現行ユーザー・リンクは、Oracle Advanced Securityオプションの一部です。 |
パブリック・データベース・リンクを作成するには、キーワードPUBLICを使用します。ここで、link_nameはグローバル・データベース名または任意のリンク名を表します。
CREATE PUBLIC DATABASE LINK link_name ...;
パブリック・データベース・リンクの例を次に示します。
| SQL文 | 結果 |
|---|---|
|
|
リモートの |
|
|
サービス名 注意: 現行ユーザーと接続ユーザーは異なる場合があります。また、現行ユーザーは、リンクに関係している両方のデータベースのグローバル・ユーザーであることが必要です（「データベース・リンクのユーザー」を参照）。 |
|
|
リモートの |
以前のリリースでは、グローバル・データベース・リンクはOracle Names Serverで定義していました。Oracle Names Serverは非推奨になりました。現在はディレクトリ・サーバーが使用できるようになり、データベースはネット・サービス名によって識別されるようになりました。このマニュアルでは、ディレクトリ・サーバーでのネット・サービス名によるデータベースの識別をグローバル・データベース・リンクと呼びます。
グローバル・データベース・リンクとして動作するディレクトリ・エントリの作成方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
データベース・リンクは、あるデータベースから別のデータベースへの通信経路を定義します。アプリケーションがデータベース・リンクを使用してリモート・データベースに接続するとき、Oracle Databaseはローカル・アプリケーションの要求にかわってリモート・データベース内でデータベース・セッションを確立します。
プライベートまたはパブリックのデータベース・リンクを作成する際、固定ユーザー、現行ユーザーおよび接続ユーザーのデータベース・リンクを作成することで、リモート・データベースのどのスキーマにリンクが接続を確立するのかを指定できます。
固定ユーザー・データベース・リンクを作成するには、リモート・データベースへのアクセスに必要な資格証明（この場合はユーザー名とパスワード）をリンク定義に埋め込みます。
CREATE DATABASE LINK ... CONNECT TO username IDENTIFIED BY password ...;
固定ユーザー・データベース・リンクの例を次に示します。
アプリケーションで固定ユーザー・データベース・リンクを使用するとき、ローカル・サーバーは必ずリモート・データベース内の固定リモート・スキーマへの接続を確立します。また、ローカル・サーバーはアプリケーションがリンクを使用してリモート・データベースにアクセスするときに、ネットワークを介して固定ユーザーの資格証明を送信します。
接続ユーザーおよび現行ユーザー・データベース・リンクでは、リンク定義に資格証明が含まれません。リモート・データベースへの接続に使用する資格証明は、データベース・リンクを参照するユーザーや、アプリケーションが実行する操作によって異なります。
接続ユーザーと現行ユーザーの区別に関する概念の詳細は、「データベース・リンクのユーザー」を参照してください。
接続ユーザー・データベース・リンクを作成するには、CONNECT TO句を省略します。次の構文は、接続ユーザー・データベース・リンクを作成します。ここで、dblinkはリンクの名前、net_service_nameはオプションの接続文字列を表します。
CREATE [SHARED] [PUBLIC] DATABASE LINK dblink ... [USING 'net_service_name'];
たとえば、接続ユーザー・データベース・リンクを作成するために、次の構文を使用します。
CREATE DATABASE LINK sales.division3.acme.com USING 'sales';
現行ユーザー・データベース・リンクを作成するには、リンク作成文で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';
場合によっては、同じリモート・データベースを指すものの、異なる通信経路を使用してリモート・データベースへの接続を確立する同じタイプ（パブリックなど）のデータベース・リンクを複数作成しなければならないことがあります。次のような場合に、この方法が役立ちます。
このような機能を容易に利用できるように、データベースでは、データベース・リンク名の中でオプションのサービス名を使用してデータベース・リンクを作成できます。データベース・リンクを作成するときは、サービス名をデータベース・リンク名の末尾部分に指定し、アットマーク（@）で区切ります。たとえば、@salesのようにします。この文字列のことを接続修飾子と呼びます。
たとえば、リモート・データベースhq.acme.comがOracle Real Application Clusters環境で管理されているとします。hqデータベースには、hq_1およびhq_2という名前の2つのインスタンスがあります。ローカル・データベースで次のパブリック・データベース・リンクを作成して、hqデータベースのリモート・インスタンスへの経路を定義できます。
CREATE PUBLIC DATABASE LINK hq.acme.com@hq_1 USING 'string_to_hq_1'; CREATE PUBLIC DATABASE LINK hq.acme.com@hq_2 USING 'string_to_hq_2'; CREATE PUBLIC DATABASE LINK hq.acme.com USING 'string_to_hq';
最初の2つの例では、サービス名が単にデータベース・リンク名の一部であることに注意してください。サービス名のテキストは、必ずしも接続の確立方法を示す必要はありません。この情報は、USING句のサービス名で指定します。また、3番目の例ではサービス名がリンク名の一部として指定されていません。この場合は、サービス名をリンク名の一部として指定したときと同様に、USING文字列によってインスタンスが決まります。
サービス名を使用して特定のインスタンスを指定するには、サービス名をグローバル・オブジェクト名の末尾に付けます。
SELECT * FROM scott.emp@hq.acme.com@hq_1
この例では、2つのアットマーク（@）があることに注意してください。
標準のデータベース・リンクを使用してリモート・サーバーを参照するアプリケーションはすべて、ローカル・データベースとリモート・データベースの間で接続を確立します。多くのユーザーがアプリケーションを同時に実行した場合、ローカル・データベースとリモート・データベースの間で多数の接続が発生する可能性があります。
共有データベース・リンクを使用すると、ローカル・サーバーとリモート・サーバーの間で必要なネットワーク接続の数を制限できます。
この項の内容は、次のとおりです。
アプリケーションおよび共有サーバーの構成を綿密に検討して、共有リンクを使用するかどうかを判断してください。簡単なガイドラインとして、データベース・リンクにアクセスするユーザー数がローカル・データベース内のサーバー・プロセス数よりもかなり多いと予測されるときは、共有データベース・リンクを使用します。
データベース・リンクに関して可能な3つの構成を次の表に示します。
共有データベース・リンクは、必ずしもすべての状況で役立つとはかぎりません。たとえば、リモート・サーバーに接続するユーザーが1人のみの場合を考えます。このユーザーが共有データベース・リンクを定義し、ローカル・データベースに10個の共有サーバー・プロセスが存在する場合、このユーザーはリモート・サーバーへのネットワーク接続を最大10個必要とする可能性があります。ユーザーは個々の共有サーバー・プロセスを使用できるため、各プロセスはそれぞれリモート・サーバーへの接続を確立できます。
非共有のデータベース・リンクでは1つのネットワーク接続しか必要としないため、このような状況では明らかに非共有のデータベース・リンクのほうが望ましいといえます。共有データベース・リンクでは、シングル・ユーザーの場合に多くのネットワーク接続が発生します。したがって、共有リンクは、多数のユーザーが同じリンクを使用する必要があるときのみ使用してください。通常、共有リンクはパブリック・データベース・リンクで使用しますが、多数のクライアントが同じローカル・スキーマ（したがって同じプライベート・データベース・リンク）にアクセスするときは、プライベート・データベース・リンクでも使用できます。
共有データベース・リンクを作成するには、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 tiger AUTHENTICATED BY linkuser IDENTIFIED BY ostrich USING 'sales';
共有データベース・リンクは、次の方法で構成できます。
図30-1に示す構成では、ローカル・サーバーの共有サーバー・プロセスは専用のリモート・サーバー・プロセスを所有しています。この構成の利点は、ローカルの共有サーバーとリモートの専用サーバーとの間に直接的なネットワーク・トランスポートが存在することです。ただし、余分なバックエンド・サーバー・プロセスが必要になるという欠点もあります。
図30-2に示す構成では、リモート・サーバーで共有サーバー・プロセスを使用しています。この構成では、多数の専用サーバー・プロセスは必要ありませんが、リモート・サーバーのディスパッチャを経由する接続が必要になります。この場合、ローカル・サーバーとリモート・サーバーの両方を共有サーバーとして構成する必要があります。
この項の内容は、次のとおりです。
あるセッションでデータベース・リンクにアクセスする場合、そのセッションをクローズするまでリンクはオープンしたままです。リンクがオープンしているということは、そのリンクを介してアクセスしている各リモート・データベースのプロセスがアクティブであることを意味します。この状況では、次のような結果が生じます。
セッションをクローズした後、セッションでアクティブだったリンクは自動的にクローズされます。ユーザーがリンクを手動でクローズする場合もあります。たとえば、次のようなときにリンクをクローズします。
リンクをクローズする場合は、次の文を発行します。ここで、linknameはリンクの名前を表します。
ALTER SESSION CLOSE DATABASE LINK linkname;
この文は、現行セッションでアクティブなリンクのみをクローズします。
データベース・リンクは、表やビューと同様に削除できます。リンクがプライベートの場合は、自分のスキーマ内に存在する必要があります。リンクがパブリックの場合は、DROP PUBLIC DATABASE LINKシステム権限が必要です。
構文は次のとおりです。ここで、dblinkはリンクの名前を表します。
DROP [PUBLIC] DATABASE LINK dblink;
CONNECT scott@local_db
USER_DB_LINKSを問い合せて、所有しているリンクを確認します。たとえば、次のように入力します。
SELECT DB_LINK FROM USER_DB_LINKS; DB_LINK ----------------------------------- SALES.US.ORACLE.COM MKTG.US.ORACLE.COM 2 rows selected.
DROP DATABASE LINK文を使用して、目的のリンクを削除します。たとえば、次のように入力します。
DROP DATABASE LINK sales.us.oracle.com;
DROP PUBLIC DATABASE LINK権限を持つユーザーとして接続します。たとえば、次のように入力します。
CONNECT SYSTEM@local_db AS SYSDBA
DBA_DB_LINKSを問い合せて、パブリック・リンクを確認します。たとえば、次のように入力します。
SELECT DB_LINK FROM USER_DB_LINKS WHERE OWNER = 'PUBLIC'; DB_LINK ----------------------------------- DBL1.US.ORACLE.COM SALES.US.ORACLE.COM INST2.US.ORACLE.COM RMAN2.US.ORACLE.COM 4 rows selected.
DROP PUBLIC DATABASE LINK文を使用して、目的のリンクを削除します。たとえば、次のように入力します。
DROP PUBLIC DATABASE LINK sales.us.oracle.com;
静的な初期化パラメータOPEN_LINKSを使用すると、ユーザー・プロセスからリモート・データベースへの接続数を制限できます。このパラメータは、分散トランザクションにおいて1つのユーザー・セッションが同時に使用できるリモート接続数を制御します。
このパラメータを設定する際は、次の点を考慮してください。
OPEN_LINKSを3以上に設定します。
OPEN_LINKSのデフォルト値は4です。OPEN_LINKSを0（ゼロ）に設定した場合、分散トランザクションは許可されません。 各データベースのデータ・ディクショナリには、そのデータベース内にあるデータベース・リンクの定義がすべて格納されています。データ・ディクショナリ表およびビューを使用して、リンクに関する情報を取得できます。この項の内容は、次のとおりです。
次のビューには、ローカル・データベースで定義され、データ・ディクショナリに格納されているデータベース・リンクが表示されます。
| ビュー | 用途 |
|---|---|
|
|
データベース内のデータベース・リンクがすべてリストされます。 |
|
|
接続ユーザーがアクセス可能なデータベース・リンクがすべてリストされます。 |
|
|
接続ユーザーが所有しているデータベース・リンクがすべてリストされます。 |
これらのデータ・ディクショナリ・ビューには、データベース・リンクに関する同じ基本情報が含まれていますが、いくつか例外もあります。
どのユーザーでも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.ACME.COM SYS inst1 23-JUN-99 PUBLIC DBL1.UK.ACME.COM BLAKE ora51 23-JUN-99 PUBLIC RMAN2.US.ACME.COM inst2 23-JUN-99 PUBLIC DEPT.US.ACME.COM inst2 23-JUN-99 JANE DBL.UK.ACME.COM BLAKE ora51 23-JUN-99 SCOTT EMP.US.ACME.COM SCOTT inst2 23-JUN-99 6 rows selected.
自分のセッションで現在オープンしているデータベース・リンク接続がわかれば役に立つ場合があります。しかし、SYSDBAとして接続している場合には、ビューを問い合せてすべてのセッションでオープンしているすべてのリンクを判断することはできず、現在作業中のセッションのリンク情報にアクセスすることしかできません。
次のビューには、現行セッションで現在オープンしているデータベース・リンク接続が表示されます。
これらのデータ・ディクショナリ・ビューには、データベース・リンクに関する同じ基本情報が含まれていますが、1つ例外があります。
たとえば、次のスクリプトを作成し、実行することで、オープンされているリンクを判断できます（出力例も含まれています）。
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.ACME.COM 0 YES YES UNKN 0 YES YES 255
必要なデータベース・リンクの構成が完了した後、各種のツールを使用してデータベース・システムの分散的な性質をユーザーから隠すことができます。言い換えれば、ユーザーはリモート・オブジェクトに対してあたかもローカル・オブジェクトであるかのようにアクセスできるようになります。ここでは、分散機能をユーザーから隠す方法について説明します。
ローカル・ビューは、分散データベース・システムにおいてローカルおよびリモートの表に対する位置の透過性を提供できます。
たとえば、emp表がローカル・データベースに、dept表がリモート・データベースに、それぞれ格納されているとします。システムのユーザーに対してこれらの表を透過的にするために、ローカル・データとリモート・データを結合するビューをローカル・データベースに作成できます。
CREATE VIEW company AS SELECT a.empno, a.ename, b.dname FROM scott.emp a, jward.dept@hq.acme.com b WHERE a.deptno = b.deptno;図 30-3 ビューと位置の透過性
ユーザーはこのビューにアクセスするときに、データが物理的に格納されている場所や、複数の表のデータにアクセスしているかどうかについて知る必要はありません。したがって、ユーザーは必要な情報をより簡単に取得できます。たとえば、次の問合せは、ローカルおよびリモートの両方のデータベース表からのデータを提供します。
SELECT * FROM company;
ローカル・ビューの所有者は、リモート・ユーザーによってすでに付与されているローカル・ビューのオブジェクト権限のみを付与できます（リモート・ユーザーはデータベース・リンクのタイプによって示されます）。この仕組みは、ローカル・データを参照するビューの権限の管理と似ています。
シノニムは、分散データベース・システム内での位置など、基礎となるオブジェクトの個別情報を隠すので、分散環境と非分散環境の両方で役立ちます。基礎となるオブジェクトを名前変更または移動する必要がある場合でも、シノニムを再定義するだけで済み、シノニムをベースとするアプリケーションは引き続き通常どおり動作します。また、分散データベース・システムのユーザーが使用するSQL文も、シノニムによって単純化されます。
次のもののシノニムを作成できます。
シノニムはすべて、作成するデータベースのデータ・ディクショナリに格納されるスキーマ・オブジェクトです。シノニムでは、データベース・リンクを介したリモート表へのアクセスを簡単にするために、単一ワードでリモート・データにアクセスでき、それによって特定のオブジェクト名や位置をシノニムのユーザーから隠すことができます。
シノニムを作成するための構文は、次のとおりです。
CREATE [PUBLIC] 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.acme.com;
表scott.emp@hq.acme.comの位置はパブリック・シノニムによって隠されているので、使用場所に依存しない従業員管理アプリケーションを設計できます。アプリケーション内のSQL文は、パブリック・シノニムempを参照して表にアクセスできます。
また、emp表をhqデータベースからhrデータベースに移動する場合も、システムのノードでパブリック・シノニムを変更するだけで済みます。従業員管理アプリケーションは、すべてのノードで引き続き正常に動作します。
シノニムは、実際のオブジェクトへの参照です。特定のスキーマ・オブジェクトのシノニムにアクセスするユーザーは、元のスキーマ・オブジェクトそのものに対する権限を持っている必要があります。たとえば、ユーザーがシノニムにアクセスしようとして、そのシノニムが識別する表に対してユーザーが権限を持っていなければ、表またはビューが存在しないというエラーが発生します。
scottがリモート・オブジェクトscott.emp@sales.acme.comの別名としてローカル・シノニムempを作成したとします。この場合、scottは自分以外のローカル・ユーザーにシノニムのオブジェクト権限を付与することはできません。また、scottはシノニムのローカル権限を付与することもできません。この操作は最終的にsalesデータベースのリモートのemp表の権限を付与することになりますが、そのような操作は許可されていないためです。この動作は、ローカルの表またはビューの別名であるシノニムの権限管理とは異なります。
したがって、シノニムを位置の透過性のために使用する場合、ローカル権限は管理できません。ベース・オブジェクトのセキュリティは、リモート・ノードですべて管理されます。たとえば、ユーザーadminはemp_synシノニムのオブジェクト権限を付与することはできません。
ビューやプロシージャの定義で参照されるデータベース・リンクとは異なり、シノニムで参照されるデータベース・リンクを解決する際は、シノニムへの参照が解析される時点で有効なスキーマが所有しているプライベート・リンクが最初に検索されます。したがって、オブジェクトの適切な解決を保証するには、基礎となるオブジェクトのスキーマをシノニムの定義の中で指定することが特に重要になります。
プロシージャと呼ばれるPL/SQLプログラム・ユニットは、位置の透過性を提供できます。それには、次の方法があります。
プロシージャおよびファンクションには、スタンドアロンとパッケージのどちらの場合でも、リモート・データを参照するSQL文を含めることができます。たとえば、次の文で作成されるプロシージャを考えます。
CREATE PROCEDURE fire_emp (enum NUMBER) AS BEGIN DELETE FROM emp@hq.acme.com WHERE empno = enum; END;
ユーザーまたはアプリケーションがfire_empプロシージャをコールするときに、リモート表が変更されようとしていることは見かけ上わかりません。
プロシージャ内の文でローカルのプロシージャ、ビューまたはシノニムを使用して間接的にリモート・データを参照するときは、2層目の位置の透過性が可能です。たとえば、次の文はローカル・シノニムを定義します。
CREATE SYNONYM emp FOR emp@hq.acme.com;
このシノニムがあれば、次の文を使用してfire_empプロシージャを作成できます。
CREATE PROCEDURE fire_emp (enum NUMBER) AS BEGIN DELETE FROM emp WHERE empno = enum; END;
表emp@hq.acme.comを名前変更または移動した場合でも、表を参照するローカル・シノニムを変更するだけで済みます。このプロシージャをコールするプロシージャやアプリケーションを変更する必要はありません。
ローカル・プロシージャを使用してリモート・プロシージャをコールできます。リモート・プロシージャでは、要求されたデータ操作言語（DML）を実行できます。たとえば、scottがlocal_dbに接続して次のプロシージャを作成したとします。
CONNECT scott@local_db CREATE PROCEDURE fire_emp (enum NUMBER) AS BEGIN EXECUTE term_emp@hq.acme.com; END;
ここで、scottは、リモート・データベースに接続して次のリモート・プロシージャを作成するとします。
CONNECT scott@hq.acme.com CREATE PROCEDURE term_emp (enum NUMBER) AS BEGIN DELETE FROM emp WHERE empno = enum; END;
ユーザーまたはアプリケーションがlocal_dbに接続してfire_empプロシージャをコールすると、このプロシージャはさらにhq.acme.comにあるリモートのterm_empプロシージャをコールします。
たとえば、scottがローカルのsales.acme.comデータベースに接続して次のプロシージャを作成したとします。
CREATE PROCEDURE fire_emp (enum NUMBER) AS BEGIN DELETE FROM emp@hq.acme.com WHERE empno = enum; END;
この後、ユーザーpeggyがsupply.acme.comデータベースに接続し、scottがリモートのsalesデータベースで作成したプロシージャに対する次のシノニムを作成します。
SQL> CONNECT peggy@supply SQL> CREATE PUBLIC SYNONYM emp FOR scott.fire_emp@sales.acme.com;
supplyのローカル・ユーザーは、このシノニムを使用してsalesのプロシージャを実行できます。
ローカル・プロシージャに、リモートの表またはビューを参照する文が含まれているとします。ローカル・プロシージャの所有者は、EXECUTE権限を任意のユーザーに付与することができます。これにより、そのユーザーには、プロシージャを実行する権限とリモート・データに間接的にアクセスする許可が与えられます。
一般に、プロシージャはセキュリティの面で役に立ちます。プロシージャの中で参照されるオブジェクトの権限を明示的にコール側のユーザーに付与する必要はありません。
データベースでは、次に示す標準のDML文でリモート表を参照することが可能です。
結合、集計、副問合せおよびSELECT...FOR UPDATEを含む問合せでは、ローカルおよびリモートの表およびビューをいくつでも参照できます。たとえば、次の問合せは2つのリモート表の情報を結合します。
SELECT e.empno, e.ename, d.dname FROM scott.emp@sales.division3.acme.com e, jward.dept@hq.acme.com d WHERE e.deptno = d.deptno;
同機種環境では、UPDATE、INSERT、DELETEおよびLOCK TABLE文は、ローカルおよびリモートの両方の表を参照できます。リモート・データを更新するためのプログラミングは不要です。たとえば、次の文はローカル・データベースのjwardスキーマのemp表から行を選択して、scott.salesスキーマのリモート表empに新しい行を挿入します。
INSERT INTO scott.emp@sales.division3.acme.com SELECT * FROM jward.emp;
文の透過性には、いくつかの制限事項が適用されます。
INSERT INTO remote_table@link as SELECT * FROM local_table;
LONGおよびLONG RAWの列、順序、更新済みの表およびロック済みの表は、同じノードに存在する必要があります。
CREATE、ALTER、DROPなど）は使用できません。ただし、次の例のようにDBMS_SQLパッケージのプロシージャのリモート実行を使用する場合を除きます。
DBMS_SQL.PARSE@link_name(crs, 'drop table emp', v7);
異機種間システムでは、パススルー機能によってDDLの実行が可能です。
ANALYZE文のLIST CHAINED ROWS句は、リモート表を参照できません。
SYSDATE、USER、UID、USERENVなどの環境に依存したSQLファンクションは、データベースによって、その文（または文の一部）が実行される場所にかかわらず、常にローカル・サーバーについて評価されます。
ここでは、データベース・リンクの管理例を示します。
次の文では、ローカル・データベースにjaneとして接続し、データベースsalesに対してパブリック固定ユーザーscottのデータベース・リンクを作成しています。データベースには、ネット・サービス名sldbを介してアクセスします。
CONNECT jane@local CREATE PUBLIC DATABASE LINK sales.division3.acme.com CONNECT TO scott IDENTIFIED BY tiger USING 'sldb';
この文の実行後は、ローカル・データベースに接続する任意のユーザーが、sales.division3.acme.comデータベース・リンクを使用してリモート・データベースに接続できます。各ユーザーは、リモート・データベースのスキーマscottに接続します。
ユーザーは、次のSQL問合せを発行して、scottのリモート・スキーマの表empにアクセスできます。
SELECT * FROM emp@sales.division3.acme.com;
各アプリケーションまたはユーザー・セッションは、サーバーの共通アカウントへの接続をそれぞれ別々に作成します。リモート・データベースへの接続は、アプリケーションの実行中またはユーザー・セッションの継続期間中オープンしたままです。
次の例では、ローカル・データベースにdanaとして接続し、ネット・サービス名sldbを使用してsalesデータベースへのパブリック・リンクを作成しています。このリンクによって、リモート・データベースにscottとして接続でき、このユーザーがscottとして認証されます。
CONNECT dana@local CREATE SHARED PUBLIC DATABASE LINK sales.division3.acme.com CONNECT TO scott IDENTIFIED BY tiger AUTHENTICATED BY scott IDENTIFIED BY tiger USING 'sldb';
ローカルの共有サーバーに接続する任意のユーザーがこのデータベース・リンクを使用し、共有サーバー・プロセスを介してリモートのsalesデータベースに接続できます。その後ユーザーは、scottスキーマの表を問い合せることができます。
前述の例では、ローカルの共有サーバーはリモート・サーバーへの接続を1つずつ確立できます。ローカルの共有サーバー・プロセスでsales.division3.acme.comデータベース・リンクを介したリモート・サーバーへのアクセスが必要になると、そのたびにローカルの共有サーバー・プロセスが確立済みのネットワーク接続を再利用します。
次の例では、ローカル・データベースにlarryとして接続し、ネット・サービス名sldbを使用してデータベースへのパブリック・リンクを作成しています。
CONNECT larry@local CREATE PUBLIC DATABASE LINK redwood USING 'sldb';
ローカル・データベースに接続する任意のユーザーが、redwoodデータベース・リンクを使用できます。データベース・リンクを使用するローカル・データベースの接続ユーザーによって、リモート・スキーマが決まります。
接続ユーザーscottがデータベース・リンクを使用した場合、データベース・リンクはリモート・スキーマscottに接続します。接続ユーザーfoxがデータベース・リンクを使用した場合、データベース・リンクはリモート・スキーマfoxに接続します。
リモート・スキーマfoxがempスキーマ・オブジェクトを解決できない場合は、ローカル・データベースでローカル・ユーザーfoxが次の文を実行すると失敗します。つまり、sales.division3.acme.comのfoxスキーマにempが表、ビューまたは（パブリック）シノニムとして存在しない場合は、エラーが返されます。
CONNECT fox@local SELECT * FROM emp@redwood;
次の例では、ローカル・データベースにneilとして接続し、ネット・サービス名sldbを使用してsalesデータベースへの共有パブリック・リンクを作成しています。ユーザーは、crazy/horseというユーザーID/パスワードによって認証されます。次の文は、パブリック接続ユーザーの共有データベース・リンクを作成します。
CONNECT neil@local CREATE SHARED PUBLIC DATABASE LINK sales.division3.acme.com AUTHENTICATED BY crazy IDENTIFIED BY horse USING 'sldb';
ローカル・サーバーに接続する各ユーザーは、この共有データベース・リンクを使用してリモート・データベースに接続し、対応するリモート・スキーマの表を問い合せることができます。
ローカルの共有サーバー・プロセスは、それぞれリモート・サーバーへの接続を1つずつ確立します。ローカルのサーバー・プロセスでsales.division3.acme.comデータベース・リンクを介したリモート・サーバーへのアクセスが必要になると、たとえ接続ユーザーが異なるユーザーであっても、そのたびにローカルの共有サーバー・プロセスが確立済みのネットワーク接続を再利用します。
このデータベース・リンクが頻繁に使用されると、最終的にローカル・データベースのすべての共有サーバーがリモート接続を持つことになります。この時点で、新しいユーザーがこの共有データベース・リンクを使用しても、リモート・サーバーへの物理的な接続は新たに確立されません。
次の例では、ローカル・データベースに接続ユーザーとして接続し、ネット・サービス名sldbを使用してsalesデータベースへのパブリック・リンクを作成しています。次の文は、パブリック現行ユーザーのデータベース・リンクを作成します。
CONNECT bart@local CREATE PUBLIC DATABASE LINK sales.division3.acme.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.acme.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はグローバル・ユーザーでなくてもかまいません。
scottのリモート・スキーマへの固定ユーザー・データベース・リンクを使用しても、同じ結果を得ることができます。
