分散データベースの管理には、グローバル名の管理、データベース・リンクの管理、位置および文の透過性の作成などのタスクが含まれます。
分散データベース・システムでは、各データベースが一意のグローバル・データベース名を持ちます。グローバル・データベース名は、システム内のデータベースを一意に識別します。分散データベースでの主な管理作業として、グローバル・データベース名の作成と変更の管理があります。
グローバル・データベース名は、データベース名とドメインの2つの構成要素から構成されます。
データベース名とドメイン名は、データベースの作成時に次の初期化パラメータによって決まります。
構成要素 | パラメータ | 要件 | 例 |
---|---|---|---|
データベース名 |
|
30文字以下である必要があります。 |
|
データベースが存在するドメイン |
|
インターネットの標準規則に従う必要があります。ドメイン名のレベルはドットで区切る必要があり、ドメイン名の順序は、左から右に向かってリーフからルートの順になります。 |
|
次に、有効なグローバル・データベース名の例を示します。
DB_NAME | DB_DOMAIN | グローバル・データベース名 |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
DB_DOMAIN
初期化パラメータが重要となるのは、データベースの作成時に、この初期化パラメータを(DB_NAME
パラメータと一緒に)使用して、データベースのグローバル名を構成するときだけです。この時点で、データベースのグローバル名はデータ・ディクショナリに格納されます。グローバル名を変更するには、初期化パラメータ・ファイル内のDB_DOMAIN
パラメータを変更するのではなく、ALTER DATABASE
文を使用する必要があります。ただし、次回のデータベースの起動を行う前にDB_DOMAIN
パラメータを変更してドメイン名の変更を反映することをお薦めします。
ローカル・データベースのリンクに付ける名前は、ローカル・データベースがグローバル・ネーミングを施行するかどうかによって異なります。
ローカル・データベースがグローバル・ネーミングを施行する場合は、リモート・データベースのグローバル・データベース名をリンクの名前として使用する必要があります。たとえば、ローカルのhq
サーバーに接続していて、リモートのmfg
データベースへのリンクを作成する場合は、ローカル・データベースがグローバル・ネーミングを施行していれば、mfg
のグローバル・データベース名をリンク名として使用する必要があります。
データベース・リンク名の一部としてサービス名を使用することもできます。たとえば、サービス名sn1
およびsn2
を使用してデータベースhq.example.com
に接続する場合、グローバル・ネーミングが施行されていれば、次のような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;
グローバル・データベース名のドメインを変更するには、次の手順を実行します。
アプリケーションによるデータおよびスキーマ・オブジェクトへのアクセスを分散データベース・システム全体にわたってサポートするために、必要なデータベース・リンクをすべて作成する必要があります。
データベース・リンクは、リモート・データベースのオブジェクトへのアクセスを可能にするローカル・データベース内のポインタです。プライベート・データベース・リンクを作成するには、あらかじめ適切な権限が付与されている必要があります。
次の表は、どのリンク・タイプのデータベースに対してどの権限が必要なのかを示しています。
権限 | データベース | この権限を必要とする操作 |
---|---|---|
|
ローカル |
プライベート・データベース・リンクの作成。 |
|
ローカル |
パブリック・データベース・リンクの作成。 |
|
リモート |
任意タイプのデータベース・リンクの作成。 |
現在使用可能な権限を確認するには、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
データベース・リンクを作成するときは、そのデータベース・リンクにアクセスするユーザーを決める必要があります。
プライベート・データベース・リンクを作成するには、CREATE DATABASE LINK
文を使用します。
プライベート・データベース・リンクを作成するには、次の文を指定します。ここで、link_nameはグローバル・データベース名または任意のリンク名を表します。
CREATE DATABASE LINK link_name ...;
プライベート・データベース・リンクの例を次に示します。
SQL文 | 結果 |
---|---|
|
リモートの リンクは、接続ユーザーのユーザーID/パスワードを使用します。そのため、 |
|
サービス名 |
|
サービス名 注意: 現行ユーザーと接続ユーザーは異なる場合があります。また、現行ユーザーは、リンクに関係している両方のデータベースのグローバル・ユーザーであることが必要です(「データベース・リンクのユーザー」を参照)。現行ユーザー・リンクは、Oracle Advanced Securityオプションの一部です。 |
関連項目:
CREATE DATABASE LINK
の構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
パブリック・データベース・リンクを作成するには、CREATE PUBLIC DATABASE LINK
文を使用します。
パブリック・データベース・リンクを作成するには、キーワードPUBLIC
を使用します。ここで、link_nameはグローバル・データベース名または任意のリンク名を表します。
CREATE PUBLIC DATABASE LINK link_name ...;
パブリック・データベース・リンクの例を次に示します。
SQL文 | 結果 |
---|---|
|
リモートの |
|
サービス名 注意: 現行ユーザーと接続ユーザーは異なる場合があります。また、現行ユーザーは、リンクに関係している両方のデータベースのグローバル・ユーザーであることが必要です(「データベース・リンクのユーザー」を参照)。 |
|
リモートの |
関連項目:
CREATE PUBLIC DATABASE LINK
の構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
データベース・リンクは、あるデータベースから別のデータベースへの通信経路を定義します。アプリケーションがデータベース・リンクを使用してリモート・データベースに接続するとき、Oracle Databaseはローカル・アプリケーションの要求にかわってリモート・データベース内でデータベース・セッションを確立します。プライベートまたはパブリックのデータベース・リンクを作成する際、固定ユーザー、現行ユーザーおよび接続ユーザーのデータベース・リンクを作成することで、リモート・データベースのどのスキーマにリンクが接続を確立するのかを指定できます。
アプリケーションで固定ユーザー・データベース・リンクを使用するとき、ローカル・サーバーは必ずリモート・データベース内の固定リモート・スキーマへの接続を確立します。また、ローカル・サーバーはアプリケーションがリンクを使用してリモート・データベースにアクセスするときに、ネットワークを介して固定ユーザーの資格証明を送信します。
固定ユーザー・データベース・リンクを作成するには、リモート・データベースへのアクセスに必要な資格証明(この場合はユーザー名とパスワード)をリンク定義に埋め込みます。
CREATE DATABASE LINK ... CONNECT TO username IDENTIFIED BY password ...;
固定ユーザー・データベース・リンクの例を次に示します。
SQL文 | 結果 |
---|---|
|
リモートの |
|
サービス名 |
接続ユーザーおよび現行ユーザー・データベース・リンクでは、リンク定義に資格証明が含まれません。リモート・データベースへの接続に使用する資格証明は、データベース・リンクを参照するユーザーや、アプリケーションが実行する操作によって異なります。
注意:
多くの分散アプリケーションでは、ユーザーがリモート・データベースでの権限を持つ必要はありません。これを実現する簡単な方法の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';
現行ユーザー・データベース・リンクを作成するには、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言語リファレンス』を参照してください。
場合によっては、同じリモート・データベースを指すものの、異なる通信経路を使用してリモート・データベースへの接続を確立する同じタイプ(パブリックなど)のデータベース・リンクを複数作成する必要があります。
次のような場合に、この方法が役立ちます。
リモート・データベースが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言語リファレンス』を参照してください。
共有データベース・リンクは、様々な方法で構成できます。
ローカル・サーバーの共有サーバー・プロセスは、専用リモート・サーバー・プロセスを所有できます。
この構成の利点は、ローカルの共有サーバーとリモートの専用サーバーとの間に直接的なネットワーク・トランスポートが存在することです。ただし、余分なバックエンド・サーバー・プロセスが必要になるというデメリットもあります。
注意:
リモート・サーバーは、共有サーバーまたは専用サーバーのどちらか一方にできます。ローカル・サーバーとリモート・サーバーの間には専用の接続が存在します。リモート・サーバーが共有サーバーのときは、サービス名の定義にSERVER=DEDICATED
句を使用することで、専用サーバー接続を強制できます。
リモート・サーバー上の共有サーバー・プロセスを使用して共有リンクを作成できます。
この構成では、多数の専用サーバー・プロセスは必要ありませんが、リモート・サーバーのディスパッチャを経由する接続が必要になります。この場合、ローカル・サーバーとリモート・サーバーの両方を共有サーバーとして構成する必要があります。
関連項目:
共有サーバー・オプションの詳細は、「共有サーバー・プロセス」
データベース・リンクの管理には、クローズ、削除、およびアクティブな接続数の制限などのタスクが含まれます。
あるセッションでデータベース・リンクにアクセスする場合、そのセッションをクローズするまでリンクはオープンしたままです。手動でデータベース・リンクをクローズするには、ALTER SESSION CLOSE DATABASE LINK
文を使用します。
リンクがオープンしているということは、そのリンクを介してアクセスしている各リモート・データベースのプロセスがアクティブであることを意味します。この状況では、次のような結果が生じます。
20人のユーザーがセッションをオープンしてローカル・データベースの同じパブリック・リンクにアクセスする場合、20のデータベース・リンク接続がオープンします。
20人のユーザーがセッションをオープンして各ユーザーがプライベート・リンクにアクセスする場合、20のデータベース・リンク接続がオープンします。
1人のユーザーがセッションを開始して20の異なるリンクにアクセスする場合、20のデータベース・リンク接続がオープンします。
セッションをクローズした後、セッションでアクティブだったリンクは自動的にクローズされます。ユーザーがリンクを手動でクローズする場合もあります。たとえば、次のようなときにリンクをクローズします。
リンクによって確立されたネットワーク接続がアプリケーションでそれほど頻繁に使用されないとき。
ユーザー・セッションを終了する必要があるとき。
リンクをクローズするには次の文を発行しますが、ここでlinknameはリンクの名前を表します。
ALTER SESSION CLOSE DATABASE LINK linkname;
この文は、現行セッションでアクティブなリンクのみをクローズします。
データベース・リンクは、表やビューと同様に削除できます。リンクがプライベートの場合は、自分のスキーマ内に存在する必要があります。リンクがパブリックの場合は、DROP PUBLIC DATABASE LINK
システム権限が必要です。
構文は次のとおりです。ここで、dblinkはリンクの名前を表します。
DROP [PUBLIC] DATABASE LINK dblink;
静的な初期化パラメータOPEN_LINKS
を使用すると、ユーザー・プロセスからリモート・データベースへの接続数を制限できます。
このパラメータは、分散トランザクションにおいて1つのユーザー・セッションが同時に使用できるリモート接続数を制御します。
このパラメータを設定する際は、次の点を考慮してください。
設定値は、複数のデータベースを参照する1つのSQL文によって参照されるデータベースの数以上にします。
複数の分散データベースに継続してアクセスする場合は、設定値を大きくします。たとえば、3つのデータベースに定期的にアクセスする場合は、OPEN_LINKS
を3以上に設定します。
OPEN_LINKS
のデフォルト値は4です。OPEN_LINKS
を0(ゼロ)に設定した場合、分散トランザクションは許可されません。
関連項目:
OPEN_LINKS
初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
各データベースのデータ・ディクショナリには、そのデータベース内にあるデータベース・リンクの定義がすべて格納されています。データ・ディクショナリ表およびビューを使用して、リンクに関する情報を取得できます。
ローカル・データベースに定義され、データ・ディクショナリに格納されているデータベース・リンクは、ビュー・セットに表示されます。
:
ビュー | 目的 |
---|---|
|
データベース内のデータベース・リンクがすべてリストされます。 |
|
接続ユーザーがアクセス可能なデータベース・リンクがすべてリストされます。 |
|
接続ユーザーが所有しているデータベース・リンクがすべてリストされます。 |
これらのデータ・ディクショナリ・ビューには、データベース・リンクに関する同じ基本情報が含まれていますが、いくつか例外もあります。
列 | 対象となるビュー | 説明 |
---|---|---|
|
|
データベース・リンクを作成したユーザー。リンクがパブリックの場合、ユーザーは |
|
すべて |
データベース・リンクの名前。 |
|
すべて |
リンク定義に固定ユーザーが含まれている場合、この列には固定ユーザーのユーザー名が表示されます。固定ユーザーが含まれていない場合、この列は |
|
|
使用されません。下位互換性のためにのみ維持されています。 |
|
すべて |
リモート・データベースへの接続に使用されるネット・サービス名。 |
|
すべて |
データベース・リンクの作成日時。 |
どのユーザーでも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
として接続している場合には、ビューを問い合せてすべてのセッションでオープンしているすべてのリンクを判断することはできず、現在作業中のセッションのリンク情報にアクセスすることしかできません。
次のビューには、現行セッションで現在オープンしているデータベース・リンク接続が表示されます。
ビュー | 目的 |
---|---|
|
自分のセッションでオープンしているすべてのデータベース・リンク、つまり、 |
|
自分のセッションでオープンしているすべてのデータベース・リンクと対応するインスタンスがリストされます。このビューは、Oracle Real Application Clusters構成の使用時に役立ちます。 |
これらのデータ・ディクショナリ・ビューには、データベース・リンクに関する同じ基本情報が含まれていますが、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.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 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
のプロシージャを実行できます。
分散データベースでは、いくつかの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;
同機種環境では、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
のリモート・スキーマへの固定ユーザー・データベース・リンクを使用しても、同じ結果を得ることができます。