| Oracle® Database管理者ガイド 11gリリース2 (11.2) B56301-08 |
|
 前 |
 次 |
データベースの動作を定期的に監視することは重要です。監視することによって、気付いていないエラーの情報を取得できるのみでなく、データベースの正常な動作について理解を深めることもできます。正常な動作を理解しておくことで、なんらかの誤りがある場合に状況を容易に認識できるようになります。
この章の内容は、次のとおりです。
次の項では、データベースのエラーおよびアラートを監視する方法について説明します。内容は次のとおりです。
|
注意: データベースのエラーおよびアラートを監視する最も簡単で最適な方法は、Enterprise Managerのデータベース・ホームページを使用することです。この項で説明するのは、データ・ディクショナリ・ビュー、PL/SQLパッケージおよびその他のコマンドライン機能を使用する別の監視方法です。 |
各サーバー・プロセスとバックグラウンド・プロセスは、対応するトレース・ファイルに情報を書き込むことができます。プロセスによって内部エラーが検出されると、エラー情報が関連トレース・ファイルにダンプされます。トレース・ファイルに書き込まれる情報の一部はデータベース管理者用であり、その他の情報は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などのプロセスの名前が含まれます。
|
関連項目:
|
すべてのトレース・ファイル(アラート・ログを除く)の最大サイズは、ファイルを指定のオペレーティング・システム・ブロック数に制限する初期化パラメータMAX_DUMP_FILE_SIZEを使用して制御できます。アラート・ログのサイズを制御するには、不要になったファイルを手動で削除する必要があります。削除しないと、ファイルが引き続き追加されます。
インスタンスの実行中にアラート・ログを削除しても問題はありませんが、削除する前にアラート・ログのアーカイブ・コピーを作成してください。このアーカイブ・コピーは、インスタンス履歴の調査を必要とする問題が発生したときに役立ちます。
バックグラウンド・プロセスは適宜、トレース・ファイルに情報を書き込みます。ARCnバックグラウンド・プロセスの場合は、生成されるトレース情報の量とタイプを初期化パラメータで制御できます。この動作については、「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トレース機能は、著しいシステム・オーバーヘッドを引き起こし、パフォーマンスに重大な影響を及ぼします。このため、統計を収集するときにのみ、この機能を使用可能にしてください。 |
共有サーバーが使用可能な場合、ディスパッチャを使用している各セッションは共有サーバー・プロセスにルーティングされ、セッションのトレースが有効になっている場合(またはエラーが発生した場合)のみ、トレース情報がサーバー・トレース・ファイルに書き込まれます。そのため、ディスパッチャを使用して接続していた特定のセッションのトレースを追跡する場合、複数の共有サーバー・トレース・ファイルを調べる必要がある場合があります。これを容易にするため、Oracleではコマンドライン・ユーティリティ・プログラムtrcsessを用意しており、これを使用すると特定のユーザー・セッションに関連のあるすべてのトレース情報が1箇所にまとめられ、情報が時間の順に並べられます。
|
関連項目: SQLトレース機能の使用方法、およびTKPROFとtrcsessを使用して、生成されたトレース・ファイルを解析する方法の詳細は、 |
サーバー生成アラートとは、切迫した問題に関するOracle Databaseサーバーからの通知です。この通知には、問題を修正するための提案が含まれていることがあります。問題の状況が解決した場合も通知が発行されます。
アラートは、問題が発生した場合や次のようなメトリックに予期した値に対してデータが一致しない場合に自動的に生成されます。
秒当たりの物理読込み数
秒当たりのユーザー・コミット数
SQLサービス応答時間
サーバー生成アラートは、しきい値レベルに基づいて、または単純にイベントの発生に基づいて生成されるように設定できます。しきい値ベースのアラートは、しきい値の警告およびクリティカル・レベルの両方でトリガーできます。これらのレベルの値には、顧客定義または内部値のいずれをも使用でき、一部のアラートには、必要に応じて変更可能な、デフォルトのしきい値レベルが設定されています。たとえばデフォルトで、サーバー生成アラートは領域使用状況について、領域の使用率が85%の警告レベルまたは97%のクリティカルしきい値レベルを超過すると生成されます。しきい値レベルに基づかないアラートには、次のようなものがあります。
スナップショットが古すぎます
再開可能セッションが一時停止されました
Recovery Area Space Usage
アラート・メッセージは、ユーザーSYSが所有する事前定義された永続キューALERT_QUEに送信されます。Oracle Enterprise Managerはこのキューを読込み、未処理のサーバー・アラートの通知を送信したり、場合によっては問題を修正するためのアクションを推奨します。アラートはEnterprise Managerのデータベース・ホームページに表示され、選択した管理者に電子メールまたはページャ通知を送信するように構成できます。アラートをアラート・キューに書き込めない場合、アラートに関するメッセージがOracle Databaseのアラート・ログに書き込まれます。
バックグラウンド・プロセスは、自動ワークロード・リポジトリにデータを定期的にフラッシュして、メトリック値の履歴を取得します。アラート履歴表とALERT_QUEは、システムによって一定の間隔で自動的にパージされます。
サーバー・アラート・メトリックのしきい値設定は、DBMS_SERVER_ALERT PL/SQLパッケージのSET_THRESHOLDおよびGET_THRESHOLDプロシージャを使用して表示および変更できます。次の各項では、これらのプロシージャの使用例を示します。
|
関連項目: DBMS_SERVER_ALERTパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』 |
次の例は、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です。
しきい値を取得するには、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%';
サーバー生成アラートを表示する最も簡単な方法は、Enterprise Managerのデータベース・ホームページにアクセスすることです。次の説明では、これらのアラートを表示する別の方法を示します。
Enterprise Manager以外の独自のツールを使用してアラートを表示する場合は、ALERT_QUEをサブスクライブして、ALERT_QUEを読み取り、アラートにしきい値レベルを設定した後にアラート通知を表示する必要があります。エージェントを作成して、ALERT_QUEにエージェントをサブスクライブするには、DBMS_AQADMパッケージのCREATE_AQ_AGENTおよびADD_SUBSCRIBERプロシージャを使用します。
保護されたALERT_QUEのキューで待機しているメッセージにアクセスできるのは、サブスクライブしているエージェントに関連付けられたユーザーのみであるため、データベース・ユーザーをサブスクライブしているエージェントに関連付ける必要があります。また、そのユーザーにエンキュー権限を付与する必要があります。DBMS_AQADMパッケージのENABLE_DB_ACCESSおよびGRANT_QUEUE_PRIVILEGEプロシージャを使用します。
必要な場合は、DBMS_AQ.REGISTERプロシージャに登録して、アラートがALERT_QUEにエンキューされたときに非同期通知を受信できます。通知は、電子メール、HTTPポストまたはPL/SQLプロシージャの形式にできます。
アラート・メッセージの読込みには、DBMS_AQ.DEQUEUEプロシージャまたはOCIAQDeqコールを使用できます。メッセージをデキューした後、DBMS_SERVER_ALERT.EXPAND_MESSAGEプロシージャを使用して、メッセージのテキストをオープンします。
|
関連項目: DBMS_AQパッケージとDBMS_AQADMパッケージの詳細は、 |
次のデータ・ディクショナリ・ビューは、サーバー生成アラートに関する情報を提供します。
| ビュー | 説明 |
|---|---|
DBA_THRESHOLDS |
インスタンスに定義されているしきい値設定をリストします。 |
DBA_OUTSTANDING_ALERTS |
データベースで未処理のアラートを示します。 |
DBA_ALERT_HISTORY |
消去されたアラートの履歴をリストします。 |
V$ALERT_TYPES |
各アラートのグループやタイプなどの情報を提供します。 |
V$METRICNAME |
メトリックの名前、識別子およびシステム・メトリックに関する他の情報が含まれています。 |
V$METRIC |
システム・レベルのメトリック値が含まれています。 |
V$METRIC_HISTORY |
システム・レベルのメトリック値の履歴が含まれています。 |
|
関連項目: 静的データ・ディクショナリ・ビューと動的パフォーマンス・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。 |
データベース・パフォーマンスの監視の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。ここでは、このガイドに記載されていない詳細を含む追加の内容について説明します。
ロック は、同じリソースにアクセスしている複数のトランザクション間で破壊的な相互作用が起きないようにするメカニズムです。リソースは、表や行などのユーザー・オブジェクト、またはメモリー内の共有データ構造やデータ・ディクショナリ行など、ユーザーに対して表示されないシステム・オブジェクトの場合があります。SQL文の実行中にOracle Databaseが必要なロックを自動的に取得および管理するため、ユーザーが特に意識する必要はありません。ただし、手動でデータをロックすることも可能です。
互いにロックしたデータを2人以上のユーザーが待機している場合は、デッドロックが発生する可能性があります。デッドロックによって、一部のトランザクションが続行できなくなります。Oracle Databaseは、デッドロック状況を自動的に検出し、そのデッドロックに関係している文の1つをロールバックしてデッドロック状況を解決し、競合している行ロックの一方を解放します。
Oracle Databaseは、デッドロックを回避するように設計されているため、デッドロックは頻繁には発生しません。最も多いデッドロックは、トランザクションがデータベースのデフォルトのロックを明示的に無視する場合です。デッドロックはデータベースのパフォーマンスに影響を与える可能性があるため、ロックを監視できるスクリプトとビューが用意されています。
utllockt.sqlスクリプトは、ロックを待機しているシステム上のセッションとそのロックをツリー形式で表示します。このスクリプト・ファイルの位置は、オペレーティング・システムによって異なります。
第2のスクリプトcatblock.sqlはutllockt.sqlに必要なロック・ビューを作成するスクリプトであるため、utllockt.sqlを実行する前に実行する必要があります。
待機イベントとは、イベントの完了を待機してから処理を続行する必要があることを示す統計で、サーバー・プロセスによって増分されます。セッションは、入力の待機、オペレーティング・システムによるディスクへの書込みなどのサービス完了の待機、ロックまたはラッチの待機など、様々な理由で待機することがあります。
セッションがリソースを待機している場合、そのセッションでは効率的な作業が実行されていません。待機の多くはソースに関係しています。待機イベントのデータによって、ラッチの競合、バッファの競合、I/Oの競合など、パフォーマンスに影響を与える可能性がある様々な問題の兆候が明らかになります。
このために、待機イベントの統計を表示するビューが用意されています。これらのビューの説明およびインスタンスをチューニングする際のビューの役割については、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
ここでは、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 |
非親ラッチの統計情報と、親ラッチのサマリー統計情報が含まれています。 |
|
関連項目: これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。 |
