データベースの監視

8 データベースの監視

データベースの動作を定期的に監視することは重要です。監視することによって、気付いていないエラーの情報を取得できるのみでなく、データベースの正常な動作について理解を深めることもできます。正常な動作を理解しておくことで、なんらかの誤りがある場合に状況を容易に認識できるようになります。

エラーおよびアラートの監視
データベースのエラーやアラートを監視することにより、問題を予防、検出および解決できます。
パフォーマンスの監視
パフォーマンスの監視には、ロックおよび待機イベントの監視、一連のデータ・ディクショナリ・ビューの問合せが含まれます。
隔離されたオブジェクトの監視
オブジェクトの隔離により、破損したリカバリ不能なオブジェクトが存在する場合でも、Oracleデータベースが機能できるようにすることができます。V$QUARANTINEビューに、隔離されたオブジェクトの情報が含まれています。

親トピック: 基本データベース管理

8.1 エラーおよびアラートの監視

データベースのエラーやアラートを監視することにより、問題を予防、検出および解決できます。

ノート:

データベースでのエラーおよびアラートを監視する場合、Oracle Enterprise Manager Cloud Control (Cloud Control)のデータベース・ホームページを使用する方法が最も簡単であり、かつ最適です。詳細は、Cloud Controlのオンライン・ヘルプを参照してください。この項で説明するのは、データ・ディクショナリ・ビュー、PL/SQLパッケージおよびその他のコマンドライン機能を使用する別の監視方法です。

トレース・ファイルおよびアラート・ログを使用したエラーの監視
トレース・ファイルは、問題を調査するために使用される診断データを含むファイルです。アラート・ログは、データベース・メッセージおよびエラーの時系列ログを提供するファイルです。
サーバー生成アラートを使用したデータベースの監視
サーバー生成アラートは、切迫した問題のOracle Databaseサーバーからの通知です。

親トピック: データベースの監視

8.1.1 トレース・ファイルおよびアラート・ログを使用したエラーの監視

トレース・ファイルは、問題の調査に使用される診断データが含まれるファイルです。アラート・ログは、データベース・メッセージおよびエラーの時系列ログを提供するファイルです。

トレース・ファイルおよびアラート・ログを使用したエラーの監視について
トレース・ファイルおよびアラート・ログには、エラーに関する情報が含まれています。
アラート・ログのサイズの制御
アラート・ログのサイズを制御するには、必要でないファイルを手動で削除する必要があります。削除しないと、ファイルが引き続き追加されます。
トレース・ファイル・サイズの制御
初期化パラメータMAX_DUMP_FILE_SIZEを使用して、すべてのトレース・ファイル(アラート・ログを除く)の最大サイズを制御できます。
Oracle Databaseがトレース・ファイルに書き込む時期の制御
適切な場合、バックグラウンド・プロセスは常にトレース・ファイルに書き込みます。
共有サーバー・セッション用トレース・ファイルの読込み
共有サーバーが使用可能な場合、ディスパッチャを使用している各セッションは共有サーバー・プロセスにルーティングされ、セッションのトレースが有効になっている場合(またはエラーが発生した場合)のみ、トレース情報がサーバー・トレース・ファイルに書き込まれます。そのため、ディスパッチャを使用して接続していた特定のセッションのトレースを追跡する場合、複数の共有サーバー・トレース・ファイルを調べる必要がある場合があります。

親トピック: エラーおよびアラートの監視

8.1.1.1 トレース・ファイルおよびアラート・ログを使用したエラーの監視について

トレース・ファイルとアラート・ログには、エラーについての情報が含まれています。

各サーバー・プロセスとバックグラウンド・プロセスは、対応するトレース・ファイルに情報を書き込むことができます。プロセスによって内部エラーが検出されると、エラー情報が関連トレース・ファイルにダンプされます。トレース・ファイルに書き込まれる情報の一部はデータベース管理者用であり、その他の情報はOracleサポート・サービス用です。また、トレース・ファイルの情報は、アプリケーションとインスタンスのチューニングにも使用されます。

ノート:

クリティカル・エラーの場合は、自動診断リポジトリにインシデントおよびインシデント・ダンプも作成されます。詳細は、問題の診断と解決を参照してください。

アラート・ログはメッセージとエラーの履歴ログであり、次の項目が含まれます。

