2Oracle Database Provider for DRDAのアーキテクチャ

この章では、Oracle Database Provider for DRDAのアーキテクチャについて説明します。

この章には次のトピックが含まれます:

プロトコルに関する考慮事項
2フェーズ・コミット・トランザクションのリカバリ
サービスの自律性
パッケージ
SQL言語

DB2でDRDAの詳細は、http://www.ibm.comでDB2 Version 9.1 for z/OS Information Centerを参照してください。

プロトコルに関する考慮事項

DRDAは、Oracle SQL*Netデータ・プロトコルといくつかの類似点があるデータ・プロトコルです。DRDAは、クライアントとサーバー間でリレーショナル・データを移動するように設計されていますが、SQL*Netに備わっている堅牢性の高い管理およびルーティング制御はありません。DRDAとSQL*Netの主な違いは、プロトコル自体の言語です。DRDAとSQL*Netは互換性がないため、SQL*Netクライアントを使用したDRDAサーバーへの接続(またはその逆)はできません。

DRDAで使用される用語はSQL*Netに似ており、一般的な概念は、従来のOracleの定義に当てはめると、次の例のようになります。

アプリケーション・リクエスタ(AR)は、クライアント・プログラムがSQLベースのリクエストを作成してアプリケーション・サーバーに送信するためのインタフェースです。
アプリケーション・サーバー(AS)は、クライアントのかわりにこのようなリクエストを受け入れ、データベース操作を実行し、結果データをクライアントに戻すサーバー側およびデータベース側のプログラムです。

2フェーズ・コミットおよびトランザクション・リカバリ

DRDAとDB2では、トランザクションをコミットおよびロールバックできるようにする2つのコマンド・セットが実装されています。これにより、トランザクション更新中にデータの整合性が維持され、トランザクションのコミット時に接続またはアプリケーションで障害が発生した場合にはこれらの更新をリカバリできます。DRDAでは、シングル・サイトおよび2フェーズの両方のコミット・プロトコルを実装するコマンドがサポートされています。最小限でも、ASはSingleSiteコミットをサポートする必要があります。

シングル・サイト・コミット・プロトコルは、分散トランザクションに関与しているノード間の調整機能がない単純な操作で構成されています。これは基本的なデータ・コミット・メカニズムであり、ほとんどの一般的なアプリケーションで使用されています。
2フェーズ・コミット・プロトコルでは、同一ノードまたは異なるネットワーク・ノード上の複数のトランザクションを調整できます。

サービスの自律性

アプリケーション・サーバーは、Oracle Databaseサーバーの外部にあります。このため、アプリケーションには様々なロケーション・オプションがあります。

通常の構成では、図1-1に示すように、ASはOracle Databaseと同じマシン上で実行されます。ASはOracle Databaseと密接に統合されていないため、それ自体のOracleホームにインストールされるか、または図2-1に示すようにクライアントおよびデータベースとは別のマシンにインストールされます。この中間層構成では、サービス・リソースを切り離すことができます。また、個別のマシン・リソースをASとデータベースのそれぞれに専用として使用できるため、サービスのスケーリングが向上します。

図2-1 AS中間層構成

クライアント層およびサーバー層からASを切り離すことで、セキュリティと信頼性も向上します。ASがクラッシュしても、Oracle Databaseインスタンスには影響しません。データベースの整合性が維持され、トランザクションの状態がリカバリされます。

パッケージ

DRDAアプリケーションに関連付けられているリソースはパッケージと呼ばれます。具体的には、アプリケーション・リクエスタはアプリケーションで行われる処理内容の参照としてパッケージを使用します。パッケージには文が格納されています。アプリケーションは、セクション番号によって文を参照します。アプリケーションの文は、一般に静的な文と動的な文の2種類に分類されます。

静的な文には、ハードコーディングされたSQLが含まれます。アプリケーションの実行中にSQLテキストが変更されない文です。実行にかかる時間が非常に短く、多くの場合、高いパフォーマンスを実現するために実行前に最適化されます。事前に定義されているため、静的SQLを初めてコールするときの実行時間が短縮されます。
動的な文は、主に空のプレースホルダであり、汎用カーソルとも呼ばれます。実行前にはSQLテキストがなく、アプリケーションによって操作で必要な実際のSQL文が作成され、実行時に最適化されます。通常、最初のコールの後に処理済の動的SQL文がキャッシュに入れられるので、これ以降に同じ文が実行される場合にかかる時間は、同程度に複雑な静的SQL文と同等になります。

パッケージは専用ツールを使用して作成されます。たとえばDB2アプリケーション環境では、開発者が埋込みSQL文が含まれているアプリケーションを作成することがよくあります。アプリケーション・ソースはSQL PreCompiler (OracleのPro*Cプリコンパイラに類似する機能)により処理されます。通常、出力は後処理され、ソース・プログラムで使用されるオンディスク・リソース形式の文とともにソース・モジュールに取り込まれます。DB2の用語で説明すると、これによりデータベース・リクエスト・モジュール(DBRM)が作成されます。このファイルを作成するほとんどの実装では、ファイルが独自の形式で外部に格納されます。

DBRMの内容は、リモート・データベースにロードされるか、または実行時点でASに対して使用可能になっている必要があります。ただし、独自の形式のデータをロードする際には様々な課題があります。DRDAではこれに対処するため、リソース定義をターゲットASにリモートでアップロードするための一連のコマンド・リクエストが用意されています。ほとんどのAR実装では、アプリケーションのSQLセッションの実行前または実行中にリソースをアップロードするためのオプションまたはツールがあります。このプロセスはパッケージのバインドと呼ばれます。

リソース定義(DBRM)がパッケージとしてリモート・データベースにバインドされた後で、ASはパフォーマンス向上のために事前にDBRMをロードできます。

SQL言語

現在のほとんどのSQLベース・データベース・システムと同様に、Oracleは部分的にANSI SQLに準拠していますが、いくつかの例外があります。ANSI SQL規格の実装はデータベース・ベンダーによって異なるため、SQL言語で文の実行時にいくつかの課題が生じます。DRDAで使用されていた、当初のターゲット・データベースがDB2であるため、ここで説明するアプリケーションではDB2固有のSQL言語を使用します。

ほとんどのデータ操作言語(DML)および一部のデータ定義言語(DDL)は、よく使用されるオブジェクト(表、ビュー、索引、単純なプロシージャ、ファンクンション定義など)についてANSI SQLで標準化されています。ただし、各データベース・ベンダーによって、DDLおよびDMLの両方に対するそれぞれの製品固有の拡張が今後も提供されていきます。DRDAプロトコルは、SQL文をデータベースが処理する必要があるデータベース固有のエンティティとして扱います。このことは、SQLはDB2の言語で記述されること、Oracle Databaseで処理するには翻訳サービスが必要になることを意味します。この翻訳はSQL翻訳フレームワーク機能により提供されます。詳細はOracle® Database移行ガイドを参照してください。