日本語PDF

15 プロセス・アーキテクチャ

この章では、Oracle Databaseのプロセスについて説明します。

この章の構成は、次のとおりです。

プロセスの概要

プロセスは一連の処理を実行できるオペレーティング・システムのメカニズムです。

プロセス実行のアーキテクチャは、オペレーティング・システムによって決まります。たとえば、Windowsでは、Oracleバックグラウンド・プロセスはプロセス内の実行スレッドです。LinuxおよびUNIXにおけるOracleプロセスは、オペレーティング・システム・プロセスか、またはオペレーティング・システム・プロセス内部のスレッドです。

プロセスは、コード・モジュールで実行されます。Oracle Databaseに接続されたすべてのユーザーは、データベース・インスタンスにアクセスするために、次のモジュールを実行する必要があります。

  • アプリケーションまたはOracle Databaseユーティリティ

    データベース・ユーザーは、プリコンパイラ・プログラムなどのデータベース・アプリケーションや、データベースに対してSQL文を発行するSQL*Plusなどのデータベース・ツールを実行します。

  • Oracleデータベース・コード

    各ユーザーには、各ユーザーのために実行されるOracleデータベース・コードがあり、これによってアプリケーションのSQL文を解釈および処理します。

プロセスは通常、そのプロセスのプライベート・メモリー領域で実行されます。ほとんどのプロセスは、関連付けられたトレース・ファイルに定期的に書き込むことができます。

プロセスのタイプ

複数のプロセスが、データベース・インスタンスに含まれているか、データベース・インスタンスと対話します。

プロセスは、次のタイプに分類されます。

  • クライアント・プロセスがアプリケーションまたはOracleツール・コードを実行します。

  • Oracleプロセスは、Oracleデータベース・コードを実行する実行単位です。マルチスレッド・アーキテクチャでは、Oracleプロセスは、オペレーティング・システム・プロセスにもオペレーティング・システム・プロセス内のスレッドにもなります。Oracleプロセスには、次のサブタイプがあります。

    • バックグラウンド・プロセスは、データベース・インスタンスとともに起動し、インスタンス・リカバリの実行、プロセスのクリーン・アップ、ディスクへのREDOバッファの書込みなどのメンテナンス・タスクを実行します。

    • サーバー・プロセスは、クライアントの要求に基づいて処理を実行します。

      たとえば、これらのプロセスではSQL問合せを解析して共有プールに入れ、問合せごとに問合せ計画を作成して実行し、データベース・バッファ・キャッシュまたはディスクからバッファを読み取ります。

      注意:

      サーバー・プロセスおよびサーバー・プロセス内で割り当てられたプロセス・メモリーは、データベース・インスタンス内で実行されます。サーバー・プロセスが終了しても、インスタンスは機能し続けます。

    • スレーブ・プロセスは、バックグラウンドまたはサーバー・プロセスに対して追加タスクを実行します。

プロセスの構造は、オペレーティング・システムおよびOracle Databaseオプションの選択に応じて異なります。たとえば、接続されたユーザーのコードを、専用サーバー接続または共有サーバー接続に対して構成できます。共有サーバー・アーキテクチャでは、データベース・コードを実行する各サーバー・プロセスにより複数のクライアント・プロセスに対応できます。

図15-1に、専用のサーバー接続を使用する、システム・グローバル領域(SGA)およびバックグラウンド・プロセスを示します。ユーザー接続ごとに、クライアント・プロセスによってアプリケーションが実行されます。このクライアント・プロセスは、データベース・コードを実行する専用サーバー・プロセスとは異なります。各クライアント・プロセスは、それ自体のサーバー・プロセスに関連付けられ、そのサーバー・プロセスには、それ自体のプログラム・グローバル領域(PGA)があります。

図15-1 OracleプロセスおよびSGA

図15-1の説明が続きます
「図15-1 OracleプロセスおよびSGA」の説明

関連項目:

マルチプロセスおよびマルチスレッド化されたOracle Databaseシステム

マルチ・プロセスOracle Database(マルチユーザーOracle Databaseとも呼ばれる)は、Oracle Databaseコードの各部分の実行およびユーザー用に複数のプロセスを使用します(ユーザー用のプロセスは、接続するユーザーごとに1つのプロセスの場合や、複数のユーザーが共有する1つ以上のプロセスの場合があります)。

データベースの主な利点が、複数のユーザーが同時に必要とするデータを管理できることにあるため、多くのデータベースはマルチユーザー対応です。データベース・インスタンスの各プロセスは、特定のジョブを実行します。データベースとアプリケーションの処理を複数のプロセスに分割することにより、複数のユーザーおよびアプリケーションが1つのインスタンスに同時に接続でき、優れたパフォーマンスを確保できます。

Oracle Database 12c以前のリリースでは、OracleプロセスはUNIXおよびLinuxシステムでスレッドとして実行されませんでした。Oracle Database 12cからは、マルチスレッドOracle Databaseモデルにより、Oracleプロセスが、別のアドレス領域でオペレーティング・システム・スレッドとして実行可能になりました。Oracle Database 12cがインストールされると、データベースはプロセス・モードで実行されます。データベースをスレッド・モードで実行するには、THREADED_EXECUTION初期化パラメータをTRUEに設定する必要があります。スレッド・モードでは、UNIXおよびLinux上の一部のバックグラウンド・プロセスは、プロセス(各プロセスが1つのスレッドを含む)として実行されるのに対し、残りのOracleプロセスは、プロセス内のスレッドとして実行されます。