発生したすべての内部エラー(ORA-00600)、ブロック破損エラー(ORA-01578)およびデッドロック・エラー(ORA-00060)
いくつかのCREATE、ALTERおよびDROP文などの管理操作、およびSTARTUP、SHUTDOWNおよびARCHIVELOG文
共有サーバーとディスパッチャ・プロセスの機能に関係するメッセージとエラー
マテリアライズド・ビューの自動リフレッシュ中に発生したエラー
データベースとインスタンスの起動時点でデフォルト以外の値があったすべての初期化パラメータの値

Oracle Databaseは、オペレータのコンソール上に情報を表示するかわりに(一部のシステムではコンソール上に情報を表示する)、アラート・ログを使用して、これらの操作を記録します。操作が成功すると、タイムスタンプとともに「completed」というメッセージがアラート・ログに書き込まれます。

アラート・ログは、XML形式ファイルとテキスト形式ファイルの両方として維持されます。いずれの形式のアラート・ログもテキスト・エディタで表示でき、XML形式のファイルはADRCIユーティリティを使用してXMLタグが削除された状態で表示できます。

バックグラウンド・プロセスでエラーが発生していないかどうかを確認するために、インスタンスのアラート・ログとトレース・ファイルを定期的にチェックします。たとえば、ログ・ライター・プロセス(LGWR)でログ・グループのメンバーに書き込むことができないと、LGWRトレース・ファイルとアラート・ログに、問題の内容を示すエラー・メッセージが書き込まれます。このようなエラー・メッセージが見つかった場合は、メディアまたはI/Oの問題が発生しているため、ただちに解決する必要があります。

Oracle Databaseは、他の重要な統計に加えて、初期化パラメータの値もアラート・ログに書き込みます。

バックグラウンドおよびサーバー・プロセスのアラート・ログおよびすべてのトレース・ファイルは自動診断リポジトリに書き込まれ、これらの場所はDIAGNOSTIC_DEST初期化パラメータで指定されます。トレース・ファイル名はオペレーティング・システム固有ですが、通常、各ファイルにはそれを書き込むLGWRやRECOなどのプロセスの名前が含まれます。

関連項目:

自動診断リポジトリ(ADR)の詳細は、問題の診断と解決を参照してください。
アラート・ログの詳細は、「アラート・ログ」を参照してください。
「アラート・ログの表示」
ADRCIユーティリティの詳細は、『Oracle Databaseユーティリティ』を参照してください。
トレース・ファイルの名前の詳細は、オペレーティング・システム固有のOracleマニュアルを参照してください。

親トピック: トレース・ファイルおよびアラート・ログを使用したエラーの監視

8.1.1.2 アラート・ログのサイズの制御

アラート・ログのサイズを制御するには、不要になったファイルを手動で削除する必要があります。削除しないと、ファイルが引き続き追加されます。

インスタンスの実行中にアラート・ログを削除しても問題はありませんが、削除する前にアラート・ログのアーカイブ・コピーを作成してください。このアーカイブ・コピーは、インスタンス履歴の調査を必要とする問題が発生したときに役立ちます。

アラート・ログのサイズを制御するには:

アラート・ログ・ファイルを削除します。

親トピック: トレース・ファイルおよびアラート・ログを使用したエラーの監視

8.1.1.3 トレース・ファイル・サイズの制御

初期化パラメータMAX_DUMP_FILE_SIZEを使用して、すべてのトレース・ファイル(アラート・ログを除く)の最大サイズを制御できます。

このパラメータは、次の方法で設定できます。

数値により、オペレーティング・システム・ブロック内の最大サイズを指定します。制限を取得するために、指定された値がブロック・サイズで乗算されます。
数値の後に接尾辞K、MまたはGを付けることによって、ファイル・サイズをKB、MBまたはGB単位で指定します。
デフォルトであるUNLIMITEDでは、制限は指定されません。

トレース・ファイル・セグメンテーションとMAX_DUMP_FILE_SIZE
Oracle Databaseでは、MAX_DUMP_FILE_SIZE初期化パラメータで指定された制限に基づいて、自動的にトレース・ファイルをセグメントに分割できます。制限に達すると、データベースで順序番号が使用され、現在のトレース・ファイルの名前が変更され、元の名前を使用して空のファイルが作成されます。

関連項目:

MAX_DUMP_FILE_SIZE初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
IPSの詳細は、「Oracle Databaseの障害診断インフラストラクチャについて」

