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