Database Support Blog

  • Oracle Database
2023.11.07

Oracle Trace File Analyzerとは?障害発生時の情報収集を効率化!

Oracle Trace File Analyzer

Oracle Databaseの障害調査を行う際に、サポートセンターやオラクル社から情報提供を依頼されることがよくあるかと思います。
そうしたとき、以下のような経験をされたことはありませんか?

  • 取得すべき情報の種類が多い...
  • 取得情報のサイズが大きすぎる...
  • 取得した情報が不足していた...

Oracleの稼働情報を収集するときの課題

今回は上記のような問題点の改善に役立つツールであるOracle Trace File Analyzer(以降TFA)についてご紹介します。



Trace File Analyzer(TFA)とは

TFAはオラクル社が提供するコマンドインターフェースの資料採取ツールです。
以下のいずれかの環境であればデフォルトでインストールされており、利用するエディションや有償オプションの有無に関係なく使用することができます。

  • Oracle Real Application Clusters(RAC)環境
  • Oracle Database Appliance(ODA)環境
  • Oracle Exadata環境

上記以外の環境でTFAを利用する場合には、必要なソフトウェアやモジュールを別途インストールする必要があります。オラクル社では、常に最新バージョンの使用を推奨しており、具体的な最新バージョンのモジュールやインストール手順については、以下のオラクル社公式ドキュメントにてご確認ください。

Autonomous Health Framework(AHF)- Including TFA and ORAchk/EXAchk
(ドキュメントID 2550798.1)

https://support.oracle.com/epmos/faces/DocumentDisplay?id=2550798.1
※資料の閲覧にはMy Oracle Supportへのログインが必要です。
※現在TFAはAutonomous Health Framework(AHF)に統合されています。


TFAを使用するメリット

TFAを使用することによるメリットとして以下のような点が挙げられます。

  • 複数の情報を1コマンドで取得可能
  • 情報取得する時間帯を指定可能
  • 網羅的で一貫性の取れた情報を取得可能

オラクル社のサービスリクエスト(SR)にTFAの情報をアップロードすると、MOS Automationという自動解析機能が使えるようになります。これは特にORA-600エラーのような問題に遭遇した際に有用です。実際、オラクル社でこの機能を活用して、ORA-600エラーの調査時間を19時間からわずか6秒に短縮した事例もあります。

さらに、オラクル社のReal Application Clusters(RAC)サポートチームへの問い合わせのうち、70%以上の障害問い合わせは、すでに公開されているナレッジベースに解決策が存在しています。RAC以外にもGrid Infrastructure(GI)関連の問題やORA-600エラーに遭遇した場合でも非常に効果的です。


Oracle Trace File Analyzerのメリット

TFA使用時の事前準備

情報取得はTFA制御ユーティリティであるTFACTLを使用します。


TFAのステータス確認

# tfactl status

TFAがインストール済みかつ起動中の場合、ステータスがRUNNINGで表示されます。

# tfactl status
 
+-----------------------------------------------------------------------------------------------+
| Host  | Status of TFA | PID     | Port | Version    | Build ID             | Inventory Status |
+-------+---------------+---------+------+------------+----------------------+------------------+
| node1 | RUNNING       | 1003710 | 5000 | 23.5.0.0.0 | 23500020230612233220 | COMPLETE         |
| node2 | RUNNING       |  998576 | 5000 | 23.5.0.0.0 | 23500020230612233220 | COMPLETE         |
+-------+---------------+---------+------+------------+----------------------+------------------+


TFAが起動していない場合、TFA-00002エラーが発生します。

# tfactl status
TFA-00002 Oracle Trace File Analyzer (TFA) is not running


起動していない場合は以下コマンドにて起動可能です。

# tfactl start

正常に起動できた場合、以下のような出力となります。

# tfactl start
Starting TFA..
Waiting up to 100 seconds for TFA to be started..
. . . . .
. . . . .
Successfully started TFA Process..


TFAを使用した情報取得の具体例

■基本の情報取得コマンド

# tfactl diagcollect