親トピック: トレース・ファイルおよびアラート・ログを使用したエラーの監視

8.1.1.3.1 トレース・ファイルのセグメント化およびMAX_DUMP_FILE_SIZE

Oracle Databaseでは、MAX_DUMP_FILE_SIZE初期化パラメータを使用して指定した制限に基づいて、トレース・ファイルに対し自動的にセグメントを作成できます。制限に達すると、データベースで順序番号が使用され、現在のトレース・ファイルの名前が変更され、元の名前を使用して空のファイルが作成されます。

次の表は、MAX_DUMP_FILE_SIZEの設定に基づいたトレース・ファイルのセグメントを示しています。

表8-1 MAX_DUMP_FILE_SIZEパラメータおよびトレース・ファイルのセグメント化

MAX_DUMP_FILE_SIZEの設定	トレース・ファイルのセグメント化
`UNLIMITED`	トレース・ファイルにセグメントは作成されません。
`15M`より大きい	トレース・ファイルは、`MAX_DUMP_FILE_SIZE`の設定の1/5の境界でセグメント化されます。この境界未満のサイズのトレース・ファイルはセグメント化されません。たとえば、`MAX_DUMP_FILE_SIZE`の設定が`100M`の場合、境界は20MB (100MBの1/5)になります。
`15M`以下	トレース・ファイルにセグメントは作成されません。

最大5までセグメントを作成することが可能ですが、セグメントの合計サイズはMAX_DUMP_FILE_SIZEの制限以下にする必要があります。トレース・ファイルのすべてのセグメントの合計サイズが指定した制限を超える場合、1番目のセグメントの後の最も古いセグメントが削除され、新しい空のセグメントが作成されます。したがって、トレース・ファイルには常に最新のトレース情報を含んでいることになります。最初のセグメントは、プロセスの初期状態に該当する情報が含まれる可能性があるため削除されません。

セグメントは、トレース・ファイルのスペース管理を向上させます。具体的には、セグメントによって次の方法でトレース・ファイルを管理することが可能になります。

古いトレース・ファイルは、不要になった場合消去できます。
小さなトレース・ファイルで問題を診断し、インシデント・パッケージング・サービス(IPS)用にパッケージするトレース・ファイルを分離できます。

ノート:

インシデントを含む時間範囲をカバーするセグメントは削除されません。それは5個のデフォルト・セグメントに加えて維持されます。

親トピック: トレース・ファイル・サイズの制御

8.1.1.4 Oracle Databaseがトレース・ファイルに書き込む時期の制御

バックグラウンド・プロセスは適宜、トレース・ファイルに情報を書き込みます。

ARCnバックグラウンド・プロセスの場合、LOG_ARCHIVE_TRACE初期化パラメータを介して、生成されるトレース情報の量およびタイプを制御することが可能です。これを行うには:

「ARCHIVELOGプロセスによって生成されるトレース出力の制御」の項で説明されている手順を実行してください。

他のバックグラウンド・プロセスには、このような柔軟性はありません。

クリティカル・エラーが発生したときは必ず、サーバー・プロセスのためにトレース・ファイルに情報が書き込まれます。また、初期化パラメータSQL_TRACE = TRUEを設定すると、SQLトレース機能が有効になり、インスタンスに対するすべてのSQL文の処理についてパフォーマンス統計が生成され、自動診断リポジトリに書き込まれます。

必要に応じて、サーバー・プロセスに対するトレース・ファイルの生成を要求できます。SQL文ALTER SESSION SET SQL_TRACEを使用すると、SQL_TRACE初期化パラメータの現行の値にかかわらず、対応するサーバー・プロセスのために各セッションのトレース・ロギングを使用可能または使用禁止にできます。次の例は、特定のセッションに対してSQLトレース機能を使用可能にします。

ALTER SESSION SET SQL_TRACE TRUE;

セッションのSQLトレースを制御するには、DBMS_SESSIONまたはDBMS_MONITORパッケージを使用します。

ノート:

サーバー・プロセスのSQLトレース機能は、著しいシステム・オーバーヘッドを引き起こし、パフォーマンスに重大な影響を及ぼします。このため、統計を収集するときにのみ、この機能を使用可能にしてください。

関連項目:

