14 Oracleデータベース・インスタンス

この章では、Oracleデータベース・インスタンスの性質、インスタンスに関連付けられたパラメータ・ファイルと診断ファイル、およびインスタンスの作成時やデータベースのオープン時とクローズ時に発生する処理について説明します。

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

  • Oracleデータベース・インスタンスの概要
    データベース・インスタンスとは、データベース・ファイルを管理するメモリー構造の集合です。
  • データベース・インスタンスの起動と停止の概要
    データベース・インスタンスにより、ユーザーがデータベースにアクセスできるようになります。インスタンスおよびデータベースを様々な状態にすることができます。
  • チェックポイントの概要
    一般的に、チェックポイントは、一貫性のあるデータベース停止、インスタンス・リカバリおよびOracle Database操作に不可欠なメカニズムです。
  • インスタンス・リカバリの概要
    インスタンス・リカバリは、オンラインREDOログ内のレコードをデータファイルに適用して、最も新しいチェックポイントの後に実行された変更を再構築するプロセスです。
  • パラメータ・ファイルの概要
    データベース・インスタンスを起動するには、Oracle Databaseでサーバー・パラメータ・ファイル(推奨)またはテキスト形式の初期化パラメータ・ファイル(従来型の実装)を読み取る必要があります。これらのファイルには、構成パラメータのリストが格納されます。
  • 診断ファイルの概要
    Oracle Databaseには、データベースに関する問題を防止、検出、診断および解決するための障害診断インフラストラクチャが含まれています。問題には、コードの不具合、メタデータの破損、顧客データの破損などの重大なエラーがあります。

親トピック: Oracleインスタンス・アーキテクチャ

Oracleデータベース・インスタンスの概要

データベース・インスタンスは、データベース・ファイルを管理する一連のメモリー構造です。

物理レベルでは、CDBはCREATE DATABASE文によって作成されたディスク上のファイルのセットです。CDBには、ユーザーが作成した1つ以上のPDBが含まれています。PDBには、CDBに属するデータ・ファイルの全体的なセット内に、独自のデータ・ファイルのセットが含まれています。データベース・インスタンスは、CDBとそのPDBに関連付けられたデータを管理し、ユーザーに提供します。

稼働中のすべてのCDBは、1つ以上のOracleデータベース・インスタンスに関連付けられます。インスタンスはメモリー内に存在し、データベース(最も狭い意味で)はディスク上のファイルのセットであるため、インスタンスがデータベースなしで存在することも、データベースがインスタンスなしで存在することも可能です。

親トピック: Oracleデータベース・インスタンス

データベース・インスタンスの構造

インスタンスが起動されると、Oracle Databaseによってシステム・グローバル領域(SGA)と呼ばれるメモリー領域が割り当てられ、1つ以上のバックグラウンド・プロセスが起動されます。

SGAは、次のような様々な目的で機能します。

  • 多くのプロセスおよびスレッドから同時にアクセスされる内部データ構造の維持

  • ディスクから読み取られるデータ・ブロックのキャッシュ

  • オンラインREDOログ・ファイルに書き込まれる前のREDOデータのバッファリング

  • SQL実行計画の格納

1つのコンピュータで実行中の複数のOracleプロセスは、SGAを共有します。OracleプロセスがSGAと関連付けられる方法は、オペレーティング・システムによって異なります。

データベース・インスタンスにはバックグラウンド・プロセスが含まれています。サーバー・プロセスおよびサーバー・プロセスに割り当てられたプロセス・メモリーもインスタンスに存在します。サーバー・プロセスが終了しても、インスタンスは機能し続けます。

次の図に、Oracleデータベース・インスタンスの主要なコンポーネントを示します。

図14-1 データベース・インスタンス

図14-1の説明が続きます
「図14-1 データベース・インスタンス」の説明

関連項目:

親トピック: Oracleデータベース・インスタンスの概要

データベース・インスタンス構成

Oracle Databaseは、単一インスタンス構成またはOracle Real Application Clusters (Oracle RAC)構成のいずれかで実行されます。これらの構成は相互に排他的です。

単一インスタンス構成では、データベースとデータベース・インスタンスの間に1対1関係が存在します。Oracle RACでは、データベースとデータベース・インスタンスの間に1対多関係が存在します。

次の図に、可能なデータベース・インスタンス構成を示します。

図14-2 データベース・インスタンス構成

図14-2の説明が続きます
「図14-2 データベース・インスタンス構成」の説明

単一インスタンス構成とOracle RAC構成のどちらでも、1つのデータベース・インスタンスは一度に1つのデータベースにのみ関連付けられます。データベース・インスタンスを起動して1つのデータベースをマウント(インスタンスに関連付け)できますが、2つのデータベースを同じインスタンスに同時にマウントすることはできません。

ノート:

この章では、特に記載のないかぎり単一インスタンス・データベース構成について説明します。

複数のインスタンスを同時に同じコンピュータ上で実行し、それぞれ専用のデータベースにアクセスさせることができます。たとえば、1台のコンピュータで2つの異なるデータベースprod1とprod2をホストできます。1つのデータベース・インスタンスでprod1を管理し、別のインスタンスでprod2を管理します。

関連項目:

Oracle RACの詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照してください

親トピック: Oracleデータベース・インスタンスの概要

読取り/書込みインスタンスと読取り専用インスタンス

データベース・インスタンスはすべて、読取り/書込みまたは読取り専用のいずれかです。

読取り/書込みデータベース・インスタンス(デフォルト)はDMLの処理が可能で、クライアント・アプリケーションからの直接接続をサポートしています。これに対して、読取り専用データベース・インスタンスは問合せを処理できますが、変更DML (UPDATE、DELETE、INSERTおよびMERGE)や直接クライアント接続をサポートしません。

ノート:

このマニュアルで特記していないかぎり、データベース・インスタンスへの参照はすべて、読取り/書込みインスタンスが対象です。

前のリリースでは、(スタンバイ・データベースへのアクセスでないかぎり)すべてのデータベース・インスタンスが読取り/書込みでした。Oracle Database 12cリリース2 (12.2)以降では、読取り専用インスタンスと読取り/書込みインスタンスが単一のデータベース内で共存できます。この構成は、データの問合せおよび変更の両方を行うパラレルSQL文に役立ちます。読取り/書込みインスタンスと読取り専用インスタンスは両方とも問合せを行う一方、読取り/書込みインスタンスは変更も行うためです。

読取り/書込みインスタンスと異なり、読取り専用インスタンスには次の特性があります。

  • 読取り/書込みインスタンスによってすでに開かれているデータベースのみを開きます

  • チェックポイントおよびアーカイバ・プロセスも含めて、多数の不要なバックグラウンド・プロセスを無効化します

  • 無効化されたREDOスレッド、またはオンラインREDOログのないスレッドをマウントできます

インスタンスを読取り専用として指定するには、INSTANCE_MODE初期化パラメータをREAD_ONLYに設定します。パラメータのデフォルト値はREAD_WRITEです。

関連項目:

親トピック: Oracleデータベース・インスタンスの概要

データベース・インスタンスの継続時間

データベース・インスタンスは、STARTUPコマンドを使用して作成されたときに開始し、終了されたときに終了します。

この期間中、データベース・インスタンスはそのインスタンス自体を1つのデータベースにのみ関連付けることができます。さらに、そのインスタンスでは、データベースのマウント、クローズおよびオープンをそれぞれ1回のみ実行できます。データベースがクローズまたは停止された後、このデータベースをマウントしてオープンするには、別のインスタンスを起動する必要があります。

次の表に、以前にクローズされたデータベースの再オープンを試行するデータベース・インスタンスを示します。

表14-1 インスタンスの存続期間

文 説明 
SQL> STARTUP
ORACLE instance started.
 
Total System Global Area  468729856 bytes
Fixed Size                  1333556 bytes
Variable Size             440403660 bytes
Database Buffers           16777216 bytes
Redo Buffers               10215424 bytes
Database mounted.
Database opened.

STARTUPコマンドによってインスタンスが作成されます。これにより、データベースがマウントおよびオープンされます。 

SQL> SELECT 
TO_CHAR(STARTUP_TIME,'MON-DD-RR HH24:MI:SS') 
AS "Inst Start Time" FROM V$INSTANCE;
 
Inst Start Time
------------------
JUN-18-14 13:14:48

この問合せによって、現在のインスタンスが起動された時刻が表示されます。

 
SQL> SHUTDOWN IMMEDIATE

