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