データベースでクリティカル・エラー(インシデントとも呼ばれる)がどのように処理されるかの詳細は、問題の診断と解決を参照してください。

親トピック: トレース・ファイルおよびアラート・ログを使用したエラーの監視

8.1.1.5 共有サーバー・セッション用トレース・ファイルの読込み

共有サーバーが使用可能な場合、ディスパッチャを使用している各セッションは共有サーバー・プロセスにルーティングされ、セッションのトレースが有効になっている場合(またはエラーが発生した場合)のみ、トレース情報がサーバー・トレース・ファイルに書き込まれます。そのため、ディスパッチャを使用して接続していた特定のセッションのトレースを追跡する場合、複数の共有サーバー・トレース・ファイルを調べる必要がある場合があります。

これを容易にするため、Oracleではコマンドライン・ユーティリティ・プログラムtrcsessを用意しており、これを使用すると特定のユーザー・セッションに関連のあるすべてのトレース情報が1箇所にまとめられ、情報が時間の順に並べられます。

関連項目:

SQLトレース機能の使用、および生成されたトレース・ファイルを解析するTKPROFとtrcsessの使用の詳細は、『Oracle Database SQLチューニング・ガイド』

親トピック: トレース・ファイルおよびアラート・ログを使用したエラーの監視

8.1.2 サーバー生成アラートを使用したデータベースの監視

サーバー生成アラートとは、切迫した問題に関するOracle Databaseサーバーからの通知です。

サーバー生成アラートによるデータベースの監視について
サーバー生成アラートに、問題を修正するための提案が含まれている場合があります。問題の状況が解決した場合も通知が発行されます。
サーバー生成アラートのしきい値の設定と取得
サーバー・アラート・メトリックのしきい値設定は、DBMS_SERVER_ALERT PL/SQLパッケージのSET_THRESHOLDおよびGET_THRESHOLDプロシージャを使用して表示および変更できます。
サーバー生成アラートの表示
サーバー生成アラートを表示するには、Cloud Controlのデータベース・ホーム・ページにアクセスするのが最も簡単な方法ですが、これ以外にもこれらのアラートを表示する方法があります。
サーバー生成アラートのデータ・ディクショナリ・ビュー
サーバー生成アラートの情報についてデータ・ディクショナリ・ビューを問い合せることができます。

親トピック: エラーおよびアラートの監視

8.1.2.1 サーバー生成アラートによるデータベースの監視について

サーバー生成アラートには、問題を修正するための提案が含まれていることがあります。問題の状況が解決した場合も通知が発行されます。

アラートは、問題が発生した場合や次のようなメトリックに予期した値に対してデータが一致しない場合に自動的に生成されます。

秒当たりの物理読込み数
秒当たりのユーザー・コミット数
SQLサービス応答時間

サーバー生成アラートは、しきい値レベルに基づいて、または単純にイベントの発生に基づいて生成されるように設定できます。しきい値ベースのアラートは、しきい値の警告およびクリティカル・レベルの両方でトリガーできます。これらのレベルの値には、顧客定義または内部値のいずれをも使用でき、一部のアラートには、必要に応じて変更可能な、デフォルトのしきい値レベルが設定されています。たとえばデフォルトで、サーバー生成アラートは領域使用状況について、領域の使用率が85%の警告レベルまたは97%のクリティカルしきい値レベルを超過すると生成されます。しきい値レベルに基づかないアラートには、次のようなものがあります。

スナップショットが古すぎます
再開可能セッションが一時停止されました
リカバリ領域の領域使用

アラート・メッセージは、ユーザーSYSが所有する事前定義された永続キューALERT_QUEに送信されます。Cloud Controlはこのキューを読み込み、未処理のサーバー・アラートの通知を送信したり、場合によっては問題を修正するための処理を推奨します。アラートはCloud Controlのデータベース・ホームページに表示され、選択した管理者に電子メールまたはページャ通知を送信するように構成できます。アラートをアラート・キューに書き込めない場合、アラートに関するメッセージがOracle Databaseのアラート・ログに書き込まれます。

バックグラウンド・プロセスは、自動ワークロード・リポジトリにデータを定期的にフラッシュして、メトリック値の履歴を取得します。アラート履歴表とALERT_QUEは、システムによって一定の間隔で自動的にパージされます。

親トピック: サーバー生成アラートを使用したデータベースの監視

8.1.2.2 サーバー生成アラートのしきい値の設定と取得

