オラクルのインスタンスとは

オラクルは大きく分けるとユーザー・プロセスサーバー・プロセスオラクル・サーバーその他のファイル で構成されており、その中のオラクル・サーバーは、インスタンスオラクル・データベースの 2 つで構成されている。

ユーザー・プロセス

SQL*Plus や Webアプリケーション など

サーバー・プロセス

サーバー・プロセスは、オラクル・サーバーと独立した関係になっている。 専用サーバーと共有サーバー(MTS:マルチスレッドサーバー)の2つの種類がある。(並行利用も可能)

専用サーバー

ユーザー・プロセス と インスタンスを接続するためのプロセスで構成がシンプルのため高速

  • ORACLE<SID> (専用サーバー)
      プロセス名: ORACLE<SID>(〜LOCAL={YES|NO}〜) YES=LOCAL, NO=Net Service 経由

    1接続毎に1プロセスを生成する。(Windowsはスレッドらしい)

応答性について
クエリリクエストは、経路がシンプルであるため高速に処理される。
ユーザープロセス(要求) ⇒ 専用サーバープロセス ⇒ ユーザープロセス(応答)
使用メモリについて
1接続毎に最低20M*1〜程度の確保する必要がある。(Linux)
アプリケーションコネクションプールを活用する。
(注意) SORT_AREA は PGA (サーバープロセス)に配置される
適応する環境は・・
高速な動作が求められるバッチ処理、コネクションプールと同時接続数を制限したWeb経由のシステム向けにあうサーバー構成といえる。

共有サーバー(MTS:マルチスレッドサーバー)

ユーザー・プロセス と インスタンスを接続するためのプロセス。 複数の接続を1つの共有サーバーで取り扱う事ができるため、少数の共有サーバー数で大量の接続を取り扱うことができる。

  • Snnn(共有サーバー)
      プロセス名: ORA_Snnn_<SID>

    ディスパッチャの要求キューを実際に処理する。(複数のセッションからの要求を処理する)

  • Dnnn(ディスパッチャ)
      プロセス名: ORA_Dnnn_<SID>

    共有サーバー構成時にユーザープロセスとのやり取りの窓口処理をする。(空いている共有サーバーに導いたりセッション管理を行なう)
    もしかするとディスパッチャは、サーバープロセスとも、一線を画した(リスナーのような)位置付けかもしれない。 (共有サーバーとディスパッチャが揃っていないと専用サーバーと同等にならないため、サーバープロセスの一部と判断)
    ちなみに リスナー は Net Service のプロセスで SID から独立したプログラム(プロセス)。SID との接続は listener.ora 設定ファイル経由で行なう。

応答性について
クエリリクエストはディスパッチャ経由で処理を振り分けする機能がある分、余計に時間を消費する。
ユーザープロセス(要求) ⇒ ディスパッチャ ⇒ リクエストキュー ⇒
共有サーバー ⇒ レスポンスキュー ⇒ ディスパッチャ ⇒ ユーザープロセス(応答)
使用メモリについて
複数接続で共有サーバーを使用するため SORT_AREAは SGA に配置される。
適応する環境は・・
大量の接続だが、短いクエリリクエストに比較的アイドルタイムが多いOLTP(特にクライアント・サーバー型)処理向けにあうサーバー構成といえる。

オラクル・サーバー (インスタンス)

オラクル・サーバーは、インスタンスオラクル・データベースの 2 つから構成されている。

インスタンス

オラクル・インスタンスはSGA (システム・グローバル領域)と バックグラウンド・プロセスとで構成されている。

SGA (メモリ)

  • 共有プール
  • ラージ・プール
  • データベース・バッファ・キャッシュ

    読み書きしたデータなどを保存しておくキャッシュ

  • REDO ログ・バッファ・キャッシュ