本コマンドにオプションを追加することにより、ノードや期間の指定、調査したい内容に合わせて取得情報をカスタマイズできます。


<代表的なオプション>

オプション 説明
-database <DB名> 情報取得を行うDB名の指定
※指定しなかった場合、サーバ上の全DBの情報が取得されます。
-node <NODE名> 情報取得を行うノード名の指定
※RAC環境の場合、指定しなければ全ノードの情報が取得されます。
-from "YYYY-MM-DD HH24:MI:SS"
-to "YYYY-MM-DD HH24:MI:SS"
情報取得期間の指定
-noclassify TFA 22.3.0 以降のバージョン使用時にのみ指定
※TFA 22.3.0 以降 Smart Problem Classification がデフォルトで有効となり、コマンド実行手順が異なります。「-noclassify」をオプションを付けることで従来通りコマンドラインで実行することが可能です。TFAのバージョンは上述しましたtfactl statusコマンドにて確認可能です。

今回は弊社が推奨する取得パターンをいくつかご紹介します。取得時間やファイルサイズの抑制を検討される場合はぜひご活用ください。


(1)NODE上のGI+全DB+OS

問題個所が未特定の場合

実行ユーザー:root

# tfactl diagcollect -all -node <NODE名> -from "YYYY-MM-DD HH24:MI:SS" -to "YYYY-MM-DD HH24:MI:SS" [-noclassify]

<実行例>
情報取得コマンドを実行します。

# tfactl diagcollect -all -node node1 -from "2023-10-25 00:00:00" -to "2023-10-25 23:59:59" -noclassify


実行結果が表示されます。取得ファイルのサイズや取得にかかった時間も出力されますが、これらを事前に見積もることはできません。

Collecting data for node1 node(s).
 
TFA is using system timezone for collection, All times shown in JST.
Scanning files from oct/25/2023 00:00:00 to oct/25/2023 23:59:59
 
Collection Id : 20231026222430node1
 
Detailed Logging at : /u01/app/grid/oracle.ahf/data/repository/collection_Thu_Oct_26_22_24_33_JST_2023_node_node1/diagcollect_20231026222430_node1.log
 
Waiting up to 120 seconds for collection to start
2023/10/26 22:24:38 JST : NOTE : Any file or directory name containing the string .com will be renamed to replace .com with dotcom
2023/10/26 22:24:38 JST : Collection Name : tfa_Thu_Oct_26_22_24_32_JST_2023.zip
2023/10/26 22:24:38 JST : Collecting diagnostics from hosts : [node1]
2023/10/26 22:25:13 JST : Scanning of files for Collection in progress...
2023/10/26 22:25:13 JST : Collecting Additional Diagnostic Information...
2023/10/26 22:25:28 JST : Getting list of files satisfying time range [10/25/2023 00:00:00 JST, 10/25/2023 23:59:59 JST]
2023/10/26 22:25:57 JST : Collecting ADR incident files...
2023/10/26 22:25:57 JST : Executing Collection for ASM with timeout of 1800 seconds...
2023/10/26 22:26:47 JST : Executing Collection for AFD with timeout of 1860 seconds...
2023/10/26 22:26:52 JST : Executing Collection for CRS with timeout of 1920 seconds...
2023/10/26 22:27:44 JST : Executing Collection for ACFS with timeout of 1980 seconds...
2023/10/26 22:27:47 JST : Executing Collection for OS with timeout of 2040 seconds...
2023/10/26 22:27:56 JST : Executing Collection for SOSREPORT with timeout of 2100 seconds...
2023/10/26 22:31:41 JST : Executing Collection for QOS with timeout of 2160 seconds...
2023/10/26 22:31:44 JST : Executing Collection for DATAGUARD with timeout of 2220 seconds...
2023/10/26 22:31:45 JST : Executing Collection for SYSLENS with timeout of 2280 seconds...
2023/10/26 22:32:06 JST : Completed Collection of Additional Diagnostic Information...
2023/10/26 22:32:11 JST : Completed Local Collection
2023/10/26 22:32:11 JST : Not Redacting this Collection ...
2023/10/26 22:32:11 JST : Completed collection of zip files.
 