インスタンスはデータベースをクローズして停止し、そのインスタンスの存続期間は終了します。

 
SQL> STARTUP
Oracle instance started.
. . .

STARTUPコマンドによって新しいインスタンスが作成され、データベースがマウントおよびオープンされます。 

SQL> SELECT 
TO_CHAR(STARTUP_TIME, 'MON-DD-RR HH24:MI:SS')
AS "Inst Start Time" FROM V$INSTANCE;
 
Inst Start Time
------------------
JUN-18-14 13:16:40

この問合せによって、現在のインスタンスが起動された時刻が表示されます。起動時刻が異なるため、このインスタンスがデータベースを停止したインスタンスと異なることがわかります。

親トピック: Oracleデータベース・インスタンスの概要

データベース・インスタンスの識別

複数のデータベース・インスタンスを単一のホストに配置できます。このため、アクセスするインスタンスをなんらかの方法で指定する必要があります。

Oracle Optimal Flexible Architecture (OFA)のルールは、Oracleインストールを適切に体系化するために作成された一連の構成ガイドラインです。この項の例では、OFAアーキテクチャを前提としています。

この項では、次の項目について説明します。

関連項目:

OFAの概要については、Oracle Database インストレーション・ガイド for Linuxを参照してください

親トピック: Oracleデータベース・インスタンスの概要

Oracleベース・ディレクトリ

Oracleベース・ディレクトリには、Oracle製品のバイナリが格納されます。

Oracleベース・ディレクトリは、Oracle Databaseインストール所有者のデータベース・ホーム・ディレクトリです。ホスト上には多数のOracle Databaseインストールおよび多数のOracle Databaseソフトウェア・インストール所有者が存在する可能性があります。

次の例では、オペレーティング・システムのユーザー・アカウントoracleのOracleベース・ディレクトリを示しています。 

/u01/app/oracle

上記のパスでは、/u01/がマウント・ポイントであり、/u01/app/がアプリケーション・ソフトウェアのサブツリーです。

関連項目:

Oracleベースの概要については、Oracle Database インストレーション・ガイド for Linuxを参照してください

親トピック: データベース・インスタンスの識別

Oracleホーム・ディレクトリ

Oracleホームは、Oracleデータベースのソフトウェアがある場所です。

Oracle Databaseソフトウェアを新しくインストールするたびに、新しいOracleホーム・ディレクトリを指定する必要があります。デフォルトでは、Oracleホーム・ディレクトリはOracleベース(ORACLE_BASE)ディレクトリ・ツリーの子孫です。

Oracleホーム・ディレクトリが異なれば、このリリース以前のデータベース・ソフトウェアを、同じホストの単一Oracleベース内に複数回インストールできます。異なるバージョンの、異なるユーザー・アカウントが所有する複数のデータベースが同時に共存できます。

次の例は、同じOracleベース・ディレクトリ(/u01/app/oracle/)内にある、3つの異なるOracleホームのフルパス名を示しています。 

/u01/app/oracle/product/12.1.0/dbhome_1
/u01/app/oracle/product/12.1.0/dbhome_2
/u01/app/oracle/product/18.0.0/dbhome_1

Oracleベース(/u01/app/oracle/)の後のパス名の一部には、製品リリース番号(たとえば、12.1.0)およびOracleホームの相対ディレクトリ(たとえば、dbhome_1)が含まれています。/u01/app/oracle/product/12.1.0/ディレクトリには2個の個別のOracleホーム、dbhome_1とdbhome_2が含まれています。

Oracle Database 18c以降では、ソフトウェア・イメージとして読取り専用のOracleホームを作成できます。読取り専用Oracleホームにはバイナリなどの静的ファイルが格納されます。ORACLE_BASE/homes/home_nameにあるOracleベース・ホーム(ORACLE_BASE_HOME)ディレクトリには、Oracleホームに固有の動的ファイルが格納されます。OracleベースのすべてのOracleホームによって共有されるOracleベース構成ディレクトリ(ORACLE_BASE_CONFIG)には、インスタンス固有の動的ファイルが格納されます。

次の例では、最初のパスは読取り専用のOracleホーム、2番目のパスはこのOracleホームのOracleベース・ホームです。

/u01/app/oracle/product/18.0.0/ro_dbhome_1
/u01/app/oracle/homes/ro_dbhome_1

関連項目:

Oracleホームの概要については、Oracle Database インストレーション・ガイド for Linuxを参照してください

親トピック: データベース・インスタンスの識別

Oracleシステム識別子(SID)

システム識別子(SID)とは、特定のホスト上でOracleデータベース・インスタンスを示す一意の名前です。

UNIXおよびLinuxでは、Oracle DatabaseはSIDとOracleホームの値を使用して共有メモリーに対するキーを作成します。また、Oracle DatabaseはデフォルトでSIDを使用して初期化パラメータ・ファイルを検索し、これによってデータベース制御ファイルなどの関連ファイルが検索されます。

ほとんどのプラットフォームでは、ORACLE_SID環境変数によってSIDが設定され、ORACLE_HOME変数によってOracleホームが設定されます。データベース・インスタンスへの接続時に、クライアントはOracle Net接続のSIDを指定するか、ネット・サービス名を使用できます。サービス名は、Oracle DatabaseによってORACLE_HOMEとORACLE_SIDに変換されます。

従来の読取り/書込みOracleホームには、インスタンス固有のファイルが含まれています。ただし、Oracleホームが読取り専用の場合、インスタンス固有のファイルがOracleベースに別個に格納されます。どちらの場合も、名前にSIDが含まれているファイルは、Oracleベース構成ディレクトリ(ORACLE_BASE_CONFIG)のdbsサブディレクトリに格納されます。このように分離することで、ユーザーは既存の読取り専用Oracleホームのソフトウェアを使用してデータベースを作成し、新しい読取り専用のOracleホームのソフトウェアを使用してそのデータベースのインスタンスを起動します。

関連項目:

親トピック: データベース・インスタンスの識別

データベース・インスタンスの起動と停止の概要

データベース・インスタンスにより、ユーザーはデータベースにアクセスできます。インスタンスおよびデータベースを様々な状態にすることができます。

  • インスタンスとデータベースの起動の概要
    通常は、手動でインスタンスを起動してから、データベースをマウントおよびオープンし、それをユーザーが使用できるようにします。SQL*Plus STARTUPコマンド、Oracle Enterprise Manager(Enterprise Manager)またはSRVCTLユーティリティを使用して、これらのステップを実行できます。
  • データベースとインスタンスの停止の概要
    一般的なユースケースでは、手動でデータベースを停止し、メンテナンスや他の管理作業を実行する間は、それをユーザーが使用できないようにします。SQL*Plus SHUTDOWNコマンドまたはEnterprise Managerを使用して、これらのステップを実行できます。

親トピック: Oracleデータベース・インスタンス

インスタンスとデータベースの起動の概要

通常、手動でインスタンスを起動してから、データベースをマウントおよびオープンし、ユーザーが使用できるようにします。SQL*Plus STARTUPコマンド、Oracle Enterprise Manager(Enterprise Manager)またはSRVCTLユーティリティを使用して、これらのステップを実行できます。

Oracle Netを使用してデータベース・インスタンスを起動するには、次の条件が満たされている必要があります。

  • データベースが静的にOracle Netリスナーに登録されていること。

  • 使用クライアントが、SYSDBA権限によりデータベースに接続されていること。

リスナーでは、専用サーバーが作成され、これによりデータベース・インスタンスを起動できます。

次の図に、データベースの停止状態からオープン状態までの経過を示します。

図14-3 インスタンスとデータベースの起動順序

図14-3の説明が続きます
「図14-3 インスタンスとデータベースの起動順序」の説明

データベースが停止状態からオープン状態になるとき、次のフェーズを経由します。

表14-2 インスタンスの起動のステップ

フェーズ マウント状態 説明 さらに学習するには
1

データベースにマウントせずにインスタンスを起動

インスタンスは起動されますが、まだデータベースと関連付けられていません。

「インスタンスの起動方法」
2

データベースのマウント

インスタンスが起動され、データベースの制御ファイルを読み取ってデータベースと関連付けられます。データベースは、ユーザーに対してクローズされています。

「データベースのマウント方法」
3

データベースのオープン

インスタンスが起動され、オープン状態のデータベースと関連付けられます。データファイルに含まれるデータは、許可されたユーザーからアクセス可能になります。

