11gリリース1（11.1）
E05760-03
 目次 |
 索引 |
| Oracle Database 管理者ガイド 11gリリース1（11.1） E05760-03 |
|
データベースの動作を定期的に監視することは重要です。監視することによって、気付いていないエラーの情報を取得できるのみでなく、データベースの正常な動作について理解を深めることもできます。正常な動作を理解しておくことで、なんらかの誤りがある場合に状況を容易に認識できるようになります。
この章の内容は次のとおりです。
次の各項では、データベースのエラーおよびアラートを監視する方法について説明します。この章の内容は、次のとおりです。
各サーバー・プロセスとバックグラウンド・プロセスは、対応するトレース・ファイルに情報を書き込むことができます。プロセスによって内部エラーが検出されると、エラー情報が関連トレース・ファイルにダンプされます。トレース・ファイルに書き込まれる情報の一部はデータベース管理者用であり、その他の情報はOracleサポート・サービス用です。また、トレース・ファイルの情報は、アプリケーションとインスタンスのチューニングにも使用されます。
アラート・ログはメッセージとエラーの履歴ログであり、次の項目が含まれます。
ORA-600）、ブロック破損エラー（ORA-1578）およびデッドロック・エラー（ORA-60）
CREATE/ALTER/DROP文、STARTUP/SHUTDOWN文、ARCHIVELOG文などの管理操作
Oracle Databaseは、オペレータのコンソール上に情報を表示するかわりに（一部のシステムではコンソール上に情報を表示する）、アラート・ログを使用して、これらの操作を記録します。操作が成功すると、タイムスタンプとともに「completed」というメッセージがアラート・ログに書き込まれます。
アラート・ログは、XML形式のファイルとテキスト形式のファイルの両方で保持されます。いずれの形式のアラート・ログもテキスト・エディタで表示できます。またはADRCIユーティリティを使用すると、XMLタグが削除された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パッケージを使用します。
共有サーバーが使用可能な場合、ディスパッチャを使用している各セッションは共有サーバー・プロセスに転送され、セッションでトレースが使用可能な場合（または、エラーが発生した場合）のみ、トレース情報がサーバーのトレース・ファイルに書き込まれます。ディスパッチャを使用して接続する特定のセッションのトレースを追跡するには、いくつかの共有サーバーのトレース・ファイルを調べることが必要な場合があります。このために、コマンドライン・ユーティリティ・プログラムtrcsessが用意されています。このプログラムでは、ユーザー・セッションに関係するすべてのトレース情報が1つの場所に統合され、情報が時間で順序付けされます。
サーバー生成アラートとは、切迫した問題に関するOracle Databaseサーバーからの通知です。この通知には、問題を修正するための提案が含まれていることがあります。問題の状況が解決した場合も通知が発行されます。
アラートは、問題が発生した場合や次のようなメトリックに予期した値に対してデータが一致しない場合に自動的に生成されます。
サーバー生成アラートは、しきい値レベルに基づいて発行するように指定できます。あるいは、イベントの発生に従って単純に発行することもできます。しきい値ベースのアラートは、警告レベルおよびクリティカル・レベルのしきい値でトリガーできます。これらのレベルの値には、ユーザー定義の値または内部的な値を指定できます。また、一部のアラートにはデフォルトのしきい値レベルがあり、必要に応じてレベルを変更できます。たとえば、デフォルトでは、領域使用率が85%の警告レベルまたは97%のクリティカル・レベルのしきい値を超えると、表領域使用に関するサーバー生成アラートが生成されます。次に、しきい値レベルに基づくアラートの例を示します。
アラート・メッセージは、ユーザーSYSが所有する事前定義の永続キューALERT_QUEに送信されます。Oracle Enterprise Managerがこのキューを読み取り、未処理のサーバー・アラートに関する通知を提供します。この通知には、問題を修正するための処置が示されている場合があります。アラートはEnterprise Managerのデータベース・ホームページに表示され、選択した管理者に電子メールまたはページャ通知を送信するように構成できます。アラートをアラート・キューに書き込めない場合、アラートに関するメッセージはOracle Databaseのアラート・ログに書き込まれます。
バックグラウンド・プロセスは、自動ワークロード・リポジトリにデータを定期的にフラッシュして、メトリック値の履歴を取得します。アラート履歴表とALERT_QUEは、システムによって一定の間隔で自動的にパージされます。
サーバー・アラート・メトリックのしきい値設定は、DBMS_SERVER_ALERTS PL/SQLパッケージのSET_THRESHOLDおよびGET_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.oracle.com');
この例では、各ユーザー・コールのCPU時間が8,000マイクロ秒を超えた場合は警告アラートが、各ユーザー・コールのCPU時間が10,000マイクロ秒を超えた場合はクリティカル・アラートが発行されます。次の引数が指定されています。
CPU_TIME_PER_CALLは、メトリック識別子を指定しています。 サポートされるメトリックのリストは、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
inst1に設定しています。
DBMS_ALERT.OBJECT_TYPE_SERVICEは、しきい値が設定されるオブジェクト型を指定します。この例では、サービス名はmain.regress.rdbms.dev.us.oracle.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.oracle.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プロシージャを使用して、メッセージのテキストをオープンします。
次のデータ・ディクショナリ・ビューは、サーバー生成アラートに関する情報を提供します。
データベース・パフォーマンスの監視の詳細は、『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インスタンスの監視に使用できるいくつかのデータ・ディクショナリ・ビューについて説明します。これらのビューは一般的なものです。プロセス固有の他のビューについては、そのプロセスに関する項を参照してください。
