10gリリース2（10.2）
B19215-02
 目次 |
 索引 |
| Oracle Database 概要 10gリリース2（10.2） B19215-02 |
|
この章では、Oracleデータベース・システムのプロセスと、Oracleシステムで使用可能な各種構成について説明します。
この章の内容は、次のとおりです。
接続しているOracleユーザーはすべて、Oracleデータベース・インスタンスにアクセスするために、2つのコード・モジュールを実行する必要があります。
これらのコード・モジュールは、プロセスによって実行されます。プロセスは制御のスレッド、つまり一連の処理を実行できるオペレーティング・システムのメカニズムです。（オペレーティング・システムによっては、ジョブまたはタスクという用語を使用します）。プロセスには、通常、実行するプライベート・メモリー領域があります。
マルチ・プロセスOracle（マルチユーザーOracleとも呼ばれる）は、Oracleコードの各部分とユーザーのためのその他のプロセスを実行するために、複数のプロセスを使用します。ユーザー用プロセスは、接続中のユーザーごとに個別のプロセスの場合や、複数のユーザーが共有する1つ以上のプロセスの場合があります。データベースの主な利点の1つが、複数のユーザーが同時に必要とするデータを管理できることにあるため、多くのデータベース・システムはマルチユーザー・システムです。
Oracleインスタンスにおける各プロセスは、特定のジョブを実行します。Oracleとデータベース・アプリケーションの作業を複数のプロセスに分けることにより、システムの優れたパフォーマンスを維持しながら、複数のユーザーやアプリケーションが同時に1つのデータベース・インスタンスに接続できます。
Oracleシステム内のプロセスは、次の2つの主要グループに分類できます。
プロセス構造は、オペレーティング・システムと、選択するOracleオプションによって、Oracle構成ごとに異なります。接続ユーザー用のコードは、専用サーバーまたは共有サーバーとして構成できます。
専用サーバーの場合は、それぞれのユーザーについて、データベース・アプリケーションを実行するプロセス（ユーザー・プロセス）と、Oracleデータベース・サーバー・コードを実行するプロセス（専用サーバー・プロセス）が異なります。
共有サーバーの場合は、データベース・アプリケーションを実行するプロセス（ユーザー・プロセス）と、Oracleデータベース・サーバー・コードを実行するプロセスが異なります。Oracleデータベース・サーバー・コードを実行する各サーバー・プロセス（共有サーバー・プロセス）は、マルチ・ユーザー・プロセスとして機能します。
図9-1に、専用サーバー構成を示します。接続中の各ユーザーは別々のユーザー・プロセスを持ち、複数のバックグラウンド・プロセスがOracleを実行します。
図9-1は、複数の同時実行ユーザーが、Oracleと同一のコンピュータ上にあるアプリケーションを実行していることを表しています。このような特別の構成は、通常、メインフレームまたはミニコンピュータで稼働します。
|
関連項目
|
ユーザーがアプリケーション・プログラム（Pro*Cプログラムなど）またはOracleのツール製品（Enterprise ManagerやSQL*Plusなど）を実行すると、Oracleはユーザーのアプリケーションを実行するためにユーザー・プロセスを作成します。
接続およびセッションという用語は、ユーザー・プロセスという用語と密接に関連していますが、意味的には大きな差異があります。
接続とは、ユーザー・プロセスとOracleインスタンス間の通信経路のことです。通信経路は、使用可能なプロセス間通信メカニズム（1台のコンピュータでユーザー・プロセスとOracleの両方を実行する場合）、またはネットワーク・ソフトウェア（別々のコンピュータがデータベース・アプリケーションとOracleを実行し、ネットワークを介して通信する場合）を使用して確立されます。
セッションとは、ユーザーがユーザー・プロセスを介してOracleインスタンスに接続するときの、特定の接続のことです。たとえば、ユーザーは、SQL*Plusを開始するときに、有効なユーザー名とパスワードを入力する必要があります。そうすることにより、そのユーザーのためのセッションが確立されます。 セッションは、ユーザーが接続した時点から、接続を切断するかデータベース・アプリケーションを終了する時点まで続きます。
1人のOracleユーザーに対して複数のセッションを作成し、それらを同じユーザー名で同時に存在させることができます。たとえば、SCOTT/TIGERというユーザー名/パスワードを持つユーザーは、同じOracleインスタンスに何度も接続できます。
共有サーバー以外の構成では、Oracleは、各ユーザー・セッションのためにサーバー・プロセスを作成します。しかし、共有サーバーを使用すると、多くのユーザー・セッションで1つのサーバー・プロセスを共有できます。
この項では、Oracleデータベース・サーバー・コードを実行する2種類のプロセス（サーバー・プロセスとバックグラウンド・プロセス）と、Oracleプロセスのデータベース・イベントが記録されるトレース・ファイルとアラート・ログについて説明します。
Oracleでは、インスタンスに接続されたユーザー・プロセスの要求を処理するために、サーバー・プロセスが作成されます。アプリケーションとOracleが同一のコンピュータ上で稼働しているときには、システムのオーバーヘッドを軽減するために、ユーザー・プロセスとそれに対応するサーバー・プロセスを1つのプロセスに結合できる場合もあります。ただし、アプリケーションとOracleがそれぞれ別のコンピュータ上で稼働している場合は、ユーザー・プロセスは常に独立したサーバー・プロセスを通じてOracleと通信します。
各ユーザー・アプリケーションのために作成されたサーバー・プロセス（または、結合されたユーザー/サーバー・プロセスのサーバー部）は、次の1つ以上の操作を実行できます。
パフォーマンスを最大にし、多数のユーザーが使用できるように、マルチ・プロセスOracleシステムでは、この他にバックグラウンド・プロセスという複数のOracleプロセスを使用します。
1つのOracleインスタンスは、多数のバックグラウンド・プロセスを持つことができます。ただし、常にすべてが存在するわけではありません。バックグラウンド・プロセスには、多数の種類があります。バックグラウンド・プロセスの詳細は、V$BGPROCESSビューを参照してください。Oracleインスタンスのバックグラウンド・プロセスには、次のものがあります。
多くのオペレーティング・システムでは、インスタンスが起動するときに、バックグラウンド・プロセスが自動的に作成されます。
図9-2に、Oracleデータベースの各部分とそれぞれのバックグラウンド・プロセスとの相互作用を示します。その後、各プロセスについて説明します。
|
関連項目
|
データベース・ライター・プロセス（DBWn） は、バッファの内容をデータファイルに書き込みます。 DBWnプロセスは、データベース・バッファ・キャッシュ内の変更された（使用済）バッファをディスクに書き込みます。ほとんどのシステムでは1つのデータベース・ライター・プロセス（DBW0）があれば十分ですが、追加プロセス（DBW1〜DBW9およびDBWa〜DBWj）を構成して、システムでデータを頻繁に変更する場合に書込みのパフォーマンスを改善できます。これらの追加DBWnプロセスは、ユニプロセッサ・システムでは効果がありません。
データベース・バッファ・キャッシュ内のバッファが変更されると、そのバッファには使用済のマークが付きます。コールド・バッファとは、LRUアルゴリズムに従って最近使用されたことがないバッファです。DBWnプロセスは、ユーザー・プロセスが新規ブロックをキャッシュに読み込むために使用できるクリーンなコールド・バッファを検出できるように、使用済のコールド・バッファをディスクに書き込みます。ユーザー・プロセスによってバッファが使用済の状態になると、使用可能バッファの数が減少します。使用可能バッファの数が少なすぎると、ディスクからキャッシュにブロックを読み込む必要があるユーザー・プロセスは、使用可能バッファを検出できません。ユーザー・プロセスが使用可能バッファを常に検出できるように、DBWnはバッファ・キャッシュを管理します。
使用済のコールド・バッファをディスクに書き込むことにより、DBWnは、使用頻度の高いバッファをメモリー内に保ちながら、使用可能バッファを検索するときのパフォーマンスを向上させます。たとえば、頻繁にアクセスされる小さな表または索引の一部であるブロックは、それらをディスクから再び読み込まなくても済むように、キャッシュ内に置かれます。LRUアルゴリズムは、バッファの内容をディスクに書き込むときに、すぐに使用されそうなデータが書き込まれてしまわないように、より頻繁にアクセスされるブロックをバッファ・キャッシュ内に保持します。
DBWnプロセスの個数は、初期化パラメータDB_WRITER_PROCESSESで指定します。DBWnプロセスの最大数は20です。起動時にユーザーが最大数を設定しない場合は、CPU数とプロセッサ・グループ数に基づいてDB_WRITER_PROCESSESの設定が判断されます。
DBWnプロセスは、次のような場合に使用済バッファをディスクに書き込みます。
どの場合でも、効率を向上させるためにDBWnはバッチ（マルチブロック）書込みを実行します。マルチブロック書込みで書き込まれるブロックの数は、オペレーティング・システムによって異なります。
|
関連項目
|
ログ・ライター・プロセス（LGWR）は、REDOログ・バッファ管理、つまりディスク上のREDOログ・ファイルへのREDOログ・バッファの書込みを行います。 LGWRは、最後の書込み以後にバッファにコピーされたREDOエントリすべてを、REDOログ・ファイルに書き込みます。
REDOログ・バッファは循環バッファです。LGWRがREDOログ・バッファからREDOログ・ファイルにREDOエントリを書き込んだ後、サーバー・プロセスはディスクに書き込まれたREDOログ・バッファのエントリ上に新しいエントリをコピーできます。REDOログへのアクセスが頻繁なときにも、新しいエントリを書き込めるよう常にバッファ内の領域を空けておくため、LGWRが行う書込みは通常は非常に高速になります。
LGWRは、バッファの1つの連続した部分をディスクに書き込みます。LGWRは、次のものを書き込みます。
LGWRは、ミラー化されたアクティブなREDOログ・ファイルのグループにも同時に書き込みます。グループ内のファイルのいずれかが破損している場合や使用できない場合、LGWRはそのグループ内の他のファイルへの書込みを続け、このエラーのログをLGWRトレース・ファイルやシステム・アラート・ログに記録します。グループ内のすべてのファイルが破損している場合や、アーカイブされていないためにグループ全体が使用できない場合、LGWRは機能を続行できません。
ユーザーがCOMMIT文を発行すると、LGWRはREDOログ・バッファ内にコミット・レコードを入れ、トランザクションのREDOエントリとともにそれを即時にディスクに書き込みます。対応するデータ・ブロックの変更は、それらをより効率的に書き込めるようになるまで延期されます。これを高速コミット・メカニズムと呼びます。トランザクションのコミット・レコードを含むREDOエントリのアトミックな書込みは、トランザクションがコミットされたかどうかを判別する1つのイベントです。Oracleは、データ・バッファがまだディスクに書き込まれていない場合でも、コミットしたトランザクションに成功コードを戻します。
ユーザーがトランザクションをコミットすると、そのトランザクションにはシステム変更番号（SCN）が割り当てられます。Oracleは、このシステム変更番号を該当するトランザクションのREDOエントリとともにREDOログに記録します。SCNは、Real Application Clustersおよび分散データベースでリカバリ操作を同期させることができるように、REDOログに記録されます。
アクティビティが高いときには、LGWRはグループ・コミットを使用してREDOログ・ファイルに書き込むこともあります。たとえば、ユーザーがトランザクションをコミットする場合を考えます。LGWRは、トランザクションのREDOエントリをディスクに書き込む必要がありますが、その際、他のユーザーはCOMMIT文を発行します。ただし、LGWRは前の書込み操作を完了するまで、他のユーザーのトランザクションをREDOログ・ファイルに書き込んでコミットすることはできません。最初のトランザクションのエントリをREDOログ・ファイルに書き込んだ後、待機中の（まだコミットされていない）トランザクションのREDOエントリのリスト全体を1回の操作でディスクに書き込むことができるため、トランザクションのエントリを個々に処理するときよりも、必要となるI/Oを低減できます。したがって、ディスクI/Oは最小になり、LGWRのパフォーマンスは最大になります。コミットの要求が高い頻度で続くと、REDOログ・バッファからの（LGWRによる）毎回の書込みに複数のコミット・レコードが含まれることがあります。
|
関連項目
|
チェックポイントが発生すると、すべてのデータファイルのヘッダーはそのチェックポイントの詳細を記録するために更新される必要があります。この処理は、CKPTプロセスによって実行されます。CKPTプロセスは、ブロックをディスクに書き込みません。この書込みは、常にDBWnが実行します。
Enterprise Managerのシステム統計モニターによって表示されるDBWRチェックポイントの統計には、完了したチェックポイント要求の数が示されます。
システム・モニター・プロセス（SMON）は、インスタンスの起動時に必要に応じてリカバリを実行します。また、SMONは、使用されなくなった一時セグメントをクリーン・アップする操作と、ディクショナリ管理表領域内で連続した使用可能エクステントを1つに結合する操作を受け持ちます。ファイル読取りエラーやオフライン・エラーが原因で、インスタンス・リカバリ時に終了済トランザクションがスキップされた場合、SMONはその表領域やファイルがオンラインに戻った時点でトランザクションをリカバリします。SMONは、処理が必要かどうかを定期的にチェックします。他のプロセスは、必要性が検出された場合にSMONをコールできます。
Real Application Clustersでは、あるインスタンスのSMONプロセスは、障害が発生したCPUまたはインスタンスについてもインスタンス・リカバリを実行できます。
ユーザー・プロセスが失敗すると、プロセス・モニター（PMON）がプロセスをリカバリします。PMONは、データベース・バッファ・キャッシュをクリーン・アップしたり、ユーザー・プロセスが使用していたリソースを解放します。たとえば、アクティブ・トランザクション表の状態をリセットしてロックを解除し、アクティブ・プロセスのリストからプロセスIDを削除します。
PMONは、ディスパッチャ・プロセスとサーバー・プロセスの状態も定期的にチェックし、実行を停止したサーバー・プロセスがあれば再起動します（ただし、Oracleが意図的に終了させたプロセスは除きます）。また、PMONは、インスタンスおよびディスパッチャ・プロセスに関する情報をネットワーク・リスナーに登録します。
SMONと同じように、PMONは、処理が必要かどうかを定期的にチェックし、別のプロセスで起動する必要が検出された場合にコールできます。
リカバラ・プロセス（RECO）は、分散データベース構成で使用されるバックグラウンド・プロセスであり、分散トランザクションに関連する障害を自動的に解決します。ノードのRECOプロセスは、インダウト分散トランザクションにかかわる他のデータベースに自動的に接続されます。RECOプロセスは、関係するデータベース・サーバー間の接続を再確立するときに、すべてのインダウト・トランザクションを自動的に解決し、解決されるインダウト・トランザクションに対応する行を各データベースの保留中のトランザクション表からすべて削除します。
RECOプロセスがリモート・サーバーとの接続に失敗した場合、RECOは決められた間隔で自動的に再接続しようとします。ただし、RECOが次の接続を試行するまで待機する時間は増えていきます（指数関数的に増加します）。RECOプロセスは、インスタンスが分散トランザクションを許可している場合にのみ存在します。同時分散トランザクションの数に制限はありません。
ジョブ・キュー・プロセスは、バッチ処理で使用します。ジョブ・キュー・プロセスはユーザー・ジョブを実行します。ジョブ・キュー・プロセスは、ジョブをPL/SQL文またはOracleインスタンスのプロシージャとして計画するのに使用できるスケジューラ・サービスとして表示できます。開始日付と間隔が設定されると、ジョブ・キュー・プロセスは、次に発生するジョブの実行に備えます。
また、ジョブ・キュー・プロセスは動的に管理されます。このため、ジョブ・キューのクライアントは、必要なときに、より多くのジョブ・キュー・プロセスを使用できます。新規プロセスが使用するリソースは、そのプロセスがアイドル状態になると解放されます。
動的ジョブ・キュー・プロセスは、大量のジョブを一定の間隔で同時に実行できます。ジョブ・キュー・プロセスは、ユーザー・ジョブがCJQプロセスにより割り当てられると、それを実行します。ジョブ・キュー・プロセスの実行内容を次に示します。
JOB$表から実行する必要があるジョブを定期的に選択します。選択された新規ジョブは、時間順に並べ替えられます。
初期化パラメータJOB_QUEUE_PROCESSESは、1つのインスタンスで同時に実行できるジョブ・キュー・プロセスの最大数を示します。ただし、クライアントは、すべてのジョブ・キュー・プロセスがジョブ実行に使用可能であるとは想定しません。
アーカイバ・プロセス（ARCn）は、ログ・スイッチの発生後、REDOログ・ファイルを指定のストレージ・デバイスにコピーします。ARCnプロセスが存在するのは、データベースがARCHIVELOGモードで、かつ、自動アーカイブが使用可能になっている場合のみです。
Oracleインスタンスは、最大10個のARCnプロセス（ARC0〜ARC9）を持つことができます。LGWRプロセスは、現行のARCnプロセス数ではワークロードを処理できなくなると、新しいARCnプロセスを起動します。アラート・ログには、LGWRが新しいARCnプロセスを開始した時刻が記録されます。
データのバルク・ロード中など、アーカイブに伴う大量のワークロードが予想される場合は、初期化パラメータLOG_ARCHIVE_MAX_PROCESSESを使用して複数のアーカイバ・プロセスを指定できます。ALTER SYSTEM文では、このパラメータの値を動的に変更し、ARCnプロセス数を増減させることができます。ただし、データベースのワークロードに対応しきれなくなると、必要なARCnプロセス数がシステムによって自動的に判断され、LGWRが追加のARCnプロセスを自動的に起動するため、このパラメータをデフォルト値の1から変更する必要はありません。
|
関連項目
|
キュー・モニター・プロセス（QMNn）は、メッセージ・キューを監視するOracle Streams Advanced Queuingのオプションのバックグラウンド・プロセスです。最大10個のキュー・モニター・プロセスを構成できます。これらのプロセスは、ジョブ・キュー・プロセスと同様に、プロセスの障害がインスタンス障害の原因とならない点で他のOracleバックグラウンド・プロセスと異なります。
他にも実行されているバックグラウンド・プロセスがいくつかあります。次のバックグラウンド・プロセスが含まれます。
MMONは、管理性に関連する様々なバックグラウンド・タスクを実行します。次に例を示します。
MMNLは、セッション履歴の取得、メトリック計算など、管理性に関連する軽量のバックグラウンド・タスクを頻繁に実行します。
MMANは、内部的なデータベース・タスクで使用します。
RBALは、自動ストレージ管理インスタンスでディスク・グループに対するバランス再調整アクティビティを調整します。このプロセスは、自動ストレージ管理ディスクに対するグローバル・オープンを実行します。
ORBnは、自動ストレージ管理インスタンスで実際の再バランス・データ・エクステントの移動を実行します。この種のバックグラウンド・プロセスは同時に多数実行される場合があるため、ORB0、ORB1などと呼びます。
OSMBは、自動ストレージ管理ディスク・グループを使用するデータベース・インスタンスに存在します。このプロセスは、自動ストレージ管理インスタンスと通信します。
それぞれのサーバーとバックグラウンド・プロセスは、対応付けられたトレース・ファイルに書き込むことができます。プロセスによって内部エラーが検出されると、エラーについての情報がそのプロセスのトレース・ファイルに書き込まれます。内部エラーが発生して情報がトレース・ファイルに書き込まれた場合、管理者はオラクル社カスタマ・サポート・センターに連絡してください。
バックグラウンド・プロセスに対応付けられているすべてのトレース・ファイルのファイル名には、そのトレース・ファイルを生成したプロセスの名前が含まれます。唯一の例外は、ジョブ・キュー・プロセス（Jnnn）が生成するトレース・ファイルです。
トレース・ファイル内の追加情報は、アプリケーションやインスタンスをチューニングするための手引きにもなります。バックグラウンド・プロセスは、該当する場合は、いつもトレース・ファイルにこの情報を書き込みます。
各データベースには、alert.logもあります。データベースのアラート・ログは、次のようなメッセージとエラーの履歴ログです。
CREATE/ALTER/DROP DATABASE/TABLESPACEと、Enterprise ManagerまたはSQL*Plus文のSTARTUP、SHUTDOWN、ARCHIVE LOGおよびRECOVERなど。
Oracleは、これらのイベントの記録を保管するのに、オペレータのコンソール上に情報を表示するかわりに、アラート・ログを使用します（多くのシステムではコンソール上にもこの情報が表示されます）。管理操作が成功すると、タイムスタンプとともに「completed」というメッセージがアラート・ログに書き込まれます。
共有サーバー・アーキテクチャでは、それぞれの接続に対する専用サーバー・プロセスが必要ありません。ディスパッチャが、複数の受信ネットワーク・セッション要求を共有サーバー・プロセスのプールに導きます。サーバー・プロセスの共有プールにあるアイドル状態の共有サーバー・プロセスは、共通キューからの要求をピックアップします。このことは、少数の共有サーバーで、多数の専用サーバーと同じ量の処理を行えることを意味します。また、各ユーザーに必要なメモリーの量が比較的少ないため、メモリー管理やプロセス管理も容易であり、多くのユーザーをサポートできます。
共有サーバー・システムでは、次に示すように、様々なプロセスが多数必要です。
共有サーバー・プロセスでは、Oracle Net ServicesまたはSQL*Netバージョン2が必要です。
インスタンスが起動されると、ネットワーク・リスナー・プロセスはユーザーがOracleに接続するときの通信経路をオープンして確立します。その後、各ディスパッチャ・プロセスは、接続要求をリスニングするアドレスをリスナー・プロセスに割り当てます。データベース・クライアントで使用するネットワーク・プロトコルごとに、最低1つ以上のディスパッチャ・プロセスを構成し起動する必要があります。
ユーザー・プロセスが接続を要求すると、リスナーはその要求を調べてユーザー・プロセスが共有サーバー・プロセスを使用できるかどうかを決定します。使用できる場合には、リスナー・プロセスは負荷が最も軽いディスパッチャ・プロセスのアドレスを戻し、ユーザー・プロセスはディスパッチャに直接接続します。
ディスパッチャと通信できないユーザー・プロセスもあるため、ネットワーク・リスナー・プロセスはそれらをディスパッチャに接続できません。この場合、つまりユーザー・プロセスが専用サーバーを要求すると、リスナーは専用サーバーを作成して適切な接続を確立します。
Oracleの共有サーバー・アーキテクチャによって、アプリケーションの拡張性およびデータベースへのクライアントの同時接続数が向上します。このアーキテクチャでは、アプリケーション自体を一切変更することなく、既存のアプリケーションをスケールアップできます。
ユーザーからの要求は、ユーザーのSQL文の一部である単一のプログラム・インタフェース・コールです。ユーザーがコールすると、そのディスパッチャが要求を要求キューに入れ、次に使用可能な共有サーバー・プロセスがそこから要求を取り出します。
要求キューはSGA内に存在し、インスタンスのディスパッチャ・プロセスすべてに共通です。共有サーバー・プロセスは、共通の要求キューをチェックして新しい要求がないかどうかを調べ、先入れ先出し方式に基づいて新しい要求をピックアップします。1つの共有サーバー・プロセスがキュー内の要求を1つピックアップし、その要求を完了するのに必要なデータベースに対するコールをすべて出します。
サーバーは要求を完了すると、コール・ディスパッチャのレスポンス・キューに応答を入れます。各ディスパッチャには、SGA内に固有のレスポンス・キューがあります。ディスパッチャは、完了した要求を適切なユーザー・プロセスに戻します。
たとえば、注文入力システムでは、それぞれの事務担当のユーザー・プロセスがディスパッチャに接続し、事務担当が出したそれぞれの要求がそのディスパッチャに送られ、そしてディスパッチャがその要求を要求キューに入れます。次に使用可能な共有サーバー・プロセスは、要求をピックアップして処理し、レスポンス・キューに応答を入れます。事務担当の要求が完了しても、事務担当はディスパッチャに接続されたままですが、その要求を処理した共有サーバー・プロセスは解放されるため、別の要求で使用できます。1人の事務担当が顧客と話し合っている間に、別の事務担当は同じ共有サーバー・プロセスを使用できます。
図9-3に、ユーザー・プロセスがプログラム・インタフェースを介してディスパッチャと通信する方法と、ディスパッチャがユーザー要求を共有サーバー・プロセスに伝達する方法を示します。
ディスパッチャ・プロセスは、ユーザー・プロセスが限定された数のサーバー・プロセスを共有できるようにすることで、共有サーバー構成をサポートします。共有サーバーでは、共有サーバー・プロセスの数がユーザーの数より少なくてすみます。そのため、特にクライアント・アプリケーションとサーバーが別々のコンピュータ上で稼働するようなクライアント/サーバー環境では、共有サーバーによってより多くのユーザーをサポートできます。
1つのデータベース・インスタンスに対し、複数のディスパッチャ・プロセスを作成できます。ただし、Oracleで使用する各ネットワーク・プロトコルごとに、少なくても1つのディスパッチャを作成する必要があります。データベース管理者は、オペレーティング・システムの制限とプロセス当たりの接続数に応じて、ディスパッチャ・プロセスを適切な数だけ起動する必要があります。また、インスタンスの実行中にディスパッチャ・プロセスを追加および削除できます。
共有サーバー構成では、ネットワーク・リスナー・プロセスがクライアント・アプリケーションからの接続要求を待機し、それぞれのクライアント・アプリケーションをディスパッチャ・プロセスにルーティングします。クライアント・アプリケーションをディスパッチャに接続できない場合、リスナー・プロセスは専用サーバー・プロセスを起動し、クライアント・アプリケーションを専用サーバーに接続します。リスナー・プロセスは、Oracleインスタンスの一部ではなく、Oracleとともに作動するネットワーキング・プロセスの一部です。
共有サーバー構成では、各共有サーバー・プロセスは複数のクライアント要求を処理します。共有サーバー・プロセスには専用サーバー・プロセスと同じ機能がありますが、特定のユーザー・プロセスとは対応付けられていません。共有サーバー・プロセスは、共有サーバー構成におけるクライアント要求に対してサービスを提供します。
共有サーバー・プロセスのPGAには、ユーザーに関係した（すべての共有サーバー・プロセスからアクセス可能であることが必要な）データは含まれません。共有サーバー・プロセスのPGAには、スタック領域とプロセス固有の変数のみが含まれています。
セッション関連の情報はすべてSGA内に入れられます。サーバーがどのセッションからの要求でも処理できるように、すべてのセッションのデータ領域に各共有サーバー・プロセスからアクセスできる必要があります。セッションのデータ領域ごとに、SGA内に領域が割り当てられます。ユーザーのプロファイル内のリソース制限PRIVATE_SGAを必要な領域の容量に設定すると、セッションが割り当てることのできる領域の容量を制限できます。
Oracleは、要求キューの長さに基づいて、共有サーバー・プロセスの数を動的に調整します。作成できる共有サーバー・プロセスの数は、初期化パラメータSHARED_SERVERSとMAX_SHARED_SERVERSの値で指定した範囲です。
|
関連項目
|
インスタンスの停止、インスタンスの起動、およびメディア・リカバリを含む、特定の管理アクティビティは、ディスパッチャ・プロセスに接続されている間は実行できません。ディスパッチャ・プロセスに接続されている間にこれらのアクティビティを実行しようとすると、エラー・メッセージが出されます。
これらのアクティビティは、一般的には管理者権限を使用して接続しているときに実行されます。共有サーバーにより構成されたシステムで管理者権限を使用して接続する場合は、ディスパッチャ・プロセスではなく専用サーバー・プロセスを使用することを接続文字列で明言してください（SERVER=DEDICATED）。
図9-4は、専用サーバー・アーキテクチャを使用し、2台のコンピュータ上で稼働しているOracleを示しています。この構成では、データベース・アプリケーションが1台のコンピュータのユーザー・プロセスによって実行され、対応付けられたOracleデータベース・サーバーがもう1台のコンピュータ上のサーバー・プロセスによって実行されます。
ユーザー・プロセスとサーバー・プロセスは、相互に分離した別のプロセスです。ユーザー・プロセスごとに作成された別々のサーバー・プロセスは、このサーバー・プロセスが対応付けられたユーザー・プロセスのためにのみ活動するため、専用サーバー・プロセス（またはシャドウ ・プロセス）と呼ばれます。
この構成では、ユーザー・プロセス数とサーバー・プロセス数の比率が1対1に維持されます。ユーザーが活発にデータベース要求をしていない場合でも、専用サーバー・プロセスはそのまま残ります（ただし、活動していない状態の場合、オペレーティング・システムによってはページアウトされることもあります）。
図9-4に、ネットワークを介して接続されている別々のコンピュータ上で実行されるユーザー・プロセスとサーバー・プロセスを示します。専用サーバー・アーキテクチャは、同じコンピュータ上でクライアント・アプリケーションとOracleデータベース・サーバー・コードの両方が実行される場合にも使用されますが、この2つのプログラムが1つのプロセスで実行されている場合は、ホスト・オペレーティング・システムはその2つの分離を維持できません。UNIXはそのようなオペレーティング・システムの一例です。
専用サーバー構成では、ユーザー・プロセスとサーバー・プロセスは異なるメカニズムを使用して通信します。
プログラム・インタフェースとは、データベース・アプリケーションとOracle間のソフトウェア・レイヤーです。プログラム・インタフェースには次のような機能があります。
Oracleコードはサーバーとして機能し、データ・ブロックから行をフェッチするなど、アプリケーション（クライアント）のためにデータベース・タスクを実行します。Oracleコードは、Oracleソフトウェアとオペレーティング・システム固有のソフトウェアの両方によって提供されるいくつかの部分で構成されます。
プログラム・インタフェースは、次の要素から構成されます。
ユーザー側とOracle側の両方のプログラム・インタフェースは、どちらもドライバのような仕組みでOracleソフトウェアを実行します。
Oracle Net Servicesはプログラム・インタフェースの一部であり、これによってクライアント・アプリケーション・プログラムとOracleデータベース・サーバーが通信ネットワーク内の別々のコンピュータ上に常駐できるようになります。
ドライバとは、通常はネットワークを介してデータを転送するソフトウェアの一部です。ドライバは、接続、切断、エラーの通知、エラーのテストなどの操作を実行します。ドライバは、通信プロトコルに固有であり、必ずデフォルトのドライバが存在します。
複数のドライバ（非同期またはDECnetドライバなど）をインストールし、その1つをデフォルト・ドライバとして選択しますが、各ユーザーは接続の時点で必要なドライバを指定すると、他のドライバを使用できます。プロセスが異なる場合は、異なるドライバを使用できます。1つのプロセスでも、異なるOracle Net Servicesドライバを使用して、1つのデータベースまたは複数のデータベース（ローカルまたはリモートのどちらでも）に同時に接続できます。
ユーザー側のプログラム・インタフェースと、Oracle側のプログラム・インタフェースを接続している最下位層のソフトウェアは、ホスト・オペレーティング・システムによって提供される通信ソフトウェアです。たとえば、DECnet、TCP/IP、LU6.2、ASYNCなどです。通信ソフトウェアはOracleから提供されることもありますが、通常、ハードウェア・ベンダーまたはサード・パーティのソフトウェア・サプライヤから別途、購入します。
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|