「データベースのオープン方法」
  • 管理者権限での接続
    データベースの起動と停止は、管理者権限を使用してOracle Databaseに接続するユーザーのみが実行できる、影響の大きい管理オプションです。
  • インスタンスの起動方法
    Oracle Databaseによってインスタンスが起動されるときは、段階的に進行されます。
  • データベースのマウント方法
    インスタンスによってデータベースがマウントされてそのデータベースがこのインスタンスに対応付けられます。
  • データベースのオープン方法
    マウントされたデータベースをオープンすると、そのデータベースで通常のデータベース操作を実行できるようになります。

関連項目:

親トピック: データベース・インスタンスの起動と停止の概要

管理者権限での接続

データベースの起動と停止は、管理者権限を使用してOracle Databaseに接続するユーザーのみが実行できる強力な管理オプションです。

一般のユーザーは、Oracleデータベースの現在の状態を制御できません。ユーザーの管理者権限を確立するには、オペレーティング・システムに応じて、次のいずれかの条件が必要です。

  • ユーザーのオペレーティング・システム権限により、そのユーザーが管理者権限を使用して接続できること。

  • ユーザーが特別なシステム権限を付与されており、データベースがパスワード・ファイルを使用し、ネットワークを介してデータベース管理者を認証していること。

次の特別なシステム権限により、データベースがオープンされていなくても、データベースにアクセスできます。

  • SYSDBA

  • SYSOPER

  • SYSBACKUP

  • SYSDG

  • SYSKM

前述の権限の制御は、データベース機能の範囲外にあります。SYSDBAシステム権限でデータベースに接続すると、そのユーザーはSYSが所有しているスキーマ内に置かれます。SYSOPERとして接続すると、そのユーザーはパブリック・スキーマ内に置かれます。SYSOPER権限は、SYSDBA権限のサブセットです。

関連項目:

親トピック: インスタンスとデータベースの起動の概要

インスタンスの起動方法

Oracle Databaseがインスタンスを起動する場合、段階的に行われます。

次のようなステージがあります。

  1. プラットフォーム固有のデフォルトの格納場所でサーバー・パラメータ・ファイルを検索します。見つからなかった場合は、テキスト形式の初期化パラメータ・ファイルを検索します(STARTUPにSPFILEまたはPFILEパラメータを指定すると、デフォルトの動作が上書きされます)。

  2. パラメータ・ファイルを読み取り、初期化パラメータの値を決定します。

  3. 初期化パラメータの設定に基づいてSGAを割り当てます。

  4. Oracleバックグラウンド・プロセスを起動します。

  5. アラート・ログとトレース・ファイルをオープンし、明示的に設定されたすべてのパラメータ設定をパラメータの有効な構文でアラート・ログに書き込みます。

この時点では、このインスタンスにデータベースは関連付けられていません。NOMOUNT状態が必要とされるシナリオには、データベースの作成および特定のバックアップ操作とリカバリ操作があります。

関連項目:

サーバー・パラメータ・ファイルを使用した初期化パラメータの管理方法を学習するには、『Oracle Database管理者ガイド』を参照してください

親トピック: インスタンスとデータベースの起動の概要

データベースのマウント方法

インスタンスは、データベースをマウントして、データベースをそのインスタンスに対応付けます。

データベースをマウントすると、そのインスタンスはCONTROL_FILES初期化パラメータに指定されたデータベース制御ファイルの名前を取得し、これらのファイルをオープンします。Oracle Databaseでは、制御ファイルを読み取ることによって、データベースのオープン時にアクセスを試行するデータファイルとオンラインREDOログ・ファイルの名前を検出します。

マウントされたデータベースでは、データベースはクローズされているため、データベース管理者のみがそのデータベースにアクセスできます。管理者は、特定のメンテナンス操作を完了するまでの間、データベースをクローズしたままにしておくことができます。ただし、データベースに対して通常の操作を行うことはできません。

Oracle Databaseで、複数のインスタンスによる同じデータベースの同時マウントが許可されている場合、CLUSTER_DATABASE初期化パラメータの設定で、複数のインスタンスによるデータベースの使用を可能にできます。データベースの動作は、設定によって異なります。

  • データベースをマウントする最初のインスタンスのCLUSTER_DATABASEパラメータがfalse(デフォルト)の場合は、最初のインスタンスのみがデータベースをマウントできます。

  • このCLUSTER_DATABASEパラメータがtrueの場合は、他のインスタンスもCLUSTER_DATABASEパラメータの設定がtrueに設定されている状態でデータベースをマウントできます。データベースをマウントできるインスタンスの数は、データベースの作成時に指定された最大数によって決まります。

関連項目:

親トピック: インスタンスとデータベースの起動の概要

データベースのオープン方法

マウントされたデータベースをオープンすると、そのデータベースで通常のデータベース操作を実行できるようになります。

有効なユーザーは、オープン状態のデータベースに接続して、データベースの情報にアクセスできます。通常、データベース管理者は、データベースをオープンして一般に使用できる状態にします。

データベースをオープンするときに、Oracle Databaseでは次のアクションを自動的に実行します。

  • UNDO表領域以外の表領域でオンライン・データファイルをオープンします。

    データベースを前回停止したときに表領域がオフラインであった場合は、データベースを再オープンしたとき、その表領域と対応するデータファイルはオフラインのままです。

  • UNDO表領域を取得します。

    複数のUNDO表領域が存在する場合には、使用するUNDO表領域をUNDO_TABLESPACE初期化パラメータで指定できます。このパラメータが設定されていない場合、使用可能な最初のUNDO表領域が選択されます。

  • オンラインREDOログ・ファイルをオープンします。

  • 読取り専用モード
    デフォルトでは、データベースは読取り/書込みモードでオープンされます。このモードでは、ユーザーがデータを変更し、オンラインREDOログにREDOを生成できます。また、読取り専用モードでオープンすると、ユーザー・トランザクションによってデータが変更されるのを防ぐことができます。
  • データベース・ファイルのチェック
    インスタンスによってデータベースがオープンされるときに、データファイルまたはREDOログ・ファイルが存在しない場合、またはこれらのファイルが存在はするが一貫性テストで不合格だった場合は、データベースによってエラーが返されます。メディア・リカバリが必要な場合があります。

関連項目:

親トピック: インスタンスとデータベースの起動の概要

読取り専用モード

デフォルトでは、データベースは読取り/書込みモードでオープンします。このモードでは、ユーザーがデータを変更し、オンラインREDOログにREDOを生成できます。また、読取り専用モードでオープンすると、ユーザー・トランザクションによってデータが変更されるのを防ぐことができます。

ノート:

デフォルトでは、フィジカル・スタンバイ・データベースは読取り専用モードでオープンします。

読取り専用モードでは、データベース・アクセスは読取り専用トランザクションに限定され、データファイルやオンラインREDOログ・ファイルに書き込むことはできません。ただし、データベースではリカバリや、REDOを生成しないでデータベースの状態を変更する操作を実行できます。たとえば、読取り専用モードでは、次の操作を実行できます。

  • データファイルのオフラインとオンラインを切り替えることができます。ただし、永続表領域はオフライン化できません。

  • オフラインのデータファイルと表領域をリカバリできます。

  • 制御ファイルは、データベースの状態の更新に引き続き使用できます。

  • CREATE TEMPORARY TABLESPACE文を使用して作成された一時表領域は、読取り/書込み可能です。

  • オペレーティング・システムの監査証跡、トレース・ファイルおよびアラート・ログへの書込みは引き続き実行できます。

関連項目:

親トピック: データベースのオープン方法

データベース・ファイルのチェック

インスタンスがデータベースをオープンするとき、データファイルまたはREDOログ・ファイルが存在しない場合、またはこれらのファイルは存在するが、一貫性テストに失敗した場合は、データベースからエラーが戻されます。メディア・リカバリが必要な場合があります。

データベースとインスタンスの停止の概要

通常のユースケースでは、手動でデータベースを停止し、メンテナンスや他の管理作業の実行中にユーザーがデータベースを使用できないようにします。SQL*Plus SHUTDOWNコマンドまたはEnterprise Managerを使用して、これらのステップを実行できます。

次の図に、オープン状態から一貫性のある停止状態までの経過を示します。

図14-4 インスタンスとデータベースの停止順序

図14-4の説明が続きます
「図14-4 インスタンスとデータベースの停止順序」の説明

オープン状態のデータベースが一貫性のある状態で停止されるときは、Oracle Databaseが次のステップを自動的に実行します。

表14-3 一貫性のある停止のステップ

フェーズ マウント状態 説明 さらに学習するには
1

データベースのクローズ

データベースはマウントされていますが、オンライン・データファイルとREDOログ・ファイルはクローズされます。

 「データベースのクローズ方法」