サーバー・アラート・メトリックのしきい値設定は、DBMS_SERVER_ALERT PL/SQLパッケージのSET_THRESHOLDおよびGET_THRESHOLDプロシージャを使用して表示および変更できます。

ノート:

しきい値を設定および取得する最も便利な方法は、Cloud Controlのグラフィカル・インタフェースを使用する方法です。手順は、アラート管理に関するCloud Controlのオンライン・ヘルプを参照してください。

しきい値レベルの設定
DBMS_SERVER_ALERTパッケージのSET_THRESHOLDプロシージャは、しきい値のレベルを設定できます。
しきい値情報の取得
DBMS_SERVER_ALERTパッケージのGET_THRESHOLDプロシージャは、しきい値の情報を取得できます。

関連項目:

DBMS_SERVER_ALERTパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

親トピック: サーバー生成アラートを使用したデータベースの監視

8.1.2.2.1 しきい値レベルの設定

DBMS_SERVER_ALERTパッケージのSET_THRESHOLDプロシージャは、しきい値のレベルを設定できます。

しきい値のレベルを設定するには:

DBMS_SERVER_ALERTパッケージのSET_THRESHOLDプロシージャを実行し、適切な引数を指定します。

次の例は、SET_THRESHOLDプロシージャを使用して、インスタンスに対する各ユーザー・コールのCPU時間にしきい値を設定する方法を示しています。

DBMS_SERVER_ALERT.SET_THRESHOLD(
 DBMS_SERVER_ALERT.CPU_TIME_PER_CALL, DBMS_SERVER_ALERT.OPERATOR_GE, '8000', 
 DBMS_SERVER_ALERT.OPERATOR_GE, '10000', 1, 2, 'inst1',
 DBMS_SERVER_ALERT.OBJECT_TYPE_SERVICE, 'main.regress.rdbms.dev.us.example.com');

この例では、各ユーザー・コールのCPU時間が8,000マイクロ秒を超えた場合は警告アラートが、各ユーザー・コールのCPU時間が10,000マイクロ秒を超えた場合はクリティカル・アラートが発行されます。次の引数が指定されています。

CPU_TIME_PER_CALLは、メトリック識別子を指定しています。サポートされるメトリックのリストは、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
観察期間は1分に設定しています。条件がしきい値を逸脱し、ここに指定した期間(分単位)にわたって逸脱状態が継続すると、アラートが発行されます。
連続発生回数は2回に設定しています。ここに指定した回数分メトリック値がしきい値に違反すると、アラートが生成されます。
インスタンスの名前はinst1に設定しています。
定数DBMS_ALERT.OBJECT_TYPE_SERVICEは、しきい値が設定されるオブジェクト型を指定します。この例では、サービス名はmain.regress.rdbms.dev.us.example.comです。

親トピック: サーバー生成アラートのしきい値の設定と取得

8.1.2.2.2 しきい値情報の取得

DBMS_SERVER_ALERTパッケージのGET_THRESHOLDプロシージャは、しきい値の情報を取得できます。

しきい値を取得するには:

DBMS_SERVER_ALERTパッケージのGET_THRESHOLDプロシージャを実行し、適切な引数を指定します。

次の例は、しきい値を取得します。

DECLARE
 warning_operator         BINARY_INTEGER;
 warning_value            VARCHAR2(60);
 critical_operator        BINARY_INTEGER; 
 critical_value           VARCHAR2(60);
 observation_period       BINARY_INTEGER;
 consecutive_occurrences  BINARY_INTEGER;
BEGIN
 DBMS_SERVER_ALERT.GET_THRESHOLD(
 DBMS_SERVER_ALERT.CPU_TIME_PER_CALL, warning_operator, warning_value,
    critical_operator, critical_value, observation_period, 
    consecutive_occurrences, 'inst1',
 DBMS_SERVER_ALERT.OBJECT_TYPE_SERVICE, 'main.regress.rdbms.dev.us.example.com');
 DBMS_OUTPUT.PUT_LINE('Warning operator:       ' || warning_operator);
 DBMS_OUTPUT.PUT_LINE('Warning value:          ' || warning_value);
 DBMS_OUTPUT.PUT_LINE('Critical operator:      ' || critical_operator);
 DBMS_OUTPUT.PUT_LINE('Critical value:         ' || critical_value);     
 DBMS_OUTPUT.PUT_LINE('Observation_period:     ' || observation_period);
 DBMS_OUTPUT.PUT_LINE('Consecutive occurrences:' || consecutive_occurrences);