スレッド・モードで実行されているデータベースでは、PMONおよびDBWがオペレーティング・システム・プロセスとして実行される可能性があるのに対して、LGWRおよびCMONは単一プロセス内のスレッドとして実行される可能性があります。2つのフォアグラウンド・プロセスおよびパラレル実行(PX)サーバー・プロセスは、2つ目のオペレーティング・システム・プロセス内のスレッドとして実行される可能性があります。3番目のオペレーティング・システム・プロセスには、複数のフォアグラウンド・スレッドが含まれている可能性があります。したがって、Oracleプロセスは、必ずしもオペレーティング・システム・プロセスとはかぎりません。

注意:

THREADED_EXECUTION初期化パラメータがTRUEに設定された場合、オペレーティング・システム認証はサポートされません。

例15-1 Oracleプロセス・メタデータの表示

V$PROCESSビューには、データベース・インスタンスに接続されているOracleプロセスごとに1行が含まれます。たとえば、次のSQL*Plusでの問合せを実行して、オペレーティング・システム・プロセスIDおよびオペレーティング・システム・スレッドIDをプロセスごとに取得できます。

COL SPID FORMAT a8
COL STID FORMAT a8
SELECT SPID, STID, PROGRAM FROM V$PROCESS ORDER BY SPID;

問合せにより、次の部分的サンプル出力が得られます。

SPID   STID   PROGRAM
-----  -----  ---------------------------
7190   7190   oracle@samplehost (PMON) 
7192   7192   oracle@samplehost (PSP0) 
7194   7194   oracle@samplehost (VKTM) 
7198   7198   oracle@samplehost (SCMN) 
7198   7200   oracle@samplehost (GEN0) 
7202   7202   oracle@samplehost (SCMN) 
7202   7204   oracle@samplehost (DIAG) 
7198   7205   oracle@samplehost (DBRM) 
7202   7206   oracle@samplehost (DIA0) 
.
.
.

関連項目:

クライアント・プロセスの概要

ユーザーがPro*CプログラムやSQL*Plusなどのアプリケーションを実行する場合、オペレーティング・システムでは、そのユーザー・アプリケーションを実行するために、クライアント・プロセス(ユーザー・プロセスとも呼ばれる)を作成します。クライアント・アプリケーションにはOracle Databaseライブラリがリンクされており、このライブラリによってデータベースとの通信に必要なAPIが提供されます。

クライアントおよびサーバー・プロセス

クライアント・プロセスは、インスタンスと直接対話するOracleプロセスとは大きく異なります。

クライアント・プロセスにサービスを提供するOracleプロセスでは、SGAからの読取りおよびSGAへの書込みが可能ですが、クライアント・プロセスではできません。クライアント・プロセスは、データベース・ホストとは別のホストで実行できますが、Oracleプロセスは実行できません。

たとえば、クライアント・ホストのユーザーがSQL*Plusを起動し、データベース・インスタンスが開始されていないときに、ネットワークを介して別のホストのデータベース、sampleに接続するとします。

SQL> CONNECT SYS@inst1 AS SYSDBA
Enter password: *********
Connected to an idle instance.

クライアント・ホスト上でsqlplusまたはsampleのプロセスを検索すると、sqlplusクライアント・プロセスのみが表示されます。

% ps -ef | grep -e sample -e sqlplus | grep -v grep
clientuser 29437 29436  0 15:40 pts/1    00:00:00 sqlplus           as sysdba

データベース・ホスト上でsqlplusまたはsampleのプロセスを検索すると、ローカル以外の接続を伴うサーバー・プロセスが表示されますが、クライアント・プロセスは表示されません。

% ps -ef | grep -e sample -e sqlplus | grep -v grep
serveruser 29441     1  0 15:40 ?        00:00:00 oraclesample (LOCAL=NO)

関連項目:

インスタンスが開始されていないときにクライアントがデータベースに接続する方法の詳細は、「インスタンスの開始方法」を参照してください

接続とセッション

データベース接続とは、クライアント・プロセスとデータベース・インスタンスとの間の物理的な通信経路のことです。

接続中、通信経路は、使用可能なプロセス間通信メカニズムまたはネットワーク・ソフトウェアを使用して確立されます。一般的に、接続はクライアント・プロセスとサーバー・プロセスまたはディスパッチャとの間で確立されますが、クライアント・プロセスとOracle Connection Manager(CMAN)との間でも確立されます。

データベース・セッションは、データベースに対する現在のユーザー・ログインの状況を示す、データベース・インスタンス・メモリー内の論理エンティティです。たとえば、ユーザーがパスワードによってデータベースから認証されると、このユーザーに対してセッションが確立されます。セッションは、ユーザーがデータベースから認証された時点から、ユーザーが接続を切断するか、データベース・アプリケーションを終了する時点まで続きます。

1つの接続では、セッションが確立されないか、1つ以上のセッションが確立されます。セッションはそれぞれ独立していて、あるセッションでのコミットは、他のセッションのトランザクションには影響しません。

注意:

Oracle Net接続プーリングが構成されると、接続が中断されることがありますが、セッションはそのまま残されます。

単独のデータベース・ユーザーに対して、複数のセッションが同時に存在できます。次の図に示すように、ユーザーhrが1つのデータベースに複数の接続を確立できます。専用サーバー接続の場合、それぞれの接続のかわりに1つのサーバー・プロセスがデータベースによって作成されます。これは、専用サーバーを作成するクライアント・プロセスのみが使用します。共有サーバー接続では、多数のクライアント・プロセスが1つの共有サーバー・プロセスにアクセスします。

図15-2 各接続に1セッション

図15-2の説明が続きます
「図15-2 各接続に1セッション」の説明

図15-3は、ユーザーhrが1つのデータベースに1つの接続を確立していることを示していますが、この接続には2つのセッションがあります。

