| Oracle® Database管理者ガイド 12cリリース1 (12.1) B71301-11 |
|
 前 |
 次 |
分散データベースに関連する概念には、分散データベース・アーキテクチャ、データベース・リンク、トランザクション処理、アプリケーション開発およびキャラクタ・セットのサポートが含まれます。
分散データベース・システムを使用すると、アプリケーションはローカル・データベースおよびリモート・データベースのデータにアクセスできます。同機種間分散データベース・システムでは、個々のデータベースはOracle Databaseです。異機種間分散データベース・システムでは、少なくともデータベースの1つがOracle Database以外のデータベースです。分散データベースは、クライアント/サーバー・アーキテクチャを使用して情報の要求を処理します。
同機種間分散データベース・システムには、Oracleデータベースのみが含まれます。
同機種間分散データベース・システムとは、1つ以上のシステムに存在する2つ以上のOracle Databaseのネットワークを表します。
図31-1は、hq、mfgおよびsalesの3つのデータベースを接続している分散システムを示しています。アプリケーションは、1つの分散環境内にある複数のデータベースのデータに同時にアクセスしたり、データを同時に変更できます。たとえば、ローカル・データベースmfgの製造(Mfg)クライアントから発行する1回の問合せによって、ローカル・データベースのproducts表のデータとリモート・データベースhqのdept表のデータを結合したデータを取得できます。
クライアント・アプリケーションに対して、データベースの位置とプラットフォームは透過的です。また、分散システム内のリモート・オブジェクトに対してユーザーがローカル・オブジェクトと同じ構文を使用してアクセスできるように、リモート・オブジェクトのシノニムを作成することもできます。たとえば、mfgデータベースに接続しているときにデータベースhqのデータにアクセスする場合は、リモートのdept表に対するシノニムをmfg上に作成することで、次の問合せを発行できます。
SELECT * FROM dept;
このように、分散システムではローカル・データベースと同様のデータ・アクセスが可能です。mfgのユーザーは、アクセスするデータがリモート・データベースに存在していることを知る必要はありません。
Oracle Databaseの分散データベース・システムは、異なるリリースのOracle Databaseで構成することが可能です。サポートされているOracle Databaseのリリースは、すべて分散データベース・システムに加わることができます。しかし、分散データベースを使用するアプリケーションでは、システムの各ノードで使用可能な機能を理解しておく必要があります。分散データベース・アプリケーションでは、Oracle Databaseでのみ使用可能なSQLの拡張をOracle7で実行できるかのような想定を行ってはなりません。
分散データベースおよび分散処理という用語は密接に関連していますが、その意味は異なります。
この2つの用語の定義は、次のとおりです。
分散データベース
分散システムを構成する一連のデータベース。アプリケーションからは単一のデータソースのように見えます。
分散処理
アプリケーションが自身のタスクをネットワーク内の異なるコンピュータ間に分散するときに発生する操作。たとえば、データベース・アプリケーションは通常、フロントエンド側のプレゼンテーション・タスクをクライアント・コンピュータに配置し、バックエンド側のデータベース・サーバーでデータベースへの共有アクセスを管理できるようにします。このことから、分散データベース・アプリケーション処理システムは、一般にクライアント/サーバー・データベース・アプリケーション・システムとも呼ばれます。
分散データベース・システムは、分散処理アーキテクチャを利用しています。たとえば、Oracle Databaseサーバーは、別のOracle Databaseサーバーが管理しているデータを要求するときにクライアントとして動作します。
分散データベース・システムおよびデータベース・レプリケーションという用語は関連していますが、その意味は異なります。
純粋な(つまり、レプリケートされていない)分散データベースでは、すべてのデータとそれをサポートしているデータベース・オブジェクトの単一コピーが管理されています。通常、分散データベース・アプリケーションは、分散トランザクションを使用してローカルおよびリモートのデータにアクセスし、グローバル・データベースをリアルタイムで変更します。
注意:
このマニュアルでは、純粋な分散データベースについてのみ説明しています。
レプリケーションという用語は、分散システムに属している複数のデータベースの間でデータベース・オブジェクトをコピーし、管理する操作を指します。レプリケーションは分散データベース・テクノロジに依存していますが、データベース・レプリケーションを使用すると、純粋な分散データベース環境では得られないような利点をアプリケーションが利用できます。
一般に、レプリケーションを使用すると代替のデータ・アクセス手段が提供されるので、ローカル・データベースのパフォーマンスが向上し、アプリケーションの可用性が保護されます。たとえば、アプリケーションは、ネットワークの通信量を最小限に抑えてパフォーマンスの最大化を図るために、リモート・サーバーではなくローカル・データベースにアクセスできます。また、ローカル・サーバーに障害が発生しても、レプリケートされたデータを持つ他のサーバーにアクセスできれば、アプリケーションは引き続き実行できます。
異機種間分散データベース・システムには、Oracleデータベースと非Oracleデータベースの両方が含まれます。
異機種間分散データベース・システムでは、少なくともデータベースの1つがOracle Database以外のシステムです。アプリケーションにとって、異機種間分散データベース・システムは1つのローカルなOracle Databaseのように見えます。ローカルのOracle Databaseサーバーでは、データの分散と異機種性は隠されています。
Oracle Databaseサーバーは、Oracle Database以外のシステムへのアクセスに、Oracle異機種間サービスとエージェントを使用します。Oracle Database以外のデータ・ストアにOracle Transparent Gatewayを使用してアクセスする場合、エージェントはシステム固有のアプリケーションになります。たとえば、Oracle Database分散システムにSybaseデータベースを含める場合は、そのシステム内のOracle DatabaseがSybaseデータベースとやり取りできるように、Sybase固有のTransparent Gatewayを入手する必要があります。
Oracle Database以外のシステムがODBCまたはOLE DBプロトコルをサポートしている場合は、かわりにGeneric Connectivityを使用してOracle Database以外のデータ・ストアにアクセスできます。
注意:
このマニュアルでOracle異機種間サービスについて説明しているのは、この章の概要的な内容のみです。異機種間サービスの詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』を参照してください。
異機種間サービスはOracle Databaseサーバー内部に統合されたコンポーネントであり、現在のOracle Transparent Gateway製品群を実現するためのテクノロジです。
異機種間サービスは、Oracle Databaseゲートウェイ製品とその他の異機種間アクセス機能に対して共通のアーキテクチャと管理のメカニズムを提供します。また、以前にリリースされたほとんどのOracle Transparent Gatewayのユーザーに上位互換の機能を提供します。
Oracle Database以外の個々のシステムにアクセスする場合、異機種間サービスはTransparent Gatewayエージェントを使用して、Oracle Database以外の特定のシステムとのインタフェースの役目を果たします。エージェントはOracle Database以外のシステムに固有のものであり、システムのタイプごとに異なるエージェントが必要になります。
Transparent Gatewayエージェントは、Oracle Databaseサーバー内の異機種間サービス・コンポーネントを使用して、Oracle DatabaseシステムとOracle Database以外のシステムとの間のやり取りを容易にします。エージェントはOracle Databaseサーバーのかわりに、Oracle Database以外のシステムでSQLとトランザクション要求を実行します。
関連項目:
Transparent Gatewayの詳細は、オラクル社が提供するゲートウェイ固有のマニュアルを参照してください。
Generic Connectivityを使用すると、異機種間サービスODBCエージェントまたは異機種間サービスOLE DBエージェントのどちらかを使用してOracle Database以外のデータ・ストアに接続できます。
これらはどちらもOracle製品に標準機能として組み込まれています。ODBCまたはOLE DBの規格と互換性があれば、どのようなデータソースでもGeneric Connectivityエージェントを使用してアクセスできます。
Generic Connectivityの利点は、必ずしもシステム固有のエージェントを別途購入して構成する必要がないことです。ODBCドライバまたはOLE DBドライバを使用して、エージェントとインタフェースできます。ただし、一部のデータ・アクセス機能はTransparent Gatewayエージェントでしか利用できません。
データベース・サーバーとはデータベースを管理するOracleソフトウェアのことであり、クライアントとはサーバーの情報を要求するアプリケーションのことです。ネットワーク内の各コンピュータはノードと呼ばれ、1つ以上のデータベースのホストとなることができます。分散データベース・システム内の各ノードは、状況に応じてクライアント、サーバー、あるいはその両方として機能します。
図31-2のhqデータベースのホストは、そのローカル・データに対して文が発行されたときはデータベース・サーバーとして機能します。たとえば、トランザクション内の2番目の文は、ローカルのdept表に対して文を発行しています。しかし、リモート・データに対して文が発行されたときはクライアントとして機能します。たとえば、トランザクション内の最初の文は、salesデータベース内のリモートの表empに対して発行されています。
クライアントは、データベース・サーバーに直接または間接に接続できます。直接接続となるのは、クライアントがサーバーに接続し、そのサーバー上に存在するデータベースの情報にアクセスするときです。たとえば、図31-2のように、hqデータベースに接続してこのデータベースのdept表にアクセスする場合は、次の文を発行できます。
SELECT * FROM dept;
この場合は、リモート・データベースのオブジェクトにアクセスしていないので、問合せは直接になります。
これに対して、間接接続となるのは、クライアントがサーバーに接続した後、別の異なるサーバー上のデータベースに格納されている情報にアクセスするときです。たとえば、図31-2のように、hqデータベースに接続した後、リモートのsalesデータベースのemp表にアクセスする場合は、次の文を発行できます。
SELECT * FROM emp@sales;
この場合は、アクセスしようとしているオブジェクトが直接接続しているデータベース上にないため、問合せは間接になります。
分散データベース・システムの中心的な概念となるのが、データベース・リンクです。データベース・リンクは2つの物理データベース・サーバー間の接続であり、データベース・リンクを使用すると、クライアントから1つの論理データベースとしてこれらのサーバーにアクセスできます。
データベース・リンクは、あるOracle Databaseサーバーから別のデータベース・サーバーへの一方向の通信経路を定義するポインタです。
パブリック・データベース・リンクおよびプライベート・データベース・リンクの場合、実際には、リンク・ポインタはデータ・ディクショナリ表のエントリとして定義されます。リンクにアクセスするには、データ・ディクショナリ・エントリのあるローカル・データベースに接続する必要があります。グローバル・データベース・リンクの場合、リンク・ポインタはディレクトリ・サービスで定義されます。様々なタイプのデータベース・リンクの詳細は、「データベース・リンクのタイプ」を参照してください。
データベース・リンク接続が一方向であるということは、たとえばローカル・データベースAに接続しているクライアントはデータベースAに格納されているリンクを使用してリモート・データベースBの情報にアクセスできるが、データベースBに接続しているユーザーは同じリンクを使用してデータベースAのデータにアクセスできないことを意味します。データベースBのローカル・ユーザーがデータベースAのデータにアクセスする場合には、データベースBのデータ・ディクショナリに格納されるリンクを定義する必要があります。
データベース・リンク接続を使用することで、ローカル・ユーザーはリモート・データベースのデータにアクセスできるようになります。この接続を実現するためには、分散システム内の各データベースがネットワーク・ドメイン内で一意のグローバル・データベース名を持っていることが必要です。グローバル・データベース名は、分散システム内のデータベース・サーバーを一意に識別します。
図31-3は、ユーザーscottがグローバル名hq.example.comを使用して、リモート・データベースのemp表にアクセスしている例を示します。
データベース・リンクには、プライベートとパブリックの2種類があります。プライベートの場合は、そのリンクを作成したユーザーのみがアクセスでき、パブリックの場合は、すべてのデータベース・ユーザーがアクセスできます。
データベース・リンクの間の重要な違いとして、リンク定義ごとに決められた、リンク接続の認証方法をあげることができます。ユーザーは、次のタイプのリンクによってリモート・データベースにアクセスします。
| リンクのタイプ | 説明 |
|---|---|
接続ユーザー・リンク |
ユーザーはユーザー自身として接続します。つまり、ユーザーにはローカル・データベースのアカウントと同じユーザー名およびパスワードを持つリモート・データベースのアカウントが必要です。 |
固定ユーザー・リンク |
ユーザーは、リンク内で参照されるユーザー名とパスワードを使用して接続します。たとえば、Janeが、ユーザー名とパスワード |
現行ユーザー・リンク |
ユーザーはグローバル・ユーザーとして接続します。ローカル・ユーザーは、ストアド・プロシージャのコンテキスト内では、グローバル・ユーザーのパスワードをリンク定義に格納せずに、グローバル・ユーザーとして接続できます。たとえば、JaneはScottが記述したプロシージャにアクセスでき、 |
データベース・リンクを作成するには、CREATE DATABASE LINK文を使用します。リンクを作成した後、SQL文の中でリンクを使用してスキーマ・オブジェクトを指定できます。
関連項目:
CREATE DATABASE文の構文は、『Oracle Database SQL言語リファレンス』
共有データベース・リンクとは、ローカル・サーバー・プロセスとリモート・データベースの間のリンクのことです。複数のクライアント・プロセスが同じリンクを同時に使用できるので、共有データベース・リンクと呼ばれます。
ローカル・データベースがデータベース・リンクを介してリモート・データベースに接続するとき、どちらのデータベースも専用サーバー・モードまたは共有サーバー・モードのいずれかで稼働しています。可能な組合せを次の表に示します。
| ローカル・データベースのモード | リモート・データベースのモード |
|---|---|
専用 |
専用 |
専用 |
共有サーバー |
共有サーバー |
専用 |
共有サーバー |
共有サーバー |
共有データベース・リンクは、これら4つのどの構成でも確立できます。共有リンクは、通常のデータベース・リンクと次の点で異なります。
データベース・リンクを介して同じスキーマ・オブジェクトにアクセスする異なるユーザーの間で、ネットワーク接続を共有できます。
ユーザーが特定のサーバー・プロセスからリモート・サーバーに接続を確立するときに、そのプロセスからリモート・サーバーに対してすでに確立されている接続を再利用できます。接続を再利用するには、その接続が同じサーバー・プロセスから同じデータベース・リンクを使用して確立されている必要があります(セッションは異なっていてもかまいません)。非共有のデータベース・リンクでは、接続が複数のセッション間で共有されることはありません。
共有サーバー構成で共有データベース・リンクを使用すると、ネットワーク接続はローカル・サーバーの共有サーバー・プロセスの外部で直接に確立されます。ローカル共有サーバーでの非共有のデータベース・リンクでは、この接続はローカル・ディスパッチャを介して確立されるため、ローカル・ディスパッチャのためのコンテキスト・スイッチングが発生し、データがディスパッチャを経由することになります。
関連項目:
共有サーバーの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
データベース・リンクの大きな利点として、ユーザーがリモート・データベースにある他のユーザーのオブジェクトに対して、オブジェクトの所有者が持つ権限の制限内でアクセスできるという点があります。つまり、ローカル・ユーザーはリモート・データベースのユーザーにならなくても、リモート・データベースへのリンクにアクセスできます。
たとえば、従業員が経費精算書を買掛管理(A/P)アプリケーションに送信し、さらにA/Pアプリケーションを使用するユーザーが従業員に関する情報をhqデータベースから取得する必要がある場合を想定します。A/Pのユーザーは、必要な情報を取得するために、hqデータベースに接続してリモートのhqデータベース内のストアド・プロシージャを実行できます。A/Pのユーザーは、自分のジョブを実行するためにhqデータベースのユーザーになる必要はなく、プロシージャに記述されている制御された方法でhqの情報にアクセスできればそれで済みます。
関連項目:
データベース・リンク・ユーザーの詳細は、「データベース・リンクのユーザー」
パスワードを管理者以外のユーザーから隠す方法の詳細は、「データベース・リンク情報の表示」
データベース・リンクの動作の仕組みを理解するには、まずグローバル・データベース名について理解する必要があります。分散データベース内の各データベースは、それぞれのグローバル・データベース名によって一意に識別されます。
データベースは、DB_NAME初期化パラメータで指定された個々のデータベース名の前に、データベース作成時にDB_DOMAIN初期化パラメータで指定されたデータベース・ネットワーク・ドメインを付けることで、グローバル・データベース名を形成します。
たとえば、図31-4では、ネットワーク全体のデータベースを階層的な配置で表しています。
データベースの名前は、ツリーのリーフ(葉)から始まってルート(根)に至るまでの経路によって形成されます。たとえば、mfgデータベースは、comドメインのexample_toolsブランチのdivision3にあります。mfgのグローバル・データベース名は、ツリー内のノードを次のように連結して作成されます。
mfg.division3.example_tools.com
複数のデータベースが1つの個別名を共有できますが、各データベースのグローバル・データベース名は一意にする必要があります。たとえば、ネットワーク・ドメインus.americas.example_auto.comとuk.europe.example_auto.comには、どちらにもsalesデータベースがあります。グローバル・データベース名の命名体系では、americas部門のsalesデータベースとeurope部門のsalesデータベースが次のように区別されます。
sales.us.americas.example_auto.com
sales.uk.europe.example_auto.com
関連項目:
グローバル・データベース名を指定および変更する方法の詳細は、「分散システムでのグローバル名の管理」
データベースのグローバル名は、データベース・リンクを明示的に作成せずに、ループバック・データベース・リンクとして使用できます。SQL文中のデータベース・リンクが現行データベースのグローバル名と一致すると、データベース・リンクは事実上無視されます。
たとえば、データベースのグローバル名がdb1.example.comであると想定します。このデータベース上で次のSQL文を実行します。
SELECT * FROM hr.employees@db1.example.com;
この場合、SQL文の@db1.example.comの部分が事実上無視されます。
通常、データベース・リンクの名前は、参照先のリモート・データベースのグローバル・データベース名と同じです。
たとえば、データベースのグローバル・データベース名がsales.us.example.comであれば、データベース・リンクの名前もsales.us.example.comになります。
初期化パラメータGLOBAL_NAMESをTRUEに設定すると、データベース・リンクの名前がリモート・データベースのグローバル・データベース名と同じになることが保証されます。たとえば、hqのグローバル・データベース名がhq.example.comで、GLOBAL_NAMESがTRUEの場合は、リンク名も必ずhq.example.comになります。データベースでチェックされるのはデータ・ディクショナリに保存されているグローバル・データベース名のドメイン部分で、初期化パラメータ・ファイルのDB_DOMAIN設定ではない点に注意してください(「グローバル・データベース名のドメインの変更」を参照)。
初期化パラメータGLOBAL_NAMESをFALSEに設定した場合は、グローバル・ネーミングを使用する必要はありません。データベース・リンクに自由に名前を付けられます。たとえば、hq.example.comへのデータベース・リンクにfooという名前を付けることができます。
注意:
グローバル・ネーミングはレプリケーションなどの多数の機能で必要になるため、グローバル・ネーミングの使用をお薦めします。
グローバル・ネーミングを有効にすると、データベース・リンクの名前がリンクの参照先であるデータベースのグローバル名と同じになるため、データベース・リンクは本質的に分散データベースのユーザーに対して透過的になります。たとえば、次の文は、リモート・データベースsalesへのデータベース・リンクをローカル・データベース内に作成します。
CREATE PUBLIC DATABASE LINK sales.division3.example.com USING 'sales1';
関連項目:
初期化パラメータGLOBAL_NAMESの指定の詳細は、『Oracle Databaseリファレンス』
Oracle Databaseでは、プライベート、パブリックおよびグローバルのデータベース・リンクを作成できます。
これらの基本的なリンク・タイプは、どのユーザーに対してリモート・データベースへのアクセスが許可されているかによって異なります。
| タイプ | 所有者 | 説明 |
|---|---|---|
プライベート |
リンクを作成したユーザー。次のビューによって所有権データを表示できます。
|
ローカル・データベースの特定のスキーマにリンクを作成します。プライベート・データベース・リンクの所有者またはスキーマ内のPL/SQLサブプログラムのみが、このリンクを使用して、対応するリモート・データベース内のデータベース・オブジェクトにアクセスできます。 |
パブリック |
PUBLICと呼ばれるユーザー。プライベート・データベース・リンクと同じビューによって所有権データを表示できます。 |
データベース全体にわたるリンクを作成します。データベース内のすべてのユーザーとPL/SQLサブプログラムが、パブリック・リンクを使用して、対応するリモート・データベース内のデータベース・オブジェクトにアクセスできます。 |
グローバル |
グローバル・データベース・リンクは、いずれのユーザーにも所有されません。グローバル・データベース・リンクはディレクトリ・サービスに存在します。 |
ネットワーク全体にわたるリンクを作成します。Oracleネットワークでディレクトリ・サーバーを使用し、データベースがディレクトリ・サービスに登録されている場合、この情報をデータベース・リンクとして使用できます。どのデータベースのユーザーとPL/SQLサブプログラムでも、グローバル・データベース・リンクを使用して、対応するリモート・データベース内のオブジェクトにアクセスできます。グローバル・データベース・リンクは、ディレクトリ・サーバーのネット・サービス名の使用を指します。 |
分散データベースで利用するデータベース・リンクのタイプは、システムを使用しているアプリケーションの仕様要件によって決まります。リンクの選択時には、次の機能を考慮してください。
| リンクのタイプ | 特徴 |
|---|---|
プライベート・データベース・リンク |
このリンクは、パブリック・リンクやグローバル・リンクよりも安全です。その理由は、このリンクを使用してリモート・データベースにアクセスできるのが、プライベート・リンクの所有者と、同じスキーマ内のサブプログラムのみに限定されるためです。 |
パブリック・データベース・リンク |
多数のユーザーがリモートのOracle Databaseへのアクセス・パスを必要とするときは、データベース内のすべてのユーザーが使用できる1つのパブリック・データベース・リンクを作成できます。 |
グローバル・データベース・リンク |
Oracleネットワークでディレクトリ・サーバーを使用すると、管理者は、システムに存在するすべてのデータベースに対するグローバル・データベース・リンクを容易に管理できます。データベース・リンクの管理が集中化され、単純になります。 グローバル・データベース・リンク定義に関連付けられるユーザー・データはありません。グローバル・データベース・リンクは、接続されたユーザー・データベース・リンクとして操作できる必要があります。 |
関連項目:
異なるタイプのデータベース・リンクの作成方法については、「リンク・タイプの指定」
リンクに関する情報へのアクセス方法は、「データベース・リンク情報の表示」
データベース・リンクのユーザーには、接続ユーザー、現行ユーザーおよび固定ユーザーが含まれます。
リンクを作成するときは、どのユーザーがリモート・データベースに接続してデータにアクセスする必要があるかを決めます。
次の表は、データベース・リンクに関係するユーザーのカテゴリについて、それらの違いを説明したものです。
| ユーザー・タイプ | 説明 | リンク作成構文のサンプル |
|---|---|---|
接続ユーザー |
固定のユーザー名およびパスワードが指定されていないデータベース・リンクにアクセスするローカル・ユーザー。 注意: 接続ユーザーは、必ずしもリンクを作成したユーザーである必要はありません。リンクにアクセスしようとしているすべてのユーザーが接続ユーザーになります。 |
|
現行ユーザー |
グローバル・セキュリティの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。 |
|
固定ユーザー |
ユーザー名/パスワードがリンク定義の一部になっているユーザー。リンクに固定ユーザーが含まれている場合は、その固定ユーザーのユーザー名とパスワードがリモート・データベースへの接続に使用されます。 |
|
注意:
次のユーザーはデータベース・リンクのターゲット・ユーザーにはなれません: SYSおよびPUBLIC。
関連項目:
リンクを作成するときのユーザーの指定方法の詳細は、「リンク・ユーザーの指定」
接続ユーザー・リンクには、接続文字列が対応付けられていません。接続ユーザー・リンクの利点は、リンクを参照するユーザーが同じユーザーとしてリモート・データベースに接続するため、資格証明がデータ・ディクショナリのリンク定義に格納されている必要がないことです。
接続ユーザー・リンクには、いくつかのデメリットがあります。これらのリンクでは、ユーザーが接続先のリモート・データベースのアカウントと権限を持っている必要があるため、管理者の権限管理作業が増えます。また、必要以上の権限をユーザーに与えることは、セキュリティの基本概念である最低限の権限、つまり「ユーザーにはユーザー自身のジョブの実行に必要な権限のみを与える」に反することになります。
接続ユーザー・データベース・リンクの使用許可を左右する要因はいくつかありますが、最も重要な要因として、ユーザーがパスワードを使用してデータベースで認証されるのか、またはオペレーティング・システムやネットワーク認証サービスによって外部認証されるのかという要因があります。ユーザーが外部認証される場合、接続ユーザー・リンクの使用許可も、リモート・データベースでユーザーのリモート認証が許可されるかどうか(REMOTE_OS_AUTHENT初期化パラメータの設定)によって異なります。
REMOTE_OS_AUTHENTパラメータは、次のように働きます。
| REMOTE_OS_AUTHENTの値 | 結果 |
|---|---|
リモート・データベースに対して |
外部認証方式のユーザーは、接続ユーザー・データベース・リンクを使用してリモート・データベースに接続できます。 |
リモート・データベースに対して |
外部認証方式のユーザーは、セキュリティ保護されたプロトコルまたはネットワーク認証サービス・オプションを使用しないかぎり、接続ユーザー・データベース・リンクを使用してリモート・データベースに接続することはできません。 |
注意:
REMOTE_OS_AUTHENT初期化パラメータは非推奨です。これは、下位互換性のためにのみ残されています。
固定ユーザー・リンクの利点は、接続文字列で指定したユーザーのセキュリティ・コンテキストを使用して、プライマリ・データベースのユーザーをリモート・データベースに接続することです。
たとえば、ローカル・ユーザーjoeは、固定ユーザーscottとパスワードpasswordを指定したパブリック・データベース・リンクをjoeのスキーマ内に作成できます。janeがこの固定ユーザー・リンクを使用して問合せを発行すると、ローカル・データベースのユーザーであるjaneが、scott/passwordとしてリモート・データベースに接続します。
固定ユーザー・リンクでは、接続文字列にユーザー名とパスワードが対応付けられています。ユーザー名とパスワードは、データ・ディクショナリ表の別のリンク情報に格納されます。
現行ユーザー・データベース・リンクは、グローバル・ユーザーを利用します。グローバル・ユーザーは、X.509証明書またはパスワードによって認証される必要があり、リンクに関係する両方のデータベースのユーザーであることが必要です。
CURRENT_USERリンクを実行するユーザーは、必ずしもグローバル・ユーザーである必要はありません。たとえば、janeがパスワードを使用して買掛金データベースに(グローバル・ユーザーとしてではなく)認証されている場合、ストアド・プロシージャにアクセスしてhqデータベースからデータを取得できます。プロシージャでは、現行ユーザー・データベース・リンクを使用して彼女をグローバル・ユーザーscottとしてhqに接続します。ユーザーscottはグローバル・ユーザーでSSLを介した証明書により認証されますが、janeは認証されません。
現行ユーザー・データベース・リンクによって、次のような結果になることに注意してください。
現行ユーザー・データベース・リンクがストアド・オブジェクト内からアクセスされていない場合、現行のユーザーはリンクにアクセスしている接続ユーザーと同じです。たとえば、scottが現行ユーザー・リンクを介してSELECT文を発行した場合、現行ユーザーはscottになります。
プロシージャ、ビュー、トリガーなど、データベース・リンクにアクセスするストアド・オブジェクトを実行する場合、現行ユーザーとはストアド・オブジェクトを所有するユーザーで、オブジェクトをコールするユーザーではありません。たとえば、janeがプロシージャscott.p (scottが作成したプロシージャ)をコールし、コールされたプロシージャ内に現行ユーザー・リンクが表示された場合、scottがリンクの現行ユーザーになります。
ストアド・オブジェクトが実行者権限のファンクション、プロシージャまたはパッケージである場合は、実行者の認可IDを使用してリモート・ユーザーとして接続します。たとえば、ユーザーjaneがプロシージャscott.p(scottによって作成された実行者権限のプロシージャ)をコールし、プロシージャscott.pの内部からリンクが確立される場合、リンクの現行ユーザーはjaneになります。
データベースにエンタープライズ・ユーザーとして接続して、共有のグローバル・スキーマ内に存在するストアド・プロシージャで現行ユーザー・リンクを使用することはできません。たとえば、ユーザーjaneがデータベースhq上の共有スキーマguest内のストアド・プロシージャにアクセスする場合、リモート・データベースへのログオン用にこのスキーマ内の現行ユーザー・リンクは使用できません。
関連項目:
データベース・リンクに関連するセキュリティ上の問題の詳細は、「分散データベースのセキュリティ」
実行者権限のファンクション、プロシージャまたはパッケージの詳細は、『Oracle Database PL/SQL言語リファレンス』。
データベース・リンクを作成するには、CREATE DATABASE LINK文を使用します。
次の表は、ローカル・データベース内でリモートのsales.us.americas.example_auto.comデータベースへのデータベース・リンクを作成するSQL文の例です。
関連項目:
リンクの作成方法の詳細は、「データベース・リンクの作成」
CREATE DATABASE LINK文の構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
データベース・リンクを作成した後、リモート・データベースのオブジェクトにアクセスするSQL文を実行できます。特定のリモート・オブジェクトにアクセスするには、リモート・データベース内での認可も必要です。
たとえば、データベース・リンクfooを使用してリモート・オブジェクトempにアクセスするには、次の文を発行します。
SELECT * FROM emp@foo;
データベース・リンクを使用して適切な構成のオブジェクト名を作成することは、分散システムにおいて欠かせないデータ操作の1つです。
Oracle Databaseは、グローバルにスキーマ・オブジェクトの名前を付けるために、グローバル・データベース名を使用します。
グローバル・データベース名は、次の形式をとります。
schema.schema_object@global_database_name
説明:
schemaは、データの論理構造(スキーマ・オブジェクト)の集まりです。スキーマはデータベース・ユーザーによって所有され、そのユーザーと同じ名前を持ちます。ユーザーはそれぞれ1つのスキーマを所有します。
schema_objectは、表、索引、ビュー、シノニム、プロシージャ、パッケージ、データベース・リンクなどの論理データ構造です。
global_database_nameは、リモート・データベースを一意に識別する名前です。この名前は、リモート・データベース初期化パラメータDB_NAMEとDB_DOMAINの連結と同じ必要があります(ただし、パラメータGLOBAL_NAMESがFALSEに設定されている場合は、任意の名前を使用できます)。
たとえば、ユーザーまたはアプリケーションは、データベースsales.division3.example.comへのデータベース・リンクを次のように使用して、リモート・データを参照できます。
SELECT * FROM scott.emp@sales.division3.example.com; # emp table in scott's schema SELECT loc FROM scott.dept@sales.division3.example.com;
GLOBAL_NAMESをFALSEに設定している場合は、sales.division3.example.comへのリンクに対して任意の名前を使用できます。たとえば、リンクfooをコールできます。次に、リモート・データベースに次のようにアクセスできます。
SELECT name FROM scott.emp@foo; # link name different from global name
リモート・スキーマ・オブジェクトにアクセスするには、リモート・データベース内でそのオブジェクトへのアクセス権を付与される必要があります。
また、リモート・オブジェクトの更新、挿入または削除を実行するには、オブジェクトに対するREADまたはSELECT権限と、UPDATE、INSERTまたはDELETE権限を付与される必要があります。データベースにはリモート記述機能がないため、ローカル・オブジェクトにアクセスする場合とは異なり、リモート・オブジェクトにアクセスするにはREADまたはSELECT権限が必要です。データベースでは、構造を判断するためにリモート・オブジェクトのSELECT *を実行する必要があります。
Oracle Databaseでは、シノニムを作成して、データベース・リンク名をユーザーから隠すことができます。
シノニムを使用すると、ローカル・データベースの表にアクセスする場合と同じ構文を使用して、リモート・データベースの表にアクセスできます。たとえば、リモート・データベース内の表に対して次の問合せを発行するとします。
SELECT * FROM emp@hq.example.com;
この場合、emp@hq.example.comに対応するシノニムempを作成すれば、同じデータにアクセスする際に次の問合せを発行できます。
SELECT * FROM emp;
関連項目:
データベース・リンクを使用して指定したオブジェクトのシノニムを作成する方法の詳細は、「シノニムを使用した位置の透過性の作成」
スキーマ・オブジェクトへのアプリケーション参照を解決する(このプロセスを名前解決と呼びます)ために、データベースではオブジェクト名を階層的に構成しています。
たとえば、データベースでは、データベース内部の各スキーマは一意の名前を持ち、スキーマ内部では各オブジェクトが一意の名前を持つことが保証されています。そのため、スキーマ・オブジェクトの名前はデータベースの内部で常に一意になります。また、データベースはオブジェクトのローカル名へのアプリケーション参照を解決します。
分散データベースでは、表などのスキーマ・オブジェクトに対してシステム内のすべてのアプリケーションからアクセスが可能です。データベースは、グローバル・データベース名による階層ネーミング・モデルを拡張してグローバル・オブジェクト名を効果的に作成することによって、分散データベース・システム内のスキーマ・オブジェクトへの参照を解決します。たとえば、問合せでリモートの表を参照する場合は、その完全修飾名(表が存在しているデータベースを含む)を指定します。
たとえば、ローカル・データベースにユーザーSYSTEMとして接続するとします。
CONNECT SYSTEM@sales1
次に、データベース・リンクhq.example.comを使用して次の文を発行し、リモート・データベースhqのscottスキーマおよびjaneスキーマにあるオブジェクトにアクセスします。
SELECT * FROM scott.emp@hq.example.com; INSERT INTO jane.accounts@hq.example.com (acc_no, acc_name, balance) VALUES (5001, 'BOWER', 2000); UPDATE jane.accounts@hq.example.com SET balance = balance + 500; DELETE FROM jane.accounts@hq.example.com WHERE acc_name = 'BOWER';
データベース・リンクに適用されるいくつかの制限事項があります。
データベース・リンクを使用して次の操作を実行することはできません。
リモート・オブジェクトへの権限の付与。
一部のリモート・オブジェクトに対するDESCRIBEの実行。ただし、次のリモート・オブジェクトはDESCRIBEをサポートしています。
表
ビュー
プロシージャ
ファンクション
リモート・オブジェクトの分析。
参照整合性の定義または規定。
リモート・データベース内のユーザーへのロールの付与。
リモート・データベースにおけるデフォルト以外のロールの取得。たとえば、janeがローカル・データベースに接続し、scottとして接続する固定ユーザー・リンクを使用したストアド・プロシージャを実行する場合、janeはリモート・データベースにおけるscottのデフォルト・ロールを受け取ります。janeは、SET ROLEを発行してデフォルト以外のロールを取得することはできません。
SSL、パスワードまたはMicrosoft Windowsのシステム固有の認証によって認証されていない現行ユーザー・リンクの使用。
関連項目:
ユーザー定義タイプに対するデータベース・リンクの制限事項の詳細は、『Oracle Databaseオブジェクト・リレーショナル開発者ガイド』を参照してください。
LOBに対するデータベース・リンクの制限事項の詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。
分散データベースの管理には、サイト自律性、セキュリティ、データベース・リンクの監査および管理ツールに関連するトピックが含まれます。
関連項目:
同機種システムの管理方法の詳細は、「分散データベースの管理」
異機種間サービスの概念の詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』を参照してください。
サイト自律性とは、分散データベース内の各サーバーが他のすべてのデータベースから独立して管理されることを意味します。
複数のデータベースが協調して動作する場合もありますが、各データベースはそれぞれ別々のデータ・リポジトリであり、個別に管理されます。Oracle Databaseの分散データベースのサイト自律性には、次のような利点があります。
独立性を維持する必要がある個々の企業またはグループの論理的な組織構造を、システムのノード群として反映できます。
ローカル管理者がそれぞれ対応するローカル・データを管理します。したがって、個々のデータベース管理者の責任範囲が小さくなり、管理しやすくなります。
障害が単独で発生するため、分散データベースの他のノードに損傷を与える可能性が低くなります。1つのデータベース障害によってすべての分散操作が停止したり、パフォーマンスのボトルネックが生じることはありません。
孤立したシステム障害が発生した際、管理者は、システム内の他のノードとは独立してリカバリできます。
各ローカル・データベースにはデータ・ディクショナリが存在します。ローカル・データへのアクセスにグローバル・カタログは不要です。
各ノードで独立してソフトウェアをアップグレードできます。
Oracle Databaseでは分散データベース・システム内の各データベースを独立して管理できますが、システムのグローバルな要件を無視することのないようにしてください。たとえば、次のような作業が必要になることがあります。
サーバー間接続を容易にするために作成したリンクをサポートするため、追加のユーザー・アカウントを各データベースに作成する。
COMMIT_POINT_STRENGTHやOPEN_LINKSなどの追加の初期化パラメータを設定する。
データベースは、ユーザーおよびロールのパスワード認証、ユーザーおよびロールのためのいくつかの外部認証タイプ(接続ユーザー・リンク用のKerberosバージョン5を含む)、クライアント/サーバー間およびサーバー間接続のためのログイン・パケットの暗号化を含め、分散データベース・システムのために非分散データベース環境で使用可能なすべてのセキュリティ機能をサポートします。
関連項目:
外部認証の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
データベース・リンクにはプライベートとパブリックの2種類があり、それぞれについて認証ありの場合と認証なしの場合があります。パブリック・リンクを作成するには、リンク作成文でPUBLICキーワードを指定します。
たとえば、次の文を発行できます。
CREATE PUBLIC DATABASE LINK foo USING 'sales';
認証ありのリンクを作成するには、データベース・リンク作成文でCONNECT TO句、AUTHENTICATED BY句、あるいはこれら両方の句を指定します。たとえば、次の文を発行できます。
CREATE DATABASE LINK sales CONNECT TO scott IDENTIFIED BY password USING 'sales'; CREATE SHARED PUBLIC DATABASE LINK sales CONNECT TO nick IDENTIFIED BY password1 AUTHENTICATED BY david IDENTIFIED BY password2 USING 'sales';
次の表は、ユーザーがリンクを介してリモート・データベースにアクセスする方法を示しています。
| リンク・タイプ | 認証済 | セキュリティ・アクセス |
|---|---|---|
プライベート |
いいえ |
データベースでは、リモート・データベースに接続するときに、ローカル・セッションから取得したセキュリティ情報(ユーザーID/パスワード)を使用します。そのため、このリンクは接続ユーザー・データベース・リンクです。2つのデータベース間で、パスワードが同期化されている必要があります。 |
プライベート |
はい |
ユーザーID/パスワードがローカル・セッションのコンテキストからではなく、リンク定義から取得されます。そのため、このリンクは固定ユーザー・データベース・リンクです。 この構成では、2つのデータベース間で異なるパスワードを使用できますが、ローカル・データベース・リンクのパスワードはリモート・データベースのパスワードと一致している必要があります。 |
パブリック |
いいえ |
動作はプライベートの非認証リンクとほぼ同じですが、すべてのユーザーがこのリモート・データベースへのポインタを参照できる点が異なります。 |
パブリック |
はい |
ローカル・データベースのすべてのユーザーがリモート・データベースにアクセスでき、すべてのユーザーが同じユーザーID/パスワードを使用して接続します。 |
接続ユーザーまたは現行ユーザーのデータベース・リンクを使用するときは、Kerberosなどの外部認証ソースを使用してエンドツーエンドのセキュリティを確立できます。
エンドツーエンド認証では、資格証明がサーバー間で渡され、同じドメインに属するデータベース・サーバーによって資格証明を認証できます。たとえば、janeがローカル・データベースで外部認証されているときに、接続ユーザー・リンクを使用してリモート・データベースに彼女自身として接続しようとする場合、ローカル・サーバーからリモート・データベースにセキュリティ・チケットが渡されます。
分散データベース・システムでは、システムを使用するアプリケーションのサポートに必要なユーザー・アカウントおよびロールについて慎重に計画する必要があります。
次の点に注意してください。
サーバー間接続の確立に必要なユーザー・アカウントは、分散データベース・システムのすべてのデータベースで使用可能である必要があります。
分散データベース・アプリケーションのユーザーに対してアプリケーション権限を使用可能にするために必要なロールは、分散データベース・システムのすべてのデータベースに存在する必要があります。
分散データベース・システム内のノードに対応するデータベース・リンクを作成する際は、それらのリンクを使用するサーバー間接続をサポートするために、各サイトでどのユーザー・アカウントとロールが必要になるかを決めてください。
通常、分散環境では、ユーザーは多数のネットワーク・サービスへのアクセスが必要になります。個々のユーザーが個々のネットワーク・サービスにアクセスするために個別の認証を構成する必要があるときは、特に大規模なシステムの場合にセキュリティの管理が難しくなることがあります。
関連項目:
各種データベース・リンクをシステムでサポートするために使用可能にする必要があるユーザー・アカウントの詳細は、「データベース・リンクの作成」
ユーザーおよび権限の集中管理のために、認証方法を検討する必要があります。また、スキーマに依存するグローバル・ユーザーまたはスキーマに依存しないグローバル・ユーザーも検討できます。
データベースには、分散システムに関係するユーザーおよび権限を管理するための様々な手段が用意されています。
たとえば、次のような方法があります。
エンタープライズ・ユーザー管理。SSLを介して、またはパスワードを使用して認証されるグローバル・ユーザーを作成し、それらのユーザーと権限を独立したディレクトリ・サービスによってディレクトリ内で管理できます。
ネットワーク認証サービス。この一般的な方法によって、分散環境のセキュリティ管理が容易になります。Oracle Advanced Securityオプションを使用することで、Oracle NetとOracle Databaseの分散データベース・システムのセキュリティを強化できます。Oracle以外の認証ソリューションの例としては、Microsoft Windowsのシステム固有の認証があります。
関連項目:
『Oracle Databaseセキュリティ・ガイド』
『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』
ユーザーと権限の管理を集中化するための1つのオプションは、集中ディレクトリにグローバル・ユーザーを作成し、グローバル・ユーザーが接続する必要のあるすべてのデータベースにユーザーを作成することです。
たとえば、次のSQL文を使用してfredというグローバル・ユーザーを作成できます。
CREATE USER fred IDENTIFIED GLOBALLY AS 'CN=fred adams,O=Oracle,C=England';
この解決方法を使用すると、1つのグローバル・ユーザーを中央ディレクトリによって認証できます。
スキーマに依存するグローバル・ユーザーのソリューションでは、このユーザーがアクセスする必要のあるすべてのデータベースでfredと呼ばれるユーザーを作成する必要が生じるという結果になります。ユーザーの多くはアプリケーション・スキーマにアクセスする権限は必要とするものの、独自のスキーマは不要であるため、すべてのグローバル・ユーザーに対してデータベースごとに別個のアカウントを作成すると、大幅なオーバーヘッドが生じます。この問題のため、データベースでは、スキーマに依存しないユーザー(すべてのデータベースで単一の汎用的なスキーマにアクセスできるグローバル・ユーザー)もサポートされています。
データベースは、グローバル・ユーザーをエンタープライズ・ディレクトリ・サービスによって集中管理する機能をサポートしています。このディレクトリ内で管理されるユーザーのことを、エンタープライズ・ユーザーと呼びます。
このディレクトリには、次のことに関する情報が格納されています。
エンタープライズ・ユーザーが分散システムのどのデータベースにアクセスできるのか。
エンタープライズ・ユーザーが各データベースのどのロールを使用できるのか。
エンタープライズ・ユーザーが各データベースのどのスキーマに接続できるのか。
各データベースの管理者は、エンタープライズ・ユーザーが接続する必要のあるデータベースごとに各エンタープライズ・ユーザーのグローバル・ユーザー・アカウントを作成する必要はありません。そのかわりに、複数のエンタープライズ・ユーザーが共有スキーマと呼ばれる同じデータベース・スキーマに接続できます。
注意:
共有スキーマ内の現行ユーザー・データベース・リンクにはアクセスできません。
たとえば、jane、billおよびscottが全員、人事管理アプリケーションを使用しているとします。hqアプリケーション・オブジェクトは、hqデータベース上のguestスキーマにすべて格納されています。この場合、共有スキーマとして使用するローカル・グローバル・ユーザー・アカウントを作成できます。このグローバル・ユーザー名(共有スキーマ名)はguestです。jane、billおよびscottは、いずれもディレクトリ・サービスでエンタープライズ・ユーザーとして作成されます。また、彼らをディレクトリのguestスキーマにマップし、hqアプリケーションで別の認可を割り当てることもできます。
図31-5は、エンタープライズ・ディレクトリ・サービスを使用したグローバル・ユーザーのセキュリティの例を示しています。
エンタープライズ・ディレクトリ・サービスに、hqおよびsalesのエンタープライズ・ユーザーに関する次の情報が格納されているとします。
| データベース | ロール | スキーマ | エンタープライズ・ユーザー |
|---|---|---|---|
|
|
|
|
|
|
|
|
また、hqおよびsalesのローカル管理者が次の文を発行したとします。
| データベース | CREATE文 |
|---|---|
|
CREATE USER guest IDENTIFIED GLOBALLY AS ''; CREATE ROLE clerk1 GRANT select ON emp; CREATE PUBLIC DATABASE LINK sales_link CONNECT AS CURRENT_USER USING 'sales'; |
|
CREATE USER guest IDENTIFIED GLOBALLY AS ''; CREATE ROLE clerk2 GRANT select ON dept; |
ここで、salesに関係する分散トランザクションを実行するために、エンタープライズ・ユーザーscottがローカル・データベースhqへの接続を要求するとします。このとき、次の手順が実行されます(ただし、必ずしもこの順序どおりとはかぎりません)。
エンタープライズ・ユーザーscottが、SSLまたはパスワードを使用して認証されます。
ユーザーscottが次の文を発行します。
SELECT e.ename, d.loc FROM emp e, dept@sales_link d WHERE e.deptno=d.deptno;
データベースhqとsalesが、SSLを使用して相互に認証します。
データベースhqはエンタープライズ・ディレクトリ・サービスを問い合せて、エンタープライズ・ユーザーscottがhqにアクセスできるかどうかを判断し、scottがロールclerk1を使用してローカル・スキーマguestにアクセスできることを確認します。
データベースsalesはエンタープライズ・ディレクトリ・サービスを問い合せて、エンタープライズ・ユーザーscottがsalesにアクセスできるかどうかを判断し、scottがロールclerk2を使用してローカル・スキーマguestにアクセスできることを確認します。
エンタープライズ・ユーザーscottはsalesにログインし、ロールclerk2を使用してguestスキーマにアクセスします。そこでSELECTを発行し、必要な情報を取得してその情報をhqに送信します。
データベースhqは要求されたデータをsalesから受信し、それをクライアントscottに返します。
関連項目:
エンタープライズ・ユーザー・セキュリティの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
Oracle Advanced Securityオプションでは、データが解読または改ざんされないように、Oracle Netとその関連製品でネットワーク・データの暗号化とチェックサムも使用できます。これにより、RSA Data Security社のRC4またはデータ暗号化規格(DES)暗号化アルゴリズムを使用して、データを不当な表示から保護します。
データが転送中に改ざん、削除または再現されなかったことを保証するために、Oracle Advanced Securityオプションのセキュリティ・サービスは、暗号的に安全なメッセージ・ダイジェストを生成し、ネットワーク上に送られる各パケットにそのダイジェストを含めることができます。
関連項目:
Oracle Advanced Securityオプションのこれらの機能およびその他の機能の詳細は、『Oracle Database Advanced Securityガイド』を参照してください。
操作の監査は、常にローカルで実行する必要があります。つまり、適切な監査オプションがそれぞれのデータベースで設定されている場合は、ユーザーがローカル・データベース内で操作を実行し、データベース・リンクを介してリモート・データベースにアクセスすると、ローカルの操作はローカル・データベースで監査され、リモートの操作はリモート・データベースで監査されます。
リモート・データベースでは、正常終了した接続要求とその後のSQL文が別のサーバーからのものか、またはローカルに接続しているクライアントからのものかを判断することはできません。たとえば、次のような場合を考えてみます。
固定ユーザー・リンクhq.example.comにより、ローカル・ユーザーjaneがリモート・ユーザーscottとしてリモートのhqデータベースに接続します。
ユーザーscottは、リモート・データベースで監査されます。
リモート・データベース・セッション中に実行される操作は、あたかもscottがhqにローカルに接続し、そこで同じ操作を実行しているかのように監査されます。janeがリモート・データベースで何を実行しているのかを監査する場合は、リモート・データベースで監査オプションを設定し、リンクに埋め込まれているユーザー名(この場合はhqデータベースのscott)の操作を捕捉する必要があります。
注意:
グローバル・ユーザーに対応するグローバル・ユーザー名を監査できます。
リモート・オブジェクトに対してローカルの監査オプションを設定することはできません。したがって、リモート・オブジェクトへのアクセスをリモート・データベースで監査することはできますが、データベース・リンクの使用は監査できません。
データベース管理者は、Oracle Databaseの分散データベース・システムを管理する際にいくつかのツールを選択できます。
Oracle Enterprise Manager Cloud Controlは、グラフィカル・ユーザー・インタフェース(GUI)を提供するOracle Database管理ツールです。Cloud Controlでは、操作性に優れたインタフェースを介して、分散データベースの管理機能を提供します。
Cloud Controlを使用して、次のことを実行できます。
複数のデータベースの管理。Cloud Controlを使用して、1つのデータベースを管理したり、複数のデータベースを同時に管理できます。
データベース管理作業の集中化。世界中のあらゆる場所のあらゆるOracle Databaseプラットフォームで稼働しているローカルおよびリモートの両方のデータベースを管理できます。また、Oracle Netがサポートしている任意のネットワーク・プロトコルでこれらのOracle Databaseプラットフォームを接続できます。
SQL、PL/SQLおよびCloud Controlコマンドの動的な実行。Cloud Controlを使用して、文を入力、編集および実行できます。Cloud Controlにより、実行した文の履歴も保持されます。
これにより、それらの文を再入力しなくても再実行できるので、分散データベース・システムで非常に長い文を繰り返し実行する必要がある場合に特に便利です。
グローバル・ユーザー、グローバル・ロール、エンタープライズ・ディレクトリ・サービスなどのセキュリティ機能の管理。
現在、Oracle Databaseおよびネットワークの管理に役立つ製品が、60を超える企業から150以上出荷されており、真にオープンな環境を実現しています。
Oracle Simple Network Management Protocol (SNMP)のサポートでは、ネットワーク管理機能以外に、任意のSNMPベースのネットワーク管理システムによってOracle Databaseサーバーを検索および問合せできるようにします。
SNMPは、次に示す多数の一般的なネットワーク管理システムの基盤となる公認規格です。
HP社のOpenView
Digital社のPOLYCENTER Manager on NetView
IBM社のNetView/6000
Novell社のNetWare Management System
SunSoft社のSunNet Manager
注意:
Oracle NetリスナーでのSNMPサポートは非推奨になりました。新しい実装ではSNMPを使用しないことをお薦めします。詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。
トランザクションとは、1人のユーザーが実行する1つ以上のSQL文によって構成された論理作業単位のことです。トランザクションは、ユーザーの最初に実行可能なSQL文で開始し、そのユーザーによってコミットまたはロールバックされたときに終了します。リモート・トランザクションは、1つのリモート・ノードにアクセスする文のみで構成されます。分散トランザクションは、複数のノードにアクセスする文で構成されます。
リモートSQL文は、同じリモート・ノードに存在する1つ以上のリモート表の問合せまたは変更を行います。
リモート問合せ文とは、そのすべてが同一のリモート・ノードに存在している1つ以上のリモート表から情報を選択する問合せのことです。たとえば、次の問合せは、リモートのsalesデータベースのscottスキーマにあるdept表のデータにアクセスします。
SELECT * FROM scott.dept@sales.us.americas.example_auto.com;
リモート更新文とは、そのすべてが同一のリモート・ノードに存在している1つ以上の表のデータを変更する更新のことです。たとえば、次の問合せは、リモートのsalesデータベースのscottスキーマにあるdept表を更新します。
UPDATE scott.dept@mktng.us.americas.example_auto.com SET loc = 'NEW YORK' WHERE deptno = 10;
注意:
リモート更新には1つ以上のリモート・ノードからデータを取得する副問合せを含めることができますが、更新は1つのリモート・ノードでのみ発生するため、その文はリモート更新として分類されます。
分散SQL文は、2つ以上のノード上のデータの問合せまたは変更を行います。
分散問合せ文は、複数のノードから情報を取得します。たとえば、次の問合せは、ローカル・データベースのデータと同時にリモートのsalesデータベースのデータにもアクセスします。
SELECT ename, dname FROM scott.emp e, scott.dept@sales.us.americas.example_auto.com d WHERE e.deptno = d.deptno;
分散更新文は、複数のノードのデータを変更します。分散更新を行うには、プロシージャやトリガーなど、異なるノードのデータにアクセスする複数のリモート更新を含むPL/SQLサブプログラム・ユニットを使用します。たとえば、次のPL/SQLプログラム・ユニットは、ローカル・データベースとリモートのsalesデータベースにある表を更新します。
BEGIN
UPDATE scott.dept@sales.us.americas.example_auto.com
SET loc = 'NEW YORK'
WHERE deptno = 10;
UPDATE scott.emp
SET deptno = 11
WHERE deptno = 10;
END;
COMMIT;
データベースによってプログラム内の文がリモート・ノードに送られると、それらの文の実行はユニットとして成功または失敗します。
共有SQLを使用したリモート文または分散型の文の仕組みは、本質的にはローカル文の仕組みと同じです。
SQLテキストは必ず一致している必要があり、参照先のオブジェクトも必ず一致している必要があります。可能であれば、任意の文または分解された問合せをローカルまたはリモートで処理するために共有SQL領域を使用できます。
関連項目:
共有SQLの詳細は、『Oracle Database概要』を参照してください。
リモート・トランザクションには1つ以上のリモート文があり、そのすべてが1つのリモート・ノードを参照しています。
たとえば、次のトランザクションには2つの文があり、それぞれがリモートのsalesデータベースにアクセスします。
UPDATE scott.dept@sales.us.americas.example_auto.com SET loc = 'NEW YORK' WHERE deptno = 10; UPDATE scott.emp@sales.us.americas.example_auto.com SET deptno = 11 WHERE deptno = 10; COMMIT;
分散トランザクションとは、1つ以上の文からなり、それらが個別に、またはグループとして、分散データベースの複数のノードのデータを更新するようなトランザクションのことです。
たとえば、このトランザクションは、ローカル・データベースとリモートのsalesデータベースを更新します。
UPDATE scott.dept@sales.us.americas.example_auto.com SET loc = 'NEW YORK' WHERE deptno = 10; UPDATE scott.emp SET deptno = 11 WHERE deptno = 10; COMMIT;
注意:
トランザクションのすべての文が1つのリモート・ノードのみを参照している場合、そのトランザクションは分散トランザクションではなくリモート・トランザクションです。
データベースの2フェーズ・コミット・メカニズムは、分散トランザクションに関係するすべてのデータベース・サーバーが、そのトランザクション内の文のすべてをコミットするか、すべてをロールバックするかのどちらか一方のみになるように保証するものです。
データベースは、トランザクションが分散か非分散かにかかわらず、トランザクション内のすべての文がユニットとしてコミットまたはロールバックすることを保証します。実行中のトランザクションの結果は、すべてのノードの全トランザクションに対して不可視であり、このような透過性は、問合せや更新、リモート・プロシージャ・コールなど、あらゆるタイプの操作を含むトランザクションにおいて成り立つことが必要です。
非分散データベースにおけるトランザクション管理の一般的なメカニズムの詳細は、『Oracle Database概要』を参照してください。分散データベースでは、データベースはネットワーク上で同じ特性を持つトランザクション管理を連携させる必要があり、ネットワークやシステムに障害が発生しても、データ整合性を維持する必要があります。
また、2フェーズ・コミット・メカニズムにより、整合性制約、リモート・プロシージャ・コールおよびトリガーによって実行される暗黙的なデータ操作言語(DML)操作が保護されます。
関連項目:
Oracle Databaseの2フェーズ・コミット・メカニズムの詳細は、「分散トランザクションの概念」
SQL文にグローバル・オブジェクト名への参照が含まれていると、データベースでは、必ずグローバル・オブジェクト名の中で指定されているデータベース名と一致する名前を持つデータベース・リンクを検索します。
グローバル・オブジェクト名とは、データベース・リンクを使用して指定されたオブジェクトのことです。
グローバル・オブジェクト名の必須構成要素は、次のとおりです。
オブジェクト名
データベース名
ドメイン
次の表は、明示的に指定されるグローバル・データベース・オブジェクト名の構成要素を示しています。
| 文 | オブジェクト | データベース | ドメイン |
|---|---|---|---|
|
|
|
|
|
|
|
|
SQL文にグローバル・オブジェクト名への参照が含まれていると、データベースでは、必ずグローバル・オブジェクト名の中で指定されているデータベース名と一致する名前を持つデータベース・リンクを検索します。たとえば、次の文を発行した場合を考えます。
SELECT * FROM scott.emp@orders.us.example.com;
この場合は、データベースによってorders.us.example.comというデータベース・リンクが検索されます。データベースはこの操作を実行して、指定されたリモート・データベースへのパスを判断します。
データベースは、一致するデータベース・リンクを常に次の順序で検索します。
SQL文を発行したユーザーのスキーマ内のプライベート・データベース・リンク。
ローカル・データベース内のパブリック・データベース・リンク。
グローバル・データベース・リンク(ディレクトリ・サーバーが使用可能な場合のみ)。
SQL文に完全なグローバル・データベース名が含まれる場合、データベースは、指定されたグローバル・データベース名に一致するリンクのみを検索します。
完全なグローバル・データベース名が指定された次のSQL文を発行するとします。
SELECT * FROM emp@prod1.us.example.com;
この場合は、データベース名(prod1)とドメイン構成要素(us.example.com)の両方を指定しているため、データベースは、プライベート、パブリックおよびグローバルのデータベース・リンクを検索します。
ドメインのいずれかの部分が指定されている場合、データベースは、完全なグローバル・データベース名が指定されていると仮定します。
SQL文で部分的なグローバル・データベース名を指定した場合(つまり、データベース構成要素のみを指定した場合)、データベースはDB_DOMAIN初期化パラメータ値をDB_NAME初期化パラメータ値の後に追加し、完全な名前を構成します。たとえば、次の文を発行した場合を考えます。
CONNECT scott@locdb SELECT * FROM scott.emp@orders;
locdbのネットワーク・ドメインがus.example.comの場合、データベースはこのドメインをordersの後に追加し、orders.us.example.comという完全なグローバル・データベース名を構成します。データベースは、構築されたグローバル名のみに一致するデータベース・リンクを検索します。一致するリンクが見つからない場合、データベースはエラーを返し、SQL文は実行できません。
グローバル・オブジェクト名がローカル・データベース内のオブジェクトを参照していて、データベース・リンク名の指定に@記号が使用されていない場合、データベースは、オブジェクトがローカルであることを自動的に検出して検索を行わないか、またはデータベース・リンクを使用してオブジェクト参照を解決します。
たとえば、次の文を発行した場合を考えます。
CONNECT scott@locdb SELECT * from scott.emp;
2番目の文ではデータベース・リンク接続文字列を使用してグローバル・データベース名を指定していないため、データベースは、データベース・リンクを検索しません。
データベースは、最初に一致したデータベース・リンクが見つかったときに、必ずしも一致するデータベース・リンクの検索を停止するとはかぎりません。データベースは、リモート・データベースへの完全なパス(リモート・アカウントとサービス名の両方)がわかるまで、一致するプライベート、パブリックおよびネットワークのデータベース・リンクを検索します。
最初に一致したデータベース・リンクが見つかると、次の表に従ってリモート・スキーマが決定されます。
| ユーザー操作 | データベースの応答 | 例 |
|---|---|---|
|
接続ユーザー・データベース・リンクを使用します。 |
|
|
固定ユーザー・データベース・リンクを使用します。 |
|
|
現行ユーザー・データベース・リンクを使用します。 |
|
|
データベース文字列を指定するリンクが見つかるまで検索します。一致するデータベース・リンクが見つかっても文字列がまったく識別されない場合、データベースはエラーを返します。 |
|
完全なパスを決定した後、データベースはリモート・セッションを作成します(同じローカル・セッションのために同一の接続がまだオープンになっていない場合)。セッションがすでに存在している場合、データベースはそのセッションを再利用します。
Oracleデータベースがリモート・データベースに接続したときのリモート・スキーマの決定方法を理解するのは重要なことです。
ローカルのOracle Databaseが、SQL文を発行したローカル・ユーザーのために指定のリモート・データベースに接続した後も、あたかもリモート・ユーザーが対応するSQL文を発行したかのように、オブジェクトの解決処理が続きます。
最初に一致したデータベース・リンクが見つかると、次の規則に従ってリモート・スキーマが決定されます。
| 指定したリンクのタイプ | オブジェクト解決の場所 |
|---|---|
固定ユーザー・データベース・リンク |
リンク作成文で指定されたスキーマ |
接続ユーザー・データベース・リンク |
接続ユーザーのリモート・スキーマ |
現行ユーザー・データベース・リンク |
現行ユーザーのスキーマ |
オブジェクトが見つからなかった場合、データベースはリモート・データベースのパブリック・オブジェクトをチェックします。オブジェクトを解決できなくても確立されたリモート・セッションは残りますが、SQL文は実行できず、エラーが返されます。
次に、分散データベース・システムにおけるグローバル・オブジェクトの名前解決の例を示します。以降のすべての例で、示しているようなことを想定します。
データベースが完全なグローバル・オブジェクト名を解決し、プライベートおよびパブリックの両方のデータベース・リンクを使用してリモート・データベースへの適切なパスを決定する方法の例を示します。
この例では、次のことを想定しています。
リモート・データベースの名前は、sales.division3.example.comです。
ローカル・データベースの名前は、hq.division3.example.comです。
ディレクトリ・サーバーは使用できません。したがって、グローバル・データベース・リンクも使用できません。
リモート表empは、スキーマtsmith内にあります。
次の文がscottによってローカル・データベースで発行された場合を考えます。
CONNECT scott@hq CREATE PUBLIC DATABASE LINK sales.division3.example.com CONNECT TO guest IDENTIFIED BY network USING 'dbstring';
その後、JWARDが接続して次の文を発行するとします。
CONNECT jward@hq CREATE DATABASE LINK sales.division3.example.com CONNECT TO tsmith IDENTIFIED BY radio; UPDATE tsmith.emp@sales.division3.example.com SET deptno = 40 WHERE deptno = 10;
データベースは、最後の文を次のように処理します。
データベースは、jwardのUPDATE文で完全なグローバル・オブジェクト名が参照されていると判断します。したがって、一致する名前を持つデータベース・リンクの検索がローカル・データベース内で開始されます。
データベースは、一致するプライベート・データベース・リンクをスキーマjward内で検索します。しかし、プライベート・データベース・リンクjward.sales.division3.example.comは、リモートのsalesデータベースへの完全なパスを示しておらず、リモート・アカウントのみを示しています。そのため、データベースは、一致するパブリック・データベース・リンクを続いて検索します。
データベースは、パブリック・データベース・リンクをscottのスキーマ内で検索します。データベースは、このパブリック・データベース・リンクからネット・サービス名dbstringを取得します。
データベースは、一致するプライベートの固定ユーザー・データベース・リンクから取得したリモート・アカウントを結合して完全なパスを決定し、次に、ユーザーtsmith/radioとしてリモートのsalesデータベースに接続します。
これで、リモート・データベースは、emp表へのオブジェクト参照を解決できます。データベースはtsmithスキーマ内で検索を行い、参照先のemp表を検出します。
リモート・データベースは文の実行を完了し、その結果をローカル・データベースに返します。
データベースが部分的なグローバル・オブジェクト名を解決し、プライベートおよびパブリックの両方のデータベース・リンクを使用してリモート・データベースへの適切なパスを決定する方法の例を示します。
この例では、次のことを想定しています。
リモート・データベースの名前は、sales.division3.example.comです。
ローカル・データベースの名前は、hq.division3.example.comです。
ディレクトリ・サーバーは使用できません。したがって、グローバル・データベース・リンクも使用できません。
リモート・データベースsalesの表empはスキーマtsmith内にあり、スキーマscott内にはありません。
リモート・データベースsalesにempというパブリック・シノニムが存在します。このシノニムは、リモート・データベースsalesのtsmith.empを指しています。
「グローバル・オブジェクトの名前解決の例: 完全なオブジェクト名」 で示したパブリック・データベース・リンクが、ローカル・データベースhqにすでに作成されています。
CREATE PUBLIC DATABASE LINK sales.division3.example.com CONNECT TO guest IDENTIFIED BY network USING 'dbstring';
ローカル・データベースhqで次の文が発行された場合を考えます。
CONNECT scott@hq CREATE DATABASE LINK sales.division3.example.com; DELETE FROM emp@sales WHERE empno = 4299;
データベースは、最後のDELETE文を次のように処理します。
データベースは、scottのDELETE文で部分的なグローバル・オブジェクト名が参照されていると感知します。ローカル・データベースのドメインを使用して、次のように完全なグローバル・オブジェクト名に拡張します。
DELETE FROM emp@sales.division3.example.com WHERE empno = 4299;
データベースは、一致する名前を持つデータベース・リンクをローカル・データベース内で検索します。
データベースは、一致するプライベート接続ユーザー・リンクをスキーマscott内で検出しますが、そのプライベート・データベース・リンクにはパスがまったく示されていません。データベースは接続ユーザー名/パスワードをパスのリモート・アカウント部分として使用して、一致するパブリック・データベース・リンクを検索して検出します。
CREATE PUBLIC DATABASE LINK sales.division3.example.com CONNECT TO guest IDENTIFIED BY network USING 'dbstring';
データベースは、このパブリック・データベース・リンクからサービス名dbstringを取得します。この時点で、データベースは完全なパスを決定しました。
データベースは、リモート・データベースにscott/passwordとして接続して検索しますが、スキーマscott内でempというオブジェクトは検出しません。
リモート・データベースは、empというパブリック・シノニムを検索して見つけます。
リモート・データベースは文を実行し、その結果をローカル・データベースに返します。
グローバル・オブジェクト名は、完全または部分的である可能性があります。
ビュー、シノニムまたはPL/SQLプログラム・ユニット(プロシージャ、ファンクション、トリガーなど)は、グローバル・オブジェクト名によってリモートのスキーマ・オブジェクトを参照できます。
グローバル・オブジェクト名が完全な場合、データベースは、グローバル・オブジェクト名を拡張せずにオブジェクトの定義を格納します。ただし、名前が部分的な場合、データベースはローカル・データベース名のドメインを使用してその名前を拡張します。
次の表は、ビュー、シノニムおよびプログラム・ユニットの部分的なグローバル・オブジェクト名を、データベースがいつ拡張するのかを示したものです。
| ユーザー操作 | データベースの応答 |
|---|---|
ビューの作成 |
部分的なグローバル名は拡張しません。定義内の問合せのテキストがそのままデータ・ディクショナリに格納されます。そのかわりに、ビューを使用する文が解析されるたびに、データベースは、部分的なグローバル・オブジェクト名を拡張します。 |
シノニムの作成 |
部分的なグローバル名が拡張されます。データ・ディクショナリに格納されるシノニムの定義には、拡張されたグローバル・オブジェクト名が含まれます。 |
プログラム・ユニットのコンパイル |
部分的なグローバル名が拡張されます。 |
グローバル名の変更は、部分的なグローバル・オブジェクト名を使用してリモート・データを参照するビュー、シノニムおよびプロシージャに影響を与える可能性があります。
参照先データベースのグローバル名を変更すると、ビューおよびプロシージャは存在しないデータベースまたは正しくないデータベースを参照しようとすることがあります。ただし、シノニムは実行時にデータベース・リンク名を拡張しないので、何も変わりません。
グローバル名の変更のシナリオを示します。
たとえば、sales.uk.example.comおよびhq.uk.example.comという2つのデータベースを考えます。また、salesデータベースに次のビューとシノニムがあるとします。
CREATE VIEW employee_names AS
SELECT ename FROM scott.emp@hr;
CREATE SYNONYM employee FOR scott.emp@hr;
データベースは、employeeシノニム定義を拡張して、次のように保存します。
scott.emp@hr.uk.example.com
シナリオは、両方のグローバル・データベース名が変更される状況を示しています。
最初に、営業および人事の両部門が米国に配置替えされるという状況を考えます。その結果、対応するグローバル・データベース名はどちらも次のように変更されます。
sales.uk.example.comはsales.us.example.comになります。
hq.uk.example.comはhq.us.example.comになります。
次の表は、グローバル名の変更前および変更後の問合せの拡張を示しています。
| salesへの問合せ | 変更前の拡張 | 変更後の拡張 |
|---|---|---|
|
|
|
|
|
|
シナリオは、1つのグローバル・データベース名が変更される状況を示しています。
この例では、営業部のみが米国に移動し、人事部は英国に留まるとします。その結果、対応するグローバル・データベース名はどちらも次のように変更されます。
sales.uk.example.comはsales.us.example.comになります。
hq.uk.example.comは変わりません
次の表は、グローバル名の変更前および変更後の問合せの拡張を示しています。
| salesへの問合せ | 変更前の拡張 | 変更後の拡張 |
|---|---|---|
|
|
|
|
|
|
この場合、employee_namesビューを定義している問合せが、存在しないグローバル・データベース名に拡張されます。ただし、employeeシノニムは、引き続き正しいデータベースであるhq.uk.example.comを参照します。
分散システムでアプリケーション開発を行うと、非分散システムには当てはまらない問題が発生します。
関連項目:
分散システム向けアプリケーションの開発方法の詳細は、「分散データベース・システムのアプリケーション開発」
Oracle Database分散データベース・システムを、システムを使用するユーザーに対して透過的にするアプリケーションを最小限の作業で開発できます。透過性の目的は、分散データベース・システムを単一のOracle Databaseであるかのように処理することです。その結果、分散データベース・アプリケーション開発を困難なものにし、ユーザーの生産性を損なう恐れのある複雑さがなくなり、システムの開発者やユーザーの負担が軽減します。
Oracle Databaseの分散データベース・システムには、アプリケーション開発者および管理者がデータベース・オブジェクトの物理的な位置をアプリケーションおよびユーザーから隠す機能があります。
ユーザーが、アプリケーションの接続先ノードに関係なく、表などのデータベース・オブジェクトを一様に参照できるのには、位置の透過性が関係しています。位置の透過性には、次のようないくつかの利点があります。
データベースのユーザーはデータベース・オブジェクトの物理的な位置を知る必要がないため、リモート・データへのアクセスが簡単になります。
管理者は、エンド・ユーザーや既存のデータベース・アプリケーションに影響を与えることなく、データベース・オブジェクトを移動できます。
通常、管理者および開発者は、アプリケーション・スキーマ内の表およびサポート・オブジェクトに対する位置の透過性を確立するために、シノニムを使用します。たとえば、次の文は、データベース内に別のリモート・データベース内の表に対応するシノニムを作成します。
CREATE PUBLIC SYNONYM emp FOR scott.emp@sales.us.americas.example_auto.com; CREATE PUBLIC SYNONYM dept FOR scott.dept@sales.us.americas.example_auto.com;
これにより、リモート表にアクセスする際に次のような問合せを使用する必要がなくなります。
SELECT ename, dname
FROM scott.emp@sales.us.americas.example_auto.com e,
scott.dept@sales.us.americas.example_auto.com d
WHERE e.deptno = d.deptno;
アプリケーションでは、リモート表の位置を考慮せずに、単純な問合せを発行できます。
SELECT ename, dname FROM emp e, dept d WHERE e.deptno = d.deptno;
シノニムの他にも、ビューおよびストアド・プロシージャを使用して、分散データベース・システムで動作するアプリケーションに対する位置の透過性を確立できます。
Oracle Databaseの分散データベース・アーキテクチャは、問合せ、更新およびトランザクションの透過性を提供します。
たとえば、SELECT、INSERT、UPDATE、DELETEなどの標準のSQL文は、非分散データベース環境の場合とまったく同じように動作します。また、アプリケーションは、標準のSQL文であるCOMMIT、SAVEPOINTおよびROLLBACKを使用して、トランザクションを管理します。分散トランザクションを制御するために複雑なプログラミングやその他の特別な操作を行う必要はありません。
1つのトランザクション内の文からは任意の数のローカル表またはリモート表を参照できます。
データベースでは、分散トランザクションに関係するノードがすべて同じ動作をすることが保証されており、それらのノードすべてがトランザクションをコミットまたはロールバックします。
分散トランザクションのコミット中にネットワークまたはシステムの障害が発生した場合、トランザクションは自動的かつ透過的、およびグローバルに解決されます。具体的には、ネットワークまたはシステムがリストアされると、すべてのノードがトランザクションをコミットまたはロールバックします。
データベースの内部では、コミットされた各トランザクションに対して、そのトランザクション内の文による変更を一意に識別するためのシステム変更番号(SCN)が対応付けられます。分散データベースでは、次のときに通信中のノードのSCNが調整されます。
1つ以上のデータベース・リンクによって表されるパスを使用して接続が確立されるとき。
分散SQL文が実行されるとき。
分散トランザクションがコミットされるとき。
特に、分散データベース・システムのノード間でSCNが調整されることにより、文とトランザクションの両方のレベルでグローバルな分散読込み一貫性が保証されることは大きな利点です。必要であれば、グローバルな時間ベースの分散リカバリを完了することもできます。
開発者は、分散データベースで動作するアプリケーションをサポートするためのPL/SQLパッケージおよびプロシージャをコーディングできます。アプリケーションでは、ローカル・データベースでの処理を実行するためにローカル・プロシージャ・コールを実行でき、リモート・データベースでの処理を実行するためにRPCを実行できます。
プログラムがリモート・プロシージャをコールすると、ローカル・サーバーはすべてのプロシージャ・パラメータをコールされたリモートサーバーに渡します。たとえば、次のPL/SQLプログラム・ユニットでは、リモートのsalesデータベースにあるパッケージ・プロシージャdel_empをコールし、パラメータ1257を渡します。
BEGIN emp_mgmt.del_emp@sales.us.americas.example_auto.com(1257); END;
RPCを正常に実行するためには、コール側プロシージャがリモート・サイトに存在し、接続しようとするユーザーがそのプロシージャを実行するための適切な権限を持っている必要があります。
分散データベース・システム対応のパッケージおよびプロシージャを開発する際、開発者は、どのプログラム・ユニットをリモートの位置で実行し、その結果をどのようにコール側アプリケーションに返すのかについて理解した上で、コードを記述する必要があります。
Oracle Databaseの機能の1つである分散問合せの最適化は、トランザクションの分散SQL文内で参照されているリモート表からデータを取得するときに、サイト間で必要となるデータ転送の量を減らします。
分散問合せの最適化では、コストベース最適化の設定を使用して、リモート表から必要なデータのみを抽出するSQL式が検索または生成され、抽出されたデータはリモート・サイト(場合によってローカル・サイト)で処理され、その結果がローカル・サイトに送信されて最終処理が行われます。表データすべてをローカル・サイトに転送して処理する際にかかる時間と比較して、この操作では必要なデータ転送量が削減されます。
DRIVING_SITE、NO_MERGE、INDEXなど、各種のコストベース・オプティマイザ・ヒントを使用することによって、Oracle Databaseがデータを処理する場所と、データへのアクセス方法を制御できます。
関連項目:
コストベースの最適化の詳細は、「コストベース最適化の使用」
分散環境では、異なるデータベースおよびクライアントが異なるキャラクタ・セットを使用できます。
Oracle Databaseは、クライアント、Oracle DatabaseサーバーおよびOracle Database以外のサーバーが異なるキャラクタ・セットを使用する環境をサポートしています。異機種環境のためにNCHARのサポートが提供されています。
各国語サポート(NLS)および異機種間サービス(HS)に関連する各種の環境変数および初期化パラメータを設定することにより、異なるキャラクタ・セット間でのデータ変換を制御できます。
キャラクタの設定は、次のNLSおよびHSパラメータで定義されます。
| パラメータ | 環境 | 定義の対象 |
|---|---|---|
|
クライアント/サーバー |
クライアント |
|
クライアント/サーバー 非異機種間分散 異機種間分散 |
Oracle Databaseサーバー |
|
異機種間分散 |
Oracle以外のデータベース・サーバー Transparent Gateway |
|
異機種間分散 |
Oracle Databaseサーバー Transparent Gateway |
関連項目:
NLSパラメータの詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。
HSパラメータの詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』を参照してください
クライアント/サーバー環境では、クライアントのキャラクタ・セットは、Oracle Databaseサーバーのキャラクタ・セットと同じにするか、またはそのサブセットに設定します。
図31-6は、クライアント/サーバー環境を示しています。
非異機種環境では、クライアントとサーバーのキャラクタ・セットは、メイン・サーバーのキャラクタ・セットと同じにするか、またはそのサブセットにする必要があります。
図31-7は、同機種間分散環境を示しています。
異機種環境では、クライアント、Transparent Gatewayおよび非Oracle Databaseデータソースのグローバリゼーション・サポート・パラメータの設定は、データベース・サーバーのキャラクタ・セットと同じにするか、そのサブセットにする必要があります。
図31-8は、異機種間分散環境を示しています。Transparent Gatewayは、グローバリゼーションを完全にサポートしています。
異機種環境では、異機種間サービス・テクノロジによって構築されたTransparent Gatewayのみが完全なNCHAR機能をサポートします。特定のTransparent GatewayがNCHARをサポートしているかどうかは、対象となるOracle Database以外のデータソースによって異なります。特定のTransparent GatewayによるNCHARサポートの処理方法の詳細は、システム固有のTransparent Gatewayのマニュアルを参照してください。
関連項目:
異機種間サービスの詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』を参照してください。