END;
/

DBA_THRESHOLDSビューを使用して、特定のしきい値設定をチェックすることもできます。たとえば:

SELECT metrics_name, warning_value, critical_value, consecutive_occurrences 
   FROM DBA_THRESHOLDS 
   WHERE metrics_name LIKE '%CPU Time%';

親トピック: サーバー生成アラートのしきい値の設定と取得

8.1.2.3 サーバー生成アラートの表示

サーバー生成アラートを表示するには、Cloud Controlのデータベース・ホーム・ページにアクセスするのが最も簡単な方法ですが、これ以外にもこれらのアラートを表示する方法があります。

Cloud Controlではなく、独自のツールを使用してアラートを表示する場合は、サーバー生成アラートを表示するための次のステップを実行してください。

ALERT_QUEにサブスクライブします。
ALERT_QUEを読み取ります。
アラートのしきい値レベルを設定した後にアラート通知を表示します

エージェントを作成し、ALERT_QUEにエージェントをサブスクライブするには、次のステップを実行します。

DBMS_AQADMパッケージのCREATE_AQ_AGENTプロシージャを実行します。
DBMS_AQADMパッケージのADD_SUBSCRIBERプロシージャを実行します。
保護されたALERT_QUEのキューで待機しているメッセージにアクセスできるのは、サブスクライブしているエージェントに関連付けられたユーザーのみであるため、サブスクライブしているエージェントとデータベース・ユーザーを関連付けます。
DBMS_AQADMパッケージのENABLE_DB_ACCESSおよびGRANT_QUEUE_PRIVILEGEプロシージャを実行することにより、ユーザーにエンキュー権限を割り当てます。
アラートがALERT_QUEにエンキューされたときに非同期通知を受信するために、DBMS_AQ.REGISTERプロシージャで登録します。通知は、電子メール、HTTPポストまたはPL/SQLプロシージャの形式にできます。

アラート・メッセージを読むには、次のステップを実行します。

DBMS_AQ.DEQUEUEプロシージャまたはOCIAQDeqコールを使用します。
メッセージをデキューした後、DBMS_SERVER_ALERT.EXPAND_MESSAGEプロシージャを使用して、メッセージのテキストをオープンします。

関連項目:

DBMS_AQパッケージの詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスを参照
DBMS_AQADMパッケージについては、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください

親トピック: サーバー生成アラートを使用したデータベースの監視

8.1.2.4 サーバー生成アラートのデータ・ディクショナリ・ビュー

サーバー生成アラートの情報について、データ・ディクショナリ・ビューに問い合せることができます。

ビュー	説明
`DBA_THRESHOLDS`	インスタンスに定義されているしきい値設定をリストします。
`DBA_OUTSTANDING_ALERTS`	データベースで未処理のアラートを示します。
`DBA_ALERT_HISTORY`	クリアされたアラートの履歴をリストします。
`V$ALERT_TYPES`	各アラートのグループやタイプなどの情報を提供します。
`V$METRICNAME`	メトリックの名前、識別子およびシステム・メトリックに関する他の情報が含まれています。
`V$METRIC`	システム・レベルのメトリック値が含まれています。
`V$METRIC_HISTORY`	システム・レベルのメトリック値の履歴が含まれています。

親トピック: サーバー生成アラートを使用したデータベースの監視

8.2 パフォーマンスの監視

パフォーマンスの監視には、ロックおよび待機イベントの監視、一連のデータ・ディクショナリ・ビューの問合せが含まれます。

データベース・パフォーマンスの監視の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』および『Oracle Database SQLチューニング・ガイド』を参照してください。

ロックの監視
ロックは、同じリソースにアクセスする複数のトランザクション間で破壊的な相互作用を防止するメカニズムです。リソースは、表や行などのユーザー・オブジェクト、またはメモリー内の共有データ構造やデータ・ディクショナリ行など、ユーザーに対して表示されないシステム・オブジェクトの場合があります。
待機イベントの監視について
待機イベントは、処理を継続する前にイベントが完了するまで待機する必要があることを示すために、サーバー・プロセスによって増分される統計です。セッションは、入力の待機、オペレーティング・システムによるディスクへの書込みなどのサービス完了の待機、ロックまたはラッチの待機など、様々な理由で待機することがあります。
パフォーマンス監視のデータ・ディクショナリ・ビュー
Oracle Databaseインスタンスを監視するために、データ・ディクショナリ・ビューのセットを問い合せることができます。