図15-3 1つの接続に存在する2つのセッション

図15-3の説明が続きます
「図15-3 1つの接続に存在する2つのセッション」の説明

SQL文実行統計の自動トレース・レポートを作成すると、図15-3のシナリオが再作成されます。

例15-2DISCONNECTコマンドは、実際には、接続ではなくセッションを終了しています。

例15-2 接続とセッション

次の例では、ユーザーSYSTEMとしてデータベースにSQL*Plusを接続してトレースを実行可能にし、新規セッションを作成しています(サンプル出力を含みます)。

SQL> SELECT SID, SERIAL#, PADDR FROM V$SESSION WHERE USERNAME = USER;

SID SERIAL# PADDR
--- ------- --------
 90      91 3BE2E41C
 
SQL> SET AUTOTRACE ON STATISTICS;
SQL> SELECT SID, SERIAL#, PADDR FROM V$SESSION WHERE USERNAME = USER;
 
SID SERIAL# PADDR
--- ------- --------
 88      93 3BE2E41C
 90      91 3BE2E41C
...
SQL> DISCONNECT

DISCONNECTコマンドは、実際には、接続ではなくセッションを終了しています。新規端末を開いて別のユーザーとしてインスタンスに接続し、次の問合せを実行すると、アドレス3BE2E41Cの接続がアクティブなままであることが示されます。

SQL> CONNECT dba1@inst1
Password: ********
Connected.
SQL> SELECT PROGRAM FROM V$PROCESS WHERE ADDR = HEXTORAW('3BE2E41C');

PROGRAM
------------------------------------------------
oracle@stbcs09-1 (TNS V1-V3)

データベース操作

データベース監視のコンテキストにおけるデータベースの操作は、エンド・ユーザーまたはアプリケーション・コードによって定義されたとおりの2つの時点間のセッション・アクティビティです。

単一データベースの操作は、1つのSQL文または1つのPL/SQLプロシージャかファンクションのいずれかです。コンポジット・データベースの操作は、一連の単一またはコンポジット操作です。

タスクを監視、比較およびチューニングするため、大きなタスクのセットは複数のデータベース操作に分割し、複数の操作は複数のフェーズにさらに分割できます。ユースケースとしては、実行速度が通常より遅いPL/SQLバッチ・ジョブがあります。ジョブをデータベース操作として構成することで、ジョブ内のコストのかかるステップを特定してチューニングできます。

データベース操作の各実行は、操作名と実行IDという属性のペアにより一意に特定されます。あるセッションから、セッションIDとシリアル番号を指定することで、別のセッションのデータベース操作を開始または終了できます。

同じデータベース操作が2つ出現した場合、同じ名前で異なる実行IDを使用すれば、同時に実行できます。同じ名前のデータベース操作の各実行には、異なる文を含めることができます。

データベース操作は、DBMS_SQL_MONITOR PL/SQLパッケージにより作成し管理します。V$SQL_MONITORV$SQL_PLAN_MONITORおよびV$SQL_MONITOR_SESSTATを使用して操作を監視できます。

関連項目:

サーバー・プロセスの概要

Oracle Databaseでは、インスタンスに接続されたクライアント・プロセスの要求を処理するために、サーバー・プロセスが作成されます。クライアント・プロセスは常に別のサーバー・プロセスを介してデータベースと通信します。

データベース・アプリケーション用に作成されるサーバー・プロセスは、次のタスクを1つ以上実行できます。

  • アプリケーションを介して発行されたSQL文を解析し、実行します。これには問合せ計画の作成および実行も含まれます。

  • PL/SQLコードを実行します。

  • データファイルからデータベース・バッファ・キャッシュにデータ・ブロックを読み取ります(DBWバックグラウンド・プロセスには、修正されたブロックをディスクに戻して書き込むというタスクがあります)。

  • アプリケーションが情報を処理できるような方法で結果を戻します。

関連項目:

SQL処理の段階

専用サーバー・プロセス

専用サーバー接続の場合、クライアント接続は、1つのサーバー・プロセスにのみ関連付けられています。

Linuxでは、1つのデータベース・インスタンスに接続された20のクライアント・プロセスに、20のサーバー・プロセスが対応します。各クライアント・プロセスは、そのサーバー・プロセスと直接通信します。セッションの継続中、このサーバー・プロセスはそのクライアント・プロセス専用になります。サーバー・プロセスでは、プロセス固有の情報およびUGAをPGAに格納します。

共有サーバー・プロセス

共有サーバー接続の場合、クライアント・アプリケーションはネットワーク上でサーバー・プロセスではなく、ディスパッチャ・プロセスに接続します。たとえば、20のクライアント・プロセスが1つのディスパッチャ・プロセスに接続できます。

ディスパッチャ・プロセスでは、接続されたクライアントからのリクエストを受け取り、ラージ・プールのリクエスト・キューに入れます。最初に使用可能な共有サーバー・プロセスが、キューからリクエストを受け取って処理します。その後、共有サーバーは、その結果をディスパッチャ・レスポンス・キューに入れます。ディスパッチャ・プロセスはこのキューを監視し、結果をクライアントに送信します。

専用サーバー・プロセスと同様、共用サーバー・プロセスにはそれ自体のPGAがあります。ただし、共有サーバーがセッション・データにアクセスできるように、セッションのUGAはSGAにあります。

Oracle Databaseによるサーバー・プロセスの作成方法

データベースでは接続メソッドに応じて、様々な方法でサーバー・プロセスが作成されます。

