Oracle Database 2日でデータ・レプリケーションおよび統合ガイド 11g リリース1(11.1) E05777-03 |
|
この章では、複数のOracleおよびOracle以外のデータベース内の情報のアクセス方法および変更方法を説明します。
この章は次の項で構成されています。
Oracle Databaseに接続している間は、他のOracle Database内およびOracle以外のデータベース内の情報にアクセスして変更できます。2つ以上のデータベース内の情報が1つのデータベースに出現する場合は、これをフェデレーションと呼びます。フェデレーションは、情報を元の場所に残し、そこでメンテナンスと更新が行われます。複数のデータ・ソースが1つの仮想データベースに統合されているように見えるため、異なる種類のデータベースが1つの統合ビューに表示されます。フェデレーテッド構成により、すべてのデータベースがアプリケーションとエンド・ユーザーから1つの仮想データベースのように見えるため、分散システムの複雑さが一部緩和されます。
次の各項で、複数のデータベース内の情報のアクセスおよび変更に関する詳細情報を示します。
分散SQLにより、アプリケーションおよびユーザーは、複数のデータベース内の情報を単一のSQL文で問合せまたは変更できます。分散SQLはデータの物理的な位置をマスクするため、アプリケーションを変更しなくてもデータの位置を変更できます。分散SQLには、分散問合せ(データにアクセスします)と分散トランザクション(データを変更します)があります。分散トランザクションでは、2フェーズ・コミット・メカニズムにより、分散トランザクションに関係する各データベースでトランザクション内のすべての文を1単位としてコミットまたはロール・バックすることでデータの整合性が保証されます。
アプリケーションまたはユーザーが分散トランザクションのコミットを試行する場合、アプリケーションまたはユーザーが接続されているデータベースはグローバル・コーディネータと呼ばれます。グローバル・コーディネータは、次のフェーズを開始することによって2フェーズ・コミットを完了します。
シノニムは、別のデータベース・オブジェクトの別名として機能するデータベース・オブジェクトです。パブリック・シノニムとプライベート・シノニムの両方を作成できます。すべてのデータベース・ユーザーがパブリック・シノニムにアクセスできます。プライベート・シノニムは、特定のユーザーのスキーマにあり、プライベート・シノニムへのアクセス権を付与されたユーザーのみがこれを使用できます。
分散環境では、シノニムはデータベース・オブジェクトの位置の透過性を提供できます。シノニムは、データベース・オブジェクトの位置をアプリケーションおよびユーザーから隠します。データベース・オブジェクトを移動または名前変更する必要がある場合は、シノニムを再定義でき、アプリケーションおよびユーザーは変更を行わずにシノニムを使用し続けることができます。
たとえば、リモート・データベースにあるhr.employees
表にii2.example.com
というグローバル名でアプリケーションがアクセスする必要があるとします。リモート・データベースへのデータベース・リンクが存在し、データベース・リンクの名前はii2.example.com
です。この場合は、hr
スキーマに表hr.employees@ii2.example.com
を指すemployees
という名前のシノニムを作成できます。シノニムがある場合、ローカル・データベースのアプリケーションはhr.employees
を使用してリモート表にアクセスできます。
分散SQLを使用して、Oracle DatabaseだけでなくOracle以外のデータベース内のデータをフェデレートできます。Oracle Database Gatewayにより、Oracle Databaseは、Sybase、DB2、Informix、Microsoft SQL Server、INGRES、Teradataデータベースなどの多くのOracle以外のデータベース内のデータにアクセスして変更できます。このアクセスは、エンド・ユーザーに対して完全に透過的です。つまり、Oracle DatabaseとOracle以外のデータベースのどちらのデータにアクセスするかにかかわらず、同じSQL文を発行できます。
フェデレーテッド環境で複雑な操作を実行する際のネットワーク・トラフィックを削減するために、ストアド・プロシージャを使用できます。プロシージャまたはファンクションは、特定の問題を解決するため、または関連する一連のタスクを実行するために実行されるスキーマ・オブジェクトです。ファンクションがコール元に必ず単一の値を返すのに対し、プロシージャは値を返さないという点を除き、プロシージャとファンクションは同一です。一般に、アクションの実行にはプロシージャを使用し、値の計算にはファンクションを使用します。このマニュアルでは、ストアド・プロシージャという一般用語にはプロシージャとファンクションの両方が含まれます。
Oracle Databaseでは、PL/SQLまたはJavaに書き込まれるストアド・プロシージャがサポートされますが、このマニュアルでは、PL/SQLストアド・プロシージャについてのみ説明します。PL/SQLストアド・プロシージャは、SQL文のセットと、グループ化されてデータベースに格納されている他のPL/SQL構成メンバーから構成されます。ストアド・プロシージャでは、SQLの容易性および柔軟性を構造化プログラミング言語のプロシージャ型機能と組み合せることができます。
SQL文と同様に、ストアド・プロシージャを実行するには、物理的な位置を認識する必要はありません。同様に、適切なOracle Database Gatewayを使用して、Oracle以外のデータベースにあるストアド・プロシージャもコールできます。この場合、ゲートウェイはPL/SQLコールをOracle以外のデータベースのストアド・プロシージャにマッピングします。
参照:
|
この項では、他のデータベースにある情報にアクセスしそれを変更するためのデータベースの準備に必要なアクションについて説明します。
GLOBAL_NAMES
初期化パラメータをTRUE
に設定します。方法については、「GLOBAL_NAMES初期化パラメータをTRUEに設定」を参照してください。
分散問合せは、2つ以上のデータベース内の情報にアクセスします。シノニムまたはSELECT
文で、名前の最後に@
dblink
を付けることにより、リモート表、ビュー、またはマテリアライズド・ビューを識別できます。dblink
は、リモート・データベース・オブジェクトを含むデータベースへのデータベース・リンクです。
この項の分散問合せを実行する前に、次の条件を満たします。
ii1.example.com
データベースのSYSTEM
ユーザーが、ii2.example.com
データベースのSYSTEM
ユーザーに接続するデータベース・リンクを使用します。このようなデータベース・リンクの作成の詳細は、「チュートリアル: データベース・リンクの作成」を参照してください。
hr
サンプル・スキーマがローカル・データベースにインストールされ、oe
サンプル・スキーマがリモート・データベースにインストールされていることを確認します。これらのサンプル・スキーマは、Oracle Databaseとともにデフォルトでインストールされます。
この項では、ii1.example.com
とii2.example.com
をサンプル・データベースとして使用します。使用している環境で、これらの条件を満たす任意の2つのデータベースをかわりに使用できます。
この例では、次のことを想定します。
ii1.example.com
データベースのhr
スキーマに保持し、注文入力情報をii2.example.com
データベースに保持しています。
hr.employees
表のemployee_id
はoe.orders
表のsales_rep_id
に対応します。
この場合、営業担当者の連絡先情報は、ii1.example.com
データベースのhr.employees
表にあり、注文情報はii2.example.com
データベースのoe.orders
表にあります。
ii2.example.com
データベースにあるoe.orders
表を指すord
というシノニムをhr
スキーマ内に作成します。
SYSTEM
ユーザーとしてEnterprise Managerにログインします。
ii1.example.com
データベース・インスタンスの「データベース」ホームページに移動します。
ord
と入力します。
「スキーマ」
を選択した状態で、「スキーマ」フィールドにhr
と入力し、懐中電灯アイコンをクリックしてhr
スキーマを選択します。
SYSTEM
ユーザーのii2.example.com
データベース・リンクを選択します。
oe.orders
と入力します。
SYSTEM
ユーザーとしてii1.example.com
データベースに接続します。SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
COLUMN FIRST_NAME HEADING 'First Name' FORMAT A20 COLUMN LAST_NAME HEADING 'Last Name' FORMAT A20 COLUMN PHONE_NUMBER HEADING 'Phone Number' FORMAT A20 SELECT e.first_name, e.last_name, e.phone_number FROM hr.employees e, hr.ord o WHERE o.order_id = 2456 AND e.employee_id = o.sales_rep_id;
出力は、次のようになります。
First Name Last Name Phone Number -------------------- -------------------- -------------------- Danielle Greene 011.44.1346.229268
分散トランザクションには、2つ以上のデータベース内のデータまたはデータベース・オブジェクトの構造を個別に、またはグループとして変更する1つ以上の文が含まれます。シノニム、またはリモート・データベース内のデータを変更する文では、名前の最後に@
dblink
を追加することでデータベース・オブジェクトを識別できます。dblink
は、リモート・データベース・オブジェクトを含むデータベースへのデータベース・リンクです。
表のデータを変更する文は、データ操作言語(DML)と呼ばれます。データベース・オブジェクトの構造を変更する文は、データ定義言語(DDL)文と呼ばれます。DML文とDDL文は、どちらも分散トランザクションの一部にすることができます。
この項の分散トランザクションを実行する前に、次の条件を満たします。
ii1.example.com
データベースのSYSTEM
ユーザーが、ii2.example.com
データベースのSYSTEM
ユーザーに接続するデータベース・リンクを使用します。このようなデータベース・リンクの作成の詳細は、「チュートリアル: データベース・リンクの作成」を参照してください。
hr
サンプル・スキーマがローカル・データベースにインストールされ、oe
サンプル・スキーマがリモート・データベースにインストールされていることを確認します。これらのサンプル・スキーマは、Oracle Databaseとともにデフォルトでインストールされます。
この項では、ii1.example.com
とii2.example.com
をサンプル・データベースとして使用します。使用している環境で、これらの条件を満たす任意の2つのデータベースをかわりに使用できます。
この例では、次のことを想定します。
ii1.example.com
データベースのhr
スキーマに保持し、注文入力情報をii2.example.com
データベースに保持しています。
hr.employees
表のemployee_id
はoe.orders
表のsales_rep_id
に対応します。
hr.employees
表内のこの営業担当者のemployee_id
は154
です。この従業員のjob_id
およびmanager_id
データをhr.employees
表で変更する必要があります。
hr.employees
内で、注文を担当する営業担当者のemployee_id
は148
です。sales_rep_id
154
に現在割り当てられているoe.orders
表のすべての注文は、sales_rep_id
148
に変更する必要があります。
会社は、これらの変更を単一の分散トランザクションでコミットすることを希望します。
ii2.example.com
データベースにあるoe.orders
表を指すord
というシノニムをhr
スキーマ内に作成します。このシノニムの作成方法は、「チュートリアル: 複数のOracle Databaseの問合せ」の手順1を参照してください。
SYSTEM
ユーザーとしてii1.example.com
データベースに接続します。SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
UPDATE hr.employees SET job_id = 'SA_MAN', manager_id = 100 WHERE employee_id = 154; UPDATE hr.ord SET sales_rep_id = 148 WHERE sales_rep_id = 154; COMMIT;
リモート・プロシージャ・コール(RPC)は、リモート・データベースのプロシージャまたはファンクションを実行します。RPCは、リモート・プロシージャに定義されている作業を実行します。リモート・プロシージャまたはファンクションを実行するには、名前の最後に@
dblink
を追加することでリモート・プロシージャまたはファンクションを識別できます。dblink
は、リモート・プロシージャまたはファンクションを含むデータベースへのデータベース・リンクです。リモート・プロシージャまたはファンクションを指すシノニムも作成できます。
この項のサンプルRPCを実行する前に、次の条件を満たします。
ii1.example.com
データベースのSYSTEM
ユーザーが、ii2.example.com
データベースのSYSTEM
ユーザーに接続するデータベース・リンクを使用します。このようなデータベース・リンクの作成の詳細は、「チュートリアル: データベース・リンクの作成」を参照してください。
hr
サンプル・スキーマがリモート・データベースにインストールされていることを確認します。hr
サンプル・スキーマは、Oracle Databaseとともにデフォルトでインストールされます。
この項では、ii1.example.com
とii2.example.com
をサンプル・データベースとして使用します。使用している環境で、これらの条件を満たす任意の2つのデータベースをかわりに使用できます。
この例では、次のことを想定します。
ii2.example.com
データベースのhr
スキーマに保持しています。
hr
スキーマはローカルii1.example.com
データベースに存在しません。
hr
スキーマのadd_job_history
というプロシージャはhr.job_history
表に行を挿入します。この行には、従業員の会社での履歴に関する情報が含まれます。
employee_id
が127
の従業員が会社を退職します。
ii1.example.com
データベースに接続し、ii2.example.com
データベースのadd_job_history
プロシージャを実行して、従業員127
のジョブ履歴を記録します。
SYSTEM
ユーザーとしてii1.example.com
データベースに接続します。SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
ii2.example.com
データベースのadd_job_history
プロシージャを実行して、従業員のジョブ履歴を記録します。
exec hr.add_job_history@ii2.example.com(127,'14-JAN-99','26-JUN-06','ST_CLERK',50);
COMMIT;
この手順は、リモート・プロシージャがコミットする場合は不要です。
ii2.example.com
データベースのhr.job_history
表を問い合せて、挿入された行を確認します。
SELECT * FROM hr.job_history@ii2.example.com ORDER BY employee_id;
出力は、次のようになります。
EMPLOYEE_ID START_DAT END_DATE JOB_ID DEPARTMENT_ID ----------- --------- --------- ---------- ------------- 101 21-SEP-89 27-OCT-93 AC_ACCOUNT 110 101 28-OCT-93 15-MAR-97 AC_MGR 110 102 13-JAN-93 24-JUL-98 IT_PROG 60 114 24-MAR-98 31-DEC-99 ST_CLERK 50 122 01-JAN-99 31-DEC-99 ST_CLERK 50 127 14-JAN-99 26-JUN-06 ST_CLERK 50 176 24-MAR-98 31-DEC-98 SA_REP 80 176 01-JAN-99 31-DEC-99 SA_MAN 80 200 17-SEP-87 17-JUN-93 AD_ASST 90 200 01-JUL-94 31-DEC-98 AC_ACCOUNT 90 201 17-FEB-96 19-DEC-99 MK_REP 20
employee_id
が127
の従業員のジョブ履歴が表に記録されていることに注意してください。
Oracle Database Gatewayでは、Oracle Databaseから、Sybase、DB2、Informix、Microsoft SQL Server、IngresおよびTeradataデータベースなどの多くのOracle以外のデータベースにアクセスおよび変更できます。最良のパフォーマンスおよび有用性のために、Oracle以外のデータベースを処理する際には、確立されたベスト・プラクティスに従う必要があります。
この項の内容は次のとおりです。
データの問合せ、データの変更、またはOracle以外のデータベース内のストアド・プロシージャを実行する前に、いくつかのタスクを実行する必要があります。
Oracle Database Gatewayとの通信が確立された後で、Oracle DatabaseはOracle以外のデータベースと通信できます。Oracle Databaseは、異機種間サービスを使用してOracle Database Gatewayと通信します。異機種間サービスの構成オプションの詳細は、『Oracle Database Heterogeneous Connectivity管理者ガイド』を参照してください。
CONNECT
TO
句を使用する必要があります。手順1および2を完了すると、Oracle Databaseに接続するときと同様にデータベース・リンクを作成できます。方法については、「チュートリアル: データベース・リンクの作成」を参照してください。
これらの手順を完了した後で、Oracle以外のデータベース内のデータおよびプロシージャに透過的にアクセスできます。Oracle以外のデータベースを操作するには、次の項の手順に従って、Oracle以外のデータベース内のデータベース・オブジェクトを指定します。
Oracle Database Gatewayのパフォーマンスは、ネットワークのスピード、使用可能なメモリー、データベースからデータベースへ転送されるデータ量および同時セッションの数などの、いくつかの要素から影響を受けます。これらの要素には、より高いパフォーマンスを得るために調整できるものもあります。
次のベスト・プラクティスで、より高いパフォーマンスを実現できます。
大量の事後処理がある場合、パフォーマンスに悪影響を与えます。より高いパフォーマンスを実現するには、可能なかぎりSQL文をOracle以外のデータベースで処理するようにします。WHERE
句の一部がOracle以外のデータベースへ送信されたSQLから欠落したり、結合が分割されると、問合せは事後処理になります。
次のベスト・プラクティスに従って事後処理を削減します。
WHERE
句でSQLファンクションを使用しないでください。WHERE
句のSQLファンクションはゲートウェイのパフォーマンスに影響を与えます。Oracle以外のデータベース内で一致しないOracleファンクションを使用している場合、ゲートウェイは補正を行います。データはOracle以外のデータベースから取得され、ファンクションはOracle Databaseに適用されます。
オプティマイザに最適な計画を生成する十分な情報がない場合、パフォーマンスは悪影響を受けます。Oracleオプティマイザは、Oracle以外のデータベースの表および索引統計を使用し最適なパスを決定して、Oracle以外のデータベースのデータにアクセスします。この情報が欠落または不正確な場合、アクセス・パスは最適ではありません。Oracle以外のデータベースで索引を定義すると、ゲートウェイのパフォーマンスが向上します。Oracleオプティマイザの詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。
次の初期化パラメータをカスタマイズして、パフォーマンスを向上できます。
たとえば、Oracle以外のデータベースでアクセスしているデータが、Oracle Databaseで使用しているキャラクタ・セットと同じ場合、HS_LANGUAGE
初期化パラメータをOracle Databaseのキャラクタ・セットに設定します。
Oracle Database Gatewayのインストールの場所がパフォーマンスに影響する可能性があります。たとえば、CPUに制約がある場合、Oracle Databaseを実行中のコンピュータ・システムでOracle Database Gatewayをインストールしないでください。
Oracle Database Gatewayを実行中のコンピュータ・システムに十分なメモリーがあることを確認してください。処理中のSQL文、同時セッションの数、オープン・カーソルの数およびアクセス中の表の列など、いくつかの要素はメモリー要件に影響します。
Oracle以外のデータベースを操作する場合は、識別子を二重引用符で囲まないかぎりOracle Databaseの文字がデフォルトで大文字になることに注意してください。たとえば、emp
という名前のSybase表を参照するには、次の例のように二重引用符で囲んだ名前を入力します。
SELECT * FROM "emp"@SYBS;
一方、ユーザーSmith
が所有しているemp
という名前のSybase表をOracleアプリケーションから参照するには、次のように入力します。
SELECT * FROM "Smith"."emp"@SYBS;
emp
という名前のSybase表がSMITH
(大文字の表所有者名)によって所有されている場合は、次の例に示すように二重引用符を付けずに所有者名を入力できます。
SQL> SELECT * FROM SMITH."emp"@SYBS; SQL> SELECT * FROM smith."emp"@SYBS; SQL> SELECT * FROM SmItH."emp"@SYBS;
|
![]() Copyright © 2007, 2008 Oracle Corporation. All Rights Reserved. |
|