親トピック: データベースの監視

8.2.1 ロックの監視

ロックは、同じリソースにアクセスしている複数のトランザクション間で破壊的な相互作用が起きないようにするメカニズムです。リソースは、表や行などのユーザー・オブジェクト、またはメモリー内の共有データ構造やデータ・ディクショナリ行など、ユーザーに対して表示されないシステム・オブジェクトの場合があります。

SQL文の実行中にOracle Databaseが必要なロックを自動的に取得および管理するため、ユーザーが特に意識する必要はありません。ただし、手動でデータをロックすることも可能です。

互いにロックしたデータを2人以上のユーザーが待機している場合は、デッドロックが発生する可能性があります。デッドロックが発生すると、トランザクションの処理を継続できなくなる場合があります。Oracle Databaseは、デッドロック状況を自動的に検出し、そのデッドロックに関係している文の1つをロールバックしてデッドロック状況を解決し、競合している行ロックの一方を解放します。

Oracle Databaseは、デッドロックを回避するように設計されているため、デッドロックは頻繁には発生しません。最も多いデッドロックは、トランザクションがデータベースのデフォルトのロックを明示的に無視する場合です。デッドロックはデータベースのパフォーマンスに影響を与える可能性があるため、ロックを監視できるスクリプトとビューが用意されています。

ロックを監視するには:

ロック・ビューを作成するcatblock.sqlを実行します。
catblock.sqlによって作成されたビューを使用して、システムでロックを待機中のセッションと、それらが待機しているロックをツリー形式で表示するために、utllockt.sqlスクリプトを実行します。

スクリプト・ファイルの場所は、オペレーティング・システムごとに異なります。

関連項目:

「パフォーマンス監視データ・ディクショナリ・ビュー」
ロックの詳細は、『Oracle Database概要』を参照してください。

親トピック: パフォーマンスの監視

8.2.2 待機イベントの監視について

待機イベントとは、イベントの完了を待機してから処理を続行する必要があることを示す統計で、サーバー・プロセスによって増分されます。セッションは、入力の待機、オペレーティング・システムによるディスクへの書込みなどのサービス完了の待機、ロックまたはラッチの待機など、様々な理由で待機することがあります。

セッションがリソースを待機している場合、そのセッションでは効率的な作業が実行されていません。待機の多くはソースに関係しています。待機イベントのデータによって、ラッチの競合、バッファの競合、I/Oの競合など、パフォーマンスに影響を与える可能性がある様々な問題の兆候が明らかになります。

このために、待機イベントの統計を表示するビューが用意されています。これらのビューの説明およびインスタンスをチューニングする際のビューの役割については、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

親トピック: パフォーマンスの監視

8.2.3 パフォーマンス監視のデータ・ディクショナリ・ビュー

Oracle Databaseインスタンスを監視するために、データ・ディクショナリ・ビューのセットを問い合せることができます。

これらのビューは一般的なものです。プロセス固有の他のビューについては、そのプロセスに関する項を参照してください。

ビュー	説明
`V$LOCK`	現在Oracle Databaseによって保持されているロックと、未処理のロック要求またはラッチ要求が表示されます。
`DBA_BLOCKERS`	別のセッションが待機しているオブジェクトのロックを保持しているセッションが表示されます。
`DBA_WAITERS`	ロックされているオブジェクトを待機しているセッションが表示されます。
`DBA_DDL_LOCKS`	データベース内のすべてのDDLロックおよびDDLロックに対する未処理の要求すべてが表示されます。
`DBA_DML_LOCKS`	データベース内のすべてのDMLロックおよびDMLロックに対する未処理の要求すべてが表示されます。
`DBA_LOCK`	データベース内のすべてのロックまたはラッチ、およびロックまたはラッチに対する未処理の要求すべてが表示されます。
`DBA_LOCK_INTERNAL`	保持しているロックまたはラッチごとに1行、ロックまたはラッチの未処理要求ごとに1行の情報が表示されます。
`V$LOCKED_OBJECT`	システム上のすべてのトランザクションが獲得したすべてのロックがリストされます。
`V$SESSION_WAIT`	アクティブ・セッションが待機しているリソースまたはイベントが表示されます。
`V$SYSSTAT`	セッション統計情報が含まれています。
`V$RESOURCE_LIMIT`	一部のシステム・リソースについて、現行および最大のグローバル・リソース使用率が表示されます。
`V$SQLAREA`	共有SQL領域に関する統計情報が、SQL文字列ごとに1行ずつ含まれています。また、メモリー内にあり、解析済で、実行準備のできているSQL文に関する統計情報も提供します。
`V$LATCH`	非親ラッチの統計情報と、親ラッチのサマリー統計情報が含まれています。