接続方法は次のとおりです。

  • Bequeath

    SQL*Plus、OCIクライアントまたは別のクライアント・アプリケーションがサーバー・プロセスを直接生成します。

  • Oracle Net Listener

    クライアント・アプリケーションがリスナー経由でデータベースに接続します。

  • 専用ブローカ

    これは、フォアグラウンド・プロセスを作成するデータベース・プロセスです。リスナーと異なり、ブローカはデータベース・インスタンスの内部に常駐します。専用ブローカを使用するときは、クライアントがリスナーに接続した後、リスナーがその接続を専用ブローカに渡します。

接続にBequeathが使用されないときは、データベースによって次のようにサーバー・プロセスが作成されます。

  1. クライアント・アプリケーションがリスナーまたはブローカから新規の接続をリクエストします。

  2. リスナーまたはブローカが新規のプロセスまたはスレッドの作成を開始します。

  3. オペレーティング・システムが新規のプロセスまたはスレッドを作成します。

  4. Oracle Databaseが各種のコンポーネントおよび通知を初期化します。

  5. データベースが接続および接続固有コードを引き渡します。

オプションで、専用ブローカ接続メソッドを使用する場合は、DBMS_PROCESSパッケージを使用してサーバー・プロセスのプールを事前に作成できます。この場合、Process Manager (PMAN)バックグラウンド・プロセスは、クライアント・リクエストとの関連付けを待機する、事前作成されたプロセスのプールを監視します。接続でサーバー・プロセスが求められる場合、データベースではプロセス作成のステップ2-4がスキップされ、ステップ5のみが実行されます。この最適化により、パフォーマンスが向上します。

注意:

バックグラウンド・プロセスの概要

バックグラウンド・プロセスはマルチプロセスのOracleデータベースによって使用される追加のプロセスです。バックグラウンド・プロセスでは、データベースの操作、および複数ユーザーのパフォーマンスの最大化に必要なメンテナンス・タスクを実行します。

各バックグラウンド・プロセスには個別のタスクがありますが、他のプロセスと連携して動作します。たとえば、LGWRプロセスでは、REDOログ・バッファのデータをオンラインREDOログに書き込みます。いっぱいになったREDOログ・ファイルをアーカイブする準備ができたら、LGWRから別のプロセスにそのREDOログ・ファイルをアーカイブするように信号が送られます。

Oracle Databaseは、データベース・インスタンスが起動すると、自動的にバックグラウンド・プロセスを作成します。インスタンスは多数のバックグラウンド・プロセスを持つことができますが、そのすべてが常にそれぞれのデータベース構成に存在するとはかぎりません。次の問合せを実行すると、データベースで実行中のバックグラウンド・プロセスが表示されます。

SELECT PNAME 
FROM   V$PROCESS 
WHERE  PNAME IS NOT NULL 
ORDER BY PNAME;

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

関連項目:

すべてのバックグラウンド・プロセスの詳細は、『Oracle Databaseリファレンス』を参照

必須のバックグラウンド・プロセス

必須のバックグラウンド・プロセスは、すべての一般的なデータベース構成に存在します。

これらのプロセスは、デフォルトでは、最小限に構成された初期化パラメータ・ファイルを使用して起動される読取り/書込みデータベース・インスタンス内で実行されます。読取り専用データベース・インスタンスはこれらの一部のプロセスを無効化します。

この項では、次の必須のバックグラウンド・プロセスについて説明します。

関連項目:

プロセス・モニター・プロセス(PMON)グループ

PMONグループには、PMON、クリーンアップ・メイン・プロセス(CLMN)およびクリーンアップ・ヘルパー・プロセス(CLnn)が含まれています。これらのプロセスは、他のプロセスの監視とクリーンアップを担当します。

PMONグループは、バッファ・キャッシュのクリーンアップとクライアント・プロセスが使用していたリソースの解放を監視します。たとえば、PMONグループはアクティブ・トランザクション表の状態をリセットし、不要になったロックを解除し、アクティブ・プロセスのリストから終了したプロセスのプロセスIDを削除します。

データベースでは、終了したプロセスによって保持されていたリソースが解放され、他のプロセスで使用できるようになっていることを確認する必要があります。そうしないと、競合のためにプロセスがブロックされたり、動作不能になる可能性があります。

プロセス・モニター・プロセス(PMON)

プロセス・モニター(PMON)は、他のバックグラウンド・プロセスの終了を検出します。サーバー・プロセスまたはディスパッチャ・プロセスが異常終了すると、PMONグループがプロセスのリカバリを実行します。プロセス終了には、オペレーティング・システムのkillコマンドまたはALTER SYSTEM KILL SESSION文などの複数の原因が考えられます。

クリーンアップ・メイン・プロセス(CLMN)

PMONは、クリーンアップ作業をクリーンアップ・メイン・プロセス(CLMN)に委譲します。異常終了を検知するタスクはPMONに残されます。

CLMNでは終了したプロセス、終了したセッション、トランザクション、ネットワーク接続、アイドル・セッション、デタッチされたトランザクション、およびアイドル・タイムアウトを超過したデタッチされたネットワーク接続のクリーンアップが、定期的に実行されます。

クリーンアップ・ヘルパー・プロセス(CLnn)

CLMNは、クリーンアップ作業をCLnnヘルパー・プロセスに委譲します。

CLnnプロセスは終了したプロセスおよびセッションのクリーンアップを補助します。ヘルパー・プロセスの数は、実行されるクリーンアップ作業の量と、現在のクリーンアップ効率に比例します。

クリーンアップ・プロセスはブロックされる場合があり、これによって他のプロセスのクリーンアップを続行できなくなります。また、複数のプロセスでクリーンアップが要求されると、クリーンアップ時間が膨大になる可能性があります。これらの理由から、Oracle Databaseでは複数のヘルパー・プロセスをパラレルに使用してクリーンアップを実行できるため、パフォーマンスの低下が緩和されます。