バックグラウンド・プロセス(その1)

  • PMON(プロセスモニタ)
      プロセス名: ORA_PMON_<SID>

    ユーザープロセスの障害時に ロールバック、リソース解放を行なう。
    ディスパッチャとサーバープロセスを監視し、障害がある場合 プロセスの再起動を行なう。

  • DBWn(データベース・ライタ)
      プロセス名: ORA_DBWn_<SID>

    複数プロセスで処理させることが可能(n=[0..9][a..j])
    データベース・バッファ・キャッシュの変更されたブロックをデータファイルに書き込む。
    実際の書き込みは効率的に処理するために延期される(=高速コミット、チェックポイント))
    ⇒ 遅延書き込み、マルチブロック書き込み、非同期書き込みを使用する。
    最大 20プロセス、関連初期パラメータ DB_WRITER_PROCESSES
    注意 単一CPUでは複数プロセスの構成にしても効果はない(マルチコアについては、わかりません)

  • LGWR(ログ・ライタ)

    REDOバッファより生成された、REDOエントリをオンラインREDOファイルに書き込む
      プロセス名: ORA_LGWR_<SID> DBWnと異なり、REDOエントリは常に空き領域を作り出すために高速に書き出される。
    耐障害性重視のため、極小単位の書き込み(OS-ブロックサイズ)、シーケンス書き込み、同期書き込みを使用している。
    DBWn と異なり、REDOログ書き込みはシリアライズ化(シーケンス書き込み)される。
    通常は、1COMMIT(トランザクション)、1書き込みとなる。しかし、大量のREDOログエントリがされると、 複数のトランザクションが書き込み待機中となり、書き込み終了待ち状態になる。
    このとき、これらのトランザクション群を1つのトランザクションとして1書き込みで取り扱うことがある。(=グループコミット)

  • CKPT(チェックポイント)
      プロセス名: ORA_CKPT_<SID>

    チェックポイント処理は、負荷の高い処理のため専用にプロセスが用意される。
    以前はオプションのプロセス

  • RECO(リカバラ)
      プロセス名: ORA_RECO_<SID>

    分散データベースにおける、ネットワーク障害などによる未解決のトランザクション(インダウト・トランザクション)を解決しようとする。
    (一定間隔でリモートデータベースに接続し、トランザクションを コミット、または、ロールバック しようとする)
    9i から、このプロセスを起動しないようにする初期化パラメータは廃止されている。
    シングルインスタンスが、この機能を使用する場合には、'ALTER SYSTEM ENABLE DISTRIBUTED RECOVERY; ' を宣言する必要がある。との記述があるため、初期値は DISABLE と思われる。
    現在の状態の確認方法については不明、また使用しないつもりであっても、このプロセスを起動させないパラメータも不明
    (初期化パラメータ OPEN_LINKS=0 でも効果がなかった)

バックグラウンド・プロセス(その2)

  • CJQn(ジョブキュー・コーディネータ)
      プロセス名: ORA_CJQn_<SID>

    スケジューラサービスを実行する。Jnnn プロセスを生成して並列実行を行なうことができる。

関連初期パラメータ
JOB_QUEUE_PROCESSES
  • Jnnn(ジョブキュー・スレーブ)
      プロセス名: ORA_Jnnn_<SID>

    CJQnにより起動され、ジョブを実行する。(J000..J999)

  • QMNn(キュー・モニタ)
      プロセス名: ORA_QMNn_<SID>

    AQ(アドバンスド・キュー)のメッセージ・キューを監視する。(QMN0..QMN9)

  • QMNC(キュー・モニタ・コーディネータ) Oracle 10g
      プロセス名: ORA_QMNC_<SID>

    キュー・モニタのコーディネータ、スレーブモデル

  • Qnnn(キュー・スレーブ)
      プロセス名: ORA_Qnnn_<SID>

    QMNCにより起動され処理を行なう

  • Innn

    DBW0 の スレーブプロセス(パラメータ設定ではそのように見える、マニュアルには記載が見あたらない) (I101..I09)(I201..I209) ??

関連初期パラメータ
DBWR_IO_SLAVES(DB_WRITER_PROCESSESとは排他関係)
  • MMON(マネージメント・モニタ)
      プロセス名: ORA_MMON_<SID>

    管理性に関連する様々なバックグラウンド・タスクを実行する。
    統計情報、AWR のスナップショットの取得やあるメトリック(※)がしきい値を超えた場合のアラート通知処理を行なう。

    (※) メトリックとは統計情報、および、それを管理しやすく時系列で集計などを施した指標のことである。
    例えば表領域のメトリックとして表領域の使用率が指定値を超えると警告、さらに別の指定値を超えるとクリティカルなアラートとして検知することができる。

  • MMNL
      プロセス名: ORA_MMNL_<SID>

    管理性に関連する軽量のバックグラウンド・タスクを頻繁に実行する。

  • MMAN
      プロセス名: ORA_MMAN_<SID>

    データベースの内部的なタスクの実行

  • RBAL

    Automatic Storage Managementに関するタスクの実行(略)

  • ORBn

    Automatic Storage Managementにエクステントなどに関するタスクの実行(略)

  • OSMB

    Automatic Storage Management インスタンスとの通信(略)

オラクル・サーバー (オラクルデータベース)

オラクルデータベース は、記憶領域(通常はハードディスク)に保存されている。
各保存先は、データベースの削除 を参照のこと

オラクルデータベース