親トピック: パフォーマンスの監視

8.3 隔離されたオブジェクトの監視

オブジェクトの隔離により、破損したリカバリ不能なオブジェクトが存在する場合でも、Oracleデータベースが機能できるようにすることができます。V$QUARANTINEビューに、隔離されたオブジェクトの情報が含まれています。

オブジェクトの隔離について
オブジェクトの隔離は、エラーが発生したオブジェクトを隔離し、システムへの影響についてオブジェクトを監視します。
隔離されたオブジェクトの表示
V$QUARANTINEビューに、現在隔離されているオブジェクトの情報が格納されています。

親トピック: データベースの監視

8.3.1 オブジェクトの隔離について

オブジェクトの隔離は、エラーが発生したオブジェクトを隔離し、システムへの影響についてオブジェクトを監視します。

ORA-00600およびORA-07445などのいくつかのOracle Databaseエラーにより、通常ではプロセスが終了し、これによりデータベースが終了する可能性があります。このようなエラーが発生した場合、データベースの実行を継続できるように、オブジェクトの隔離はエラーの発生したリソースの隔離を試みます。データベースの残りの部分に影響を与えないように、リソースはメモリーに隔離されます。V$QUARANTINEビューに、現在隔離されているオブジェクトの情報が格納されています。

ほとんどのデータベース・リソースは、データベースを終了する可能性があるエラーを発生することがあります。たとえば、ライブラリ・キャッシュ・メモリー・オブジェクトは、このようなエラーを発生することがあります。

マルチテナント環境では、場合によっては、マルチテナント・コンテナ・データベース(CDB)がオブジェクトの隔離を使用して、CDBを終了せずに、重大なエラーの発生したプラガブル・データベース(PDB)を隔離し、終了することもできます。

通常、隔離されたリソースは、データベースが再起動するまで隔離されたままです。リソースがCDBにPDBのために隔離されている場合、PDBがクローズし、再オープンするまで、リソースは隔離されています。

親トピック: 隔離されたオブジェクトの監視

8.3.2 隔離されたオブジェクトの表示

V$QUARANTINEビューに、現在隔離されているオブジェクトの情報が格納されています。

データベースに管理ユーザーとして接続します。
V$QUARANTINEビューを問い合せます。

例8-1 V$QUARANTINEビューの問合せ

この問合せは、現在隔離されているリソースを表示します。

COLUMN OBJECT FORMAT A10
COLUMN ADDRESS FORMAT A10
COLUMN BYTES FORMAT 999999999
COLUMN ERROR FORMAT A20
COLUMN TIMESTAMP FORMAT A20

SELECT OBJECT, ADDRESS, BYTES, ERROR, TIMESTAMP
   FROM V$QUARANTINE;

出力は次のようになります。

OBJECT     ADDRESS         BYTES ERROR                TIMESTAMP
---------- ---------- ---------- -------------------- --------------------
session    0000000078       9528 ORA-00600: internal  16-SEP-15 01.17.42.2
           B54BC8                error code, argument 85878 PM -07:00
                                 s: [12345], [], [], 
                                 [], [], [], [], [], 
                                 [], [], [], []

この出力は、隔離されたリソースについて次のことを示しています。

リソースの名前は「session」です。
隔離されているメモリー領域の開始アドレスは0000000078B54BC8です。通常、これは、この例のセッションなどのリソースのアドレスです。
リソースは、隔離中に9528バイトのメモリーを使用しています。
リソースが隔離される原因となったエラー・メッセージは、ORA-00600内部エラー・コードです。
タイムスタンプがエラーの日付と時間を示しています。

親トピック: 隔離されたオブジェクトの監視