V$CLEANUP_PROCESSビューおよびV$DEAD_CLEANUPビューにCLMNクリーンアップに関するメタデータが含まれます。V$CLEANUP_PROCESSビューには、クリーンアップ・プロセスごとに1行が含まれます。たとえば、V$CLEANUP_PROCESS.STATEBUSYの場合は、このプロセスが現在クリーンアップを行っています。

関連項目:

V$CLEANUP_PROCESSの詳細は、『Oracle Databaseリファレンス』を参照

データベース・リソースの隔離

プロセスまたはセッションが終了した場合、PMONグループは保持リソースをデータベースに解放します。場合によっては、破損してリカバリ不可能なリソースがPMONグループによって自動的に隔離されるため、データベース・インスタンスがただちに強制終了されることはありません。

PMONグループは、隔離されたリソースを保持していたプロセスまたはセッションに対して、できるかぎり多くのクリーンアップを実行し続けます。V$QUARANTINEビューには、リソースのタイプ、消費されたメモリー量、隔離の原因であるOracleエラーなどのメタデータが含まれます。

関連項目:

V$QUARANTINEの詳細は、『Oracle Databaseリファレンス』を参照

プロセス・マネージャ(PMAN)

プロセス・マネージャ(PMAN)は、共有サーバー、プーリングされたサーバーおよびジョブ・キュー・プロセスを含む、いくつかのバックグラウンド・プロセスを監視します。

PMANは、次のタイプのプロセスを監視、起動および停止します。

  • ディスパッチャ・プロセスおよび共有サーバー・プロセス

  • 接続ブローカおよびデータベース常駐接続プールのプール・サーバー・プロセス

  • ジョブ・キュー・プロセス

  • 再起動可能なバックグラウンド・プロセス

リスナー登録プロセス(LREG)

リスナー登録プロセス(LREG)では、データベース・インスタンスおよびディスパッチャ・プロセスに関する情報をOracle Netリスナーに登録します。

インスタンスの起動時に、LREGはリスナーに対してポーリングを実行し、リスナーが実行されているかどうかを確認します。リスナーが実行されている場合、LREGはリスナーに該当パラメータを渡します。実行されていない場合には、LREGは定期的にリスナーとの接続を試行します。

注意:

Oracle Database 12cまでのリリースでは、PMONがリスナー登録を実行していました。

システム・モニター・プロセス(SMON)

システム・モニター・プロセス(SMON)は、システム・レベルで様々なクリーン・アップ作業を実行します。

SMONには次のような役割があります。

  • 必要に応じて、インスタンスの起動時に、インスタンス・リカバリを実行します。Oracle RACデータベースでは、障害の発生したインスタンスのインスタンス・リカバリを、データベース・インスタンスのSMONプロセスが実行できます。

  • ファイル読取りまたは表領域オフライン・エラーが原因で、インスタンス・リカバリ時にスキップされた終了済トランザクションがリカバリされます。表領域またはファイルがオンラインに戻ると、SMONによってトランザクションがリカバリされます。

  • 未使用の一時セグメントをクリーン・アップします。たとえば、Oracle Databaseでは、索引を作成するときにエクステントを割り当てます。この操作が失敗すると、SMONによって一時領域がクリーン・アップされます。

  • ディクショナリ管理表領域内の、連続した空きエクステントを結合します。

SMONは、処理が必要かどうかを定期的にチェックします。他のプロセスは、必要性が検出された場合にSMONをコールできます。

データベース・ライター・プロセス(DBW)

データベース・ライター・プロセス(DBW)は、データベース・バッファの内容をデータファイルに書き込みます。DBWプロセスは、データベース・バッファ・キャッシュ内の変更されたバッファをディスクに書き込みます。

ほとんどのシステムでは1つのデータベース・ライター・プロセス(DBW0)があれば十分ですが、追加プロセス(DBW1からDBW9およびDBWaからDBWj)を構成して、システムでデータを頻繁に変更する場合の書込みのパフォーマンスを改善できます。これらの追加DBWプロセスは、ユニプロセッサ・システムでは効果がありません。

DBWプロセスは、次のような場合に使用済バッファをディスクに書き込みます。

  • サーバー・プロセスがしきい値の数までバッファをスキャンしても、クリーンな再利用可能バッファが見つからない場合は、DBWに書込み信号が送られます。DBWは、可能であれば、他の処理中に使用済バッファをディスクに非同期に書き込みます。

  • DBWは、定期的にバッファを書き込んで、REDOスレッド内のインスタンス・リカバリを開始する位置(チェックポイント)を進めます。チェックポイントのログ位置は、バッファ・キャッシュ内の最も古い使用済バッファ・キャッシュによって決まります。

多くの場合、DBWによって書き込まれるブロックは、ディスク内に分散されます。このため、この書込みは、LGWRが実行する順次書込みよりも遅くなる傾向があります。効率を向上させるために、可能であればDBWは、マルチブロック書込みを実行します。マルチブロック書込みで書き込まれるブロックの数は、オペレーティング・システムに応じて異なる。

関連項目:

ログ・ライター・プロセス(LGWR)

ログ・ライター・プロセス(LGWR)では、オンラインREDOログ・バッファを管理します。

LGWRは、バッファの一部分をオンラインREDOログに書き込みます。データベース・バッファを変更するタスクを切り離すことによって、分散した使用済バッファのディスクへの書込み、およびREDOのディスクへの高速順次書込みの処理で、データベースのパフォーマンスが向上します。