2

データベースのアンマウント

インスタンスは起動状態にありますが、データベースの制御ファイルとの関連付けは解消されます。

「データベースのアンマウント方法」
3

データベース・インスタンスの停止

データベース・インスタンスは起動状態にありません。

 「インスタンスの停止方法」

インスタンス障害やSHUTDOWN ABORTの場合、Oracle Databaseは前述のステップのすべてを実行せず、インスタンスを即時に終了します。

  • 停止モード
    SYSDBAまたはSYSOPER権限があるデータベース管理者は、SQL*PlusのSHUTDOWNコマンドまたはEnterprise Managerを使用してデータベースを停止できます。SHUTDOWNコマンドには、停止動作を指定するオプションがあります。
  • データベースのクローズ方法
    データベースのクローズ操作は、データベース停止時に暗黙的に実行されます。この操作の性質は、データベースが正常停止されたか、異常停止されたかによって異なります。
  • データベースのアンマウント方法
    データベースがクローズされると、Oracle Databaseによってそのデータベースがアンマウントされてインスタンスから切り離されます。
  • インスタンスの停止方法
    データベース停止の最後のステップは、インスタンスの停止です。データベース・インスタンスが停止すると、SGAではメモリーの占有を中止し、バックグラウンド・プロセスが終了します。

関連項目:

データベースの停止方法を学習するには、Oracle Database管理者ガイドを参照してください

親トピック: データベース・インスタンスの起動と停止の概要

停止モード

SYSDBAまたはSYSOPER権限を持つデータベース管理者は、SQL*PlusのSHUTDOWNコマンドまたはEnterprise Managerを使用してデータベースを停止できます。SHUTDOWNコマンドには、停止動作を指定するオプションがあります。

次の表に、様々な停止モードの動作の概要を示します。

表14-4 データベース停止モード

データベースの動作 ABORT IMMEDIATE TRANSACTIONAL NORMAL

新しいユーザー接続を許可

いいえ

いいえ

いいえ

いいえ

現行セッションが終了するまで待機

いいえ

いいえ

いいえ

はい

現行トランザクションが終了するまで待機

いいえ

いいえ

はい

はい

チェックポイントを実行し、オープン状態のファイルをクローズ

いいえ

はい

はい

はい

使用可能なSHUTDOWN文は、次のとおりです。

  • SHUTDOWN ABORT

    このモードは、他の停止方法が機能しない場合などの非常時のために用意されています。これは最速の停止モードです。ただし、停止後にこのデータベースをオープンする際に、データファイルの整合性を保つためにインスタンス・リカバリを実行する必要があるため、非常に長い時間がかかる場合があります。

    SHUTDOWN ABORTでは、オープン状態のデータファイルのチェックポイントが実行されないため、データベースを再オープンする前にインスタンス・リカバリが必要です。その他の停止モードでは、データベースを再オープンする前にインスタンス・リカバリを実行する必要はありません。

    ノート:

    CDBでは、PDBに対してSHUTDOWN ABORTを発行することは、非CDBに対してSHUTDOWN IMMEDIATEを発行することと同じです。

  • SHUTDOWN IMMEDIATE

    通常は、SHUTDOWN ABORTの次に速い停止モードです。Oracle Databaseは、実行中のSQL文をすべて終了し、ユーザーとの接続を切断します。アクティブなトランザクションは終了され、コミットされていない変更はロールバックされます。

  • SHUTDOWN TRANSACTIONAL

    このモードでは、ユーザーが新しいトランザクションを開始することはできませんが、すべての現行トランザクションが完了するまで待機してから停止します。現行トランザクションの性質によっては、停止までにかなりの時間がかかる場合があります。

  • SHUTDOWN NORMAL

    これはデフォルトの停止モードです。データベースは、接続されたすべてのユーザーの接続が解除されるまで待機してから停止します。

関連項目:

親トピック: データベースとインスタンスの停止の概要

データベースのクローズ方法

データベースのクローズ操作は、データベース停止時に暗黙的に実行されます。この操作の性質は、データベースが正常停止されたか、異常停止されたかによって異なります。

  • 正常停止時のデータベースのクローズ方法
    ABORT以外のオプションが指定されたSHUTDOWNの一環としてデータベースがクローズされると、Oracle DatabaseによってSGA内のデータがデータファイルとオンラインREDOログ・ファイルに書き込まれます。
  • 異常停止時のデータベースのクローズ方法
    SHUTDOWN ABORTまたは異常終了が発生すると、オープン状態のデータベースのインスタンスがクローズされ、そのデータベースが即座に停止されます。

親トピック: データベースとインスタンスの停止の概要

正常停止時のデータベースのクローズ方法

ABORT以外のオプションが指定されたSHUTDOWNの一環としてデータベースがクローズされると、Oracle DatabaseはSGA内のデータをデータファイルとオンラインREDOログ・ファイルに書き込みます。

次に、データベースはオンライン・データファイルとオンラインREDOログ・ファイルをクローズします。オフライン表領域のオフライン・データファイルは、すでにクローズされています。データベースを再オープンしたとき、オフラインになっていた表領域はオフラインのままです。

この時点でデータベースはクローズされているため、通常の操作は実行できません。データベースがクローズされても、制御ファイルはオープンされたままになります。

異常停止時のデータベースのクローズ方法

SHUTDOWN ABORTまたは異常終了が発生すると、オープン状態のデータベースのインスタンスはクローズされ、データベースはただちに停止されます。

異常終了時に、Oracle DatabaseはSGAのバッファ内のデータをデータファイルとREDOログ・ファイルに書き込みません。次にデータベースを再オープンするときに必要なインスタンス・リカバリは、Oracle Databaseで自動的に実行されます。

データベースのアンマウント方法

データベースがクローズされると、Oracle Databaseはデータベースをアンマウントしてインスタンスから切り離します。

データベースをアンマウン卜すると、Oracle Databaseでは、データベースの制御ファイルがクローズされます。この時点ではデータベース・インスタンスはメモリーに残っています。

インスタンスの停止方法

データベース停止の最後の操作は、インスタンスの停止です。データベース・インスタンスが停止すると、SGAではメモリーの占有を中止し、バックグラウンド・プロセスが終了します。

異常な状況では、データベース・インスタンスが正常に停止しないことがあります。たとえば、メモリー構造がメモリーから削除されない場合や、バックグラウンド・プロセスの1つが終了されない場合があります。前のインスタンスの一部が残っていると、後続のインスタンスの起動が失敗します。このような状況では、残っている前のインスタンスを削除してから新しいインスタンスを起動するか、SHUTDOWN ABORT文を発行することで、新しいインスタンスの起動を強制実行できます。

場合によっては、プロセスのクリーンアップ自体でエラーが発生し、その結果としてプロセス・モニター(PMON)またはインスタンスが終了することもあります。動的な初期化パラメータINSTANCE_ABORT_DELAY_TIMEは、内部で発生したインスタンス障害を遅延させる秒数を指定します。この遅延により、対応する機会が得られます。終了の遅延が始動したとき、データベースによってアラート・ログにメッセージが書き込まれます。状況によっては、特定のデータベース・リソースを隔離できるようにすることで、インスタンスの終了を回避できます。

関連項目:

親トピック: データベースとインスタンスの停止の概要

チェックポイントの概要

一般的に、チェックポイントは、一貫性のあるデータベースの停止、インスタンス・リカバリおよびOracle Databaseの操作に不可欠なメカニズムです。

この用語の意味は次のとおりです。

  • チェックポイント位置を示すデータ構造。これは、インスタンス・リカバリを開始する必要があるREDOストリーム内のSCNです。

    チェックポイント位置は、データベース・バッファ・キャッシュ内の最も古い使用済バッファによって決まります。チェックポイント位置は、REDOストリームへのポインタとして機能し、制御ファイル内と各データファイル・ヘッダー内に格納されます。

  • データベース・バッファ・キャッシュ内の変更済データベース・バッファのディスクへの書込み

関連項目:

「システム変更番号(SCN)」

親トピック: Oracleデータベース・インスタンス

チェックポイントの目的

Oracle Databaseでは、複数の目的を達成するためにチェックポイントを使用します。

目的には次のものがあります。

  • インスタンス障害またはメディア障害時のリカバリに要する時間を短縮します。

  • データベースでは、ディスクへのバッファ・キャッシュで、使用済バッファを定期的に書き込みます。

  • 一貫性のある停止が実行されるとき、すべてのコミット済データがデータベースによりディスクに書き込まれることを保証します。