以下の 3つ のファイルをもって、オラクルデータベース と呼ばれる。

  • データファイル

    OSのファイルシステムによって管理されたファイルまたは、RAWファイル(デバイス)

    • すべてのデータベース・データが保存される。
    • ファイルサイズを自動的に拡張することができる。
    • 1つ以上のデータファイルからテーブルスペースを形成する。
  • コントロール・ファイル

    データベースの構造情報を管理するファイル(以下のデータを管理している。らしい)

    • データベース名
    • データベースを作成したときのタイムスタンプ
    • 対応するデータファイルとREDO ログ・ファイルの名前と位置
    • 表領域情報
    • データファイルのオフライン範囲
    • ログ履歴
    • アーカイブログ情報
    • バックアップ・セットとバックアップ・ピースの情報
    • バックアップ・データファイルとREDO ログ情報
    • データファイルのコピーの情報
    • カレントのログ順序番号
    • チェックポイント 情報
  • REDOログ・ファイル

    データベース・データに加えられたすべての変更( NOLOGGING 除く)を時間順序で保存したファイル
    明示的なリカバリやSHUTDOWN ABORTなどでの自動的なリカバリ(クラッシュ・リカバリ、インスタンス・リカバリ)により稀に?使用される。

その他のファイル

オラクルデータベースと同様 ディスク媒体に保存されているが、位置付けは異なる。
起動に必須なパラメータ・ファイルやパスワードファイルがオラクルデータベースに含まれないのは不思議だが、それらはメモリ内に取り込まれているため、そのバックアップファイルと考えれば、ある程度自分を納得させることができる。
各保存先は、データベースの削除 を参照のこと

  • アーカイブログ・ファイル

    REDOログファイルは、REDOロググループ/メンバの組み合わせで循環形式で保存されている。
    この循環が一回りする間に、別の記憶領域にバックアップが作成される。(アーカイブログモード:アーカイバプロセスの仕事)
    (通常運用では利用されることは、ほとんどないことはない。ログマイナや障害時に使う)

    SQL*Plus> ARCHIVE LOG LIST
    -- 出力形式
    SQL> SELECT value FROM v$parameter WHERE  name = 'log_archive_format';
  • パラメータ・ファイル

    データベースの構成パラメータを記述する編集可能なテキストファイル
    SPFILEと呼ばれるサーバー・パラメータ・ファイルもある。(動的に変更できるパラメータが増えた)
    (SPFILEはデータベース上に取り込まれて管理されている。編集できないバイナリファイル)

    ALTER SYSTEM SET param=value SCOPE={BOTH|MEMORY|SPFILE} ~

    ALTER SYSTEM による初期化パラメータの変更

  • パスワード・ファイル

    パスワード認証で使用するファイル(バイナリファイル) orapwd コマンドにて作成する。
    インスタンス起動時に削除してはいけない。
    (インスタンスに情報を持っているためリモート接続で ORA-01031: 権限が不足しています。 が発生する)

  • アラート・ファイル / アラートログ

    障害があると、まず見るという重要なファイル(トレースファイルの親分的存在)
    bdump ディレクトリに ファイル名 : 'alert_<SID>.log' の 追記型のテキストファイル。対象が存在しない場合には自動的に再作成されるので削除しても再作成される。しかし、稼動中には移動、編集、削除操作はログの監視を行なっている場合に異常を検出したり、書き込み中の一部のログ内容を失う可能性がある。アラートログを操作する場合には一旦インスタンスを停止することお勧めする。

    bdump ディレクトリの位置 (デフォルト $ORACLE_BASE/admin/<SID>)
    以下のSQLで現在のディレクトリ位置を取得することができる。

    SELECT value FROM v$parameter WHERE  name = 'background_dump_dest';
  • トレース・ファイル

    サーバー・プロセス、バックグラウンド・プロセスから個別のファイルに出力される。 ログ情報以外にもプロセスに障害が検出されると自動的に出力される。
    bdump ディレクトリに ファイル名: '<SID>_processname_processid.trc' の 追記型のテキストファイル。

イメージ

oracle_server.png
 
 


関連事項

Oracle データベース概要 マニュアル Oracle 10g

  • 8 メモリ・アーキテクチャ
  • 9 プロセス・アーキテクチャ
    • Oracle プロセスの概要 近辺
  • 12 Oracle インスタンスの概要
    を読んで確認してください。
日本オラクル
■ 日本オラクル 株式会社
■ オラクルマスター資格 (オラクルマスターとは
■ Oracle Web セミナー

*1 デフォルト設定、起動時に約15MB使用している。40MB 位には膨れ上がる:PGA_AGGREGATE_TARGET 初期化パラメータにも影響される。
*2 PCTINCREASEが0の表領域は対象外