次の状況では、LGWRは、最後の書込み以降にバッファにコピーされたREDOエントリすべてを、REDOログ・ファイルに書き込みます。

  • ユーザーがトランザクションをコミットしたとき。

  • オンラインREDOログ・スイッチが発生したとき

  • LGWRによる最後の書込みから3秒経過したとき

  • REDOログ・バッファが3分の1になったとき、またはバッファ・データが1MBになったとき

  • DBWが修正済のバッファをディスクに書き込む必要があるとき

    DBWが使用済バッファを書き込むには、バッファの変更に関連するすべてのREDOレコードがディスクに書き込まれている必要があります(事前書込みプロトコル)。DBWは、書き込まれていないREDOレコードがあることを検出すると、そのレコードをディスクに書き込むようにLGWRに信号を送り、LGWRの処理が完了するまで待機して、データ・バッファをディスクに書き込みます。

LGWRおよびコミット

Oracle Databaseは、コミットされたトランザクションのパフォーマンスを向上させるために、高速コミット・メカニズムを使用します。

ユーザーがCOMMIT文を発行すると、トランザクションにシステム変更番号(SCN)が割り当てられます。LGWRはREDOログ・バッファ内にコミット・レコードを入れ、コミットSCNおよびトランザクションのREDOエントリとともにそれを即時にディスクに書き込みます。

REDOログ・バッファは循環バッファです。LGWRがREDOログ・バッファからオンラインREDOログ・ファイルにREDOエントリを書き込んだ後、サーバー・プロセスはディスクに書き込まれたREDOログ・バッファのエントリ上に新しいエントリをコピーできます。オンラインREDOログへのアクセスが頻繁なときにも、新しいエントリを書き込めるよう常にバッファ内の領域を空けておくため、LGWRが行う書込みは通常は非常に高速になります。

トランザクションのコミット・レコードを含むREDOエントリのアトミックな書込みは、トランザクションがコミットされたかどうか確認する1つのイベントです。Oracle Databaseでは、データ・バッファがまだディスクに書き込まれていない場合でも、コミットしたトランザクションに対する成功コードが戻されます。対応するデータ・ブロックの変更は、DBWがそれらの変更を効率的にデータファイルに書き込めるようになるまで延期されます。

注意:

LGWRでは、トランザクションがコミットする前に、REDOログ・エントリをディスクに書き込むことができます。後でトランザクションがコミットされた場合にのみ、REDOエントリにより保護された変更が確定します。

アクティビティが高いとき、LGWRはグループ・コミットを使用できます。たとえば、ユーザーがコミットし、これによって、LGWRがトランザクションのREDOエントリをディスクに書き込むとします。この書込み中、他のユーザーがコミットします。LGWRでは、前の書込みが完了するまで、これらのトランザクションをディスクに書き込んでコミットすることはできません。完了すると、LGWRは、(まだコミットされていない)待機しているトランザクションに関するREDOエントリのリストを1回の操作で書き込むことができます。これにより、データベースでは、ディスクI/Oが最小化され、パフォーマンスが最大化されます。コミットの要求が高い頻度で続くと、LGWRによる毎回の書込みに複数のコミット・レコードが含まれることがあります。

LGWRおよびアクセス不能ファイル

LGWRは、ミラー化されたアクティブなオンラインREDOログ・ファイルのグループにも同時に書き込みます。

ログ・ファイルにアクセスできない場合、LGWRはグループ内の他のファイルに書込みを続け、LGWRトレース・ファイルおよびアラート・ログにエラーを書き込みます。グループ内のすべてのファイルが破損している場合や、アーカイブされていないためにグループ全体が使用できない場合、LGWRは機能を続行できません。

関連項目:

チェックポイント・プロセス(CKPT)

チェックポイント・プロセス(CKPT)は、チェックポイント情報により制御ファイルおよびデータファイル・ヘッダーを更新し、DBWに対してブロックをディスクに書き込むように信号を送ります。チェックポイント情報には、チェックポイント位置、SCNおよびオンラインREDOログの中でリカバリを開始する位置が含まれます。

図15-4に示すように、CKPTではデータファイルへのデータ・ブロックの書込み、およびオンラインREDOログ・ファイルへのREDOブロックの書込みは行いません。

図15-4 チェックポイント・プロセス

図15-4の説明が続きます
「図15-4 チェックポイント・プロセス」の説明
管理性モニター・プロセス(MMONおよびMMNL)

管理性モニター・プロセス(MMON)は、自動ワークロード・リポジトリ(AWR)に関連する多数のタスクを実行します。

たとえば、MMONはスナップショットを取得し、前回変更されたSQLオブジェクトの統計値を取得して、メトリックがそのしきい値を超えたときに書込みを行います。

管理性モニター・ライト・プロセス(MMNL)は、SGAのアクティブ・セッション履歴(ASH)バッファ内の統計をディスクに書き込みます。MMNLは、ASHバッファがいっぱいになるとディスクに書き込みます。

リカバラ・プロセス(RECO)

分散データベースでは、リカバラ・プロセス(RECO)によって、分散トランザクションに関連する障害が自動的に解決されます。

ノードのRECOプロセスは、インダウト分散トランザクションにかかわる他のデータベースに自動的に接続されます。RECOでは、データベース間の接続を再確立するとき、すべてのインダウト・トランザクションを自動的に解決し、解決されるトランザクションに対応する行を各データベースの保留中のトランザクション表からすべて削除します。

関連項目:

分散トランザクション・リカバリの詳細は、『Oracle Database管理者ガイド』を参照してください

オプションのバックグラウンド・プロセス

オプションのバックグラウンド・プロセスは、必須として定義されていないバックグラウンド・プロセスです。