+----------------------------------+
|        Collection Summary        |
+-------+-----------+-------+------+
| Host  | Status    | Size  | Time |
+-------+-----------+-------+------+
| node1 | Completed | 113MB | 453s |
+-------+-----------+-------+------+


実行結果の最後に取得されたzipファイル名が出力されます。

Logs are being collected to: /u01/app/grid/oracle.ahf/data/repository/collection_Thu_Oct_26_22_24_33_JST_2023_node_node1
/u01/app/grid/oracle.ahf/data/repository/collection_Thu_Oct_26_22_24_33_JST_2023_node_node1/node1.tfa_Thu_Oct_26_22_24_32_JST_2023.zip


zipファイルを解凍すると主に以下のような情報が含まれています。

<主な取得情報>

取得情報 出力ディレクトリ/ファイル名
クラスタウェアアラートログ、トレースファイル <ホスト名>/diag/crs/<ホスト名>/crs/trace/
ASMアラートログ、トレースファイル <ホスト名>/diag/asm/+asm/<SID名>/trace/
全DBアラートログ、トレースファイル <ホスト名>/diag/rdbms/<DB名>/<SID名>/trace/
全DBインシデントファイル <ホスト名>/diag/rdbms/<DB名>/<SID名>/incident/
ローカル、SCANリスナーログ <ホスト名>/diag/tnslsnr/<ホスト名>/<リスナー名>/trace/
messagesファイル <ホスト名>/messages
opatch情報 <ホスト名>/<ホスト名>_OPATCH_DBHOMES

(2)NODE上のGI+特定DB+OS

特定DBの問題でGI/OS側の確認も必要な場合

実行ユーザー:root

# tfactl diagcollect -asm -crs -os -database <DB名> -node <NODE名> -from "YYYY-MM-DD HH24:MI:SS" -to "YYYY-MM-DD HH24:MI:SS" [-noclassify]

<主な取得情報>

取得情報 出力ディレクトリ/ファイル名
クラスタウェアアラートログ、トレースファイル <ホスト名>/diag/crs/<ホスト名>/crs/trace/
ASMアラートログ、トレースファイル <ホスト名>/diag/asm/+asm/<SID名>/trace/
特定DBアラートログ、トレースファイル <ホスト名>/diag/rdbms/<DB名>/<SID名>/trace/
特定DBインシデントファイル <ホスト名>/diag/rdbms/<DB名>/<SID名>/incident/
ローカル、SCANリスナーログ <ホスト名>/diag/tnslsnr/<ホスト名>/<リスナー名>/trace/
messagesファイル <ホスト名>/messages
opatch情報 <ホスト名>/<ホスト名>_OPATCH_DBHOMES

(3)NODE上のGI+OS

GI/OSの確認が必要な場合

実行ユーザー:grid

$ tfactl diagcollect -srdc gridinfrainst -node <NODE名> -from "YYYY-MM-DD HH24:MI:SS" -to "YYYY-MM-DD HH24:MI:SS" [-noclassify]

<主な取得情報>

取得情報 出力ディレクトリ/ファイル名
クラスタウェアアラートログ、トレースファイル <ホスト名>/diag/crs/<ホスト名>/crs/trace/
ASMアラートログ、トレースファイル <ホスト名>/diag/asm/+asm/<SID名>/trace/
ローカル、SCANリスナーログ <ホスト名>/diag/tnslsnr/<ホスト名>/<リスナー名>/trace/
messagesファイル <ホスト名>/messages
opatch情報 <ホスト名>/<ホスト名>_OPATCH_DBHOMES

(4)NODE上の特定DB

DB固有の問題で特定DBのみの確認が必要な場合

実行ユーザー:oracle

$ tfactl diagcollect -database <DB名> -node <NODE名> -from "YYYY-MM-DD HH24:MI:SS" -to "YYYY-MM-DD HH24:MI:SS" [-noclassify]

<主な取得情報>

