この章では、Oracleデータベース・インスタンスの性質、インスタンスに関連付けられたパラメータ・ファイルと診断ファイル、およびインスタンスの作成時やデータベースのオープン時とクローズ時に発生する処理について説明します。
この章の内容は、次のとおりです。
データベース・インスタンスは、データベース・ファイルを管理する一連のメモリー構造です。データベースは、CREATE DATABASE
文によって作成されたディスク上の一連の物理ファイルです。インスタンスは、関連データを管理し、データベースのユーザーに対応します。
稼働中のすべてのOracleデータベースは、1つ以上のOracleデータベース・インスタンスに関連付けられます。インスタンスはメモリー内に存在し、データベースはディスク上に存在するため、インスタンスがデータベースなしで存在することも、データベースがインスタンスなしで存在することも可能です。
インスタンスが起動されると、Oracle Databaseによってシステム・グローバル領域(SGA)と呼ばれるメモリー領域が割り当てられ、1つ以上のバックグラウンド・プロセスが起動されます。SGAは、次のような様々な目的で機能します。
多くのプロセスおよびスレッドから同時にアクセスされる内部データ構造の維持
ディスクから読み取られるデータ・ブロックのキャッシュ
オンラインREDOログ・ファイルに書き込まれる前のREDOデータのバッファリング
SQL実行計画の格納
SGAは、サーバー・プロセスおよびバックグラウンド・プロセスを含むOracleプロセスで共有され、1台のコンピュータ上で実行されます。OracleプロセスがSGAと関連付けられる方法は、オペレーティング・システムによって異なります。
データベース・インスタンスにはバックグラウンド・プロセスが含まれています。サーバー・プロセスおよびサーバー・プロセスに割り当てられたプロセス・メモリーもインスタンスに存在します。サーバー・プロセスが終了しても、インスタンスは機能し続けます。
図13-1に、Oracleデータベース・インスタンスの主要なコンポーネントを示します。
次の矛盾しない構成のいずれかでOracle Databaseを実行できます。
単一インスタンス構成
データベースとインスタンスの間には1対1関係が存在します。
Oracle Real Application Clusters(Oracle RAC)構成
データベースとインスタンスの間には1対多関係が存在します。
図13-2に、可能なデータベース・インスタンス構成を示します。
単一インスタンス構成とOracle RAC構成のどちらでも、1つのデータベース・インスタンスは一度に1つのデータベースにのみ関連付けられます。データベース・インスタンスを起動して1つのデータベースをマウント(インスタンスに関連付け)できますが、2つのデータベースを同じインスタンスに同時にマウントすることはできません。
注意: この章では、特に記載のないかぎり単一インスタンス・データベース構成について説明します。 |
複数のインスタンスを同時に同じコンピュータ上で実行し、それぞれ専用のデータベースにアクセスさせることができます。たとえば、1台のコンピュータで2つの異なるデータベースprod1
とprod2
をホストできます。1つのデータベース・インスタンスでprod1
を管理し、別のインスタンスでprod2
を管理します。
関連項目: Oracle RACの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。 |
インスタンスは、STARTUP
コマンドを使用して作成されたときに開始し、終了されたときに終了します。この期間中、インスタンスはそのインスタンス自体を1つのデータベースにのみ関連付けることができます。さらに、そのインスタンスでは、データベースのマウント、クローズおよびオープンをそれぞれ1回のみ実行できます。データベースがクローズまたは停止された後、このデータベースをマウントしてオープンするには、別のインスタンスを起動する必要があります。
表13-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-11 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-11 13:16:40
|
この問合せによって、現在のインスタンスが起動された時刻が表示されます。起動時刻が異なるため、このインスタンスがデータベースを停止したインスタンスと異なることがわかります。 |
システム識別子(SID)とは、特定のホスト上でOracleデータベース・インスタンスを示す一意の名前です。UNIXおよびLinuxでは、Oracle DatabaseはSIDとOracleホームの値を使用して共有メモリーに対するキーを作成します。また、SIDは、デフォルトでパラメータ・ファイルを検索するためにも使用され、パラメータ・ファイルは、データベース制御ファイルなどの関連ファイルの検索に使用されます。
ほとんどのプラットフォームでは、ORACLE_SID
環境変数によってSIDが設定され、ORACLE_HOME
変数によってOracleホームが設定されます。インスタンスへの接続時に、クライアントはOracle Net接続のSIDを指定するか、ネット・サービス名を使用できます。サービス名は、Oracle DatabaseによってORACLE_HOME
とORACLE_SID
に変換されます。
データベース・インスタンスにより、ユーザーはデータベースにアクセスできます。この項では、インスタンスとデータベースがどのような状態になる可能性があるかについて説明します。
通常のユースケースでは、手動でインスタンスを起動してから、データベースをマウントおよびオープンし、ユーザーが使用できるようにします。SQL*Plus STARTUP
コマンド、Oracle Enterprise Manager(Enterprise Manager)またはSRVCTLユーティリティを使用して、これらの手順を実行できます。図13-3に、データベースの停止状態からオープン状態までの経過を示します。
データベースが停止状態からオープン状態になるとき、次のフェーズを経由します。
データベースにマウントせずにインスタンスを起動
インスタンスは起動されますが、まだデータベースと関連付けられていません。
この段階については、「インスタンスの起動方法」を参照してください。
データベースのマウント
インスタンスが起動され、データベースの制御ファイルを読み取ってデータベースと関連付けられます(「制御ファイルの概要」を参照)。データベースは、ユーザーに対してクローズされています。
この段階については、「データベースのマウント方法」を参照してください。
データベースのオープン
インスタンスが起動され、オープン状態のデータベースと関連付けられます。データファイルに含まれるデータは、許可されたユーザーからアクセス可能になります。
この段階については、「データベースのオープン方法」で説明しています。
関連項目:
|
データベースの起動と停止は、管理者権限を使用してOracle Databaseに接続するユーザーのみが実行できる強力な管理オプションです。一般のユーザーは、Oracleデータベースの現在の状態を制御できません。
ユーザーの管理者権限を確立するには、オペレーティング・システムに応じて、次のいずれかの条件が必要です。
SYSDBA
とSYSOPER
は、データベースがオープンしていない場合でもデータベース・インスタンスにアクセスできる、特別なシステム権限です。これらの権限は、データベースでは制御されません。SYSDBA
システム権限で接続すると、ユーザーはSYS
が所有するスキーマ内に置かれます。SYSOPER
として接続すると、そのユーザーはパブリック・スキーマ内に置かれます。SYSOPER
権限は、SYSDBA
権限のサブセットです。
関連項目:
|
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では次のアクションを自動的に実行します。
UNDO表領域以外の表領域でオンライン・データファイルをオープンします。
データベースを前回停止したときに表領域がオフラインであった場合は(「オンライン表領域とオフライン表領域」を参照)、データベースを再オープンしたとき、その表領域と対応するデータファイルはオフラインのままです。
UNDO表領域を取得します。
複数のUNDO表領域が存在する場合には、使用するUNDO表領域をUNDO_TABLESPACE
初期化パラメータで指定できます。このパラメータが設定されていない場合、使用可能な最初のUNDO表領域が選択されます。
オンラインREDOログ・ファイルをオープンします。
デフォルトでは、データベースは読取り/書込みモードでオープンします。このモードでは、ユーザーがデータを変更し、オンラインREDOログにREDOを生成できます。また、読取り専用モードでオープンすると、ユーザー・トランザクションによってデータが変更されるのを防ぐことができます。
読取り専用モードでは、データベース・アクセスは読取り専用トランザクションに限定され、データファイルやオンラインREDOログ・ファイルに書き込むことはできません。ただし、データベースではリカバリや、REDOを生成しないでデータベースの状態を変更する操作を実行できます。たとえば、読取り専用モードでは、次の操作を実行できます。
データファイルのオフラインとオンラインを切り替えることができます。ただし、永続表領域はオフライン化できません。
オフラインのデータファイルと表領域をリカバリできます。
制御ファイルは、データベースの状態の更新に引き続き使用できます。
CREATE TEMPORARY TABLESPACE
文を使用して作成された一時表領域は、読取り/書込み可能です。
関連項目: データベースを読取り専用モードでオープンする方法の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
通常のユースケースでは、手動でデータベースを停止し、メンテナンスや他の管理作業の実行中にユーザーがデータベースを使用できないようにします。SQL*Plus SHUTDOWN
コマンドまたはEnterprise Managerを使用して、これらの手順を実行できます。図13-4に、オープン状態から一貫性のある停止状態までの経過を示します。
オープン状態のデータベースが一貫性のある状態で停止されるときは、Oracle Databaseが次の手順を自動的に実行します。
データベースのクローズ
データベースはマウントされていますが、オンライン・データファイルとREDOログ・ファイルはクローズされます。
この段階については、「データベースのクローズ方法」を参照してください。
データベースのアンマウント
インスタンスは起動状態にありますが、データベースの制御ファイルとの関連付けは解消されます。
この段階については、「データベースのアンマウント方法」を参照してください。
データベース・インスタンスの停止
データベース・インスタンスは起動状態にありません。
この段階については、「インスタンスの停止方法」を参照してください。
インスタンス障害やSHUTDOWN ABORT
の場合、Oracle Databaseは前述の手順のすべてを実行せず、インスタンスを即時に終了します。
関連項目: データベースの停止方法の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。 |
SYSDBA
またはSYSOPER
権限を持つデータベース管理者は、SQL*PlusのSHUTDOWN
コマンドまたはEnterprise Managerを使用してデータベースを停止できます。SHUTDOWN
コマンドには、停止動作を指定するオプションがあります。表13-2に、様々な停止モードの動作の概要を示します。
表13-2 停止モード
データベースの動作 | ABORT | IMMEDIATE | TRANSACTIONAL | NORMAL |
---|---|---|---|---|
新しいユーザー接続を許可 |
いいえ |
いいえ |
いいえ |
いいえ |
現行セッションが終了するまで待機 |
いいえ |
いいえ |
いいえ |
はい |
現行トランザクションが終了するまで待機 |
いいえ |
いいえ |
はい |
はい |
チェックポイントを実行し、オープン状態のファイルをクローズ |
いいえ |
はい |
はい |
はい |
使用可能なSHUTDOWN
文は、次のとおりです。
SHUTDOWN ABORT
このモードは、他の停止方法が機能しない場合などの非常時のために用意されています。これは最速の停止モードです。ただし、停止後にこのデータベースをオープンする際に、データファイルの整合性を保つためにインスタンス・リカバリを実行する必要があるため、非常に長い時間がかかる場合があります。
SHUTDOWN IMMEDIATE
通常は、SHUTDOWN
ABORT
の次に速い停止モードです。Oracle Databaseは、実行中のSQL文をすべて終了し、ユーザーとの接続を切断します。アクティブなトランザクションは終了され、コミットされていない変更はロールバックされます。
SHUTDOWN TRANSACTIONAL
このモードでは、ユーザーが新しいトランザクションを開始することはできませんが、すべての現行トランザクションが完了するまで待機してから停止します。現行トランザクションの性質によっては、停止までにかなりの時間がかかる場合があります。
SHUTDOWN NORMAL
これはデフォルトの停止モードです。データベースは、接続されたすべてのユーザーの接続が解除されるまで待機してから停止します。
関連項目:
|
データベースのクローズ操作は、データベース停止時に暗黙的に実行されます。この操作の性質は、データベースが正常停止されたか、異常停止されたかによって異なります。
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つとなっています。DBWnは、実行する処理の有無を少なくとも3秒ごとにチェックします。DBWnが使用済バッファを書き込むと、チェックポイント位置が前進し、これにより、CKPTでは、このチェックポイント位置をデータファイル・ヘッダーではなく制御ファイルに書き込みます。
その他のタイプには、インスタンスとメディア・リカバリのチェックポイント、およびスキーマ・オブジェクトが削除または切り捨てられたときのチェックポイントがあります。
関連項目:
|
インスタンス・リカバリは、オンライン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が自動的に適用されます。ユーザーが介入する必要はありません。
関連項目:
|
インスタンス・リカバリでは、データファイルに適用する必要がある変更を判断するためにチェックポイントが使用されます。チェックポイント位置は、チェックポイントSCNより小さいSCNを持つすべてのコミット済の変更がデータファイルに保存されることを保証するものです。
図13-5に、オンラインREDOログ内のREDOスレッドを示します。
インスタンス・リカバリ時には、データベースによってチェックポイント位置からREDOスレッドの最後までに発生した変更が適用される必要があります。図13-5に示されているように、変更の一部はすでにデータファイルに書き込まれています。ただし、ディスクに書き込まれるのは、チェックポイント位置より小さいSCNを持つ変更のみであることが保証されます。
関連項目: リカバリ時間の制限方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
インスタンス・リカバリの最初のフェーズは、キャッシュ・リカバリまたはロールフォワードと呼ばれ、このフェーズでは、オンラインREDOログに記録されているすべての変更がデータファイルに再適用されます。オンラインREDOログにはロールバック・データが記録されているため、ロールフォワードでは対応するUNDOセグメントも再生成されます。
ロールフォワードでは、必要に応じて多数のオンラインREDOログ・ファイルをたどり、データベースを後の時点まで進行させます。ロールフォワード後のデータ・ブロックには、オンラインREDOログ・ファイルに記録されたコミット済の変更がすべて含まれています。これらのファイルには、障害発生前にデータファイルに保存されていたか、オンラインREDOログに記録されてキャッシュ・リカバリ時に取り込まれた、コミットされていない変更も含まれることがあります。
ロールフォワード後は、コミットされなかった変更を取り消す必要があります。Oracle Databaseでは、チェックポイント位置が使用され、これにより、チェックポイントSCNより小さいSCNを持つすべてのコミット済の変更がディスクに保存されることが保証されます。Oracle Databaseでは、UNDOブロックの適用により、障害発生前に書き込まれたか、キャッシュ・リカバリ中に取り込まれたデータ・ブロック内の、コミットされていない変更がロールバックされます。このフェーズは、ロールバックまたはトランザクション・リカバリと呼ばれます。
図13-6に、ロールフォワードとロールバックを示します。この2つは、データベース・インスタンスの障害からのリカバリに必要なステップです。
Oracle Databaseは、必要に応じて同時に複数のトランザクションをロールバックできます。 障害時点でアクティブになっていたトランザクションすべてに、終了マークが付けられます。終了したトランザクションがSMONプロセスによりロールバックされるのを待たずに、新しいトランザクションによりトランザクション自体で個別のブロックをロールバックし、必要なデータを取得できます。
関連項目:
|
データベース・インスタンスを起動するには、Oracle Databaseはサーバー・パラメータ・ファイル(推奨)またはテキスト形式の初期化パラメータ・ファイル(従来型の実装)を読み取る必要があります。これらのファイルには、構成パラメータのリストが格納されます。
データベースを手動で作成するには、パラメータ・ファイルを使用してインスタンスを起動してから、CREATE DATABASE
コマンドを発行する必要があります。このため、データベース自体が存在していない場合でも、インスタンスとパラメータ・ファイルが存在することがあります。
初期化パラメータは、インスタンスの基本操作に影響する構成パラメータです。インスタンスは、起動時にファイルから初期化パラメータを読み取ります。
Oracle Databaseには、様々な環境に応じて操作を最適化する多数の初期化パラメータが用意されています。ほとんどの場合はデフォルト値のままで十分で、明示的な設定を必要とするパラメータはごく少数です。
ほとんどの初期化パラメータは、次の機能グループのいずれかに属しています。
ファイルやディレクトリなどのエンティティに名前を指定するパラメータ
プロセス、データベース・リソースまたはデータベース自体の制限を設定するパラメータ
可変パラメータを使用するとデータベースのパフォーマンスを改善できるため、これらのパラメータは、特にデータベース管理者によって頻繁に使用されます。
初期化パラメータは、基本と拡張という2つのグループに分かれています。ほとんどの場合、妥当なパフォーマンスを得るには、約30種類の基本パラメータのみを設定およびチューニングする必要があります。基本パラメータでは、データベース名、制御ファイルの場所、データベース・ブロック・サイズ、UNDO表領域などの特性を設定します。
ただし最適なパフォーマンスを得るために、拡張パラメータの変更が必要になる場合があります。拡張パラメータを使用することによって、熟練したDBAは固有の要件にあわせてOracle Databaseの動作を調整できます。
Oracle Databaseは、データベース・ソフトウェアで提供される最初の初期化パラメータ・ファイル、またはDatabase Configuration Assistantにより作成される最初の初期化パラメータ・ファイルに値を提供します(「データベースのインストールおよび構成ツール」を参照)。構成およびデータベースのチューニング計画に応じて、これらのOracle提供の初期化パラメータを編集し、他のパラメータを追加できます。該当する初期化パラメータがパラメータ・ファイルに組み込まれていない場合には、Oracle Databaseによりデフォルトが指定されます。
関連項目:
|
サーバー・パラメータ・ファイルは、Oracle Databaseにより管理される初期化パラメータのリポジトリです。サーバー・パラメータ・ファイルには、主に次の特徴があります。
サーバー・パラメータ・ファイルは、データベースに対して1つのみ存在します。このファイルは、データベース・ホストに常駐する必要があります。
サーバー・パラメータ・ファイルは、クライアント・アプリケーションではなく、Oracle Databaseのみが書込みと読取りを実行します。
サーバー・パラメータ・ファイルはバイナリであり、テキスト・エディタでは編集できません。
サーバー・パラメータ・ファイルに格納されている初期化パラメータは永続的です。データベース・インスタンスの実行中に行われたパラメータの変更は、インスタンスを停止して起動しても残ります。
サーバー・パラメータ・ファイルを使用すると、クライアント・アプリケーション用に複数のテキスト形式の初期化パラメータ・ファイルを保持する必要がなくなります。サーバー・パラメータ・ファイルは、最初は、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でデータベースを起動できるようにする必要があるとします。この場合、図13-7に示すように、個別のテキスト形式の初期化パラメータ・ファイルが2つ(コンピュータごとに1つ)存在する必要があります。サーバー・パラメータ・ファイルは、パラメータ・ファイルが増加する問題を解決します。
関連項目:
|
初期化パラメータを調整してデータベースの動作を変更できます。パラメータの分類が静的であるか、動的であるかによって、パラメータの変更方法が決まります。表13-3に、これらの違いの概要を示します。
表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サポートとのやりとりの簡略化
自動診断リポジトリ(ADR)は、トレース・ファイル、アラート・ログ、状態モニター・レポートなどデータベース診断データを格納するファイルベース・リポジトリです。ADRの主な特徴は、次のとおりです。
統合ディレクトリ構造
一貫性のある診断データ形式
統合されたツール・セット
これらの特性により、ユーザーとOracleサポートは、複数のOracleインスタンス、コンポーネントおよび製品間で診断データを相関付けて、分析できます。
ADRはデータベースの外側に位置するため、物理データベースが使用不可の場合でも、Oracle DatabaseはADRにアクセスして管理できます。インスタンスにより、データベースの作成が完了する前にADRが作成されることがあります。
ADRは、データベース内で重大なエラーとなる問題を予防的に追跡します。重大なエラーとは、ORA-600
などの内部エラーや他のサーバー・エラーのことです。各問題には、問題を説明する文字列である問題キーがあります。
1つの問題が複数回発生した場合は、発生するたびに、タイムスタンプの付いたインシデントがADRによって作成されます。インシデントは、数字のインシデントIDによって一意に識別されます。インシデントが発生すると、ADRではインシデント・アラートをEnterprise Managerに送信します。通常、重大なエラーを診断および解決する場合、最初にインシデント・アラートを確認します。
1つの問題で短時間に多数のインシデントが生成される場合があるため、ADRでは特定のしきい値に到達した後、インシデントの生成にフラッド制御を適用します。大量データを制御されたインシデントでは、アラート・ログ・エントリは生成されますが、インシデントのダンプは生成されません。この方法では、ADRから重大なエラーが継続中であることが通知され、診断データによるシステムのオーバーロードは回避されます。
関連項目: 障害診断性インフラストラクチャの詳細は、『Oracle Database管理者ガイド』を参照してください。 |
ADRベースは、ADRのルート・ディレクトリです。ADRベースには、複数のADRホームを格納でき、それぞれのADRホームは、Oracle製品やコンポーネントのインスタンスごとにすべての診断データ(トレース、ダンプ、アラート・ログなど)を格納するルート・ディレクトリです。たとえば、共有記憶域とASMがあるOracle RAC環境では、各データベース・インスタンスと各ASMインスタンスにはそれぞれ独自のADRホームがあります。
図13-8に、データベース・インスタンスのADRディレクトリ階層を示します。この階層内の同じADRベースの下に、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> SELECT NAME, VALUE FROM V$DIAG_INFO; NAME VALUE --------------------- -------------------------------------------------- Diag Enabled TRUE ADR Base /u01/oracle/log ADR Home /u01/oracle/log/diag/rdbms/dbn/osi Diag Trace /u01/oracle/log/diag/rdbms/dbn/osi/trace Diag Alert /u01/oracle/log/diag/rdbms/dbn/osi/alert Diag Incident /u01/oracle/log/diag/rdbms/dbn/osi/incident Diag Cdump /u01/oracle/log/diag/rdbms/dbn/osi/cdump Health Monitor /u01/oracle/log/diag/rdbms/dbn/osi/hm Default Trace File /u01/oracle/log/diag/rdbms/dbn/osi/trace/osi_ora_10533.trc Active Problem Count 0 Active Incident Count 0
次の各項では、ADRの内容について説明します。
各データベースには、アラート・ログがあり、これは、データベースのメッセージとエラーの履歴ログが格納されたXMLファイルです。アラート・ログの内容は次のとおりです。
すべての内部エラー(ORA-600
)、ブロック破損エラー(ORA-1578
)およびデッドロック・エラー(ORA-60
)
管理的な操作(たとえば、DDL文やSQL*PlusコマンドのSTARTUP
、SHUTDOWN
、ARCHIVE LOG
、およびRECOVER
など)
共有サーバーとディスパッチャ・プロセスの機能に関係するいくつかのメッセージとエラー。
マテリアライズド・ビューの自動リフレッシュにおけるエラー。
Oracle Databaseでは、Enterprise ManagerのGUIに情報を表示するかわりに、アラート・ログを使用します。管理操作が成功すると、Oracle Databaseはタイムスタンプとともに「completed」というメッセージをアラート・ログに書き込みます。
最初にデータベース・インスタンスを起動すると、データベースがまだ作成されていない場合でも、Oracle Databaseは図13-8
に示すalertサブディレクトリにアラート・ログを作成します。次の例では、テキストのみのアラート・ログの一部を示します。
Fri Jun 19 17:05:34 2011 Starting ORACLE instance (normal) LICENSE_MAX_SESSION = 0 LICENSE_SESSIONS_WARNING = 0 Shared memory segment for instance monitoring created Picked latch-free SCN scheme 2 Autotune of undo retention is turned on. IMODE=BR ILAT =12 LICENSE_MAX_USERS = 0 SYS auditing is disabled Starting up ORACLE RDBMS Version: 11.2.0.0.0. Using parameter settings in client-side pfile . . . System parameters with nondefault values: db_name = "my_test" Fri Jun 19 17:05:37 2011 PMON started with pid=2, OS id=10329 Fri Jun 19 17:05:37 2011 VKTM started with pid=3, OS id=10331 at elevated priority VKTM running at (20)ms precision Fri Jun 19 17:05:37 2011 DIAG started with pid=4, OS id=10335
例13-1に示すように、アラート・ログを検索するにはV$DIAG_INFO
を問い合せます。
トレース・ファイルは、問題の調査に使用される診断データを含む管理用のファイルです。「パフォーマンス診断およびチューニング」で説明しているように、トレース・ファイルは、アプリケーションやインスタンスをチューニングするための手引きにもなります。
それぞれのサーバーとバックグラウンド・プロセスは、関連付けられたトレース・ファイルに定期的に書き込むことができます。トレース・ファイルには、プロセスの環境、ステータス、アクティビティおよびエラーに関する情報が含まれています。
SQLトレース機能でも、個別のSQL文に関するパフォーマンス情報を提供するトレース・ファイルが作成されます。クライアント識別子、サービス、モジュール、アクション、セッション、インスタンスまたはデータベースのトレースを有効にするには、DBMS_MONITOR
パッケージで適切なプロシージャを実行するか、Oracle Enterprise Managerを使用する必要があります。
ダンプは、特別なタイプのトレース・ファイルです。多くの場合、トレースでは診断データが連続して出力されますが、ダンプでは、通常、1つのイベント(インシデントなど)に対応して診断データが1回出力されます。インシデントが発生すると、データベースは、そのインシデント用に作成されたインシデント・ディレクトリに1つ以上のダンプを書き込みます。インシデントのダンプには、ファイル名にインシデント番号も付きます。
関連項目:
|
図13-8
に示すように、ADRはトレース・ファイルをtraceサブディレクトリに格納します。トレース・ファイル名はプラットフォーム依存であり、拡張子.trc
が使用されます。
通常、データベース・バックグラウンド・プロセスのトレース・ファイル名には、Oracle SID、バックグラウンド・プロセス名およびオペレーティング・システムのプロセス番号が含まれています。たとえば、RECO
プロセスのトレース・ファイル名は、mytest_reco_10355.trc
のようになります。
サーバー・プロセスのトレース・ファイル名には、Oracle SID、文字列ora
およびオペレーティング・システムのプロセス番号が含まれています。たとえば、サーバー・プロセスのトレース・ファイル名は、mytest_ora_10304.trc
のようになります。
トレース・ファイルには、対応するトレース・マップ(.trm
)のファイルが付くことがあります。これらのファイルには、トレース・ファイルの構造に関する情報が含まれており、検索やナビゲーションに使用されます。
関連項目: トレース・ファイルの検索方法の詳細は、『Oracle Database管理者ガイド』を参照してください。 |