ほとんどのオプションのバックグラウンド・プロセスは、タスクまたは機能に固有です。たとえば、Oracle ASMをサポートするバックグラウンド・プロセスは、この機能が有効になっている場合のみ使用できます。

この項では、いくつかの一般的なオプションのプロセスについて説明します。

関連項目:

アーカイバ・プロセス(ARCn)

アーカイバ・プロセス(ARCn)は、REDOログ・スイッチが行われると、オンラインREDOログ・ファイルをオフライン・ストレージにコピーします。

また、トランザクションのREDOデータを収集し、そのデータをスタンバイ・データベースの宛先に転送できます。ARCnプロセスは、データベースがARCHIVELOGモードに設定され、自動アーカイブが使用可能になっている場合にのみ存在します。

関連項目:

ジョブ・キュー・プロセス(CJQ0およびJnnn)

キュー・プロセスでは、多くの場合バッチ・モードでユーザー・ジョブを実行します。ジョブとは、1回以上実行するようにスケジューリングされたユーザー定義のタスクです。

たとえば、ジョブ・キューを使用して、バックグラウンドで長時間実行される更新をスケジュールできます。開始日と時間間隔を指定すると、ジョブ・キュー・プロセスは、指定された間隔でジョブの実行を試行します。

Oracle Databaseではジョブ・キュー・プロセスが動的に管理されるため、ジョブ・キュー・クライアントは、必要に応じてより多くのジョブ・キュー・プロセスを使用できます。新規プロセスが使用するリソースは、そのプロセスがアイドル状態になると解放されます。

動的ジョブ・キュー・プロセスは、指定された間隔で多数のジョブを同時に実行できます。各イベントの順序は次のとおりです。

  1. ジョブ・コーディネータ・プロセス(CJQ0)は、Oracle Schedulerの必要に応じて、自動的に起動し、停止します。コーディネータ・プロセスは、システムのJOB$表から、実行する必要があるジョブを定期的に選択します。選択された新規ジョブは、時間順に並べ替えられます。

  2. コーディネータ・プロセスは、ジョブを実行するためにジョブ・キュー・スレーブ・プロセス(Jnnn)を動的に生成します。

  3. ジョブ・キュー・プロセスは、実行のためにCJQ0プロセスによって選択されたジョブの1つを実行します。ジョブ・キュー・プロセスは、一度に1つずつジョブを実行して完了します。

  4. ジョブ・キュー・プロセスは、1つのジョブの実行が終了すると、次のジョブの問合せを行います。実行予定のジョブが存在しない場合、ジョブ・キュー・プロセスはスリープ状態に入り、定期的な周期で起動すると次のジョブの問合せを行います。新しいジョブがない場合、事前に設定した周期が経過した後に終了します。

初期化パラメータJOB_QUEUE_PROCESSESは、1つのインスタンスで同時に実行できるジョブ・キュー・プロセスの最大数を示します。ただし、クライアントは、すべてのジョブ・キュー・プロセスがジョブの実行に使用可能であると想定することはできません。

注意:

初期化パラメータJOB_QUEUE_PROCESSESが0(ゼロ)に設定されている場合、コーディネータ・プロセスは起動しません。

関連項目:

フラッシュバック・データ・アーカイブ・プロセス(FBDA)

フラッシュバック・データ・アーカイブ・プロセス(FBDA)は、追跡した表の履歴行をフラッシュバック・データ・アーカイブにアーカイブします。

追跡した表に対するDMLを含むトランザクションがコミットされると、このプロセスでは、変更された行の事前イメージがフラッシュバック・データ・アーカイブに格納されます。また、現在の行にメタデータを保存します。

FBDAは、フラッシュバック・データ・アーカイブの領域、編成および保存に関する管理を自動的に行います。また、追跡対象トランザクションのアーカイブが行われた期間が記録されます。

領域管理コーディネータ・プロセス(SMCO)

SMCOプロセスでは、様々な領域管理関連タスクの実行を調整します。

通常のタスクには、事前の領域割当ておよび領域の再利用が含まれます。SMCOにより、自動的にスレーブ・プロセス(Wnnn)が起動され、タスクが実行されます。

関連項目:

フラッシュバック・データ・アーカイブおよび一時履歴機能の詳細は、『Oracle Database開発ガイド』を参照してください

スレーブ・プロセス

スレーブ・プロセスは、他のプロセスにかわって作業を実行するバックグラウンド・プロセスです。

この項では、Oracle Databaseが使用するスレーブ・プロセスの一部について説明します。

関連項目:

Oracle Databaseのスレーブ・プロセスの詳細は、『Oracle Databaseリファレンス』を参照してください。

I/Oスレーブ・プロセス

I/Oスレーブ・プロセス(Innn)は、非同期I/Oがサポートされていないシステムおよびデバイスにかわって、非同期I/Oをシミュレートします。

非同期I/Oの場合、伝送のためのタイミング要件がないため、伝送が終了する前に他のプロセスを起動できます。

たとえば、非同期I/Oがサポートされていないオペレーティング・システムのディスクに、アプリケーションが1000ブロックを書き込むとします。それぞれの書込みは順次実行され、書込みの完了確認まで待機します。非同期ディスクの場合、アプリケーションは一括でブロックを書き込み、すべてのブロックが書き込まれたというオペレーティング・システムからのレスポンスを待機している間、他の作業を実行できます。

非同期I/Oをシミュレートするには、1プロセスがいくつかのスレーブ・プロセスを監視します。実行者プロセスでは、それぞれの書込みの完了報告を待機し、完了時にそれを実行者に転送する各スレーブ・プロセスに作業を割り当てます。真の非同期I/Oでは、オペレーティング・システムがI/Oの完了と、その報告のプロセスへの転送を待機しますが、シミュレートされた非同期I/Oの場合、スレーブが完了報告を待機し、実行者へそれを転送します。