取得情報 出力ディレクトリ/ファイル名
特定DBアラートログ、トレースファイル <ホスト名>/diag/rdbms/<DB名>/<SID名>/trace/
特定DBインシデントファイル <ホスト名>/diag/rdbms/<DB名>/<SID名>/incident/

(5)NODE上の特定DBの特定エラー

DB固有の問題で特定DBエラー(ORA-600等)の確認が要な場合

実行ユーザー:oracle

$ tfactl diagcollect -database <DB名> -node <NODE名> -srdc ORA-00600 [-noclassify]

<主な取得情報>

取得情報 出力ディレクトリ/ファイル名
特定DBアラートログ、トレースファイル <ホスト名>/diag/rdbms/<DB名>/<SID名>/trace/
特定DBインシデントファイル <ホスト名>/diag/rdbms/<DB名>/<SID名>/incident/
opatch情報 <ホスト名>/<ホスト名>_OPATCH_DBHOMES

本ブログには記載しておりませんが、その他に指定可能なオプションについては一部、以下のオラクル社公式ドキュメントにて紹介されております。ご参考にしていただけますと幸いです。

TFA診断情報収集ウォークスルーのリファレンス・ドキュメント
(ドキュメントID 2940525.1)

https://support.oracle.com/epmos/faces/DocumentDisplay?id=2940525.1


まとめ

いかがでしたでしょうか。このように TFA を使うことで障害発生時の情報収集の手間を軽減でき、問題解決のスピードアップにつなげることができます。

Oracle Trace File Analyzerを使用するメリット

TFAで取得いただいた情報は弊社での調査のみではなく、オラクル社による調査の際にもMOS Automation(自動解析機能)が活用できるため、効率化されます。ぜひ、TFA の使用をご検討ください。本記事が障害調査の早期解決の一助になれば幸いです。


この記事で知りたい情報は得られましたか?

以下のページや記事でも、Oracle Database運用の効率化や障害発生時の対応の迅速化に関する情報をお伝えしています。ぜひあわせてお読みください。




Oracle Databaseに関するお問い合わせはこちら

オンプレミスでもクラウドでも、Oracle Databaseの導入/運用や弊社が提供する支援サービスに関してご不明な点がございましたら、お気軽にお問い合わせください。




執筆者情報

いいだ ようすけ プロフィール画像

2017年入社。Oracle Databaseのサポート業務に従事。
高可用性製品、Engineered Systemsを中心としたトラブル対応に奮闘中。夜間休日帯など営業時間外の緊急対応や、Oracle Databaseのフィールドエンジニア、研修講師も経験。趣味はサッカー。...show more


■本記事の内容について
 本記事に示した定義及び条件は変更される場合があります。あらかじめご了承ください。

■商標に関して
 ・Oracle®、Java、MySQL及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
 ・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
  文中の社名、商品名等は各社の商標または登録商標である場合があります。

関連している記事

  • Oracle Database
2024.04.08

【Oracle Database】FAQで安定運用に貢献!サポートセンターのナレッジ公開の取り組み

アシストオラクルサポートセンターが公開しているFAQは、仕様に関するQAやエラー発生時の対処方法などはもちろん、不具合情報や障害発生時の情報取得方法といった安定運用に役立つ内容も扱っています。そのFAQをどのように作成しているのか、サポートセンターの取り組みをご紹介します。

  • Oracle Cloud
  • Oracle Database
2024.02.02

OCIにおけるOracle Database 11g R2、12g R1、12g R2の新規プロビジョニング終了とその影響

Oracle Databaseのバージョン11g R2、12g.R1、12g.R2は既にすべてのメーカーサポートが終了しています。OCIのBase Database Serviceでも2024年1月中旬ころから11g R2、12g R1、12g R2での新規プロビジョニングができなくなりました。

  • Oracle Database
  • その他
2023.12.21

【Oracle Database】サポートセンターでの生成AI(Glean)活用

アシストでは全社員にAIアシスタントGleanを導入しました。サポートセンターで2ヶ月間使ってみて感じた効果やメリットをお伝えします。

ページの先頭へ戻る