親トピック: チェックポイントの概要

Oracle Databaseでチェックポイントが開始される時期

チェックポイント・プロセス(CKPT)は、データファイル・ヘッダーと制御ファイルにチェックポイントを書き込みます。

チェックポイントは、様々な状況で発生します。たとえば、Oracle Databaseでは、次のタイプのチェックポイントを使用します。

  • スレッドのチェックポイント

    データベースは、特定のターゲットより前の特定のスレッド内でREDOによって変更されたすべてのバッファをディスクに書き込みます。データベース内の全インスタンスに対するスレッドのチェックポイントのセットが、データベースのチェックポイントです。スレッドのチェックポイントは、次の状況で発生します。

    • 一貫性のあるデータベースの停止

    • ALTER SYSTEM CHECKPOINT文

    • オンラインREDOログの切替え

    • ALTER DATABASE BEGIN BACKUP文

  • 表領域とデータファイルのチェックポイント

    データベースは、特定のターゲットより前のREDOによって変更されたすべてのバッファをディスクに書き込みます。表領域のチェックポイントは、表領域のデータファイルごとに1つあるデータファイルのチェックポイントのセットです。これらのチェックポイントは、表領域の読取り専用化やNORMALモードでのオフライン化、データファイルの縮小、またはALTER TABLESPACE BEGIN BACKUPの実行時など、様々な状況で発生します。

  • 増分チェックポイント

    増分チェックポイントはスレッドのチェックポイントの一種であり、オンラインREDOログを切り替えるとき、大量のブロックの書込みを防止することが目的の1つとなっています。DBWは、実行する処理の有無を少なくとも3秒ごとにチェックします。DBWが使用済バッファを書き込むと、チェックポイント位置が前進し、これにより、CKPTでは、このチェックポイント位置をデータファイル・ヘッダーではなく制御ファイルに書き込みます。

その他のタイプには、インスタンスとメディア・リカバリのチェックポイント、およびスキーマ・オブジェクトが削除または切り捨てられたときのチェックポイントがあります。

関連項目:

親トピック: チェックポイントの概要

インスタンス・リカバリの概要

インスタンス・リカバリは、オンラインREDOログ内のレコードをデータファイルに適用し、最新のチェックポイントの後に行われた変更を再構築するプロセスです。

管理者が前回一貫性のない状態で停止されたデータベースの再オープンを試行すると、インスタンス・リカバリが自動的に実行されます。

  • インスタンス・リカバリの目的
    インスタンス・リカバリでは、インスタンス障害の発生後に必ずそのデータベースが一貫性のある状態になります。Oracle Databaseでのデータベースの変更管理方法により、データベースのファイルが一貫性のない状態のままになることがあります。
  • Oracle Databaseでインスタンス・リカバリが実行される時期
    インスタンス・リカバリが必要かどうかは、REDOスレッドの状態によります。
  • インスタンス・リカバリでのチェックポイントの重要性
    インスタンス・リカバリでは、データファイルに適用する必要がある変更内容を判断するためにチェックポイントが使用されます。チェックポイント位置は、チェックポイントSCNより小さいSCNを持つすべてのコミット済の変更がデータファイルに保存されることを保証するものです。
  • インスタンス・リカバリのフェーズ
    インスタンス・リカバリの最初のフェーズは、キャッシュ・リカバリまたはロールフォワードと呼ばれており、このフェーズでは、オンラインREDOログに記録されているすべての変更内容がデータファイルに再適用されます。

親トピック: Oracleデータベース・インスタンス

インスタンス・リカバリの目的

インスタンス・リカバリは、インスタンス障害後にデータベースが一貫性のある状態になることを保証します。Oracle Databaseでのデータベースの変更管理方法により、データベースのファイルが一貫性のない状態のままになることがあります。

REDOスレッドは、インスタンスによって生成された変更のすべてのレコードです。単一インスタンス・データベースには1つのREDOスレッドがあり、Oracle RACデータベースには各データベース・インスタンスに対応する複数のREDOスレッドがあります。

トランザクションがコミットされると、ログ・ライター・プロセス(LGWR)は、メモリー内の残りのREDOエントリとトランザクションのSCNの両方をオンラインREDOログに書き込みます。ただし、データベース・ライター(DBW)プロセスでは、変更されたデータ・ブロックを最も効率的な時点でデータファイルに書き込みます。このため、コミットされた変更がまだデータファイルに存在しないとき、コミットされていない変更が一時的にデータファイルに存在することがあります。

SHUTDOWN ABORT文または異常終了のいずれかにより、オープン状態のデータベースのインスタンスに障害が発生すると、次の状態になることがあります。

  • トランザクションによってコミットされたデータ・ブロックはデータファイルに書き込まれず、オンラインREDOログにのみ表示されます。これらの変更は、データ・ファイルに再適用される必要があります。

  • インスタンスに障害が発生した時点でコミットされていない変更がデータファイルに含まれています。これらの変更は、トランザクションの一貫性を保証するためにロールバックする必要があります。

インスタンス・リカバリは、オンラインREDOログ・ファイルと現行のオンライン・データファイルのみを使用してデータファイルを同期し、これらが一貫性のある状態になることを保証します。

関連項目:

親トピック: インスタンス・リカバリの概要

Oracle Databaseでインスタンス・リカバリが実行される時期

インスタンス・リカバリが必要かどうかは、REDOスレッドの状態によります。

制御ファイル内では、データベース・インスタンスが読取り/書込みモードでオープンすると、REDOスレッドにオープンのマークが付けられ、インスタンスが一貫性のある状態で停止されると、クローズ済のマークが付けられます。REDOスレッドに制御ファイルでオープンのマークが付けられると、稼働中のインスタンスはこれらのスレッドに対応するスレッドのエンキューを保持しないため、データベースでインスタンス・リカバリが必要となります。

Oracle Databaseでは、次の場合にインスタンス・リカバリが自動的に実行されます。

  • 単一インスタンス・データベースまたはOracle RACデータベースの全インスタンスの障害後に、最初にデータベースをオープンするとき。このタイプのインスタンス・リカバリはクラッシュ・リカバリとも呼ばれます。Oracle Databaseでは、終了したインスタンスのオンラインREDOスレッドも同時にリカバリされます。

  • Oracle RACデータベースに含まれる全インスタンスではなく一部のインスタンスに障害が発生したとき。インスタンス・リカバリは、構成内で正常に稼働しているインスタンスにより自動的に実行されます。

SMONバックグラウンド・プロセスではインスタンス・リカバリが実行され、オンラインREDOが自動的に適用されます。ユーザーが介入する必要はありません。

関連項目:

親トピック: インスタンス・リカバリの概要

インスタンス・リカバリでのチェックポイントの重要性

インスタンス・リカバリでは、データファイルに適用する必要がある変更を判断するためにチェックポイントが使用されます。チェックポイント位置は、チェックポイントSCNより小さいSCNを持つすべてのコミット済の変更がデータファイルに保存されることを保証するものです。

次の図に、オンラインREDOログ内のREDOスレッドを示します。

図14-5 オンラインREDOログ内のチェックポイント位置

図14-5の説明が続きます
「図14-5 オンラインREDOログ内のチェックポイント位置」の説明

インスタンス・リカバリ時には、データベースによってチェックポイント位置からREDOスレッドの最後までに発生した変更が適用される必要があります。図14-5に示されているように、変更の一部はすでにデータファイルに書き込まれています。ただし、ディスクに書き込まれるのは、チェックポイント位置より小さいSCNを持つ変更のみであることが保証されます。

関連項目:

リカバリ時間の制限方法を学習するには、Oracle Databaseパフォーマンス・チューニング・ガイドを参照してください

親トピック: インスタンス・リカバリの概要

インスタンス・リカバリのフェーズ

インスタンス・リカバリの最初のフェーズは、キャッシュ・リカバリまたはロールフォワードと呼ばれ、オンラインREDOログに記録されているすべての変更をデータファイルに再適用します。

オンラインREDOログにはUNDOデータが含まれているため、ロールフォワードでは対応するUNDOセグメントも再生成されます。ロールフォワードでは、必要に応じて多数のオンラインREDOログ・ファイルをたどり、データベースを後の時点まで進行させます。ロールフォワード後のデータ・ブロックには、オンラインREDOログ・ファイルに記録されたコミット済の変更がすべて含まれています。これらのファイルには、障害発生前にデータファイルに保存されていたか、オンラインREDOログに記録されてキャッシュ・リカバリ時に取り込まれた、コミットされていない変更も含まれることがあります。

ロールフォワード後は、コミットされなかった変更を取り消す必要があります。Oracle Databaseでは、チェックポイント位置が使用され、これにより、チェックポイントSCNより小さいSCNを持つすべてのコミット済の変更がディスクに保存されることが保証されます。Oracle Databaseでは、UNDOブロックの適用により、障害発生前に書き込まれたか、キャッシュ・リカバリ中に取り込まれたデータ・ブロック内の、コミットされていない変更がロールバックされます。このフェーズは、ロールバックまたはトランザクション・リカバリと呼ばれます。

次の図に、ロールフォワードとロールバックを示します。この2つは、データベース・インスタンスの障害からのリカバリに必要なステップです。

図14-6 インスタンス・リカバリの基本ステップ: ロールフォワードとロールバック

図14-6の説明が続きます
「図14-6 インスタンス・リカバリの基本ステップ: ロールフォワードとロールバック」の説明

Oracle Databaseは、必要に応じて同時に複数のトランザクションをロールバックできます。障害時点でアクティブになっていたトランザクションすべてに、終了マークが付けられます。終了したトランザクションがSMONプロセスによりロールバックされるのを待たずに、新しいトランザクションによりトランザクション自体で個別のブロックをロールバックし、必要なデータを取得できます。

関連項目:

親トピック: インスタンス・リカバリの概要

パラメータ・ファイルの概要

データベース・インスタンスを起動するには、Oracle Databaseはサーバー・パラメータ・ファイル(推奨)またはテキスト形式の初期化パラメータ・ファイル(従来型の実装)を読み取る必要があります。これらのファイルには、構成パラメータのリストが格納されます。

データベースを手動で作成するには、パラメータ・ファイルを使用してインスタンスを起動してから、CREATE DATABASE文を発行する必要があります。このため、データベース自体が存在していない場合でも、インスタンスとパラメータ・ファイルが存在することがあります。

  • 初期化パラメータ
    初期化パラメータとは、インスタンスの基本操作に影響する構成パラメータです。インスタンスは、起動時にファイルから初期化パラメータを読み取ります。
  • サーバー・パラメータ・ファイル
    サーバー・パラメータ・ファイルとは、初期化パラメータのリポジトリです。
  • テキスト形式の初期化パラメータ・ファイル
    テキスト形式の初期化パラメータ・ファイルとは、初期化パラメータのリストが含まれているテキスト・ファイルです。
  • 初期化パラメータ値の変更
    初期化パラメータを調整してデータベースの動作を変更できます。パラメータの分類が静的であるか、動的であるかによって、パラメータの変更方法が決まります。

親トピック: Oracleデータベース・インスタンス

初期化パラメータ

初期化パラメータは、インスタンスの基本操作に影響する構成パラメータです。インスタンスは、起動時にファイルから初期化パラメータを読み取ります。

Oracle Databaseには、様々な環境に応じて操作を最適化する多数の初期化パラメータが用意されています。これらのパラメータのごく一部は、通常はデフォルト値のままで十分であり、明示的な設定が必要です。

親トピック: パラメータ・ファイルの概要

初期化パラメータの機能グループ

初期化パラメータは様々な機能グループに分類されます。

ほとんどの初期化パラメータは、次のグループのいずれかに属しています。

  • ファイルやディレクトリなどのエンティティに名前を指定するパラメータ

  • プロセス、データベース・リソースまたはデータベース自体の制限を設定するパラメータ

  • SGAのサイズなどの容量に影響するパラメータ(可変パラメータと呼ばれる)

可変パラメータを使用するとデータベースのパフォーマンスを改善できるため、これらのパラメータは、特にデータベース管理者によって頻繁に使用されます。

親トピック: 初期化パラメータ

基本的な初期化パラメータと拡張初期化パラメータ

初期化パラメータは、基本と拡張という2つのグループに分かれています。

通常、妥当なパフォーマンスを得るには、約30種類の基本パラメータのみを設定およびチューニングする必要があります。基本パラメータでは、データベース名、制御ファイルの場所、データベース・ブロック・サイズ、UNDO表領域などの特性を設定します。

ただし最適なパフォーマンスを得るために、拡張パラメータの変更が必要になる場合があります。拡張パラメータを使用することによって、熟練したDBAは固有の要件にあわせてOracle Databaseの動作を調整できます。

Oracle Databaseは、データベース・ソフトウェアで提供される最初の初期化パラメータ・ファイル、またはDatabase Configuration Assistantにより作成される最初の初期化パラメータ・ファイルに値を提供します。構成およびデータベースのチューニング計画に応じて、これらのOracle提供の初期化パラメータを編集し、他のパラメータを追加できます。該当する初期化パラメータがパラメータ・ファイルに組み込まれていない場合には、Oracle Databaseによりデフォルトが指定されます。

関連項目:

親トピック: 初期化パラメータ

サーバー・パラメータ・ファイル

サーバー・パラメータ・ファイルは、初期化パラメータのリポジトリです。

サーバー・パラメータ・ファイルには、主に次の特徴があります。

  • Oracle Databaseのみが、サーバー・パラメータ・ファイルに対する読取りおよび書き込みを行います。

  • サーバー・パラメータ・ファイルは、データベースに対して1つのみ存在します。このファイルは、データベース・ホストに常駐する必要があります。

  • サーバー・パラメータ・ファイルはバイナリであり、テキスト・エディタでは編集できません。

  • サーバー・パラメータ・ファイルに格納されている初期化パラメータは永続的です。データベース・インスタンスの実行中に行われたパラメータの変更は、インスタンスを停止して起動しても残ります。

サーバー・パラメータ・ファイルを使用すると、クライアント・アプリケーション用に複数のテキスト形式の初期化パラメータ・ファイルを保持する必要がなくなります。最初のサーバー・パラメータ・ファイルは、CREATE SPFILE文を使用して、テキスト形式の初期化パラメータ・ファイルから作成します。また、Database Configuration Assistantにより直接作成することもできます。

関連項目:

親トピック: パラメータ・ファイルの概要

テキスト形式の初期化パラメータ・ファイル

テキスト形式の初期化パラメータ・ファイルは、初期化パラメータのリストが格納されるテキスト・ファイルです。

このタイプのパラメータ・ファイルは、従来型の実装のパラメータ・ファイルであり、主に次の特徴があります。

  • データベースを起動または停止するときに、テキスト形式の初期化パラメータ・ファイルは、データベースに接続するクライアント・アプリケーションと同じホストに常駐する必要があります。

  • テキスト形式の初期化パラメータ・ファイルはテキストベースであり、バイナリではありません。

  • Oracle Databaseは、テキスト形式の初期化パラメータ・ファイルの読取りはできますが、書込みはできません。パラメータ値を変更するには、テキスト・エディタを使用してファイルを手動で編集する必要があります。

  • ALTER SYSTEMを使用した初期化パラメータ値の変更は、現行インスタンスにのみ有効になります。変更内容を確認するには、テキスト形式の初期化パラメータ・ファイルを手動で更新し、インスタンスを再起動する必要があります。

テキスト形式の初期化パラメータ・ファイルには、一連のキー=値のペア(行ごとに1ペア)が格納されています。たとえば、初期化パラメータ・ファイルの一部は、次のように表示されます。 

db_name=sample
control_files=/disk1/oradata/sample_cf.dbf
db_block_size=8192
open_cursors=52
undo_management=auto
shared_pool_size=280M
pga_aggregate_target=29M
.
.
.

テキスト形式のパラメータ・ファイルの管理性に関する問題を具体的に説明するため、clientaとclientbというコンピュータを使用し、いずれのコンピュータ上でもSQL*Plusでデータベースを起動できるようにする必要があるとします。この場合、図14-7に示すように、個別のテキスト形式の初期化パラメータ・ファイルが2つ(コンピュータごとに1つ)存在する必要があります。サーバー・パラメータ・ファイルは、パラメータ・ファイルが増加する問題を解決します。

図14-7 複数の初期化パラメータ・ファイル

図14-7の説明が続きます
「図14-7 複数の初期化パラメータ・ファイル」の説明

関連項目:

親トピック: パラメータ・ファイルの概要

初期化パラメータ値の変更

初期化パラメータを調整してデータベースの動作を変更できます。パラメータの分類が静的であるか、動的であるかによって、パラメータの変更方法が決まります。

以下の表にその違いをまとめています。

表14-5 静的な初期化パラメータと動的な初期化パラメータ

特徴 静的 動的

パラメータ・ファイル(テキストまたはサーバー)を変更する必要性

はい

いいえ

設定を有効にする前にデータベース・インスタンスを再起動する必要性

はい

いいえ

『Oracle Databaseリファレンス』の初期化パラメータのエントリでの変更可能という説明

いいえ

はい

データベースまたはインスタンスによってのみ変更可能かどうか

はい

いいえ

静的なパラメータには、DB_BLOCK_SIZE、DB_NAMEおよびCOMPATIBLEがあります。動的なパラメータは、現行のユーザー・セッションにのみ影響するセッション・レベルのパラメータと、データベースおよびすべてのセッションに影響するシステム・レベルのパラメータに分類されます。たとえば、MEMORY_TARGETはシステム・レベルのパラメータであり、NLS_DATE_FORMATはセッション・レベルのパラメータです。

パラメータ変更の有効範囲は、変更が有効になる時期によって異なります。インスタンスがサーバー・パラメータ・ファイルで起動されている場合は、ALTER SYSTEM SET文を使用して、次のようにシステム・レベルのパラメータの値を変更できます。

  • SCOPE=MEMORY

    変更はデータベース・インスタンスにのみ適用されます。データベースが停止して再起動された場合、変更は存続しません。

  • SCOPE=SPFILE

    変更はサーバー・パラメータ・ファイルに適用されますが、現行インスタンスには影響しません。このため、インスタンスが再起動されるまで変更は有効になりません。

    ノート:

    『Oracle Databaseリファレンス』で変更不可と説明されているパラメータの値を変更する場合は、SPFILEを指定する必要があります。

  • SCOPE=BOTH

    Oracle Databaseでは、変更はメモリーとサーバー・パラメータ・ファイルの両方に書き込まれます。これは、データベースがサーバー・パラメータ・ファイルを使用している場合のデフォルトの有効範囲です。

データベースにより、初期化パラメータの新しい値と古い値がアラート・ログに出力されます。無効な値がサーバー・パラメータ・ファイルに書き込まれるのを防ぐため、予防策として、データベースにより基本的なパラメータの変更が検証されます。

関連項目:

親トピック: パラメータ・ファイルの概要

診断ファイルの概要

Oracle Databaseには、データベースの問題を防止、検出、診断および解決するための障害診断性インフラストラクチャが含まれています。問題には、コードの不具合、メタデータの破損、顧客データの破損などの重大なエラーがあります。

この高度な障害診断性インフラストラクチャの目的は、次のとおりです。

  • 問題の予防的な検出

  • 問題が検出された後の損害および中断の抑制

  • 問題の診断時間と解決時間の短縮

  • トレース・ファイルのパーティション化を有効にすること、ユーザーがピース当たりのサイズおよび保持するピースの最大数を定義できるようにすること、ユーザー指定のディスク領域制限に到達後にトレースを無効にすることによる管理容易性の向上

  • 顧客とOracleサポートのやり取りの簡略化

マルチテナント・コンテナ・データベース(CDB)と非CDBには、アーキテクチャに違いがあります。この項では、特に他に指示がないかぎり、非CDBのアーキテクチャを前提としています。

  • 自動診断リポジトリ
    自動診断リポジトリ(ADR)とは、トレース・ファイル、アラート・ログ、DDLログ、状態モニター・レポートなどのデータベース診断データが格納される、ファイルベースのリポジトリです。
  • アラート・ログ
    各データベースには、アラート・ログがあり、これはデータベースのメッセージとエラーの履歴ログが格納されたXMLファイルです。
  • DDLログ
    DDLログは、形式と基本動作はアラート・ログと同じですが、DDL文および詳細のみが含まれる点が異なります。データベースでは、DDL情報を自身のファイルに書き込み、アラート・ログでの乱雑さを減らします。
  • トレース・ファイル
    トレース・ファイルとは、問題の調査に使用する診断データが含まれているファイルです。また、トレース・ファイルはアプリケーションまたはインスタンスのチューニングにガイダンスを提供することもできます。
  • 診断ダンプ
    診断ダンプ・ファイルは、特殊な種類のトレース・ファイルであり、特定時点での状態または構造に関する詳細情報が含まれています。

関連項目:

CDBでの診断ファイルの管理方法を学習するには、『Oracle Database管理者ガイド』を参照してください

親トピック: Oracleデータベース・インスタンス

自動診断リポジトリ

自動診断リポジトリ(ADR)は、トレース・ファイル、アラート・ログ、DDLログ、状態モニター・レポートなどのデータベース診断データを格納するファイルベース・リポジトリです。

ADRの主な特徴は、次のとおりです。

  • 統合ディレクトリ構造

  • 一貫性のある診断データ形式

  • 統合されたツール・セット

これらの特性により、ユーザーとOracleサポートは、複数のOracleインスタンス、コンポーネントおよび製品間で診断データを相関付けて、分析できます。

ADRはデータベースの外側に位置するため、物理データベースが使用不可の場合でも、Oracle DatabaseはADRにアクセスして管理できます。データベース・インスタンスにより、データベースの作成が完了する前にADRが作成されることがあります。

  • 問題とインシデント
    ADRは、データベースにおいて重大なエラーとなる問題を、予防的に追跡します。
  • ADRの構造
    ADRベースは、ADRのルート・ディレクトリです。

親トピック: 診断ファイルの概要

問題とインシデント

ADRは、データベース内で重大なエラーとなる問題を予防的に追跡します。

重大なエラーとは、ORA-600などの内部エラーや他のサーバー・エラーのことです。各問題には、問題を説明する文字列である問題キーがあります。

1つの問題が複数回発生した場合は、発生するたびに、タイムスタンプの付いたインシデントがADRによって作成されます。インシデントは、数字のインシデントIDによって一意に識別されます。インシデントが発生すると、ADRではインシデント・アラートをEnterprise Managerに送信します。通常、クリティカル・エラーの診断と解決は、インシデント・アラートから開始されます。

1つの問題で短時間に多数のインシデントが生成される場合があるため、ADRでは特定のしきい値に到達した後、インシデントの生成にフラッド制御を適用します。大量データを制御されたインシデントでは、アラート・ログ・エントリは生成されますが、インシデントのダンプは生成されません。この方法では、ADRから重大なエラーが継続中であることが通知され、診断データによるシステムのオーバーロードは回避されます。

関連項目:

障害診断性インフラストラクチャの詳細は、『Oracle Database管理者ガイド』を参照してください

親トピック: 自動診断リポジトリ

ADRの構造

ADRベースは、ADRのルート・ディレクトリです。

ADRベースには、複数のADRホームを格納でき、それぞれのADRホームは、Oracle製品やコンポーネントのインスタンスごとにすべての診断データ(トレース、ダンプ、アラート・ログなど)を格納するルート・ディレクトリです。たとえば、共有記憶域とOracle ASMがあるOracle RAC環境では、各データベース・インスタンスと各Oracle ASMインスタンスにはそれぞれ独自のADRホームがあります。

図14-8に、データベース・インスタンスのADRディレクトリ階層を示します。この階層内の同じADRベースの下に、Oracle ASMまたはOracle Net Servicesなどの他のOracle製品やコンポーネントに対する別のADRホームを格納できます。

図14-8 Oracleデータベース・インスタンスのADRディレクトリ構造

図14-8の説明が続きます
「図14-8 Oracleデータベース・インスタンスのADRディレクトリ構造」の説明

次のLinuxの例に示すように、データベースを作成する前に一意のSIDとデータベース名でインスタンスを起動すると、Oracle Databaseは、ホスト・ファイル・システムのディレクトリ構造としてデフォルトでADRを作成します。SIDとデータベース名は、ADRホーム内のファイルのパス名の一部になります。

例14-1 ADRの作成

% setenv ORACLE_SID osi
% echo "DB_NAME=dbn" > init.ora
% sqlplus / as sysdba
.
.
. 
Connected to an idle instance.
 
SQL> STARTUP NOMOUNT PFILE="./init.ora"
ORACLE instance started.
 
Total System Global Area  146472960 bytes
Fixed Size                  1317424 bytes
Variable Size              92276176 bytes
Database Buffers           50331648 bytes
Redo Buffers                2547712 bytes
 
SQL> COL NAME FORMAT a21
SQL> COL VALUE FORMAT a60
SQL> SELECT NAME, VALUE FROM V$DIAG_INFO;
 
