データベースの動作を定期的に監視することは重要です。監視することによって、気付いていないエラーの情報を取得できるのみでなく、データベースの正常な動作について理解を深めることもできます。正常な動作を理解しておくことで、なんらかの誤りがある場合に状況を容易に認識できるようになります。
データベースのエラーやアラートを監視することにより、問題を予防、検出および解決できます。
注意:
データベースでのエラーおよびアラートを監視する場合、Oracle Enterprise Manager Cloud Control (Cloud Control)のデータベース・ホームページを使用する方法が最も簡単であり、かつ最適です。詳細は、Cloud Controlのオンライン・ヘルプを参照してください。この項で説明するのは、データ・ディクショナリ・ビュー、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などのプロセスの名前が含まれます。
関連項目:
自動診断リポジトリの詳細は、「診断データの管理」を参照してください。
アラート・ログの詳細は、「アラート・ログ」を参照してください。
ADRCIユーティリティの詳細は、『Oracle Databaseユーティリティ』を参照してください。
トレース・ファイルの名前の詳細は、オペレーティング・システム固有のOracleマニュアルを参照してください。
アラート・ログのサイズを制御するには、不要になったファイルを手動で削除する必要があります。削除しないと、ファイルが引き続き追加されます。
インスタンスの実行中にアラート・ログを削除しても問題はありませんが、削除する前にアラート・ログのアーカイブ・コピーを作成してください。このアーカイブ・コピーは、インスタンス履歴の調査を必要とする問題が発生したときに役立ちます。
アラート・ログのサイズを制御するには:
アラート・ログ・ファイルを削除します。
初期化パラメータMAX_DUMP_FILE_SIZE
を使用して、すべてのトレース・ファイル(アラート・ログを除く)の最大サイズを制御できます。
このパラメータは、次の方法で設定できます。
数値により、オペレーティング・システム・ブロック内の最大サイズを指定します。制限を取得するために、指定された値がブロック・サイズで乗算されます。
数値の後に接尾辞K、MまたはGを付けることによって、ファイル・サイズをKB、MBまたはGB単位で指定します。
デフォルトであるUNLIMITED
では、制限は指定されません。
関連項目:
MAX_DUMP_FILE_SIZE
初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
Oracle Databaseでは、MAX_DUMP_FILE_SIZE
初期化パラメータを使用して指定した制限に基づいて、トレース・ファイルに対し自動的にセグメントを作成できます。制限に達すると、データベースで順序番号が使用され、現在のトレース・ファイルの名前が変更され、元の名前を使用して空のファイルが作成されます。
次の表は、MAX_DUMP_FILE_SIZE
の設定に基づいたトレース・ファイルのセグメントを示しています。
表8-1 MAX_DUMP_FILE_SIZEパラメータおよびトレース・ファイルのセグメント化
MAX_DUMP_FILE_SIZEの設定 | トレース・ファイルのセグメント化 |
---|---|
|
トレース・ファイルにセグメントは作成されません。 |
|
トレース・ファイルは、 |
|
トレース・ファイルにセグメントは作成されません。 |
最大5までセグメントを作成することが可能ですが、セグメントの合計サイズはMAX_DUMP_FILE_SIZE
の制限以下にする必要があります。トレース・ファイルのすべてのセグメントの合計サイズが指定した制限を超える場合、1番目のセグメントの後の最も古いセグメントが削除され、新しい空のセグメントが作成されます。したがって、トレース・ファイルには常に最新のトレース情報を含んでいることになります。最初のセグメントは、プロセスの初期状態に該当する情報が含まれる可能性があるため削除されません。
セグメントは、トレース・ファイルのスペース管理を向上させます。具体的には、セグメントによって次の方法でトレース・ファイルを管理することが可能になります。
古いトレース・ファイルは、不要になった場合消去できます。
小さなトレース・ファイルで問題を診断し、インシデント・パッケージング・サービス(IPS)用にパッケージするトレース・ファイルを分離できます。
注意:
インシデントを含む時間範囲をカバーするセグメントは削除されません。それは5個のデフォルト・セグメントに加えて維持されます。
バックグラウンド・プロセスは適宜、トレース・ファイルに情報を書き込みます。
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トレース機能は、著しいシステム・オーバーヘッドを引き起こし、パフォーマンスに重大な影響を及ぼします。このため、統計を収集するときにのみ、この機能を使用可能にしてください。
関連項目:
データベースによるクリティカル・エラー(インシデントとも呼ばれる)の処理方法の詳細は、「診断データの管理」を参照してください。
共有サーバーが使用可能な場合、ディスパッチャを使用している各セッションは共有サーバー・プロセスにルーティングされ、セッションのトレースが有効になっている場合(またはエラーが発生した場合)のみ、トレース情報がサーバー・トレース・ファイルに書き込まれます。そのため、ディスパッチャを使用して接続していた特定のセッションのトレースを追跡する場合、複数の共有サーバー・トレース・ファイルを調べる必要がある場合があります。
これを容易にするため、Oracleではコマンドライン・ユーティリティ・プログラムtrcsess
を用意しており、これを使用すると特定のユーザー・セッションに関連のあるすべてのトレース情報が1箇所にまとめられ、情報が時間の順に並べられます。
関連項目:
SQLトレース機能の使用、および生成されたトレース・ファイルを解析するTKPROF
とtrcsess
の使用の詳細は、『Oracle Database SQLチューニング・ガイド』
サーバー生成アラートとは、切迫した問題に関するOracle Databaseサーバーからの通知です。
サーバー生成アラートに、問題を修正するための提案が含まれている場合があります。問題の状況が解決した場合も通知が発行されます。
アラートは、問題が発生した場合や次のようなメトリックに予期した値に対してデータが一致しない場合に自動的に生成されます。
秒当たりの物理読込み数
秒当たりのユーザー・コミット数
SQLサービス応答時間
サーバー生成アラートは、しきい値レベルに基づいて、または単純にイベントの発生に基づいて生成されるように設定できます。しきい値ベースのアラートは、しきい値の警告およびクリティカル・レベルの両方でトリガーできます。これらのレベルの値には、顧客定義または内部値のいずれをも使用でき、一部のアラートには、必要に応じて変更可能な、デフォルトのしきい値レベルが設定されています。たとえばデフォルトで、サーバー生成アラートは領域使用状況について、領域の使用率が85%の警告レベルまたは97%のクリティカルしきい値レベルを超過すると生成されます。しきい値レベルに基づかないアラートには、次のようなものがあります。
スナップショットが古すぎます
再開可能セッションが一時停止されました
Recovery Area Space Usage
アラート・メッセージは、ユーザーSYS
が所有する事前定義された永続キューALERT_QUE
に送信されます。Cloud Controlはこのキューを読み込み、未処理のサーバー・アラートの通知を送信したり、場合によっては問題を修正するための処理を推奨します。アラートはCloud Controlのデータベース・ホームページに表示され、選択した管理者に電子メールまたはページャ通知を送信するように構成できます。アラートをアラート・キューに書き込めない場合、アラートに関するメッセージがOracle Databaseのアラート・ログに書き込まれます。
バックグラウンド・プロセスは、自動ワークロード・リポジトリにデータを定期的にフラッシュして、メトリック値の履歴を取得します。アラート履歴表とALERT_QUE
は、システムによって一定の間隔で自動的にパージされます。
サーバー・アラート・メトリックのしきい値設定は、DBMS_SERVER_ALERT
PL/SQLパッケージのSET_THRESHOLD
およびGET_THRESHOLD
プロシージャを使用して表示および変更できます。
注意:
しきい値を設定および取得する最も便利な方法は、Cloud Controlのグラフィカル・インタフェースを使用する方法です。手順は、アラート管理に関するCloud Controlのオンライン・ヘルプを参照してください。
関連項目:
DBMS_SERVER_ALERT
パッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
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
です。
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%';
サーバー生成アラートを表示するには、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
パッケージとDBMS_AQADM
パッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
サーバー生成アラートの情報について一連のデータ・ディクショナリ・ビューを問い合せることができます。
ビュー | 説明 |
---|---|
|
インスタンスに定義されているしきい値設定をリストします。 |
|
データベースで未処理のアラートを示します。 |
|
消去されたアラートの履歴をリストします。 |
|
各アラートのグループやタイプなどの情報を提供します。 |
|
メトリックの名前、識別子およびシステム・メトリックに関する他の情報が含まれています。 |
|
システム・レベルのメトリック値が含まれています。 |
|
システム・レベルのメトリック値の履歴が含まれています。 |
関連項目:
静的データ・ディクショナリ・ビューと動的パフォーマンス・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
パフォーマンスの監視には、ロックおよび待機イベントの監視、一連のデータ・ディクショナリ・ビューの問合せが含まれます。
データベース・パフォーマンスの監視の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』および『Oracle Database SQLチューニング・ガイド』を参照してください。
ロック は、同じリソースにアクセスしている複数のトランザクション間で破壊的な相互作用が起きないようにするメカニズムです。リソースは、表や行などのユーザー・オブジェクト、またはメモリー内の共有データ構造やデータ・ディクショナリ行など、ユーザーに対して表示されないシステム・オブジェクトの場合があります。
SQL文の実行中にOracle Databaseが必要なロックを自動的に取得および管理するため、ユーザーが特に意識する必要はありません。ただし、手動でデータをロックすることも可能です。
互いにロックしたデータを2人以上のユーザーが待機している場合は、デッドロックが発生する可能性があります。デッドロックによって、一部のトランザクションが続行できなくなります。Oracle Databaseは、デッドロック状況を自動的に検出し、そのデッドロックに関係している文の1つをロールバックしてデッドロック状況を解決し、競合している行ロックの一方を解放します。
Oracle Databaseは、デッドロックを回避するように設計されているため、デッドロックは頻繁には発生しません。最も多いデッドロックは、トランザクションがデータベースのデフォルトのロックを明示的に無視する場合です。デッドロックはデータベースのパフォーマンスに影響を与える可能性があるため、ロックを監視できるスクリプトとビューが用意されています。
ロックを監視する手順:
ロック・ビューを作成するcatblock.sql
を実行します。
catblock.sql
によって作成されたビューを使用して、システムでロックを待機中のセッションと、それらが待機しているロックをツリー形式で表示するために、utllockt.sql
スクリプトを実行します。
スクリプト・ファイルの場所は、オペレーティング・システムごとに異なります。
関連項目:
ロックの詳細は、『Oracle Database概要』を参照してください。
待機イベントとは、イベントの完了を待機してから処理を続行する必要があることを示す統計で、サーバー・プロセスによって増分されます。セッションは、入力の待機、オペレーティング・システムによるディスクへの書込みなどのサービス完了の待機、ロックまたはラッチの待機など、様々な理由で待機することがあります。
セッションがリソースを待機している場合、そのセッションでは効率的な作業が実行されていません。待機の多くはソースに関係しています。待機イベントのデータによって、ラッチの競合、バッファの競合、I/Oの競合など、パフォーマンスに影響を与える可能性がある様々な問題の兆候が明らかになります。
このために、待機イベントの統計を表示するビューが用意されています。これらのビューの説明およびインスタンスをチューニングする際のビューの役割については、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
Oracle Databaseインスタンスを監視するために、データ・ディクショナリ・ビューのセットを問い合せることができます。
これらのビューは一般的なものです。プロセス固有の他のビューについては、そのプロセスに関する項を参照してください。
ビュー | 説明 |
---|---|
|
現在Oracle Databaseによって保持されているロックと、未処理のロック要求またはラッチ要求が表示されます。 |
|
別のセッションが待機しているオブジェクトのロックを保持しているセッションが表示されます。 |
|
ロックされているオブジェクトを待機しているセッションが表示されます。 |
|
データベース内のすべてのDDLロックおよびDDLロックに対する未処理の要求すべてが表示されます。 |
|
データベース内のすべてのDMLロックおよびDMLロックに対する未処理の要求すべてが表示されます。 |
|
データベース内のすべてのロックまたはラッチ、およびロックまたはラッチに対する未処理の要求すべてが表示されます。 |
|
保持しているロックまたはラッチごとに1行、ロックまたはラッチの未処理要求ごとに1行の情報が表示されます。 |
|
システム上のすべてのトランザクションが獲得したすべてのロックがリストされます。 |
|
アクティブ・セッションが待機しているリソースまたはイベントが表示されます。 |
|
システム統計情報が含まれています。 |
|
一部のシステム・リソースについて、現行および最大のグローバル・リソース使用率が表示されます。 |
|
共有SQL領域に関する統計情報が、SQL文字列ごとに1行ずつ含まれています。また、メモリー内にあり、解析済で、実行準備のできているSQL文に関する統計情報も提供します。 |
|
非親ラッチの統計情報と、親ラッチのサマリー統計情報が含まれています。 |
関連項目:
これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。