Oracle Databaseでは、次のような様々なタイプのI/Oスレーブがサポートされています。

  • Recovery Manager(RMAN)のI/Oスレーブ

    データのバックアップまたはリストアにRMANを使用するとき、ディスクおよびテープ・デバイスにI/Oスレーブを使用できます。

  • データベース・ライター・スレーブ

    複数のデータベース・ライター・プロセスを使用することが現実的でない場合、たとえば、コンピュータのCPUが1つのみである場合、Oracle Databaseは、複数のスレーブ・プロセスにI/Oを分散できます。DBWは、ディスクへのブロックの書込みを可能にするため、バッファ・キャッシュLRUリストをスキャンする唯一のプロセスです。ただし、I/Oスレーブは、これらのブロックに対するI/Oを実行します。

関連項目:

パラレル実行(PX)サーバー・プロセス

パラレル実行では、複数のプロセスが同時に機能して、単一のSQL文を実行します。

複数プロセス内で作業を分割すると、Oracle Databaseでは、より迅速に文を実行できます。たとえば、1つのプロセスで4つの四半期分をすべて処理するのではなく、4つのプロセスが1年のそれぞれの四半期を分担して処理するなどがこの例です。

パラレル実行に対して、シリアル実行の場合、SQL文の順次実行に必要な処理のすべてを1つのサーバー・プロセスが実行します。たとえば、SELECT * FROM employeesなどの全表スキャンを実行するには、図15-5に示すように、1つのサーバー・プロセスですべての処理が実行されます。

図15-5 シリアルの全表スキャン

図15-5の説明が続きます
「図15-5 シリアルの全表スキャン」の説明

パラレル実行では、データ・ウェアハウスなどの大規模データベースでの、データ処理集中型の操作におけるレスポンス時間が短縮されます。対称型マルチプロセッサ(SMP)およびクラスタ化されたシステムでは、文の処理を多数のCPUに分割できるため、パラレル実行によりパフォーマンスが大幅に改善されます。パラレル実行は、特定のタイプのOLTPおよびハイブリッド・システムにとっても利点があります。

Oracle RACシステムでは、特定のサービスのサービス配置によってパラレル実行が制御されます。つまり、パラレル・プロセスはサービスが構成されているノードで実行されます。デフォルトでは、Oracle Databaseは、データベースへの接続に使用されるサービスを提供するインスタンスでのみパラレル・プロセスを実行します。これは、パラレル・リカバリやGV$問合せの処理などの他のパラレル操作には影響しません。

関連項目:

問合せコーディネータ

パラレル実行において、サーバー・プロセスは問合せコーディネータとして動作します(パラレル実行コーディネータとも呼ばれます)。

問合せコーディネータの役割は次のとおりです。

  1. 問合せの解析

  2. パラレル実行サーバー・プロセスの割当てと制御

  3. ユーザーへの出力の送信

問合せの問合せ計画では、まずコーディネータがSQL問合せ内の各演算子をパラレル・ピースに分割し、それらを問合せで指定した順序に従って実行してから、演算子を実行するパラレル実行サーバーによって生成された部分的な結果を統合します。

1つの操作に割り当てられたパラレル実行サーバーの数が、その操作の並列度となります。同じSQL文中の複数の操作の並列度は、すべて同じです。

プロデューサとコンシューマ

パラレル実行サーバーは、プロデューサとコンシューマに分かれます。プロデューサはデータを処理し、それを必要とするコンシューマに配布します。

データベースは、様々なテクニックを使用して配布を実行できます。一般的な方法として、ブロードキャストとハッシュの2つがあります。ブロードキャストでは、各プロデューサがすべてのコンシューマに行を送信します。ハッシュでは、データベースが一連のキーに対するハッシュ関数を計算し、各コンシューマにハッシュ値のサブセットを担当させます。

図15-6は、次の文のパラレル実行でのプロデューサとコンシューマの相互作用を表しています。

SELECT * FROM employees ORDER BY last_name;

実行計画により、employees表の全体スキャンが実装されます。スキャンの後に、取得された行のソートが続きます。また、スキャン操作に関係するすべてのプロデューサ・プロセスが、ソートを実行する適切なコンシューマ・プロセスに行を送信します。

図15-6 プロデューサとコンシューマ

図15-6の説明が続きます
図15-6「プロデューサとコンシューマ」の説明
グラニュル

パラレル実行では、表は動的にロード単位に分割されます。各単位はグラニュルと呼ばれ、データにアクセスする際の最小の作業単位です。

ブロックに基づくグラニュルは、1つのパラレル実行サーバー(PXサーバー)によって読み取られる表のデータ・ブロックの範囲です(このサーバーは名前の形式としてPnnnを使用します)。パラレル・サーバー・プロセス間で作業を均等に分散するには、グラニュル数が常にリクエストDOPよりもかなり多くなります。

図15-7に、employees表のパラレル・スキャンを示します。

図15-7 パラレルの全表スキャン

図15-7の説明が続きます
「図15-7 パラレルの全表スキャン」の説明

データベースでは、実行時にグラニュルをパラレル実行サーバーにマップします。パラレル実行サーバーがグラニュルに対応する行の読取りを終了したとき、グラニュルがまだ残っている場合、問合せコーディネータから他のグラニュルを取得します。この操作は、表全体が読み取られるまで続行されます。実行サーバーは結果をコーディネータに送り返し、それぞれの結果が組み立てられて、最終的な全表スキャンになります。

関連項目: