| Oracle® Database管理者ガイド 11gリリース2 (11.2) B56301-08 |
|
 前 |
 次 |
分散データベース・システムでは、各データベースが一意のグローバル・データベース名を持ちます。グローバル・データベース名は、システム内のデータベースを一意に識別します。分散データベースでの主な管理作業として、グローバル・データベース名の作成と変更の管理があります。
この項の内容は次のとおりです。
グローバル・データベース名は、データベース名とドメインの2つの構成要素から構成されます。データベース名とドメイン名は、データベースの作成時に次の初期化パラメータによって決まります。
| 構成要素 | パラメータ | 要件 | 例 |
|---|---|---|---|
| データベース名 | DB_NAME |
文字数は必ず8文字以内です。 | 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パラメータを変更してドメイン名の変更を反映することをお薦めします。
ローカル・データベースのリンクに付ける名前は、ローカル・データベースがグローバル・ネーミングを施行するかどうかによって異なります。ローカル・データベースがグローバル・ネーミングを施行する場合は、リモート・データベースのグローバル・データベース名をリンクの名前として使用する必要があります。たとえば、ローカルのhqサーバーに接続していて、リモートのmfgデータベースへのリンクを作成する場合は、ローカル・データベースがグローバル・ネーミングを施行していれば、mfgのグローバル・データベース名をリンク名として使用する必要があります。
データベース・リンク名の一部としてサービス名を使用することもできます。たとえば、サービス名sn1とsn2を使用してデータベースhq.example.comに接続している場合、hqがグローバル・ネーミングを施行していれば、hqへのリンク名を次のように作成できます。
HQ.EXAMPLE.COM@SN1
HQ.EXAMPLE.COM@SN2
グローバル・ネーミングがデータベースで施行されているかどうかを判断するには、データベースの初期化パラメータ・ファイルを調べるか、または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.EXAMPLE.COM
データベースのグローバル名のドメインを変更するには、ALTER DATABASE文を使用します。データベースを作成した後に初期化パラメータDB_DOMAINを変更しても、グローバル・データベース名やデータベース・リンク名の解決には効果がありません。
次の例は、名前変更文の構文を示しています。ここで、databaseはデータベース名、domainはネットワーク・ドメインを表します。
ALTER DATABASE RENAME GLOBAL_NAME TO database.domain;
グローバル・データベース名のドメインを変更するには、次の手順を実行します。
現行のグローバル・データベース名を確認します。たとえば、次の文を発行します。
SELECT * FROM GLOBAL_NAME; GLOBAL_NAME ---------------------------------------------------------------------------- SALES.EXAMPLE.COM
ALTER DATABASE文を使用して、グローバル・データベース名を変更します。たとえば、次のように入力します。
ALTER DATABASE RENAME GLOBAL_NAME TO sales.us.example.com;
GLOBAL_NAME表を問い合せて、新しい名前を確認します。たとえば、次のように入力します。
SELECT * FROM GLOBAL_NAME; GLOBAL_NAME ---------------------------------------------------------------------------- SALES.US.EXAMPLE.COM
この例では、ローカル・データベースのグローバル・データベース名のドメイン部分を変更します。また、部分指定のグローバル名を使用してデータベース・リンクを作成し、Oracle Databaseがその名前をどのように解決するのかを調べます。データベースは、初期化パラメータDB_DOMAINの値ではなく、ローカル・データベースの現行のグローバル・データベース名のドメイン部分を使用して部分名を解決することがわかります。
SALES.US.EXAMPLE.COMに接続してGLOBAL_NAMEデータ・ディクショナリ・ビューを問い合せ、現行のデータベース・グローバル名を確認します。
CONNECT SYSTEM@sales.us.example.com SELECT * FROM GLOBAL_NAME; GLOBAL_NAME ---------------------------------------------------------------------------- SALES.US.EXAMPLE.COM
V$PARAMETERビューを問い合せ、DB_DOMAIN初期化パラメータの現在の設定を調べます。
SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME = 'db_domain'; NAME VALUE --------- ----------- db_domain US.EXAMPLE.COM
部分指定のグローバル名のみを使用して、hqデータベースへのデータベース・リンクを作成します。
CREATE DATABASE LINK hq USING 'sales';
データベースは、リンクで指定されたデータベース名にローカル・データベースのグローバル・データベース名のドメイン部分を追加して、このリンクのグローバル・データベース名を拡張します。
USER_DB_LINKSを問い合せて、データベースが部分指定のグローバル・データベース名を解決するために使用したドメイン名を確認します。
SELECT DB_LINK FROM USER_DB_LINKS; DB_LINK ------------------ HQ.US.EXAMPLE.COM
この結果は、ローカル・データベースのグローバル・データベース名のドメイン部分がus.example.comであることを示しています。データベースは、データベース・リンク作成時の部分的なデータベース・リンク名を解決するために、このドメインを使用します。
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
再度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を変更することには意味があります)。
データベース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初期化パラメータの設定は使用しません。
次に、前の情報が誤りで、salesはjp.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
再び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文の発行前の時点の設定と同じであることを示しています。
最後に、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データベース・リンクを訂正するには、必ずこのデータベース・リンクを削除してから再作成してください。 |
|
関連項目: DB_NAMEおよびDB_DOMAIN初期化パラメータの指定の詳細は、 |
アプリケーションによるデータおよびスキーマ・オブジェクトへのアクセスを分散データベース・システム全体にわたってサポートするために、必要なデータベース・リンクをすべて作成する必要があります。この項の内容は次のとおりです。
データベース・リンクは、リモート・データベースのオブジェクトへのアクセスを可能にするローカル・データベース内のポインタです。プライベート・データベース・リンクを作成するには、あらかじめ適切な権限が付与されている必要があります。次の表は、どのリンク・タイプのデータベースに対してどの権限が必要なのかを示しています。
| 権限 | データベース | この権限を必要とする操作 |
|---|---|---|
CREATE DATABASE LINK |
ローカル | プライベート・データベース・リンクの作成。 |
CREATE PUBLIC DATABASE LINK |
ローカル | パブリック・データベース・リンクの作成。 |
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
データベース・リンクを作成するときは、そのデータベース・リンクにアクセスするユーザーを決める必要があります。ここでは、3種類の基本的なリンク・タイプの作成方法について説明します。
プライベート・データベース・リンクを作成するには、次の文を指定します。ここで、link_nameはグローバル・データベース名または任意のリンク名を表します。
CREATE DATABASE LINK link_name ...;
プライベート・データベース・リンクの例を次に示します。
| SQL文 | 結果 |
|---|---|
CREATE DATABASE LINK supply.us.example.com; |
リモートのsupplyデータベースへの、グローバル・データベース名を使用したプライベート・リンク。
リンクは、接続ユーザーのユーザーID/パスワードを使用します。そのため、 |
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言語リファレンス』 |
パブリック・データベース・リンクを作成するには、キーワード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言語リファレンス』 |
以前のリリースでは、グローバル・データベース・リンクはOracle Names Serverで定義していました。Oracle Names Serverは非推奨になりました。現在はディレクトリ・サーバーが使用できるようになり、データベースはネット・サービス名によって識別されるようになりました。このマニュアルでは、ディレクトリ・サーバーでのネット・サービス名によるデータベースの識別をグローバル・データベース・リンクと呼びます。
グローバル・データベース・リンクとして動作するディレクトリ・エントリの作成方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
データベース・リンクは、あるデータベースから別のデータベースへの通信経路を定義します。アプリケーションがデータベース・リンクを使用してリモート・データベースに接続するとき、Oracle Databaseはローカル・アプリケーションの要求にかわってリモート・データベース内でデータベース・セッションを確立します。
プライベートまたはパブリックのデータベース・リンクを作成する際、固定ユーザー、現行ユーザーおよび接続ユーザーのデータベース・リンクを作成することで、リモート・データベースのどのスキーマにリンクが接続を確立するのかを指定できます。
固定ユーザー・データベース・リンクを作成するには、リモート・データベースへのアクセスに必要な資格証明(この場合はユーザー名とパスワード)をリンク定義に埋め込みます。
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/パスワードでリモート・データベースに接続します。 |
アプリケーションで固定ユーザー・データベース・リンクを使用するとき、ローカル・サーバーは必ずリモート・データベース内の固定リモート・スキーマへの接続を確立します。また、ローカル・サーバーはアプリケーションがリンクを使用してリモート・データベースにアクセスするときに、ネットワークを介して固定ユーザーの資格証明を送信します。
接続ユーザーおよび現行ユーザー・データベース・リンクでは、リンク定義に資格証明が含まれません。リモート・データベースへの接続に使用する資格証明は、データベース・リンクを参照するユーザーや、アプリケーションが実行する操作によって異なります。
|
注意: 多くの分散アプリケーションでは、ユーザーがリモート・データベースでの権限を持つ必要はありません。これを実現する簡単な方法の1つは、固定ユーザーまたは現行ユーザーのデータベース・リンクを含むプロシージャを作成することです。この方法では、プロシージャにアクセスするユーザーに対して第三者の権限が一時的に付与されます。 |
接続ユーザーと現行ユーザーの区別に関する概念の詳細は、「データベース・リンクのユーザー」を参照してください。
接続ユーザー・データベース・リンクを作成するには、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';
現行ユーザー・データベース・リンクを作成するには、リンク作成文で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言語リファレンス』を参照してください。 |
場合によっては、同じリモート・データベースを指すものの、異なる通信経路を使用してリモート・データベースへの接続を確立する同じタイプ(パブリックなど)のデータベース・リンクを複数作成する必要があります。次のような場合に、この方法が役立ちます。
リモート・データベースが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つのアットマーク(@)があることに注意してください。
標準のデータベース・リンクを使用してリモート・サーバーを参照するアプリケーションはすべて、ローカル・データベースとリモート・データベースの間で接続を確立します。多くのユーザーがアプリケーションを同時に実行した場合、ローカル・データベースとリモート・データベースの間で多数の接続が発生する可能性があります。
共有データベース・リンクを使用すると、ローカル・サーバーとリモート・サーバーの間で必要なネットワーク接続の数を制限できます。
この項の内容は次のとおりです。
アプリケーションおよび共有サーバーの構成を綿密に検討して、共有リンクを使用するかどうかを判断してください。簡単なガイドラインとして、データベース・リンクにアクセスするユーザー数がローカル・データベース内のサーバー・プロセス数よりもかなり多いと予測されるときは、共有データベース・リンクを使用します。
データベース・リンクに関して可能な3つの構成を次の表に示します。
| リンク・タイプ | サーバー・モード | 結果 |
|---|---|---|
| 非共有 | 専用/共有サーバー | アプリケーションで標準のパブリック・データベース・リンクを使用していて、100人のユーザーが同時に接続を要求した場合は、リモート・データベースへの直接ネットワーク接続が100必要になります。 |
| 共有 | 共有サーバー | ローカルの共有サーバー・モード・データベースに10の共有サーバー・プロセスが存在している場合、同じデータベース・リンクを使用するユーザーが100人いるときに必要となるリモート・サーバーへのネットワーク接続数は10以下になります。ローカルの各共有サーバー・プロセスが必要とするリモート・サーバーへの接続は、それぞれ1つで済む場合があります。 |
| 共有 | 専用 | 10のクライアントがローカルの専用サーバーに接続していて、各クライアントが同じ接続のセッションを10持っており(したがって全部で100のセッションを確立している)、各セッションで同じリモート・データベースを参照している場合、必要な接続は10で済みます。非共有データベース・リンクでは、100の接続が必要になります。 |
共有データベース・リンクは、必ずしもすべての状況で役立つとはかぎりません。たとえば、リモート・サーバーに接続するユーザーが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 password
AUTHENTICATED BY linkuser IDENTIFIED BY ostrich
USING 'sales';
|
関連項目: CREATE DATABASE LINK文の詳細は、『Oracle Database SQL言語リファレンス』 |
図32-1に示す構成では、ローカル・サーバーの共有サーバー・プロセスは専用のリモート・サーバー・プロセスを所有しています。この構成の利点は、ローカルの共有サーバーとリモートの専用サーバーとの間に直接的なネットワーク・トランスポートが存在することです。ただし、余分なバックエンド・サーバー・プロセスが必要になるというデメリットもあります。
図32-2に示す構成では、リモート・サーバーで共有サーバー・プロセスを使用しています。この構成では、多数の専用サーバー・プロセスは必要ありませんが、リモート・サーバーのディスパッチャを経由する接続が必要になります。この場合、ローカル・サーバーとリモート・サーバーの両方を共有サーバーとして構成する必要があります。
あるセッションでデータベース・リンクにアクセスする場合、そのセッションをクローズするまでリンクはオープンしたままです。リンクがオープンしているということは、そのリンクを介してアクセスしている各リモート・データベースのプロセスがアクティブであることを意味します。この状況では、次のような結果が生じます。
20人のユーザーがセッションをオープンしてローカル・データベースの同じパブリック・リンクにアクセスする場合、20のデータベース・リンク接続がオープンします。
20人のユーザーがセッションをオープンして各ユーザーがプライベート・リンクにアクセスする場合、20のデータベース・リンク接続がオープンします。
1人のユーザーがセッションを開始して20の異なるリンクにアクセスする場合、20のデータベース・リンク接続がオープンします。
セッションをクローズした後、セッションでアクティブだったリンクは自動的にクローズされます。ユーザーがリンクを手動でクローズする場合もあります。たとえば、次のようなときにリンクをクローズします。
リンクによって確立されたネットワーク接続がアプリケーションでそれほど頻繁に使用されないとき。
ユーザー・セッションを終了する必要があるとき。
リンクをクローズするには次の文を発行しますが、ここでlinknameはリンクの名前を表します。
ALTER SESSION CLOSE DATABASE LINK linkname;
この文は、現行セッションでアクティブなリンクのみをクローズします。
データベース・リンクは、表やビューと同様に削除できます。リンクがプライベートの場合は、自分のスキーマ内に存在する必要があります。リンクがパブリックの場合は、DROP PUBLIC DATABASE LINKシステム権限が必要です。
構文は次のとおりです。ここで、dblinkはリンクの名前を表します。
DROP [PUBLIC] DATABASE LINK dblink;
SQL*Plusを使用して、ローカル・データベースに接続します。たとえば、次のように入力します。
CONNECT scott@local_db
USER_DB_LINKSを問い合せて、所有しているリンクを確認します。たとえば、次のように入力します。
SELECT DB_LINK FROM USER_DB_LINKS; DB_LINK ----------------------------------- SALES.US.EXAMPLE.COM MKTG.US.EXAMPLE.COM 2 rows selected.
DROP DATABASE LINK文を使用して、目的のリンクを削除します。たとえば、次のように入力します。
DROP DATABASE LINK sales.us.example.com;
ローカル・データベースにDROP PUBLIC DATABASE LINK権限を持つユーザーとして接続します。たとえば、次のように入力します。
CONNECT SYSTEM@local_db AS SYSDBA
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.
DROP PUBLIC DATABASE LINK文を使用して、目的のリンクを削除します。たとえば、次のように入力します。
DROP PUBLIC DATABASE LINK sales.us.example.com;
静的な初期化パラメータOPEN_LINKSを使用すると、ユーザー・プロセスからリモート・データベースへの接続数を制限できます。このパラメータは、分散トランザクションにおいて1つのユーザー・セッションが同時に使用できるリモート接続数を制御します。
このパラメータを設定する際は、次の点を考慮してください。
設定値は、複数のデータベースを参照する1つのSQL文によって参照されるデータベースの数以上にします。
複数の分散データベースに継続してアクセスする場合は、設定値を大きくします。たとえば、3つのデータベースに定期的にアクセスする場合は、OPEN_LINKSを3以上に設定します。
OPEN_LINKSのデフォルト値は4です。OPEN_LINKSを0(ゼロ)に設定した場合、分散トランザクションは許可されません。
|
関連項目: OPEN_LINKS初期化パラメータの詳細は、『Oracle Databaseリファレンス』 |
各データベースのデータ・ディクショナリには、そのデータベース内にあるデータベース・リンクの定義がすべて格納されています。データ・ディクショナリ表およびビューを使用して、リンクに関する情報を取得できます。この項の内容は次のとおりです。
次のビューには、ローカル・データベースで定義され、データ・ディクショナリに格納されているデータベース・リンクが表示されます。
| ビュー | 目的 |
|---|---|
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.
自分のセッションで現在オープンしているデータベース・リンク接続がわかれば役に立つ場合があります。しかし、SYSDBAとして接続している場合には、ビューを問い合せてすべてのセッションでオープンしているすべてのリンクを判断することはできず、現在作業中のセッションのリンク情報にアクセスすることしかできません。
次のビューには、現行セッションで現在オープンしているデータベース・リンク接続が表示されます。
これらのデータ・ディクショナリ・ビューには、データベース・リンクに関する同じ基本情報が含まれていますが、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
必要なデータベース・リンクの構成が完了した後、各種のツールを使用してデータベース・システムの分散的な性質をユーザーから隠すことができます。言い換えれば、ユーザーはリモート・オブジェクトに対してあたかもローカル・オブジェクトであるかのようにアクセスできるようになります。ここでは、分散機能をユーザーから隠す方法について説明します。
ローカル・ビューは、分散データベース・システムにおいてローカルおよびリモートの表に対する位置の透過性を提供できます。
たとえば、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;
ユーザーはこのビューにアクセスするときに、データが物理的に格納されている場所や、複数の表のデータにアクセスしているかどうかについて知る必要はありません。したがって、ユーザーは必要な情報をより簡単に取得できます。たとえば、次の問合せは、ローカルおよびリモートの両方のデータベース表からのデータを提供します。
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.example.com;
表scott.emp@hq.example.comの位置はパブリック・シノニムによって隠されているので、使用場所に依存しない従業員管理アプリケーションを設計できます。アプリケーション内のSQL文は、パブリック・シノニムempを参照して表にアクセスできます。
また、emp表をhqデータベースからhrデータベースに移動する場合も、システムのノードでパブリック・シノニムを変更するだけで済みます。従業員管理アプリケーションは、すべてのノードで引き続き正常に動作します。
シノニムは、実際のオブジェクトへの参照です。特定のスキーマ・オブジェクトのシノニムにアクセスするユーザーは、元のスキーマ・オブジェクトそのものに対する権限を持っている必要があります。たとえば、ユーザーがシノニムにアクセスしようとして、そのシノニムが識別する表に対してユーザーが権限を持っていなければ、表またはビューが存在しないというエラーが発生します。
scottが、リモート・オブジェクトscott.emp@sales.example.comの別名としてローカル・シノニムempを作成したとします。scottは、このシノニムのオブジェクト権限を別のローカル・ユーザーに付与できません。この操作はsalesデータベースのリモートのemp表の権限の付与に相当しますが、これは許可されていないので、scottはこのシノニムのローカル権限を付与することはできません。この動作は、ローカルの表またはビューの別名であるシノニムの権限管理とは異なります。
したがって、シノニムを位置の透過性のために使用する場合、ローカル権限は管理できません。ベース・オブジェクトのセキュリティは、リモート・ノードですべて管理されます。たとえば、ユーザーadminはemp_synシノニムのオブジェクト権限を付与することはできません。
ビューやプロシージャの定義で参照されるデータベース・リンクとは異なり、シノニムで参照されるデータベース・リンクを解決する際は、シノニムへの参照が解析される時点で有効なスキーマが所有しているプライベート・リンクが最初に検索されます。したがって、オブジェクトの適切な解決を保証するには、基礎となるオブジェクトのスキーマをシノニムの定義の中で指定することが特に重要になります。
プロシージャと呼ばれるPL/SQLプログラム・ユニットは、位置の透過性を提供できます。それには、次の方法があります。
プロシージャおよびファンクションには、スタンドアロンとパッケージのどちらの場合でも、リモート・データを参照する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を名前変更または移動した場合でも、表を参照するローカル・シノニムを変更するだけで済みます。このプロシージャをコールするプロシージャやアプリケーションを変更する必要はありません。
ローカル・プロシージャを使用してリモート・プロシージャをコールできます。リモート・プロシージャでは、要求されたデータ操作言語(DML)を実行できます。たとえば、scottがlocal_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プロシージャをコールします。
たとえば、scottがローカルのsales.example.comデータベースに接続して次のプロシージャを作成したとします。
CREATE PROCEDURE fire_emp (enum NUMBER) AS BEGIN DELETE FROM emp@hq.example.com WHERE empno = enum; END;
この後、ユーザーpeggyがsupply.example.comデータベースに接続し、scottがリモートのsalesデータベースで作成したプロシージャに対する次のシノニムを作成します。
SQL> CONNECT peggy@supply SQL> CREATE PUBLIC SYNONYM emp FOR scott.fire_emp@sales.example.com;
supplyのローカル・ユーザーは、このシノニムを使用してsalesのプロシージャを実行できます。
データベースでは、次に示す標準の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;
同機種環境では、UPDATE、INSERT、DELETEおよび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)文(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ファンクションは、データベースによって、その文(または文の一部)が実行される場所にかかわらず、常にローカル・サーバーについて評価されます。
|
注意: Oracle Databaseは、USERENVファンクションを問合せの用途でのみサポートしています。 |
リモート・オブジェクトのアクセスに関連して、次のようなパフォーマンス上の制限事項があります。
リモート・ビューは統計データを持ちません。
パーティション表に対する問合せは、最適化されない場合があります。
リモート表で考慮される索引の数は20以下です。
コンポジット索引で使用される列の数は20以下です。
Oracle Databaseの分散読込み一貫性の実装には制限があり、これによってあるノードが別のノードに対して古い状態になる可能性があります。問合せを実行したときに、読込み一貫性に従ってデータが取得されているにもかからわず、そのデータが古い場合があります。この問題の管理方法の詳細は、「読込み一貫性の管理」を参照してください。
|
関連項目: DBMS_SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』 |
次の文では、ローカル・データベースに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;
各アプリケーションまたはユーザー・セッションは、サーバーの共通アカウントへの接続をそれぞれ別々に作成します。リモート・データベースへの接続は、アプリケーションの実行中またはユーザー・セッションの継続期間中オープンしたままです。
次の例では、ローカル・データベースに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データベース・リンクを介したリモート・サーバーへのアクセスが必要になると、そのたびにローカルの共有サーバー・プロセスは確立済のネットワーク接続を再利用します。
次の例では、ローカル・データベースにlarryとして接続し、ネット・サービス名sldbを使用してデータベースへのパブリック・リンクを作成しています。
CONNECT larry@local CREATE PUBLIC DATABASE LINK redwood USING 'sldb';
ローカル・データベースに接続する任意のユーザーが、redwoodデータベース・リンクを使用できます。データベース・リンクを使用するローカル・データベースの接続ユーザーによって、リモート・スキーマが決まります。
接続ユーザーscottがデータベース・リンクを使用した場合、データベース・リンクはリモート・スキーマscottに接続します。接続ユーザーfoxがデータベース・リンクを使用した場合、データベース・リンクはリモート・スキーマfoxに接続します。
リモート・スキーマfoxがempスキーマ・オブジェクトを解決できない場合は、ローカル・データベースでローカル・ユーザーfoxが次の文を実行すると失敗します。つまり、sales.division3.example.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.example.com AUTHENTICATED BY crazy IDENTIFIED BY horse USING 'sldb';
ローカル・サーバーに接続する各ユーザーは、この共有データベース・リンクを使用してリモート・データベースに接続し、対応するリモート・スキーマの表を問い合せることができます。
ローカルの共有サーバー・プロセスは、それぞれリモート・サーバーへの接続を1つずつ確立します。ローカルのサーバー・プロセスでsales.division3.example.comデータベース・リンクを介したリモート・サーバーへのアクセスが必要になると、たとえ接続ユーザーが異なるユーザーであっても、そのたびにローカルの共有サーバー・プロセスは確立済のネットワーク接続を再利用します。
このデータベース・リンクが頻繁に使用されると、最終的にローカル・データベースのすべての共有サーバーがリモート接続を持つことになります。この時点で、新しいユーザーがこの共有データベース・リンクを使用しても、リモート・サーバーへの物理的な接続は新たに確立されません。
次の例では、ローカル・データベースに接続ユーザーとして接続し、ネット・サービス名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のリモート・スキーマへの固定ユーザー・データベース・リンクを使用しても、同じ結果を得ることができます。
