16 アプリケーションおよびネットワークのアーキテクチャ
この章では、アプリケーション・アーキテクチャについて定義し、分散処理環境でOracleデータベースとデータベースのアプリケーションがどのように機能するかを説明します。このマニュアルの内容は、ほとんどすべてのタイプのOracle Database環境に適用されます。
この章の構成は、次のとおりです。
Oracleアプリケーション・アーキテクチャの概要
この章では、アプリケーション・アーキテクチャは、データベース・アプリケーションがOracleデータベースに接続するコンピューティング環境を示します。
この項では、次の項目について説明します。
クライアント/サーバー・アーキテクチャの概要
Oracle Database環境では、データベース・アプリケーションとデータベースはクライアント/サーバー・アーキテクチャに分割されます。
次のコンポーネントがあります。
-
クライアントでは、データベース情報にアクセスし、ユーザーと対話するデータベース・アプリケーション(SQL*Plus、Visual Basicデータ入力プログラムなど)が実行されます。
-
サーバーでは、Oracle Databaseソフトウェアが実行され、Oracleデータベースへの同時実行の共有データ・アクセスに必要な機能が処理されます。
クライアント・アプリケーションとデータベースを同じコンピュータで実行することもできますが、クライアント部分とサーバー部分を別々のコンピュータで実行し、それらのコンピュータをネットワークで接続する方がさらに効率的です。次の各項では、Oracle Databaseクライアント/サーバー・アーキテクチャの様々な形態について説明します。
分散処理
クライアント/サーバー・アーキテクチャの利点
分散処理環境でのOracle Databaseクライアント/サーバー・アーキテクチャには、多くの利点があります。
次のような利点があります。
-
クライアント・アプリケーションではデータ処理は実行されません。そのかわり、クライアント・アプリケーションは、ユーザーに入力をリクエストし、必要なデータをサーバーにリクエストし、そのデータを分析してクライアント・ワークステーションまたは端末の表示機能(グラフィックスやスプレッドシート)を使用して表示します。
-
クライアント・アプリケーションはデータの物理的な位置に依存しません。データを他のデータベース・サーバーに移動したり分散しても、アプリケーションはほとんど、またはまったく変更することなく、機能を続行できます。
-
Oracle Databaseでは、基礎となるオペレーティング・システムのマルチタスキング機能と共有メモリー機能を活用できます。その結果、クライアント・アプリケーションに最高度の同時実行性、データ整合性およびパフォーマンスが提供されます。
-
クライアント・ワークステーションや端末はデータの表示用に最適化でき(グラフィックスやマウスのサポート提供など)、サーバーはデータの処理と格納用に最適化できます(大容量のメモリーとディスク領域の搭載など)。
-
ネットワーク化された環境では、安価なクライアント・ワークステーションを使用して、サーバーのリモート・データに効率的にアクセスできます。
-
データベースは、システムの拡張とともにスケーリングできます。複数のサーバーを追加して、データベース処理の負荷をネットワーク全体に分散することや(水平スケール)、データベースをミニコンピュータやメインフレームなどに移動して、より大規模なシステムのパフォーマンス上の利点を活用(垂直スケール)することができます。どちらの場合も、Oracle Databaseにはシステム間での移植性があるため、データとアプリケーションをほとんど、またはまったく変更することなく維持できます。
-
ネットワーク化された環境の場合、共有データは、すべてのコンピュータに格納されるのではなく、サーバーに格納されます。これにより、同時アクセスの管理が簡略化され、効率的になります。
-
ネットワーク化された環境では、クライアント・アプリケーションからサーバーにデータベース・リクエストを送るときにSQL文を使用できます。サーバーが受け取ったSQL文はそのサーバーで処理され、その結果がクライアントに戻されます。ネットワークを介してやりとりされるのはリクエストと結果のみであるため、ネットワーク通信量は最小限ですみます。
関連項目:
分散データベースの詳細は、Oracle Database管理者ガイドを参照してください
複数層アーキテクチャの概要
従来の複数層アーキテクチャにおいては、アプリケーション・サーバーはクライアントにデータを提供し、クライアントとデータベース・サーバー間のインタフェースとして機能します。
このアーキテクチャでは、アプリケーション・サーバーを使用して次のことを実行できます。
-
Webブラウザなど、クライアントの資格証明の検証
-
データベース・サーバーへの接続
-
リクエストされた操作の実行
図16-3は、複数層アーキテクチャの例を示しています。
クライアント
クライアントは、データベース・サーバー上で実行される操作についてリクエストを出します。
このクライアントは、Webブラウザでも他のエンド・ユーザー・プログラムでもかまいません。複数層アーキテクチャでは、クライアントは1つ以上のアプリケーション・サーバーを介してデータベース・サーバーに接続します。
アプリケーション・サーバー
アプリケーション・サーバーは、クライアントにデータ・アクセスを提供します。また、クライアントと、1つ以上のデータベース・サーバーとの間のインタフェースとして機能し、アプリケーションをホスティングします。
アプリケーション・サーバーでは、最小限のソフトウェア構成を備えたクライアントである、Thinクライアントから、クライアントの継続的なメンテナンスを必要とせずにアプリケーションにアクセスできます。また、アプリケーション・サーバーでは、クライアント用にデータを再フォーマットし、クライアント・ワークステーションの負荷を軽減できます。
アプリケーション・サーバーは、クライアントのためにデータベース・サーバー上で操作を実行するとき、そのクライアントの識別を想定します。クライアント操作中に不要な操作や望ましくない操作を実行できないように、アプリケーション・サーバーの権限を制限することが、最良の方法です。
データベース・サーバー
データベース・サーバーは、クライアントにかわってアプリケーション・サーバーからリクエストされたデータを提供します。問合せ処理は、データベースによって実行されます。
データベース・サーバーは、クライアントおよび自身のためにアプリケーション・サーバーで実行された操作を監査できます。たとえば、クライアント操作はクライアントに表示する情報をリクエストでき、アプリケーション・サーバー操作はデータベース・サーバーに接続をリクエストできます。
統合監査で、データベースでは、アプリケーション・コンテキスト(アプリケーション固有の名前/値のペア)を統合監査証跡のレコードに追加できます。データベースによってデータベース監査レコードに書き込まれるアプリケーション・コンテキストを構成できます。
関連項目:
-
「データベース監査」
サービス指向アーキテクチャ(SOA)
データベースは、従来の複数層またはサービス指向アーキテクチャ(SOA)環境でWebサービス・プロバイダとして機能できるようになりました。
SOAはネットワーク上にあるコンピュータ間での相互作用をサポートするサービスに依存する、複数層アーキテクチャです。SOAとの関連で、サービスは自給自足の機能的エンドポイントで、機能とサービス・レベルの明確な合意があり、監視および管理が可能で、ポリシー・コンプライアンスの実施に役立ちます。
通常、SOAサービスはHTTPプロトコルを介してアクセスできるWebサービスとして実装されます。これらのサービスは、WSDLやSOAPなどのXML標準に基づいています。
Oracle XML DBの一部として実装されるOracle DatabaseのWebサービス機能は、DBAが明示的に有効化する必要があります。アプリケーションは、データベースWebサービスを介して次のことを実行できます。
-
SQLまたはXQuery問合せの発行およびXMLでの結果の受信
-
スタンドアロンPL/SQLファンクションの起動および結果の受信
-
PL/SQLパッケージ・ファンクションの起動および結果の受信
データベースWebサービスを使用すると、アプリケーション・サーバーがなくても、アプリケーション環境に簡単にWebサービスを追加できます。ただし、Oracle Fusion Middlewareなどのアプリケーション・サーバーを介してWebサービスを起動すると、SOA環境で、セキュリティ、スケーラビリティ、UDDI登録および信頼できるメッセージ機能の面でさらに利点があります。ただし、データベースWebサービスはOracle Fusion Middlewareと簡単に統合できるため、SOAソリューションの最適化に適しています。
関連項目:
-
データベースWebサービスを有効化する方法および使用方法の詳細は、『Oracle XML Developer's Kitプログラマーズ・ガイド』を参照してください
-
SOAおよびWebサービスの詳細は、Oracle Fusion Middlewareのマニュアルを参照してください。
グリッド・アーキテクチャの概要
Oracle Database環境では、グリッド・コンピューティングは、柔軟なオンデマンド・コンピューティング・リソースに多くのサーバーおよび記憶域を効率的にプールするコンピューティング・アーキテクチャです。
ビジネスのニーズの変化に対応して、必要であればモジュール化したハードウェアおよびソフトウェア・コンポーネントのグループを接続および再結合できます。
関連項目:
サーバーおよび記憶域グリッドの詳細は、「グリッド・コンピューティングの概要」を参照してください
Global Data Servicesの概要
Global Data Services (GDS)は、レプリケートされたデータベース用の自動化されたワークロード管理ソリューションです。
データベース・サービスとは、1つ以上のデータベース・インスタンスに名前を付けて表現したものです。グローバル・サービスは、データ・レプリケーションにより同期化された複数のデータベースにより提供されるサービスです。
関連項目:
「サービス名」
サービスの目的
データベース・サービスは共通の属性、サービス・レベルのしきい値、優先度、スケジューリング、および機能属性を持つアプリケーションのグループを表します。
サービスを使用すると、データベース・ワークロードをグループ化して、特定の作業要求を適切なデータベース・インスタンスにルーティングできます。このように、サービスでは競合アプリケーションを管理するための単一のシステム・イメージが提供されます。
サービスに関連付けられたデータベース・インスタンスの数は、アプリケーションに対して透過的です。また、アプリケーションにはサービスの提供場所に関するナレッジがないため、ロケーションの透過性も備えています。
要件に応じて、次のいずれかの方法でサービスを構成できます。
-
単一のサービスをOracle Real Application Clusters (Oracle RAC)データベースの1つ以上のインスタンスか、GDSで管理されたグローバル・トポロジ内の複数のデータベースに適用できます。
-
単一のデータベース・インスタンスは複数のサービスをサポートできます。
-
単一のサービスは、XAアフィニティなどの機能的理由と、高度にスケールしないアプリケーションのために、1つのデータベース・インスタンスのみをサポートできます。
GDSの目的
GDSを使用すると、ローカルおよびグローバルにレプリケートされたデータベースを、グローバル・クライアント間で共有可能なGDS構成に統合できます。GDS構成は、データベース・クライアントには仮想の複数インスタンス・データベースのように認識されます。
GDSには、次の利点があります。
-
グローバルに分散されたマルチデータベース構成を含むグローバル・リソースの中央管理が可能
-
グローバルなスケーラビリティ、可用性およびランタイム・ロード・バランシングを提供します。
-
シームレス・フェイルオーバーのサポート
-
GDS構成へのデータベースの動的な追加、およびグローバル・サービスの動的な移行が可能
-
最適なリソース使用率が可能
関連項目:
GDSの利点の詳細は、Oracle Database Global Data Services概要および管理ガイドを参照してください。
GDSのアーキテクチャ
GDSは、グローバル・サービス用のソフトウエア・インフラストラクチャです。
GDSは、GDS構成の構成、メンテナンスおよび監視を自動化および集中化し、グローバル・サービスに対するロード・バランシングおよびフェイルオーバーを有効にします。フレームワークによって管理オーバーヘッドを最小に抑えながらこれらの仮想リソースが管理されるため、GDS構成では追加のクライアント・リクエストを処理できます。
GDSは、次の既存のOracle Databaseテクノロジに基づいて構築されています。
-
Active Data Guard
読取り専用データベースの高いパフォーマンスのファームを可能にします。
-
Data Guard Broker
プライマリ・データベースと最大30のスタンバイ・データベースを含むData Guard構成の作成、管理および監視を可能にします。
-
GoldenGate
複数のデータベースの間でレプリケーションの更新を可能にします。
図16-4は、GDS構成の例を示しています。(複雑にならないように)この図にはすべての接続は示されていませんが、GDS構成内のすべてのデータベースはすべてのGSMと通信します。次の項ではコンポーネントについて説明します。
関連項目:
GDS構成
GDS構成はデータベースの自己完結型システムに名前を付けて、1つ以上のグローバル・サービスを提供する単一の仮想サーバーに統合したものです。基本的に、一連のデータベースにGDS構成を使用する利点は、単一のデータベースにOracle Real Application Clusters (Oracle RAC)を使用する利点と同じです。
GDS構成内のデータベースは、ローカルまたはグローバルに分散できます。クライアントは、GDS構成のコンポーネントとトポロジに関する知識がなくても、グローバル・サービス名を指定することによりGDS構成に接続できます。この意味で、GDS構成へのクライアント接続は、Oracle RACでのクライアント接続と似ています。
「GDSのアーキテクチャ」は、11個のデータベースを含む1つのGDS構成を示しています。DB1、DB2およびDB5はいずれもレプリケーションにGoldenGateを使用するOracle RACデータベースです。3つのデータベースはいずれも、Data Guardによって保護されています。CATもData Guardにより保護されたデータベースであり、GDSに必要なメタデータを格納します。DB5は、スタンドバイ・データベースDB6によって保護されたOracle RACデータベースです。
関連項目:
GDS構成の管理方法の詳細は、Oracle Database Global Data Services概要および管理ガイドを参照してください。
GDSプール
GDSプールとは、一意のグローバル・サービス・セットを提供し同じ管理ドメインに属するGDS構成内の一連のデータベースに名前を付けたものです。
データベースを複数のプールにパーティション化すると、サービス管理が簡素化されます。また、各プールを異なる管理者が管理できるため、セキュリティが向上します。
1つのデータベースが属することができるのは、1つのプールのみです。プールのすべてのデータベースで同じグローバル・サービス・セットを提供する必要はありません。ただし、同じグローバル・サービスを提供するデータベースはすべて同じプールに属する必要があります。
「GDSのアーキテクチャ」は、2つのGDSプール(SALESおよびHR)を示しています。それぞれのプールは、独自のグローバル・サービスのセットに関連付けられています。
関連項目:
GDSプールの管理方法の詳細は、Oracle Database Global Data Services概要および管理ガイドを参照してください。
GDSリージョン
GDSリージョンとは、地理的あるいは他の方法で互いに関連付けられたデータベース・クライアントおよびサーバーが含まれる論理境界です。
たとえば、1つのリージョンが1つのデータ・センターに対応する場合があります。通常、リージョンのメンバーはネットワーク近接度を共有し、同じローカル・エリア・ネットワーク(LAN)またはメトロポリタン・エリア・ネットワーク(MAN)のメンバーとなります。
1つのGDS構成に複数のリージョンを含めることができます。「GDSのアーキテクチャ」では、西部リージョンと東部リージョンを示しています。各リージョンには、少なくとも1つのグローバル・サービス・マネージャが必要です。
1つのリージョンには、異なるプールに属するデータベースを含めることができます。「GDSのアーキテクチャ」では、データベースDB1とDB2は同じプールにありますが、リージョンは異なります。ただし、すべてのプールは同じGDS構成に属する必要があります。
関連項目:
GDSリージョンの詳細は、Oracle Database Global Data Services概要および管理ガイドを参照してください。
グローバル・サービス・マネージャ
グローバル・サービス・マネージャは、サービス・レベルのロード・バランシング、フェイルオーバー、およびGDS構成内のサービスの集中管理を提供する、GDSのセントラル・ソフトウェア・コンポーネントです。
グローバル・データ・サービスのクライアントは、グローバル・サービス・マネージャを使用して、GDS構成に対するすべての操作を実行します。グローバル・サービス・マネージャは、複数のデータベースに対応する点を除けば、Oracle RACデータベースでのリモート・リスナーに似ています。たとえば、グローバル・サービス・マネージャには、次のような機能があります。
-
クライアントがグローバル・サービスに接続するために使用するリージョン・リスナーとして機能します。
-
クライアントに接続時ロード・バランシングを提供します。
グローバル・サービス・マネージャには、次のような機能もあります。
-
GDS構成のリージョン全体でグローバル・サービスを管理します。
-
GDS構成内のデータベースからのパフォーマンス・メトリックの収集、およびGDS構成のリージョン間のネットワーク待機時間の測定
-
ランタイム・ロード・バランシング・アドバイザの作成、およびクライアント接続プールへの発行
1つのグローバル・サービス・マネージャは、1つのGDS構成のみに関連付けられます。1つのGDS構成に複数のグローバル・サービス・マネージャを設定して、可用性およびパフォーマンスを向上させることができます。GDS構成のすべてのグローバル・サービス・マネージャで、その構成によってサポートされるすべてのグローバル・サービスを管理します。
gdsctlは、GDSフレームワークへのユーザー・インタフェースを提供するコマンドライン・ツールです。コマンドを実行するには、gdsctlがグローバル・サービス・マネージャ、GDSカタログ・データベースまたはGDSデータベースへのOracle Net接続を確立する必要がある場合があります。
「GDSのアーキテクチャ」では、各リージョンに2つのグローバル・サービス・マネージャが示されています。各マネージャは、異なるホスト上に配置できます。gdsctlにより、グローバル・サービス・マネージャにコマンドが発行されます。
関連項目:
グローバル・サービス管理の詳細は、Oracle Database Global Data Services概要および管理ガイドを参照してください。
GDSカタログ
GDSカタログは、GDS構成およびそのすべてのグローバル・サービスの構成データが格納されるメタデータ・リポジトリです。
各GDS構成にはカタログが1つずつ存在します。GDSカタログは、Oracleデータベースに存在します。カタログ自体は、複数の表、ビューおよび関連のデータベース・オブジェクトおよび構造体で構成されています。
「GDSのアーキテクチャ」は、東部地域のスタンバイ・データベースにより保護された西部地域のGDSカタログ・データベースCATを示しています。
関連項目:
GDSカタログの詳細は、Oracle Database Global Data Services概要および管理ガイドを参照してください。
Oracle Net Servicesのアーキテクチャの概要
Oracle Net Servicesは分散した、異機種間コンピューティング環境において、企業全体の接続性を確保する一連のネットワーク・コンポーネントです。
Oracle Net Servicesを使用すると、アプリケーションからデータベース・インスタンスへ、およびデータベース・インスタンスから別のデータベース・インスタンスへのネットワーク・セッションを確立できます。
Oracle Net Servicesにより、位置の透過性、構成と管理の一元化および迅速なインストールと構成が実現されます。また、システム・リソースの最大化とパフォーマンスの改善が可能です。共有サーバー・アーキテクチャでは、アプリケーションのスケーラビリティが向上し、データベースへのクライアントの同時接続数が増加します。Virtual Interface (VI)プロトコルは、メッセージ機能の負荷のほとんどを高速ネットワーク・ハードウェアに負わせることによって、CPUを解放します。
Oracle Net Servicesは、広範囲のネットワークでサポートされている通信プロトコルやApplication Program Interface(API)を使用して、分散データベースと分散処理の機能を提供します。ネットワーク・セッションの確立後、Oracle Net Servicesは、接続を確立してメッセージを交換することによって、クライアント・アプリケーションとデータベース・サーバーのためのデータ伝達手段として機能します。Oracle Net Servicesはネットワーク内の各コンピュータに配置されているため、これらのタスクを実行できます。
この項では、次の項目について説明します。
関連項目:
Oracle Netアーキテクチャの概要は、『Oracle Database Net Services管理者ガイド』を参照してください
Oracle Net Servicesの動作
Oracle Databaseプロトコルでは、OracleアプリケーションのインタフェースからSQL文を受け取り、それらをパッケージ化してからOracle Databaseに送信します。
送信は、サポートされている業界標準の高レベルのプロトコルまたはAPIを介して行われます。Oracle Databaseからの応答は、同じ高レベルの通信メカニズムを介してパッケージ化されます。これらの処理はネットワーク・オペレーティング・システムからは独立して実行されます。
Oracle Databaseを実行するオペレーティング・システムによっては、データベース・サーバーのOracle Net Servicesソフトウェアにドライバ・ソフトウェアが含まれており、ドライバ・ソフトウェアによって追加のバックグラウンド・プロセスが起動される場合があります。
関連項目:
Oracle Net Servicesの動作の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください
Oracle Net Listener
Oracle Net Listener(リスナー)は、受信するクライアント接続リクエストをリスニングし、データベースへのトラフィックを管理する、サーバー側のプロセスです。データベース・インスタンスの起動時、および起動中の様々なタイミングで、インスタンスはリスナーに接続してそのインスタンスへの接続経路を確立します。
サービス登録により、リスナーは、データベース・サービスおよびそのサービス・ハンドラが使用可能かどうかを判断できます。サービス・ハンドラは、データベースへの接続ポイントとなる、ディスパッチャまたは専用サーバー・プロセスです。登録時に、LREGプロセスは、インスタンス名、データベース・サービス名、およびサービス・ハンドラのタイプとアドレスをリスナーに提供します。リスナーは、この情報を使用することにより、クライアント・リクエストの受信時にサービス・ハンドラを起動できます。
次の図に、それぞれ個別のホスト上に存在する2つのデータベースを示します。このデータ環境は、異なるホスト上にある2つのリスナーが対応しています。各データベース・インスタンスで実行されているLREGプロセスは、両方のリスナーと通信してデータベースを登録します。
図16-6は、ブラウザによるHTTP接続の実行と、クライアントによるリスナーを介したデータベース接続の実行を示します。このリスナーは、データベース・ホストに常駐する必要はありません。
クライアントがリスナーを経由して接続を確立する基本ステップを次に示します。
-
クライアント・プロセスまたは別のデータベースが接続をリクエストします。
-
リスナーは、クライアント・リクエストの処理に適したサービス・ハンドラを選択し、そのリクエストをハンドラに送ります。
-
クライアント・プロセスは、サービス・ハンドラに直接接続します。リスナーは通信には関わりません。
関連項目:
サービス名
サービス名とは、クライアント接続に使用するサービスの論理表現です。
クライアントは、リスナーに接続するときにサービスへの接続をリクエストします。データベース・インスタンスは、起動時にインスタンス自体をリスナーに登録し、1つ以上のサービスとして名前で指定できるようになります。このようにして、リスナーはクライアントとインスタンスとの間の仲介役を果たし、接続リクエストを適切な場所に渡します。
各サービスは、リスナーを介して、1つ以上のデータベース・インスタンスを識別できます。また、各データベース・インスタンスは、1つ以上のサービスをリスナーに登録できます。サービスに接続するクライアントは、必要なインスタンスを指定する必要がありません。
図16-7は、book.example.comとsoft.example.comの2つのサービスに関連付けられた1つの単一インスタンス・データベースを示します。これらのサービスにより、同じデータベースを異なるクライアントが個別に識別できるようになります。データベース管理者はシステム・リソースを制限または確保できるため、これらのサービスの1つをリクエストするクライアントに対してリソースをより効率的に割り当てることができます。
関連項目:
ネーミング・メソッドの詳細は、Oracle Database Net Services管理者ガイドを参照してください
サービス登録
Oracle Netでのサービス登録は、LREGプロセスがリスナーに動的にインスタンス情報を登録する機能です。
この情報により、リスナーはクライアント接続リクエストを適切なサービス・ハンドラに転送することができます。LREGによって、次の情報がリスナーに提供されます。
-
データベースが提供するデータベース・サービスの名前
-
サービスと関連付けられたデータベース・インスタンスの名前、およびそのインスタンスの現在の負荷と最大負荷
-
インスタンスから使用可能なサービス・ハンドラ(ディスパッチャおよび専用サーバー)とそのタイプ、プロトコル・アドレスおよび現在の負荷と最大負荷
サービス登録は動的であり、listener.oraファイルでの構成は必要ありません。動的登録により、複数のデータベースやインスタンスの管理に伴うオーバーヘッドが低減します。
初期化パラメータSERVICE_NAMESでは、インスタンスが属するサービスを示します。起動時に、各インスタンスは、同じサービスに属している他のインスタンスのリスナーに登録します。データベース操作中に、各サービスのインスタンスはCPUの使用と現行の接続カウントに関する情報を、同じサービスのすべてのリスナーに渡します。この通信により、動的なロード・バランシング機能と接続フェイルオーバー機能が使用可能になります。
関連項目:
-
サービス登録の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください
-
Oracle RACでのインスタンス登録およびクライアント/サービス接続の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください
専用サーバー・アーキテクチャ
専用サーバー・アーキテクチャでは、各クライアント・プロセスのかわりとして作成されたサーバー・プロセスは専用サーバー・プロセス(またはシャドウ・プロセス)と呼ばれます。
図16-8に示すように、専用サーバー・プロセスはクライアント・プロセスとは別のものであり、クライアント・プロセスのかわりとしてのみ動作します。
クライアント・プロセスとサーバー・プロセスの比率は1対1です。ユーザーが活発にデータベース・リクエストをしていない場合でも、専用サーバー・プロセスはそのまま残ります(ただし、アクティブでない状態の場合、オペレーティング・システムによっては、ページアウトされることもあります)。
図16-8には、ユーザー・プロセスとサーバー・プロセスが、ネットワーク接続された複数のコンピュータで実行されている状態を示しています。専用サーバー・アーキテクチャは、同じコンピュータ上でクライアント・アプリケーションとデータベース・コードの両方が実行される場合にも使用されますが、この2つのプログラムが1つのプロセスで実行されている場合は、ホスト・オペレーティング・システムはその2つの分離を維持できません。Linuxはそのようなオペレーティング・システムの一例です。
専用サーバー・アーキテクチャでは、ユーザー・プロセスとサーバー・プロセスは異なるメカニズムを使用して通信します。
-
クライアント・プロセスと専用サーバー・プロセスが同じコンピュータで実行される場合、プログラム・インタフェースは、ホスト・オペレーティング・システムのプロセス間通信メカニズムを使用してジョブを実行します。
-
クライアント・プロセスと専用サーバー・プロセスを別々のコンピュータで実行する場合は、プログラム・インタフェースがプログラム間の通信メカニズム(ネットワーク・ソフトウェアやOracle Net Servicesなど)を提供します。
専用サーバーを十分に活用しない場合は、オペレーティング・システムを効率的に使用できなくなることがあります。専用サーバー・プロセスを使用した注文入力システムを例にとって考えてみます。顧客から注文が入り、事務担当がデータベースにその注文を入力します。トランザクションの大部分では、事務担当が顧客と話し合っており、事務担当のクライアント・プロセス専用のサーバー・プロセスはアイドル状態になっています。サーバー・プロセスは、トランザクションの大部分で不要であり、管理されているプロセスが多数ある場合、他の事務担当が注文を入力するとき、システムの処理速度は遅くなることがあります。このようなタイプのアプリケーションでは、共有サーバー・アーキテクチャを選択してください。
関連項目:
専用サーバー・プロセスの詳細は、Oracle Database Net Services管理者ガイドを参照してください
共有サーバー・アーキテクチャ
共有サーバー・アーキテクチャでは、ディスパッチャにより、複数の受信されたネットワーク・セッション・リクエストが共有サーバー・プロセスのプールに入れられます
共有プールを使用すると、各接続の専用サーバー・プロセスの必要性が排除されます。プールにあるアイドル状態の共有サーバー・プロセスは、共通キューからリクエストをピックアップします。
共有サーバーには、次のような潜在的な利点があります。
-
オペレーティング・システム上のプロセス数の削減
少数の共有サーバーで、多数の専用サーバーと同じ量の処理を実行できます。
-
インスタンスPGAメモリーの削減
すべての専用サーバーおよび共有サーバーにはPGAがあります。サーバー・プロセスの数が減少すると、PGAおよびプロセス管理も減少します。
-
アプリケーションのスケーラビリティ向上、およびデータベースに同時に接続できるクライアントの数の増加
-
クライアントの接続と切断の比率が高いときに専用サーバーより高速である可能性の高さ
共有サーバーには、特定のケースにおけるレスポンス時間の長さ、機能の不完全なサポート、および設定やチューニングの複雑化などのデメリットがあります。一般的な目安としては、データベースへの同時接続数がオペレーティング・システムで処理可能な数を超える場合にのみ、共有サーバーを使用してください。
共有サーバー・アーキテクチャでは、次のプロセスが必要となります。
-
クライアント・プロセスをディスパッチャまたは専用サーバーに接続するネットワーク・リスナー(リスナー・プロセスは、Oracle DatabaseではなくOracle Net Servicesの一部)
注意:
共有サーバーを使用する際は、クライアント・プロセスは、Oracleデータベース・インスタンスと同一のコンピュータで実行されている場合でも、Oracle Net Servicesを介して接続する必要があります。
-
1つ以上のディスパッチャ・プロセス(Dnnn)
-
1つ以上の共有サーバー・プロセス
データベースは、共有サーバー接続と専用サーバー接続の両方を同時にサポートできます。たとえば、1つのクライアントが専用サーバーを使用してデータベースに接続すると同時に、別のクライアントが共有サーバーを使用して同じデータベースに接続できます。
関連項目:
-
共有サーバー・アーキテクチャの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください
-
共有サーバーを使用するためのデータベースの構成方法の詳細は、『Oracle Database管理者ガイド』を参照してください。
ディスパッチャのリクエスト・キューとレスポンス・キュー
ユーザーからのリクエストは、ユーザーのSQL文の一部である単一のAPIコールです。
ユーザーがコールを実行すると、次のアクションが発生します。
-
ディスパッチャがリクエストをリクエスト・キューに入れ、次に使用可能な共有サーバー・プロセスがそこからリクエストを取り出します。
リクエスト・キューはSGA内に存在し、インスタンスのディスパッチャ・プロセスすべてに共通です。
-
共有サーバー・プロセスは、共通のリクエスト・キューをチェックして新しいリクエストがないかどうかを調べ、先入れ先出し方式に基づいて新しいリクエストをピックアップします。
-
1つの共有サーバー・プロセスがキュー内のリクエストを1つピックアップし、そのリクエストを完了するのに必要なデータベースに対するコールをすべて出します。
各データベース・コールは異なるサーバー・プロセスが処理できます。このため、問合せの解析、最初の行のフェッチ、次の行のフェッチ、および結果セットのクローズそれぞれのリクエストは、別の共有サーバーが処理できます。
-
サーバー・プロセスはリクエストを完了すると、コール・ディスパッチャのレスポンス・キューに応答を入れます。各ディスパッチャには、固有のレスポンス・キューがあります。
-
ディスパッチャは、完了したリクエストを適切なクライアント・プロセスに戻します。
たとえば、注文入力システムで、各事務担当のクライアント・プロセスがディスパッチャに接続します。事務担当によって作成されたそれぞれのリクエストはこのディスパッチャに送られ、ディスパッチャがリクエストをキューに入れます。次に使用可能な共有サーバーは、リクエストをピックアップして処理し、レスポンス・キューにレスポンスを入れます。リクエストが完了しても、事務担当はディスパッチャに接続されたままですが、そのリクエストを処理した共有サーバーは解放されるため、別のリクエストで使用できます。1人の事務担当が顧客と話し合っている間に、別の事務担当は同じ共有サーバー・プロセスを使用できます。
図16-9に、クライアント・プロセスがAPIを介してディスパッチャと通信する方法と、ディスパッチャがユーザー・リクエストを共有サーバー・プロセスに伝達する方法を示します。
関連項目:
「ラージ・プール」
ディスパッチャ・プロセス(Dnnn)
ディスパッチャ・プロセスは、クライアント・プロセスが限定された数のサーバー・プロセスを共有できるようにします。
1つのデータベース・インスタンスに対し、複数のディスパッチャ・プロセスを作成できます。ディスパッチャの最適な数は、オペレーティング・システムの制限事項と各プロセスの接続数に応じて異なります。
注意:
ディスパッチャに接続する各クライアント・プロセスは、両方のプロセスが同じホスト上で実行される場合でも、Oracle Net Servicesを使用する必要があります。
ディスパッチャ・プロセスは次のように通信を確立します。
-
インスタンスが起動されると、ネットワーク・リスナー・プロセスは、ユーザーがOracle Databaseへの接続に使用する通信経路をオープンして確立します。
-
各ディスパッチャ・プロセスは、接続リクエストをリスニングするアドレスをリスナー・プロセスに割り当てます。
データベース・クライアントで使用するネットワーク・プロトコルごとに、最低1つ以上のディスパッチャ・プロセスを構成し起動する必要があります。
-
クライアント・プロセスが接続をリクエストすると、リスナーはそのクライアント・プロセスが共有サーバー・プロセスを使用する必要があるかどうかを判断します。
-
共有サーバーが必要であるとリスナーが判断した場合、リスナーは負荷が最も軽いディスパッチャ・プロセスのアドレスを戻し、クライアント・プロセスはディスパッチャに直接接続します。
-
プロセスがディスパッチャと通信できない場合、またはクライアント・プロセスが専用サーバーをリクエストする場合には、リスナーは専用サーバー・プロセスを作成して適切な接続を確立します。
-
関連項目:
ディスパッチャの構成方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください
共有サーバー・プロセス(Snnn)
共有サーバー構成では、各共有サーバー・プロセスは複数のクライアント・リクエストを処理します。
共有サーバー・プロセスには専用サーバー・プロセスと同じ機能がありますが、特定のクライアント・プロセスと関連付けられていません。共有サーバー・プロセスは、共有サーバー構成におけるクライアント・リクエストに対してサービスを提供します。
共有サーバー・プロセスのPGAには、すべての共有サーバー・プロセスがアクセスできる必要のあるUGAデータが含まれていません。共有サーバーのPGAには、プロセス固有のデータのみが含まれています。
セッション関連の情報はすべてSGA内に入れられます。各共有サーバー・プロセスは、サーバーがどのセッションからのリクエストでも処理できるように、すべてのセッションのデータ領域にアクセスできる必要があります。セッションのデータ領域ごとに、SGA内に領域が割り当てられます。
関連項目:
共有サーバーの限定的運用
インスタンスの停止、インスタンスの起動、およびメディア・リカバリを含む、特定の管理アクティビティは、ディスパッチャ・プロセスに接続されている間は実行できません。
これらのアクティビティは、一般的には管理者権限を使用して接続しているときに実行されます。共有サーバーにより構成されたシステムで管理者権限を使用して接続する場合は、専用サーバー・プロセスを使用することを指定する必要があります。
関連項目:
正しい接続文字の構文は、『Oracle Database Net Services管理者ガイド』を参照してください
データベース常駐接続プーリング
データベース常駐接続プーリング(DRCP)は、一般的なWebアプリケーション使用のシナリオにおいて、専用サーバーの接続プールを提供します。
通常、Webアプリケーションは、データベースへの接続を取得し、その接続を短時間使用した後、接続を解放します。DRCPを使用すると、データベースは同時接続数を数万にまで増やすことができます。
DRCPには、次の利点があります。
-
中間層プロセス内のスレッド間で接続を共有する、中間層接続プールを補完します。
-
複数の中間層プロセスにわたってデータベース接続を共有できるようにします。これらの中間層プロセスは、中間層ホストが同一の場合と異なる場合があります。
-
多数のクライアント接続のサポートに必要な、主要データベース・リソースを大幅に削減できます。たとえば、DRCPは、データベースに必要なメモリーの量を削減し、データベースと中間層の両方のスケーラビリティを向上させます。利用可能なサーバーのプールにより、クライアント接続を再作成するコストも削減されます。
-
中間層接続プーリングを実行できないPHPやApacheサーバーなど、マルチ・プロセスのシングルスレッド・アプリケーション・サーバーを含むアーキテクチャでプーリングが実行できるようになります。
DRCPでは、プールされたサーバーを使用し、専用サーバー・プロセス(共有サーバー・プロセスではない)とデータベース・セッションを組み合せたものと同じ機能を実現します。プールされたサーバー・モデルは、短時間だけサーバーを必要とする接続のすべてに専用サーバーを割り当てることによるオーバーヘッドを排除します。
データベース常駐接続プールから接続を取得したクライアントは、接続ブローカと呼ばれるOracleバックグラウンド・プロセスに接続します。接続ブローカはプール機能を実装しており、プールされたサーバーをクライアント・プロセスからのインバウンド接続間で多重化します。
図16-10に示すように、クライアントがデータベース・アクセスをリクエストすると、接続ブローカがプールから、サーバー・プロセスを選択してクライアントに渡します。クライアントは、リクエストが処理されるまで、サーバー・プロセスに直接接続します。サーバーでの処理が終了すると、サーバー・プロセスはプールに戻されます。クライアントからの接続はブローカにリストアされます。
DRCPでは、リソースを解放しても、セッションはそのまま残されますが、接続(サーバー・プロセス)との関連付けは失われます。共有サーバーとは異なり、このセッションではそのUGAをSGAではなくPGAに格納します。クライアントは、検出アクティビティを実行するとき、接続を透過的に再確立できます。
関連項目:
-
「接続とセッション」
-
DRCPの詳細は、Oracle Database管理者ガイドおよびOracle Call Interfaceプログラマーズ・ガイドを参照してください
プログラム・インタフェースの概要
プログラム・インタフェースとは、データベース・アプリケーションとOracle Databaseの間のソフトウェア・レイヤーです。
プログラム・インタフェースでは、次の機能を実行します。
-
クライアント・プロセスによるSGAへの破壊的アクセスを防ぐ、セキュリティのための障壁になります。
-
通信メカニズムとして機能し、情報リクエストの書式設定、データの受渡し、エラーのトラップと通知を行います。
-
特に異機種コンピュータ間、または外部ユーザー・プログラム・データ型に対してデータを変換し解釈します。
Oracleコードはサーバーとして働き、アプリケーション(クライアント)のために、データ・ブロックからの行のフェッチなどデータベース・タスクを実行します。プログラム・インタフェースは、Oracle Databaseソフトウェアとオペレーティング・システム固有のソフトウェアの両方によって提供される、複数の部分から構成されています。
プログラム・インタフェースの構造
プログラム・インタフェースは、様々なコンポーネントから構成されます。
これらのコンポーネントは、次のとおりです。
-
Oracleコール・インタフェース(OCI)またはOracleランタイム・ライブラリ(SQLLIB)
-
クライアント側またはユーザー側のプログラム・インタフェース
-
様々なOracle Net Servicesドライバ(プロトコル固有の通信ソフトウェア)
-
オペレーティング・システムの通信ソフトウェア
-
サーバーまたはOracle Database側のプログラム・インタフェース(OPIとも呼ばれます)
ユーザー側とOracle Database側のプログラム・インタフェースは、どちらもドライバのような仕組みでOracleソフトウェアを実行します。
プログラム・インタフェース・ドライバ
ドライバとは、通常はネットワークを介してデータを転送するソフトウェアの一部です。
ドライバは、接続、切断、エラーの通知、エラーのテストなどの操作を実行します。ドライバは通信プロトコルに固有のものです。
デフォルトのドライバが常に存在します。複数のドライバ(非同期またはDECnetドライバなど)をインストールし、その1つをデフォルト・ドライバとして選択しますが、各ユーザーは、接続の時点で必要なドライバを指定することで、他のドライバを使用できます。
プロセスが異なる場合は、異なるドライバを使用できます。1つのプロセスは、異なるOracle Net Servicesドライバを使用して、単一または複数のデータベースに同時接続できます。
関連項目:
-
ドライバの選択、インストールおよび追加方法の詳細は、システムのインストレーションおよび構成ガイドを参照してください。
-
JDBCドライバの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください