Oracle AI Databaseインスタンス

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

ノート:この章の目的に合わせ、特に記載のないかぎりデータベースという用語はマルチテナント・コンテナ・データベース(CDB)を指します。

Oracle AI Databaseインスタンスの概要

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

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

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

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

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

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

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

データベース・インスタンスには、バックグラウンド・プロセスとサーバー・プロセスも含まれます。各プロセスには、インスタンスの一部とみなされる、固有の専用メモリーがあります。サーバー・プロセスが終了しても、インスタンスは機能し続けます。

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

図1: データベース・インスタンス

画像cncpt325.pngの説明

関連情報:

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

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

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

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

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

画像cncpt296.gifの説明

単一インスタンス構成でも、Oracle RAC構成のどちらでも、データベース・インスタンスは同時に1つのデータベースにのみ関連付けられます。データベース・インスタンスを起動して1つのデータベースマウント(インスタンスに関連付け)できますが、2つのデータベースを同じインスタンスに同時にマウントすることはできません。ノート:この章では、特に記載のないかぎり単一インスタンス・データベース構成について説明します。

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

関連項目: Oracle RACに固有の情報は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください

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

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

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

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

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

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

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

関連情報:

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

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

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

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

表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 Optimal Flexible Architecture (OFA)のルールは、Oracleインストールを適切に構造化するために作成された一つの構成ガイドラインです。この項の例では、OFAアーキテクチャを前提としています。

この項では、次のトピックについて説明します:

Oracleベース・ディレクトリ

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

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

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

/u01/app/oracle

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

関連項目: Oracleベースの概要は、『Oracle AI Databaseインストレーション・ガイドfor Linux』

Oracleホーム・ディレクトリ

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

Oracle AI Databaseソフトウェアを新規インストールするたびに、新規Oracleホーム・ディレクトリを指定する必要があります。Oracle Database 21c以降、Oracleホームは読取り専用です。Oracleホームにはバイナリなどの静的ファイルが格納されます。

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

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

/u01/app/oracle/product/19.3.0/dbhome_1
/u01/app/oracle/product/19.3.0/dbhome_2
/u01/app/oracle/product/20.1.0/dbhome_1

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

ORACLE_BASE/homes/home_nameにあるOracleベース・ホーム(ORACLE_BASE_HOME)ディレクトリには、Oracleホームに固有の動的ファイルが格納されます。Oracleベース構成ディレクトリ(ORACLE_BASE_CONFIG)には、インスタンス固有の動的ファイルが格納されます。このディレクトリは、Oracleベースのすべての0ホームによって共有されます。

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

/u01/app/oracle/product/20.1.0/dbhome_1
/u01/app/oracle/homes/dbhome_1

関連項目: Oracleホームの概要については、「Oracle AI Databaseインストレーション・ガイドfor Linux」を参照してください。

Oracleシステム識別子(SID)

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

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

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

インスタンス固有のファイルは、Oracleベースに別々に格納されます。名前にSIDが含まれているファイルは、Oracleベース構成ディレクトリ(ORACLE_BASE_CONFIG)のdbsサブディレクトリに格納されます。このように分離することで、ユーザーは既存のOracleホームのソフトウェアを使用してデータベースを作成し、新しいOracleホームのソフトウェアを使用してそのデータベースのインスタンスを起動します。

関連情報:

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

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

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

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

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

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

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

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

画像cncpt212.gifの説明

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

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

フェーズ マウントの状態 摘要 詳細を表示するには
1 データベースにマウントせずにインスタンスを起動 インスタンスは起動されますが、まだデータベースと関連付けられていません。 「インスタンスの起動方法」
2 データベースがマウントされました インスタンスが起動され、データベースの制御ファイルを読み取ってデータベースに関連付けられます。データベースは、ユーザーに対してクローズされています。 「データベースのマウント方法」
3 データベースのオープン インスタンスが起動され、オープン状態のデータベースと関連付けられます。データファイルに含まれるデータは、許可されたユーザーからアクセス可能になります。 「データベースのオープン方法」

関連情報:

管理者権限での接続

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

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

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

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

関連情報:

インスタンスの起動方法

Oracle AI Databaseによってインスタンスが起動されるときは、段階的には進行します。

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

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

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

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

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

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

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

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

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

インスタンスは、データベースとこのインスタンスを関連付けるためにデータベースをマウントします。

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

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

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

関連情報:

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

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

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

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

関連情報:

読取り専用モード

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

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

関連情報:

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

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

関連項目:バックアップとリカバリの概要は、『Oracle AI Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

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

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

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

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

画像cncpt281.gifの説明

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

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

フェーズ マウントの状態 摘要 詳細を表示するには
1 データベースがクローズされました データベースはマウントされていますが、オンライン・データファイルとREDOログ・ファイルはクローズされます。 「データベースのクローズ方法」
2 データベースのアンマウント インスタンスは起動状態にありますが、データベースの制御ファイルとの関連付けは解消されます。 「データベースのアンマウント方法」
3 データベース・インスタンスの停止 データベース・インスタンスは起動状態にありません。 「インスタンスの停止方法」

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

シャットダウンモード

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

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

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

