【Oracle Database】忘れていませんか? 「アラートログ調査」に必要な、たった3つのキホン:データベースサポート最前線の現場から(1)(1/2 ページ)
データベース管理システムの運用でトラブルが発生したらどうするか。データベースサポートスペシャリストが現場目線の解決Tipsをお届けします。今回は基本編として「アラートログの調査で押さえるべき3つのポイント」を解説します。【Oracle Database 12c対応版】
データベーストラブル対策の基本中の基本「アラートログの確認」
アシストのサポートセンターには、年間1万件ほどオラクル製品に関する問い合わせがあります。そのうちの約半数がデータベースで発生したトラブルに関するものです。
例えば、Oracle Databaseの運用中に何かトラブルが発生したら、最初に何を調査するでしょう。そうです。「アラートログを確認する」ですね。アラートログにはデータベースに関するさまざまな情報が出力されます。トラブル調査において最も重要なファイルの1つです。
この他には、エラー発生時の詳細な情報が出力され「トレースファイル」や「インシデントファイル」もトラブル調査に必要不可欠です。実際、サポートセンターに問い合わせをいただいたら、まずこれら3つのファイルを送ってもらっています。
ユーザー企業の多いデータベースにフォーカスし、トラブル対応の基本を振り返る本連載。今回は、Oracle Databaseの「アラートログ」にはどのような情報が出力されているのか。また、どんな情報がトラブル調査に使われているのかを解説します。
アラートログの出力先
アラートログの出力先は以下の通りです。Oracle Databaseのバージョンにより異なります。
- 10gR2以前:$ORACLE_BASE/admin/DB/bdump/alert_SID.log
- 11gR1以後:$ADR_BASE/diag/rdbms/DB/SID/trace/alert_SID.log
「ADR_BASE」とは、初期化パラメータのDIAGNOSTIC_DESTで指定されているディレクトリのことです。
11gR1以後のバージョンでは、traceディレクトリと同じ階層にalertというディレクトリもあります。こちらにはXML(Extensible Markup Language)形式のアラートログファイルが格納されています。テキスト形式でもXML形式でも出力される内容は同じですが、traceディレクトリに出力されるテキスト形式の方が、多くの場合は参照するのに適していると思います。
アラートログには、どんな情報が出力されているのか
アラートログに含まれる情報は、「Oracle Database 管理者ガイド(12c Release 1)」によると次のように記載されています。
- 発生した全ての内部エラー(ORA-00600)、ブロック破損エラー(ORA-01578)およびデッドロック・エラー(ORA-00060)
- 例えば、CREATE/ALTER/DROP文、STARTUP/SHUTDOWN文、ARCHIVELOG文などの管理操作
- 共有サーバとディスパッチャ・プロセスの機能に関係するメッセージとエラー
- マテリアライズド・ビューの自動リフレッシュ中に発生したエラー
- データベースとインスタンスの起動時点でデフォルト以外の値があった全ての初期化パラメータの値
専門用語が盛りだくさんで、少し理解しにくいかもしれません。ここでは簡潔に、Oracle Databaseでエラーが発生したらまず参照すべき3つのポイントとして、「エラー情報」「管理操作」「起動時の初期化パラメータの値に関する出力内容」を順に説明します。
ポイント1:「エラー情報」を確認する
データベースで発生したエラーの情報は、アラートログにその詳細が出力されます。例えば、ブロック障害を検知したことを示す「ORA-01578」が発生した場合は以下のように出力されます。
Wed Feb 04 20:09:29 2015 Corrupt Block Found CONT = 3, TSN = 4, TSNAME = TESTSP RFN = 11, BLK = 131, RDBA = 46137475 OBJN = 91894, OBJD = 91894, OBJECT = EMP_T, SUBOBJECT = SEGMENT OWNER = TESTUSER, SEGMENT TYPE = Table Segment Errors in file /u01/app/oracle/diag/rdbms/cdb122/cdb122/trace/cdb122_ora_3314.trc (incident=17265) (PDBNAME=PDB122): ORA-01578: ORACLE data block corrupted (file # 11, block # 131) ORA-01110: data file 11: '/u01/app/oracle/oradata/CDB122/0D02D8B8B008551AE053331BA8C0B198/datafile/o1_mf_testsp_bf18xro4_.dbf' Incident details in: /u01/app/oracle/diag/rdbms/cdb122/cdb122/incident/incdir_17265/cdb122_ora_3314_i17265.trc
この情報からは、以下のことを把握できます。
- 2015年2月4日の20時9分29秒に、ブロック破損(ORA-01578)を検知した
- プラガブルデータベース(PDB)名は「PDB122」である
- 「TESTSP」表領域にある、ユーザー名「TESTUSER」が保持している「EMP_T」という表が対象である
- ブロック破損は、ファイル番号「11」のブロック番号「131」で発生した
- ファイル番号11は、「o1_mf_testsp_bf18xro4_.dbf」というファイルである
- エラーを受けたプロセスの情報は「cdb122_ora_3314.trc」というトレースファイルに出力された
- エラーの詳細情報は「cdb122_ora_3314_i17265.trc」というインシデントファイルに出力された
このように、アラートログからは「エラーの発生した時間」「内容」「エラーの詳細情報が記録されたファイル名」などの情報を取得できます。ちなみに、インシデントファイルには全てのエラーが出力対象になるのではなく、「V$DIAG_CRITICAL_ERROR」ビューで危機的と定義されているエラーや、内部エラーがデータベースで発生した場合に出力されます。
ポイント2:「管理操作」を確認する
エラー調査においては、発生したエラーだけでなく、エラーの発生前にデータベースの構成が変更されていないかを確認することも必要です。
アラートログには、データベースへの管理操作も「実行したSQL文」と共に出力されます。表領域の追加やリサイズ、初期化パラメータを変更した場合の出力例は以下の通りです。
Sat Feb 07 12:35:53 2015 create tablespace TEST_SPACE datafile size 5m autoextend on Completed: create tablespace TEST_SPACE datafile size 5m autoextend on Sat Feb 07 12:38:40 2015 alter database datafile '/u01/app/oracle/oradata/CDB122/0D02D8B8B008551AE053331BA8C0B198/datafile/o1_mf_test_spa_bfc20s53_.dbf' resize 8m Sat Feb 07 13:38:51 2015 Resize operation completed for file# 12, old size 5120K, new size 8192K Completed: alter database datafile '/u01/app/oracle/oradata/CDB122/0D02D8B8B008551AE053331BA8C0B198/datafile/o1_mf_test_spa_bfc20s53_.dbf' resize 8m Sat Feb 07 13:39:08 2015 ALTER SYSTEM SET processes=500 SCOPE=SPFILE; …
それぞれにタイムスタンプが記録されているので、データベースに対していつ変更が行われたのかを確認できます。例えば、エラー発生前にALTER SYSTEM文などがアラートログに確認できたならば、パラメータの変更がエラーの原因になっている可能性も考慮して調査します。
管理操作が失敗した場合にも、失敗したコマンドがエラーと共に出力されます。以下は、SMALLタイプの表領域に対しては許可されていない、ALTER TABLESPACE文でRESIZEを行ってしまった場合の出力例です。
Sat Feb 07 13:37:40 2015 alter tablespace test_space resize 8m ORA-32773 signalled during: alter tablespace test_space resize 8m... …
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- 障害発生! 問題切り分けはスピード勝負
Oracleデータベースの運用管理者は、突発的に直面するパフォーマンス障害にどうやって対処したらよいか。本連載は、非常に複雑なOracleのアーキテクチャに頭を悩ます管理者に向け、短時間で問題を切り分け、対処法を見つけるノウハウを紹介する。対象とするバージョンはOracle8から9iまでを基本とし、10gの情報は随時加えていく。(編集局) - それでは“ダメ”な「トラブル対応例」
本連載は、「Microsoft SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、「SQL Serverで起こりがちなトラブル」を厳選して、具体的な対処方法を紹介していきます。第1回目は「トラブルを適切に対処するための考え方」を解説します。 - パフォーマンス向上の最短コースを知る
本連載では、Oracleデータベースのパフォーマンス・チューニングの中から、特にSQLのチューニングに注目して、実践レベルの手法を解説する。読者はOracleデータベースのアーキテクチャを理解し、運用管理の実務経験を積んでいることが望ましい。対象とするバージョンは現状広く使われているOracle9iの機能を基本とするが、Oracle 10gで有効な情報も随時紹介していく。(編集局) - そもそも、リレーショナルデータベースとは何か?
データベースを基礎から勉強し理解を深めていくことは簡単なことではありません。本連載では、データベースに対するハードルを少しでも低くするために、初心者の方に必要なデータベースの基本から、障害対策やチューニングといった実践に即した内容までを幅広く解説していきます。今回は、データベースの役割と、それを管理するソフトウェアであるDBMSの基本機能について解説します。【更新】