NAME                  VALUE
--------------------- --------------------------------------------------------
Diag Enabled          TRUE
ADR Base              /d1/3910926111/oracle/log
ADR Home              /d1/3910926111/oracle/log/diag/rdbms/dbn/osi
Diag Trace            /d1/3910926111/oracle/log/diag/rdbms/dbn/osi/trace
Diag Alert            /d1/3910926111/oracle/log/diag/rdbms/dbn/osi/alert
Diag Incident         /d1/3910926111/oracle/log/diag/rdbms/dbn/osi/incident
Diag Cdump            /d1/3910926111/oracle/log/diag/rdbms/dbn/osi/cdump
Health Monitor        /d1/3910926111/oracle/log/diag/rdbms/dbn/osi/hm
Default Trace File    /d1/3910926111/oracle/log ... osi/trace/osi_ora_6825.trc
Active Problem Count  0
Active Incident Count 0

親トピック: 自動診断リポジトリ

アラート・ログ

各データベースには、アラート・ログがあり、これは、データベースのメッセージとエラーの履歴ログが格納されたXMLファイルです。

アラート・ログの内容は次のとおりです。

  • すべての内部エラー(ORA-600)、ブロック破損エラー(ORA-1578)およびデッドロック・エラー(ORA-60)

  • 管理操作(たとえば、SQL*PlusコマンドのSTARTUP、SHUTDOWN、ARCHIVE LOG、およびRECOVERなど)

  • 共有サーバーとディスパッチャ・プロセスの機能に関係するいくつかのメッセージとエラー。

  • マテリアライズド・ビューの自動リフレッシュにおけるエラー。

Oracle Databaseでは、Enterprise ManagerのGUIに情報を表示するかわりに、アラート・ログを使用します。管理操作が成功すると、Oracle Databaseはタイムスタンプとともに「completed」というメッセージをアラート・ログに書き込みます。

最初にデータベース・インスタンスを起動すると、データベースがまだ作成されていない場合でも、Oracle Databaseは図14-8に示すalertサブディレクトリにアラート・ログを作成します。このファイルはXML形式です。トレース・サブディレクトリにはテキストのみのアラート・ログが含まれ、次の例にその一部を示しています。 

Fri Nov 02 12:41:58 2014
SMP system found. enable_NUMA_support disabled (FALSE)
Starting ORACLE instance (normal)
CLI notifier numLatches:3 maxDescs:189
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Initial number of CPU is 2
Number of processor cores in the system is 2
Number of processor sockets in the system is 2
Shared memory segment for instance monitoring created
Picked latch-free SCN scheme 3
Using LOG_ARCHIVE_DEST_1 parameter default value as /disk1/oracle/dbs/arch
Autotune of undo retention is turned on.
IMODE=BR
ILAT =10
LICENSE_MAX_USERS = 0
SYS auditing is disabled
NOTE: remote asm mode is local (mode 0x1; from cluster type)
Starting up:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, Advanced Analytics and Real Application Testing options.
.
.
.
Using parameter settings in client-side pfile 
System parameters with nondefault values:
  processes                = 100
  sessions                 = 172

例14-1に示すように、アラート・ログを検索するにはV$DIAG_INFOを問い合せます。

親トピック: 診断ファイルの概要

DDLログ

DDLログは、形式および基本的な動作がアラート・ログと同じですが、DDL文および詳細のみが含まれる点が異なります。データベースでは、DDL情報を自身のファイルに書き込み、アラート・ログでの乱雑さを減らします。

DDLログ・レコードはDDLテキストであり、オプションで補足情報より拡張できます。DDL文ごとに1つのログ・レコードが存在します。DDLログは、ADRホームのlog/ddlサブディレクトリに格納されています。

親トピック: 診断ファイルの概要

トレース・ファイル

トレース・ファイルは、問題の調査に使用される診断データが含まれるファイルです。また、トレース・ファイルはアプリケーションまたはインスタンスのチューニングにガイダンスを提供することもできます。

  • トレース・ファイルのタイプ
    それぞれのサーバー・プロセスとバックグラウンド・プロセスで、関連するトレース・ファイルに定期的に書き込むことができます。トレース・ファイルには、プロセスの環境、ステータス、アクティビティおよびエラーに関する情報が含まれています。
  • トレース・ファイルの場所
    ADRでは、traceサブディレクトリにトレース・ファイルが格納されます。トレース・ファイル名はプラットフォーム依存であり、拡張子.trcが使用されます。
  • トレース・ファイルのセグメント化
    トレース・ファイルのサイズが制限されている場合は、データベースによって自動的にトレース・ファイルが最大5つのセグメントに分割される可能性があります。セグメントとは、アクティブなトレース・ファイルと同じ名前の個別のファイルですが、ora_1234_2.trcのように、セグメント番号が追加されます。

関連項目:

「パフォーマンスおよびチューニング」

親トピック: 診断ファイルの概要

トレース・ファイルのタイプ

それぞれのサーバーとバックグラウンド・プロセスは、関連付けられたトレース・ファイルに定期的に書き込むことができます。トレース・ファイルには、プロセスの環境、ステータス、アクティビティおよびエラーに関する情報が含まれています。

SQLトレース機能でも、個別のSQL文に関するパフォーマンス情報を提供するトレース・ファイルが作成されます。クライアント識別子、サービス、モジュール、アクション、セッション、インスタンスまたはデータベースのトレースを様々な方法で有効化できます。たとえば、DBMS_MONITORパッケージの適切なプロシージャを実行することも、イベントを設定することもできます。

関連項目:

親トピック: トレース・ファイル

トレース・ファイルの場所

ADRでは、traceサブディレクトリにトレース・ファイルが格納されます。トレース・ファイル名はプラットフォーム依存であり、拡張子.trcが使用されます。

通常、データベース・バックグラウンド・プロセスのトレース・ファイル名には、Oracle SID、バックグラウンド・プロセス名およびオペレーティング・システムのプロセス番号が含まれています。たとえば、RECOプロセスのトレース・ファイル名は、mytest_reco_10355.trcのようになります。

サーバー・プロセスのトレース・ファイル名には、Oracle SID、文字列oraおよびオペレーティング・システムのプロセス番号が含まれています。たとえば、サーバー・プロセスのトレース・ファイル名は、mytest_ora_10304.trcのようになります。

トレース・ファイルには、対応するトレース・メタデータのファイル(拡張子.trmで終わる)が付くことがあります。これらのファイルにはトレース・マップと呼ばれる構造に関する情報が含まれており、データベースでは検索やナビゲーションに使用されます。

関連項目:

親トピック: トレース・ファイル

トレース・ファイルのセグメント化

トレース・ファイルのサイズが制限されていると、データベースがトレース・ファイルを最大5つのセグメントに自動的に分割する場合があります。セグメントとは、アクティブなトレース・ファイルと同じ名前の個別のファイルですが、ora_1234_2.trcのように、セグメント番号が追加されます。

通常、各セグメントは、MAX_DUMP_FILE_SIZEによって設定される制限の20%になります。すべてのセグメントの結合サイズが制限を超えると、データベースは古いセグメントから削除し(ただし、プロセスの初期状態に関する情報を含む可能性のある最初のセグメントは削除しません)、新しい空のセグメントを作成します。

関連項目:

トレース・ファイルのサイズを制御する方法を学習するには、『Oracle Database管理者ガイド』を参照してください

親トピック: トレース・ファイル

診断ダンプ

診断ダンプ・ファイルは、特殊なタイプのトレース・ファイルで、状態または構造に関する特定の時点の詳細な情報が含まれています。

多くの場合、トレースでは診断データが連続して出力されます。一方、通常、ダンプではイベントに対して診断データが1回出力されます。

親トピック: 診断ファイルの概要

トレース・ダンプおよびインシデント

ほとんどのダンプは、インシデントが原因で発生します。

インシデントが発生すると、データベースは、そのインシデント用に作成されたインシデント・ディレクトリに1つ以上のダンプを書き込みます。インシデントのダンプには、ファイル名にインシデント番号も付きます。

インシデントの作成中、アプリケーションではアクションの一部として、ヒープまたはシステム状態のダンプを取得する場合があります。そのような場合、データベースでは、デフォルトのトレース・ファイル名のかわりに、ダンプ名をインシデント・ファイル名に追加します。たとえば、プロセス内の1つのインシデントのために、データベースではprod_ora_90348.trcファイルが作成されます。そのインシデントでのダンプにより、prod_ora_90348_incident_id.trcファイルが生成されます(incident_idはインシデントの数値ID)。インシデントの一部として作成されたヒープ・ダンプ・アクションにより、ヒープ・ダンプ・ファイルprod_ora_90348_incident_id_dump_id.trcが生成されます(dump_idは、トレース・ダンプの数値ID)。

親トピック: 診断ダンプ