データベースの動作 中断 IMMEDIATE トランザクション 標準
新しいユーザー接続を許可 いいえ いいえ いいえ いいえ
現行セッションが終了するまで待機 いいえ いいえ いいえ はい
現行トランザクションが終了するまで待機 いいえ いいえ はい はい
チェックポイントを実行し、オープン状態のファイルをクローズします いいえ はい はい はい

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

関連情報:

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

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

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

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

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

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

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

SHUTDOWN ABORTまたは異常終了が発生すると、オープン状態のデータベース・インスタンスが閉じ、データベースは即時に停止します。

異常終了時には、Oracle AI DatabaseはSGAのバッファ内のデータをデータファイルとREDOログ・ファイルには書き込みません。データベースを再度開くにはインスタンスのリカバリが必要であり、この処理はOracle AI Databaseで自動的に行われます。

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

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

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

インスタンスの停止方法

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

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

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

関連情報:

チェックポイントの概要

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

この用語には、次のような意味があります。

チェックポイントの目的

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

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

Oracle AI Databaseがチェックポイントを開始する場合

チェックポイント・プロセス(CKPT)により、データファイル・ヘッダーと制御ファイルにチェックポイントが書き込まれる。

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

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

関連情報:

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

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

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

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

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

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

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

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

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

関連情報:

Oracle AI Databaseがインスタンス・リカバリを実行するタイミング

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

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

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

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

関連情報:

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

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

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

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

画像cncpt282.gifの説明

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

関連項目:インスタンス・リカバリ時間の制限方法を学習するには、『Oracle AI Databaseパフォーマンス・チューニング・ガイド』を参照

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

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

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

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

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

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

画像cncpt196.gifの説明

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

関連情報:

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

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

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

初期化パラメータ

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

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

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

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

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

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

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

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

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

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

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

関連情報:

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

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

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

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

関連情報:

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

テキスト初期化パラメータ・ファイルとは、初期化パラメータのリストが含まれているテキスト・ファイルである。

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

テキスト形式の初期化パラメータ・ファイルには、一連のキー=値のペア(行ごとに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でデータベースを起動できるようにする必要があるとします。In this case, two separate text initialization parameter files must exist, one on each computer, as shown in Figure 16-7. サーバー・パラメータ・ファイルは、パラメータ・ファイルが増加する問題を解決します。

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

画像cncpt247.gifの説明

関連情報:

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

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

次の表に、相違点をまとめます。

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

特性 静的 動的
パラメータ・ファイル(テキストまたはサーバー)を変更する必要性 はい いいえ
設定を有効にする前にデータベース・インスタンスを再起動する必要性 はい いいえ
Oracle AI Databaseリファレンスの初期化パラメータ・エントリでの変更可能と呼ばれる説明 いいえ はい
データベースまたはインスタンスによってのみ変更可能かどうか はい いいえ

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

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

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

関連情報:

診断ファイルの概要

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

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

自動診断リポジトリ

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

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

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

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

問題とインシデント

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

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

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

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

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

ADRの構造

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

ADRベースには、複数のADRホームを格納できます。それぞれのADRホームは、Oracle製品やコンポーネントのインスタンスごとにすべての診断データ・トレース、ダンプ、アラート・ログなどを格納するルート・ディレクトリになります。たとえば、共有記憶域とOracle ASMがあるOracle RAC環境では、各データベース・インスタンスと各Oracle ASMインスタンスにはそれぞれ独自のADRホームがあります。図16-8に、データベース・インスタンスのADRディレクトリ階層を示します。この階層内の同じADRベースの下に、Oracle ASMまたはOracle Net Servicesなどの他のOracle製品やコンポーネントに対する別のADRホームを格納できます。

図8: Oracle AI DatabaseインスタンスのADRディレクトリ構造

画像admin077.gifの説明

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

例16-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/diag/rdbms/dbn/osi/trace/osi_ora_29229.trc
Active Problem Count  0
Active Incident Count 0
ORACLE_HOME           /d1/3910926111/oracle
Attention Log         /d1/3910926111/oracle/log/diag/rdbms/dbn/osi/trace/attention_osi.log
13 rows selected.

アラート・ログ

各データベースには、アラート・ログがあります。これは、データベースのメッセージとエラーの時系列ログを格納したファイルになります。

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

管理操作が成功すると、Oracle AI Databaseはタイムスタンプとともに「completed」というメッセージをアラート・ログに書き込みます。

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

V$DIAG_INFOを問い合せてアラート・ログを検索します。

注意ログ

すべてのデータベースには注意ログがあります。これには、非常に重要かつ際立つデータベース・イベントが含まれます。

注意ログには、重要で可視性の高いデータベース・イベントのみが含まれており、アラートを識別して適切に処置できます。各注意ログ・メッセージには、対象読者、原因、処置などの様々な属性があります。注意ログには、次の形式で情報が提供されます。

Oracle AI Databaseによって、図16-8に示すtraceサブディレクトリにattention_ORACLE_SID.logという名前の注意ログが作成されます。V$DIAG_INFOを問い合せて、注意ログを検索することもできます。

DDLログ

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

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

トレース・ファイル

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

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

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

トレース・ファイルは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 AI 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)。