| Oracle® Database概要 12c リリース1 (12.1) B71299-09 |
|
 前 |
 次 |
この章では、Oracleデータベース・インスタンスの性質、インスタンスに関連付けられたパラメータ・ファイルと診断ファイル、およびインスタンスの作成時やデータベースのオープン時とクローズ時に発生する処理について説明します。
この章の内容は、次のとおりです。
データベース・インスタンスは、データベース・ファイルを管理する一連のメモリー構造です。
データベースは、CREATE DATABASE文によって作成されたディスク上の一連の物理ファイルです。インスタンスは、関連データを管理し、データベースのユーザーに対応します。
稼働中のすべてのOracleデータベースは、1つ以上のOracleデータベース・インスタンスに関連付けられます。インスタンスはメモリー内に存在し、データベースはディスク上に存在するため、インスタンスがデータベースなしで存在することも、データベースがインスタンスなしで存在することも可能です。
インスタンスが起動されると、Oracle Databaseによってシステム・グローバル領域(SGA)と呼ばれるメモリー領域が割り当てられ、1つ以上のバックグラウンド・プロセスが起動されます。
SGAは、次のような様々な目的で機能します。
多くのプロセスおよびスレッドから同時にアクセスされる内部データ構造の維持
ディスクから読み取られるデータ・ブロックのキャッシュ
オンラインREDOログ・ファイルに書き込まれる前のREDOデータのバッファリング
SQL実行計画の格納
1つのコンピュータで実行中の複数のOracleプロセスは、SGAを共有します。OracleプロセスがSGAと関連付けられる方法は、オペレーティング・システムによって異なります。
データベース・インスタンスにはバックグラウンド・プロセスが含まれています。サーバー・プロセスおよびサーバー・プロセスに割り当てられたプロセス・メモリーもインスタンスに存在します。サーバー・プロセスが終了しても、インスタンスは機能し続けます。
次の図に、Oracleデータベース・インスタンスの主要なコンポーネントを示します。
Oracle Databaseは、単一インスタンス構成またはOracle Real Application Clusters (Oracle RAC)構成のいずれかで実行されます。これらの構成は相互に排他的です。
単一インスタンス構成では、データベースとデータベース・インスタンスの間に1対1関係が存在します。Oracle RACでは、データベースとデータベース・インスタンスの間に1対多関係が存在します。
次の図に、可能なデータベース・インスタンス構成を示します。
単一インスタンス構成とOracle RAC構成のどちらでも、1つのデータベース・インスタンスは一度に1つのデータベースにのみ関連付けられます。データベース・インスタンスを起動して1つのデータベースをマウント(インスタンスに関連付け)できますが、2つのデータベースを同じインスタンスに同時にマウントすることはできません。
注意:
この章では、特に記載のないかぎり単一インスタンス・データベース構成について説明します。
複数のインスタンスを同時に同じコンピュータ上で実行し、それぞれ専用のデータベースにアクセスさせることができます。たとえば、1台のコンピュータで2つの異なるデータベースprod1とprod2をホストできます。1つのデータベース・インスタンスでprod1を管理し、別のインスタンスでprod2を管理します。
関連項目:
Oracle RACの詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照してください
データベース・インスタンスは、STARTUPコマンドを使用して作成されたときに開始し、終了されたときに終了します。
この期間中、データベース・インスタンスはそのインスタンス自体を1つのデータベースにのみ関連付けることができます。さらに、そのインスタンスでは、データベースのマウント、クローズおよびオープンをそれぞれ1回のみ実行できます。データベースがクローズまたは停止された後、このデータベースをマウントしてオープンするには、別のインスタンスを起動する必要があります。
次の表に、以前にクローズされたデータベースの再オープンを試行するデータベース・インスタンスを示します。
表13-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. |
|
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. . . . |
|
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
|
この問合せによって、現在のインスタンスが起動された時刻が表示されます。起動時刻が異なるため、このインスタンスがデータベースを停止したインスタンスと異なることがわかります。 |
システム識別子(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 SIDの指定方法の詳細は、『Oracle Database管理者ガイド』を参照してください。
データベース・インスタンスにより、ユーザーはデータベースにアクセスできます。インスタンスおよびデータベースを様々な状態にすることができます。
通常、手動でインスタンスを起動してから、データベースをマウントおよびオープンし、ユーザーが使用できるようにします。SQL*Plus STARTUPコマンド、Oracle Enterprise Manager(Enterprise Manager)またはSRVCTLユーティリティを使用して、これらの手順を実行できます。
Oracle Netを使用してデータベース・インスタンスを起動するには、次の条件が満たされている必要があります。
データベースが静的にOracle Netリスナーに登録されていること。
使用クライアントが、SYSDBA権限によりデータベースに接続されていること。
リスナーでは、専用サーバーが作成され、これによりデータベース・インスタンスを起動できます。
次の図に、データベースの停止状態からオープン状態までの経過を示します。
データベースが停止状態からオープン状態になるとき、次のフェーズを経由します。
データベースにマウントせずにインスタンスを起動
インスタンスは起動されますが、まだデータベースと関連付けられていません。
この段階については、「インスタンスの起動方法」を参照してください。
データベースのマウント
インスタンスが起動され、データベースの制御ファイルを読み取ってデータベースと関連付けられます。データベースは、ユーザーに対してクローズされています。
この段階については、「データベースのマウント方法」を参照してください。
データベースのオープン
インスタンスが起動され、オープン状態のデータベースと関連付けられます。データファイルに含まれるデータは、許可されたユーザーからアクセス可能になります。
この段階については、「データベースのオープン方法」を参照してください。
関連項目:
インスタンスの起動方法の詳細は、『Oracle Database管理者ガイド』を参照してください
SRVCTLの使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください
データベースの起動と停止は、管理者権限を使用してOracle Databaseに接続するユーザーのみが実行できる強力な管理オプションです。
一般のユーザーは、Oracleデータベースの現在の状態を制御できません。ユーザーの管理者権限を確立するには、オペレーティング・システムに応じて、次のいずれかの条件が必要です。
ユーザーのオペレーティング・システム権限により、そのユーザーが管理者権限を使用して接続できること。
ユーザーが特別なシステム権限を付与されており、データベースがパスワード・ファイルを使用し、ネットワークを介してデータベース管理者を認証していること。
次の特別なシステム権限により、データベースがオープンされていなくても、データベースにアクセスできます。
SYSDBA
SYSOPER
SYSBACKUP
SYSDG
SYSKM
前述の権限の制御は、データベース機能の範囲外にあります。SYSDBAシステム権限でデータベースに接続すると、そのユーザーはSYSが所有しているスキーマ内に置かれます。SYSOPERとして接続すると、そのユーザーはパブリック・スキーマ内に置かれます。SYSOPER権限は、SYSDBA権限のサブセットです。
関連項目:
データベース管理者を認証するときのパスワード・ファイルと認証方式の詳細は、「データベース・セキュリティの概要」を参照してください
管理権限の管理の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください
システム権限の詳細は、『Oracle Database管理者ガイド』を参照してください
オペレーティング・システム権限グループの詳細は、『Oracle Databaseインストレーション・ガイド』を参照してください
Oracle Databaseがインスタンスを起動する場合、段階的に行われます。
次のようなステージがあります。
プラットフォーム固有のデフォルトの格納場所でサーバー・パラメータ・ファイルを検索します。見つからなかった場合は、テキスト形式の初期化パラメータ・ファイルを検索します(STARTUPにSPFILEまたはPFILEパラメータを指定すると、デフォルトの動作が上書きされます)。
パラメータ・ファイルを読み取り、初期化パラメータの値を決定します。
初期化パラメータの設定に基づいてSGAを割り当てます。
Oracleバックグラウンド・プロセスを起動します。
アラート・ログとトレース・ファイルをオープンし、明示的に設定されたすべてのパラメータ設定をパラメータの有効な構文でアラート・ログに書き込みます。
この時点では、このインスタンスにデータベースは関連付けられていません。NOMOUNT状態が必要とされるシナリオには、データベースの作成および特定のバックアップ操作とリカバリ操作があります。
関連項目:
サーバー・パラメータ・ファイルを使用した初期化パラメータの管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください
インスタンスは、データベースをマウントして、データベースをそのインスタンスに対応付けます。
データベースをマウントすると、そのインスタンスはCONTROL_FILES初期化パラメータに指定されたデータベース制御ファイルの名前を取得し、これらのファイルをオープンします。Oracle Databaseでは、制御ファイルを読み取ることによって、データベースのオープン時にアクセスを試行するデータファイルとオンラインREDOログ・ファイルの名前を検出します。
マウントされたデータベースでは、データベースはクローズされているため、データベース管理者のみがそのデータベースにアクセスできます。管理者は、特定のメンテナンス操作を完了するまでの間、データベースをクローズしたままにしておくことができます。ただし、データベースに対して通常の操作を行うことはできません。
Oracle Databaseで、複数のインスタンスによる同じデータベースの同時マウントが許可されている場合、CLUSTER_DATABASE初期化パラメータの設定で、複数のインスタンスによるデータベースの使用を可能にできます。データベースの動作は、設定によって異なります。
データベースをマウントする最初のインスタンスのCLUSTER_DATABASEパラメータがfalse(デフォルト)の場合は、最初のインスタンスのみがデータベースをマウントできます。
このCLUSTER_DATABASEパラメータがtrueの場合は、他のインスタンスもCLUSTER_DATABASEパラメータの設定がtrueに設定されている状態でデータベースをマウントできます。データベースをマウントできるインスタンスの数は、データベースの作成時に指定された最大数によって決まります。
関連項目:
データベースのマウント方法の詳細は、Oracle Database管理者ガイドを参照してください
1つのデータベースでの複数のインスタンスの使用方法の詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照してください
マウントされたデータベースをオープンすると、そのデータベースで通常のデータベース操作を実行できるようになります。
有効なユーザーは、オープン状態のデータベースに接続して、データベースの情報にアクセスできます。通常、データベース管理者は、データベースをオープンして一般に使用できる状態にします。
データベースをオープンするときに、Oracle Databaseでは次のアクションを自動的に実行します。
UNDO表領域以外の表領域でオンライン・データファイルをオープンします。
データベースを前回停止したときに表領域がオフラインであった場合は、データベースを再オープンしたとき、その表領域と対応するデータファイルはオフラインのままです。
UNDO表領域を取得します。
複数のUNDO表領域が存在する場合には、使用するUNDO表領域をUNDO_TABLESPACE初期化パラメータで指定できます。このパラメータが設定されていない場合、使用可能な最初のUNDO表領域が選択されます。
オンラインREDOログ・ファイルをオープンします。
デフォルトでは、データベースは読取り/書込みモードでオープンします。このモードでは、ユーザーがデータを変更し、オンラインREDOログにREDOを生成できます。また、読取り専用モードでオープンすると、ユーザー・トランザクションによってデータが変更されるのを防ぐことができます。
注意:
デフォルトでは、フィジカル・スタンバイ・データベースは読取り専用モードでオープンします。
読取り専用モードでは、データベース・アクセスは読取り専用トランザクションに限定され、データファイルやオンラインREDOログ・ファイルに書き込むことはできません。ただし、データベースではリカバリや、REDOを生成しないでデータベースの状態を変更する操作を実行できます。たとえば、読取り専用モードでは、次の操作を実行できます。
データファイルのオフラインとオンラインを切り替えることができます。ただし、永続表領域はオフライン化できません。
オフラインのデータファイルと表領域をリカバリできます。
制御ファイルは、データベースの状態の更新に引き続き使用できます。
CREATE TEMPORARY TABLESPACE文を使用して作成された一時表領域は、読取り/書込み可能です。
オペレーティング・システムの監査証跡、トレース・ファイルおよびアラート・ログへの書込みは引き続き実行できます。
関連項目:
データベースを読取り専用モードでオープンする方法の詳細は、『Oracle Database管理者ガイド』を参照してください。
『Oracle Data Guard概要および管理』
通常のユースケースでは、手動でデータベースを停止し、メンテナンスや他の管理作業の実行中にユーザーがデータベースを使用できないようにします。SQL*Plus SHUTDOWNコマンドまたはEnterprise Managerを使用して、これらの手順を実行できます。
次の図に、オープン状態から一貫性のある停止状態までの経過を示します。
オープン状態のデータベースが一貫性のある状態で停止されるときは、Oracle Databaseが次の手順を自動的に実行します。
データベースのクローズ
データベースはマウントされていますが、オンライン・データファイルとREDOログ・ファイルはクローズされます。
この段階については、「データベースのクローズ方法」を参照してください。
データベースのアンマウント
インスタンスは起動状態にありますが、データベースの制御ファイルとの関連付けは解消されます。
この段階については、「データベースのアンマウント方法」を参照してください。
データベース・インスタンスの停止
データベース・インスタンスは起動状態にありません。
この段階については、「インスタンスの停止方法」を参照してください。
インスタンス障害やSHUTDOWN ABORTの場合、Oracle Databaseは前述の手順のすべてを実行せず、インスタンスを即時に終了します。
関連項目:
データベースの停止方法の詳細は、Oracle Database管理者ガイドを参照してください
SYSDBAまたはSYSOPER権限を持つデータベース管理者は、SQL*PlusのSHUTDOWNコマンドまたはEnterprise Managerを使用してデータベースを停止できます。SHUTDOWNコマンドには、停止動作を指定するオプションがあります。
次の表に、様々な停止モードの動作の概要を示します。
表13-2 データベース停止モード
| データベースの動作 | 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
これはデフォルトの停止モードです。データベースは、接続されたすべてのユーザーの接続が解除されるまで待機してから停止します。
関連項目:
様々な停止モードの詳細は、『Oracle Database管理者ガイド』を参照してください。
SHUTDOWNコマンドの詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。
データベースのクローズ操作は、データベース停止時に暗黙的に実行されます。この操作の性質は、データベースが正常停止されたか、異常停止されたかによって異なります。
ABORT以外のオプションが指定されたSHUTDOWNの一環としてデータベースがクローズされると、Oracle DatabaseはSGA内のデータをデータファイルとオンラインREDOログ・ファイルに書き込みます。
次に、データベースはオンライン・データファイルとオンラインREDOログ・ファイルをクローズします。オフライン表領域のオフライン・データファイルは、すでにクローズされています。データベースを再オープンしたとき、オフラインになっていた表領域はオフラインのままです。
この時点でデータベースはクローズされているため、通常の操作は実行できません。データベースがクローズされても、制御ファイルはオープンされたままになります。
データベースがクローズされると、Oracle Databaseはデータベースをアンマウントしてインスタンスから切り離します。
データベースをアンマウン卜すると、Oracle Databaseでは、データベースの制御ファイルがクローズされます。この時点ではデータベース・インスタンスはメモリーに残っています。
データベース停止の最後の操作は、インスタンスの停止です。データベース・インスタンスが停止すると、SGAではメモリーの占有を中止し、バックグラウンド・プロセスが終了します。
異常な状況では、インスタンスが正常に停止しないことがあります。たとえば、メモリー構造がメモリーから削除されない場合や、バックグラウンド・プロセスの1つが終了されない場合があります。前のインスタンスの一部が残っていると、後続のインスタンスの起動が失敗します。このような状況では、残っている前のインスタンスを削除してから新しいインスタンスを起動するか、SQL*PlusまたはEnterprise ManagerでSHUTDOWN ABORT文を発行することで、新しいインスタンスの起動を強制実行できます。
関連項目:
データベースの停止の詳細は、『Oracle Database管理者ガイド』を参照
一般的に、チェックポイントは、一貫性のあるデータベースの停止、インスタンス・リカバリおよびOracle Databaseの操作に不可欠なメカニズムです。
この用語の意味は次のとおりです。
チェックポイント位置を示すデータ構造。これは、インスタンス・リカバリを開始する必要があるREDOストリーム内のSCNです。
チェックポイント位置は、データベース・バッファ・キャッシュ内の最も古い使用済バッファによって決まります。チェックポイント位置は、REDOストリームへのポインタとして機能し、制御ファイル内と各データファイル・ヘッダー内に格納されます。
データベース・バッファ・キャッシュ内の変更済データベース・バッファのディスクへの書込み
関連項目:
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では、このチェックポイント位置をデータファイル・ヘッダーではなく制御ファイルに書き込みます。
その他のタイプには、インスタンスとメディア・リカバリのチェックポイント、およびスキーマ・オブジェクトが削除または切り捨てられたときのチェックポイントがあります。
関連項目:
Oracle RACでのグローバル・チェックポイントの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』 を参照してください
インスタンス・リカバリは、オンラインREDOログ内のレコードをデータファイルに適用し、最新のチェックポイントの後に行われた変更を再構築するプロセスです。
管理者が前回一貫性のない状態で停止されたデータベースの再オープンを試行すると、インスタンス・リカバリが自動的に実行されます。
インスタンス・リカバリは、インスタンス障害後にデータベースが一貫性のある状態になることを保証します。Oracle Databaseでのデータベースの変更管理方法により、データベースのファイルが一貫性のない状態のままになることがあります。
REDOスレッドは、インスタンスによって生成された変更のすべてのレコードです。単一インスタンス・データベースには1つのREDOスレッドがあり、Oracle RACデータベースには各データベース・インスタンスに対応する複数のREDOスレッドがあります。
トランザクションがコミットされると、ログ・ライター・プロセス(LGWR)は、メモリー内の残りのREDOエントリとトランザクションのSCNの両方をオンラインREDOログに書き込みます。ただし、データベース・ライター(DBW)プロセスでは、変更されたデータ・ブロックを最も効率的な時点でデータファイルに書き込みます。このため、コミットされた変更がまだデータファイルに存在しないとき、コミットされていない変更が一時的にデータファイルに存在することがあります。
SHUTDOWN ABORT文または異常終了のいずれかにより、オープン状態のデータベースのインスタンスに障害が発生すると、次の状態になることがあります。
トランザクションによってコミットされたデータ・ブロックはデータファイルに書き込まれず、オンラインREDOログにのみ表示されます。これらの変更は、データ・ファイルに再適用される必要があります。
インスタンスに障害が発生した時点でコミットされていない変更がデータファイルに含まれています。これらの変更は、トランザクションの一貫性を保証するためにロールバックする必要があります。
インスタンス・リカバリは、オンラインREDOログ・ファイルと現行のオンライン・データファイルのみを使用してデータファイルを同期し、これらが一貫性のある状態になることを保証します。
インスタンス・リカバリが必要かどうかは、REDOスレッドの状態によります。
制御ファイル内では、データベース・インスタンスが読取り/書込みモードでオープンすると、REDOスレッドにオープンのマークが付けられ、インスタンスが一貫性のある状態で停止されると、クローズ済のマークが付けられます。REDOスレッドに制御ファイルでオープンのマークが付けられると、稼働中のインスタンスはこれらのスレッドに対応するスレッドのエンキューを保持しないため、データベースでインスタンス・リカバリが必要となります。
Oracle Databaseでは、次の場合にインスタンス・リカバリが自動的に実行されます。
単一インスタンス・データベースまたはOracle RACデータベースの全インスタンスの障害後に、最初にデータベースをオープンするとき。このタイプのインスタンス・リカバリはクラッシュ・リカバリとも呼ばれます。Oracle Databaseでは、終了したインスタンスのオンラインREDOスレッドも同時にリカバリされます。
Oracle RACデータベースに含まれる全インスタンスではなく一部のインスタンスに障害が発生したとき。インスタンス・リカバリは、構成内で正常に稼働しているインスタンスにより自動的に実行されます。
SMONバックグラウンド・プロセスではインスタンス・リカバリが実行され、オンラインREDOが自動的に適用されます。ユーザーが介入する必要はありません。
関連項目:
Oracle RACデータベースでのインスタンス・リカバリの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください
インスタンス・リカバリでは、データファイルに適用する必要がある変更を判断するためにチェックポイントが使用されます。チェックポイント位置は、チェックポイントSCNより小さいSCNを持つすべてのコミット済の変更がデータファイルに保存されることを保証するものです。
次の図に、オンラインREDOログ内のREDOスレッドを示します。
インスタンス・リカバリ時には、データベースによってチェックポイント位置からREDOスレッドの最後までに発生した変更が適用される必要があります。図13-5に示されているように、変更の一部はすでにデータファイルに書き込まれています。ただし、ディスクに書き込まれるのは、チェックポイント位置より小さいSCNを持つ変更のみであることが保証されます。
関連項目:
リカバリ時間の制限方法の詳細は、Oracle Databaseパフォーマンス・チューニング・ガイドを参照してください
インスタンス・リカバリの最初のフェーズは、キャッシュ・リカバリまたはロールフォワードと呼ばれ、オンラインREDOログに記録されているすべての変更をデータファイルに再適用します。オンラインREDOログにはUNDOデータが含まれているため、ロールフォワードでは対応するUNDOセグメントも再生成されます。
ロールフォワードでは、必要に応じて多数のオンラインREDOログ・ファイルをたどり、データベースを後の時点まで進行させます。ロールフォワード後のデータ・ブロックには、オンラインREDOログ・ファイルに記録されたコミット済の変更がすべて含まれています。これらのファイルには、障害発生前にデータファイルに保存されていたか、オンラインREDOログに記録されてキャッシュ・リカバリ時に取り込まれた、コミットされていない変更も含まれることがあります。
ロールフォワード後は、コミットされなかった変更を取り消す必要があります。Oracle Databaseでは、チェックポイント位置が使用され、これにより、チェックポイントSCNより小さいSCNを持つすべてのコミット済の変更がディスクに保存されることが保証されます。Oracle Databaseでは、UNDOブロックの適用により、障害発生前に書き込まれたか、キャッシュ・リカバリ中に取り込まれたデータ・ブロック内の、コミットされていない変更がロールバックされます。このフェーズは、ロールバックまたはトランザクション・リカバリと呼ばれます。
次の図に、ロールフォワードとロールバックを示します。この2つは、データベース・インスタンスの障害からのリカバリに必要なステップです。
Oracle Databaseは、必要に応じて同時に複数のトランザクションをロールバックできます。障害時点でアクティブになっていたトランザクションすべてに、終了マークが付けられます。終了したトランザクションがSMONプロセスによりロールバックされるのを待たずに、新しいトランザクションによりトランザクション自体で個別のブロックをロールバックし、必要なデータを取得できます。
関連項目:
UNDOデータの詳細は、「UNDOセグメント」を参照してください
インスタンス・リカバリのメカニズムとチューニングの詳細は、Oracle Databaseパフォーマンス・チューニング・ガイドを参照してください
データベース・インスタンスを起動するには、Oracle Databaseはサーバー・パラメータ・ファイル(推奨)またはテキスト形式の初期化パラメータ・ファイル(従来型の実装)を読み取る必要があります。これらのファイルには、構成パラメータのリストが格納されます。
データベースを手動で作成するには、パラメータ・ファイルを使用してインスタンスを起動してから、CREATE DATABASE文を発行する必要があります。このため、データベース自体が存在していない場合でも、インスタンスとパラメータ・ファイルが存在することがあります。
初期化パラメータは、インスタンスの基本操作に影響する構成パラメータです。インスタンスは、起動時にファイルから初期化パラメータを読み取ります。
Oracle Databaseには、様々な環境に応じて操作を最適化する多数の初期化パラメータが用意されています。これらのパラメータのごく一部は、通常はデフォルト値のままで十分であり、明示的な設定が必要です。
初期化パラメータは様々な機能グループに分類されます。
ほとんどの初期化パラメータは、次のグループのいずれかに属しています。
ファイルやディレクトリなどのエンティティに名前を指定するパラメータ
プロセス、データベース・リソースまたはデータベース自体の制限を設定するパラメータ
SGAのサイズなどの容量に影響するパラメータ(可変パラメータと呼ばれる)
可変パラメータを使用するとデータベースのパフォーマンスを改善できるため、これらのパラメータは、特にデータベース管理者によって頻繁に使用されます。
初期化パラメータは、基本と拡張という2つのグループに分かれています。
通常、妥当なパフォーマンスを得るには、約30種類の基本パラメータのみを設定およびチューニングする必要があります。基本パラメータでは、データベース名、制御ファイルの場所、データベース・ブロック・サイズ、UNDO表領域などの特性を設定します。
ただし最適なパフォーマンスを得るために、拡張パラメータの変更が必要になる場合があります。拡張パラメータを使用することによって、熟練したDBAは固有の要件にあわせてOracle Databaseの動作を調整できます。
Oracle Databaseは、データベース・ソフトウェアで提供される最初の初期化パラメータ・ファイル、またはDatabase Configuration Assistantにより作成される最初の初期化パラメータ・ファイルに値を提供します。構成およびデータベースのチューニング計画に応じて、これらのOracle提供の初期化パラメータを編集し、他のパラメータを追加できます。該当する初期化パラメータがパラメータ・ファイルに組み込まれていない場合には、Oracle Databaseによりデフォルトが指定されます。
関連項目:
初期化パラメータの指定方法の詳細は、『Oracle Database管理者ガイド』を参照してください
初期化パラメータのタイプの詳細は、『Oracle Databaseリファレンス』を参照してください
V$PARAMETERの詳細は『Oracle Databaseリファレンス』を、SHOW PARAMETER構文については『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください
サーバー・パラメータ・ファイルは、初期化パラメータのリポジトリです。サーバー・パラメータ・ファイルには、主に次の特徴があります。
Oracle Databaseのみが、サーバー・パラメータ・ファイルに対する読取りおよび書き込みを行います。
サーバー・パラメータ・ファイルは、データベースに対して1つのみ存在します。このファイルは、データベース・ホストに常駐する必要があります。
サーバー・パラメータ・ファイルはバイナリであり、テキスト・エディタでは編集できません。
サーバー・パラメータ・ファイルに格納されている初期化パラメータは永続的です。データベース・インスタンスの実行中に行われたパラメータの変更は、インスタンスを停止して起動しても残ります。
サーバー・パラメータ・ファイルを使用すると、クライアント・アプリケーション用に複数のテキスト形式の初期化パラメータ・ファイルを保持する必要がなくなります。サーバー・パラメータ・ファイルは、最初は、CREATE SPFILE文を使用してテキスト形式の初期化パラメータ・ファイルから作成されます。また、Database Configuration Assistantにより直接作成することもできます。
関連項目:
サーバー・パラメータ・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。
CREATE SPFILEの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
テキスト形式の初期化パラメータ・ファイルは、初期化パラメータのリストが格納されるテキスト・ファイルです。
このタイプのパラメータ・ファイルは、従来型の実装のパラメータ・ファイルであり、主に次の特徴があります。
データベースを起動または停止するときに、テキスト形式の初期化パラメータ・ファイルは、データベースに接続するクライアント・アプリケーションと同じホストに常駐する必要があります。
テキスト形式の初期化パラメータ・ファイルはテキストベースであり、バイナリではありません。
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でデータベースを起動できるようにする必要があるとします。この場合、図13-7に示すように、個別のテキスト形式の初期化パラメータ・ファイルが2つ(コンピュータごとに1つ)存在する必要があります。サーバー・パラメータ・ファイルは、パラメータ・ファイルが増加する問題を解決します。
関連項目:
テキスト形式の初期化パラメータ・ファイルの詳細は、Oracle Database管理者ガイドを参照してください
CREATE PFILEの詳細は、Oracle Database SQL言語リファレンスを参照してください
初期化パラメータを調整してデータベースの動作を変更できます。パラメータの分類が静的であるか、動的であるかによって、パラメータの変更方法が決まります。
以下の表にその違いをまとめています。
表13-3 静的な初期化パラメータと動的な初期化パラメータ
| 特徴 | 静的 | 動的 |
|---|---|---|
パラメータ・ファイル(テキストまたはサーバー)を変更する必要性 |
あり |
なし |
設定を有効にする前にデータベース・インスタンスを再起動する必要性 |
あり |
なし |
『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 Databaseリファレンス』を参照してください。
ALTER SYSTEMの構文およびセマンティクスは、『Oracle Database SQL言語リファレンス』を参照してください。
Oracle Databaseには、データベースの問題を防止、検出、診断および解決するための障害診断性インフラストラクチャが含まれています。問題には、コードの不具合、メタデータの破損、顧客データの破損などの重大なエラーがあります。
この高度な障害診断性インフラストラクチャの目的は、次のとおりです。
問題の予防的な検出
問題検出後の損害および障害の制限
問題の診断時間と解決時間の短縮
トレース・ファイルのパーティション化を有効にすること、ユーザーがピース当たりのサイズおよび保持するピースの最大数を定義できるようにすること、ユーザー指定のディスク領域制限に到達後にトレースを無効にすることによる管理容易性の向上
ユーザーとOracleサポートとのやりとりの簡略化
マルチテナント・コンテナ・データベース(CDB)と非CDBには、アーキテクチャに違いがあります。この項では、特に他に指示がないかぎり、非CDBのアーキテクチャを前提としています。
関連項目:
CDBでの診断ファイルの管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください
自動診断リポジトリ(ADR)は、トレース・ファイル、アラート・ログ、DDLログ、状態モニター・レポートなどのデータベース診断データを格納するファイルベース・リポジトリです。
ADRの主な特徴は、次のとおりです。
統合ディレクトリ構造
一貫性のある診断データ形式
統合されたツール・セット
これらの特性により、ユーザーとOracleサポートは、複数のOracleインスタンス、コンポーネントおよび製品間で診断データを相関付けて、分析できます。
ADRはデータベースの外側に位置するため、物理データベースが使用不可の場合でも、Oracle DatabaseはADRにアクセスして管理できます。データベース・インスタンスにより、データベースの作成が完了する前にADRが作成されることがあります。
ADRは、データベース内で重大なエラーとなる問題を予防的に追跡します。
重大なエラーとは、ORA-600などの内部エラーや他のサーバー・エラーのことです。各問題には、問題を説明する文字列である問題キーがあります。
1つの問題が複数回発生した場合は、発生するたびに、タイムスタンプの付いたインシデントがADRによって作成されます。インシデントは、数字のインシデントIDによって一意に識別されます。インシデントが発生すると、ADRではインシデント・アラートをEnterprise Managerに送信します。通常、重大なエラーを診断および解決する場合、最初にインシデント・アラートを確認します。
1つの問題で短時間に多数のインシデントが生成される場合があるため、ADRでは特定のしきい値に到達した後、インシデントの生成にフラッド制御を適用します。大量データを制御されたインシデントでは、アラート・ログ・エントリは生成されますが、インシデントのダンプは生成されません。この方法では、ADRから重大なエラーが継続中であることが通知され、診断データによるシステムのオーバーロードは回避されます。
関連項目:
障害診断性インフラストラクチャの詳細は、『Oracle Database管理者ガイド』を参照してください
図13-8に、データベース・インスタンスのADRディレクトリ階層を示します。この階層内の同じADRベースの下に、Oracle ASMまたはOracle Net Servicesなどの他のOracle製品やコンポーネントに対する別のADRホームを格納できます。
次のLinuxの例に示すように、データベースを作成する前に一意のSIDとデータベース名でインスタンスを起動すると、Oracle Databaseは、ホスト・ファイルシステムのディレクトリ構造としてデフォルトでADRを作成します。SIDとデータベース名は、ADRホーム内のファイルのパス名の一部になります。
例13-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は図13-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
例13-1に示すように、アラート・ログを検索するにはV$DIAG_INFOを問い合せます。
DDLログは、形式および基本的な動作がアラート・ログと同じですが、DDL文および詳細のみが含まれる点が異なります。データベースでは、DDL情報を自身のファイルに書き込み、アラート・ログでの乱雑さを減らします。
DDLログ・レコードはDDLテキストであり、オプションで補足情報より拡張できます。DDL文ごとに1つのログ・レコードが存在します。DDLログは、ADRホームのlog/ddlサブディレクトリに格納されています。
トレース・ファイルは、問題の調査に使用される診断データが含まれるファイルです。また、トレース・ファイルはアプリケーションまたはインスタンスのチューニングにガイダンスを提供することもできます。
関連項目:
それぞれのサーバーとバックグラウンド・プロセスは、関連付けられたトレース・ファイルに定期的に書き込むことができます。トレース・ファイルには、プロセスの環境、ステータス、アクティビティおよびエラーに関する情報が含まれています。
SQLトレース機能でも、個別のSQL文に関するパフォーマンス情報を提供するトレース・ファイルが作成されます。クライアント識別子、サービス、モジュール、アクション、セッション、インスタンスまたはデータベースのトレースを様々な方法で有効化できます。たとえば、DBMS_MONITORパッケージの適切なプロシージャを実行することも、イベントを設定することもできます。
関連項目:
トレース・ファイル、ダンプおよびコア・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。
アプリケーションのトレースの詳細は、Oracle Database SQLチューニング・ガイドを参照してください。
ADRでは、traceサブディレクトリにトレース・ファイルが格納されます。トレース・ファイル名はプラットフォーム依存であり、拡張子.trcが使用されます。
通常、データベース・バックグラウンド・プロセスのトレース・ファイル名には、Oracle SID、バックグラウンド・プロセス名およびオペレーティング・システムのプロセス番号が含まれています。たとえば、RECOプロセスのトレース・ファイル名は、mytest_reco_10355.trcのようになります。
サーバー・プロセスのトレース・ファイル名には、Oracle SID、文字列oraおよびオペレーティング・システムのプロセス番号が含まれています。たとえば、サーバー・プロセスのトレース・ファイル名は、mytest_ora_10304.trcのようになります。
トレース・ファイルには、対応するトレース・メタデータのファイル(拡張子.trmで終わる)が付くことがあります。これらのファイルにはトレース・マップと呼ばれる構造に関する情報が含まれており、データベースでは検索やナビゲーションに使用されます。
関連項目:
トレース・ファイルの検索方法の詳細は、『Oracle Database管理者ガイド』を参照してください
トレース・ファイルのサイズが制限されていると、データベースがトレース・ファイルを最大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)。
