| Oracle® Databaseパフォーマンス・チューニング・ガイド 11gリリース2 (11.2) B56312-06 |
|
 前 |
 次 |
Oracle Databaseには、Oracleデータベースで実行されるアプリケーションの監視および分析に役立ついくかのトレース・ツールがあります。
エンドツーエンド・アプリケーションのトレースでは、高負荷のSQL文などの過剰なワークロードのソースを、クライアント識別子、サービス、モジュール、アクション、セッション、インスタンスまたはデータベース全体によって識別できます。これによって、問題が特定のユーザー、サービス、セッションまたはアプリケーション・コンポーネントに特定されます。
Oracle Databaseには、特定の基準に基づいてトレース情報を統合するtrcsessコマンドライン・ユーティリティがあります。
SQLトレース機能およびTKPROFは、Oracleデータベースで実行されるアプリケーションの監視に役立つ2つの基本的なパフォーマンス診断ツールです。
この章には次の項があります。
|
関連項目: 自動トレースを使用したSQL*Plus文のトレースおよびチューニングの詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。 |
エンドツーエンド・アプリケーションのトレースは、複数層環境のパフォーマンス上の問題の診断プロセスを単純化します。これらの環境では、エンド・クライアントからのリクエストは中間層により様々なデータベース・セッションにルーティングされるため、異なるデータベース・セッション間でクライアントを追跡するのは困難です。エンドツーエンド・アプリケーションのトレースでは、クライアントIDを使用して、データベースへのすべての層を通じて特定のエンド・クライアントを一意にトレースします。
この機能では、高負荷のSQL文などの過剰なワークロードのソースを識別でき、担当する特定のユーザーに連絡をとることができます。また、問題が発生しているユーザーから連絡を受けることもできます。これにより、データベース・レベルで、ユーザーのセッションが何を実行しているかを識別できます。
さらに、エンドツーエンド・アプリケーションのトレースでは、あるサービスの特定のモジュールおよびアクションを追跡することで、アプリケーション・ワークロードの管理が簡素化されます。エンドツーエンド・アプリケーションのトレースでは、ワークロードの問題を次のように識別できます。
クライアント識別子
HR.HRなどのログオンIDに基づいてエンド・ユーザーを指定します。
サービス
単一のアプリケーション(会計アプリケーションの場合はACCTGなど)を指定するか、共通の属性、サービス・レベルのしきい値および優先順位持つアプリケーション・グループを指定します。
モジュール
売掛勘定または総勘定元帳など、アプリケーションの機能ブロックを指定します。
アクション
モジュールのINSERT操作やUPDATE操作などのアクションを指定します。
セッション
データベースへの現在のユーザー・ログイン状態を示します。
インスタンス
システム・グローバル領域(SGA)およびバックグラウンド・プロセスの組合せを示します。
トレース情報がファイルに書き込まれた後、この情報をtrcsessユーティリティで統合し、TKPROFなどの分析ユーティリティで診断できます。
単一インスタンスのOracleデータベースでサービスを作成するには、DBMS_SERVICE.CREATE_SERVICEプロシージャを使用するか、SERVICE_NAMES初期化パラメータを設定します。
モジュール名およびアクション名は、アプリケーション開発者が設定します。たとえば、PL/SQLプログラムでこれらの値を設定するには、DBMS_APPLICATION_INFOパッケージのSET_MODULEおよびSET_ACTIONプロシージャを使用します。
エンドツーエンド・トレースの推奨されるインタフェースは、Oracle Enterprise Managerです。Enterprise Managerを使用する場合、各コンシューマ・タイプの上位コンシューマを表示して、特定のコンシューマの統計収集およびSQLトレースを使用可能または使用禁止にできます。可能なかぎり、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』の手順に従って、Enterprise Managerを使用してエンドツーエンド・トレースを管理する必要があります。Oracle Enterprise Managerが使用可能でない場合は、次の項で説明するように、DBMS_MONITOR APIを使用してこの機能を管理できます。
|
関連項目:
|
PL/SQLを使用して適切な統計を収集するには、DBMS_MONITORパッケージのプロシージャを使用して、クライアント識別子、サービス、モジュールまたはアクションに対する統計収集を使用可能にする必要があります。
統計は次の基準でも収集できます。
デフォルト・レベルは、セッション・レベルの統計収集です。統計収集はデータベース全体を対象にしており、インスタンスの再起動後も引き続き行われます。
プロシージャCLIENT_ID_STAT_ENABLEでは、特定のクライアント識別子に対する統計収集が使用可能になります。たとえば、特定のクライアント識別子に対する統計収集を使用可能にするには、次のようにします。
EXECUTE DBMS_MONITOR.CLIENT_ID_STAT_ENABLE(client_id => 'OE.OE');
この例では、OE.OEは、統計を収集する対象のクライアント識別子です。V$SESSIONのCLIENT_IDENTIFIER列でクライアント識別子を表示できます。
プロシージャCLIENT_ID_STAT_DISABLEでは、特定のクライアント識別子に対する統計収集が使用禁止になります。たとえば、次のようにします。
EXECUTE DBMS_MONITOR.CLIENT_ID_STAT_DISABLE(client_id => 'OE.OE');
プロシージャSERV_MOD_ACT_STAT_ENABLEでは、サービス、モジュールおよびアクションの組合せに対する統計収集が使用可能になります。たとえば、次のようにします。
EXECUTE DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(service_name => 'ACCTG',
module_name => 'PAYROLL');
EXECUTE DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(service_name => 'ACCTG',
module_name => 'GLEDGER', action_name => 'INSERT ITEM');
前述のコマンドが両方とも実行された場合、統計は次のように収集されます。
ACCTGサービスに関する統計(各サービス名の累積がデフォルトであるため)
PAYROLLモジュール内のすべてのアクションに関する統計
GLEDGERモジュール内のINSERT ITEMアクションに関する統計
プロシージャSERV_MOD_ACT_STAT_DISABLEでは、サービス、モジュールおよびアクションの組合せに対する統計収集が使用禁止になります。たとえば、次のようにします。
EXECUTE DBMS_MONITOR.SERV_MOD_ACT_STAT_DISABLE(service_name => 'ACCTG',
module_name => 'GLEDGER', action_name => 'INSERT ITEM');
統計の収集に関して、これらのプロシージャでモジュールまたはアクションを変更する場合、その変更は次のユーザー・コールがセッションで実行されると有効になります。たとえば、モジュールがセッションでmodule1に設定され、そのモジュールがセッションのユーザー・コールでmodule2にリセットされた場合、このユーザー・コールでは、モジュールはmodule1のままです。モジュールは、セッションの次のユーザー・コールでmodule2に変更されます。
収集した統計情報は、いくつかの動的ビューで表示できます。
現在使用可能な統計の累積グローバル統計は、DBA_ENABLED_AGGREGATIONSビューで表示できます。
指定されたクライアント識別子の累積統計は、V$CLIENT_STATSビューで表示できます。
指定されたサービスの累積統計は、V$SERVICE_STATSビューで表示できます。
指定されたサービス、モジュールおよびアクションの組合せの累積統計は、V$SERV_MOD_ACT_STATSビューで表示できます。
データベース・コールの経過時間およびCPU使用率の累積統計は、V$SERVICEMETRICビューで表示できます。
クライアント識別子、サービス、モジュール、アクション、セッション、インスタンスまたはデータベースのトレースを使用可能にするには、DBMS_MONITORパッケージの適切なプロシージャを実行します。次の基準により、特定の診断およびワークロード管理のトレースを使用可能にできます。
指定した基準により、特定のトレース情報がトレース・ファイルのセットに収集され、1つの出力トレース・ファイルに結合されます。
CLIENT_ID_TRACE_ENABLEプロシージャでは、データベースにおける特定のクライアント識別子のトレースが全体的に使用可能になります。たとえば、次のようにします。
EXECUTE DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE(client_id => 'OE.OE',
waits => TRUE, binds => FALSE);
この例では、OE.OEは、SQLトレースを使用可能にするクライアント識別子です。TRUE引数は、待機情報がトレースに含められることを指定します。FALSE引数は、バインド情報がトレースに含められないことを指定します。
CLIENT_ID_TRACE_DISABLEプロシージャでは、データベースにおける特定のクライアント識別子のトレースが全体的に使用禁止になります。前の例でトレースを使用禁止にするには、次のようにします。
EXECUTE DBMS_MONITOR.CLIENT_ID_TRACE_DISABLE(client_id => 'OE.OE');
SERV_MOD_ACT_TRACE_ENABLEプロシージャでは、データベースにおける、サービス名、モジュールおよびアクションの指定の組合せのSQLトレースが全体的に使用可能になります。ただし、このプロシージャでインスタンス名が指定されている場合を除きます。
EXECUTE DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE(service_name => 'ACCTG',
waits => TRUE, binds => FALSE, instance_name => 'inst1');
この例では、サービスACCTGが指定されています。モジュールまたはアクション名は指定されていません。TRUE引数は、待機情報がトレースに含められることを指定します。FALSE引数は、バインド情報がトレースに含められないことを指定します。inst1インスタンスが指定されているため、このインスタンスのトレースのみが使用可能になります。
サービスおよびモジュールの指定の組合せについてすべてのアクションのトレースを使用可能にするには、次のようにします。
EXECUTE DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE(service_name => 'ACCTG',
module_name => 'PAYROLL', waits => TRUE, binds => FALSE,
instance_name => 'inst1');
SERV_MOD_ACT_TRACE_DISABLEプロシージャでは、サービス名、モジュールおよびアクション名の指定の組合せについて、使用可能なすべてのインスタンスにおけるトレースが全体的に使用禁止になります。たとえば、次の文では、この項の最初の例のトレースが使用禁止になります。
EXECUTE DBMS_MONITOR.SERV_MOD_ACT_TRACE_DISABLE(service_name => 'ACCTG',
instance_name => 'inst1');
この例では、この項の2つ目の例のトレースが使用禁止になります。
EXECUTE DBMS_MONITOR.SERV_MOD_ACT_TRACE_DISABLE(service_name => 'ACCTG',
module_name => 'PAYROLL', instance_name => 'inst1');
SESSION_TRACE_ENABLEプロシージャでは、ローカル・インスタンスにおける、特定のデータベース・セッション識別子(SID)のトレースが使用可能になります。
特定のセッションIDおよびシリアル番号のトレースを使用可能にするには、トレースするセッションの値を調べます。
SELECT SID, SERIAL#, USERNAME FROM V$SESSION;
SID SERIAL# USERNAME
---------- ---------- ------------------------------
27 60 OE
...
特定のセッションのトレースを使用可能にするには、適切な値を使用します。
EXECUTE DBMS_MONITOR.SESSION_TRACE_ENABLE(session_id => 27, serial_num => 60,
waits => TRUE, binds => FALSE);
TRUE引数は、待機情報がトレースに含められることを指定します。FALSE引数は、バインド情報がトレースに含められないことを指定します。
SESSION_TRACE_DISABLEプロシージャでは、特定のデータベース・セッション識別子(SID)およびシリアル番号のトレースが使用禁止になります。たとえば、次のようにします。
EXECUTE DBMS_MONITOR.SESSION_TRACE_DISABLE(session_id => 27, serial_num => 60);
DBMS_MONITORパッケージはDBAロールが付与されているユーザーのみが起動できる一方、任意のユーザーがDBMS_SESSIONパッケージを使用して、所有するセッションのSQLトレースを使用可能にできます。ユーザーはSESSION_TRACE_ENABLEプロシージャを起動して、ユーザー自身のセッションでセッション・レベルのSQLトレースを使用可能にできます。たとえば、次のようにします。
EXECUTE DBMS_SESSION.SESSION_TRACE_ENABLE(waits => TRUE, binds => FALSE);
TRUE引数は、待機情報がトレースに含められることを指定します。FALSE引数は、バインド情報がトレースに含められないことを指定します。
SESSION_TRACE_DISABLEプロシージャは、起動セッションのトレースを使用禁止にします。たとえば、次のようにします。
EXECUTE DBMS_SESSION.SESSION_TRACE_DISABLE();
DATABASE_TRACE_ENABLEプロシージャは、任意のインスタンスまたはデータベース全体のSQLトレースを使用可能にします。トレースは現在および将来のセッションのすべてに対して使用可能になります。たとえば、次のようにします。
EXECUTE DBMS_MONITOR.DATABASE_TRACE_ENABLE(waits => TRUE, binds => FALSE,
instance_name => 'inst1');
この例ではinst1インスタンスが指定されているため、このインスタンスのトレースが使用可能になります。TRUE引数は、待機情報がトレースに含められることを指定します。FALSE引数は、バインド情報がトレースに含められないことを指定します。この例は、inst1インスタンス内の全SQLをSQLトレースすることになります。
DATABASE_TRACE_ENABLEプロシージャは、他のすべてのセッション・レベルのトレースより優先されますが、クライアント識別子、サービス、モジュールおよびアクションのトレースを補完します。すべての新規セッションは、DATABASE_TRACE_DISABLEプロシージャがコールされるまで、このプロシージャで指定された待機およびバインド情報を継承します。instance_nameパラメータを指定してこのプロシージャを起動すると、指定されたインスタンスのセッション・レベルのSQLトレースがリセットされます。instance_nameパラメータを指定せずにこのプロシージャを起動すると、データベース全体のセッション・レベルのSQLトレースがリセットされます。
DATABASE_TRACE_DISABLEプロシージャは、インスタンス全体またはデータベース全体のトレースを使用禁止にします。たとえば、次のようにします。
EXECUTE DBMS_MONITOR.DATABASE_TRACE_DISABLE(instance_name => 'inst1');
この例では、すべてのセッション・レベルのSQLトレースは、inst1インスタンスに対して使用禁止になります。データベース全体に対してセッション・レベルのSQLトレースを使用禁止にするには、instance_nameパラメータを指定せずにDATABASE_TRACE_DISABLEプロシージャを起動します。
EXECUTE DBMS_MONITOR.DATABASE_TRACE_DISABLE();
Oracle Enterprise ManagerのレポートまたはDBA_ENABLED_TRACESビューに、未処理のトレースを表示できます。DBA_ENABLED_TRACESビューでは、トレース・タイプを含め、トレースを使用可能にした方法に関する詳細を判断できます。トレース・タイプは、クライアント識別子、セッション、サービス、データベース、またはサービス、モジュールおよびアクションの組合せについてトレースが使用可能かどうかを指定します。
trcsessユーティリティでは、次の複数の基準に基づいて、選択されたトレース・ファイルからのトレース出力が統合されます。
セッションID
クライアントID
サービス名
アクション名
モジュール名
trcsessによりトレース情報が1つの出力ファイルにマージされた後、出力ファイルをTKPROFによって処理できます。
trcsessは、パフォーマンスまたはデバッグを向上させるため、特定のセッションのトレースを統合する際に便利です。特定のセッションのトレースは、専用サーバー・モデルでは、1つの専用プロセスが存続期間中ずっと1つのセッションに対応するため、通常は問題になりません。このセッションのトレース情報は、このセッションに対応する専用サーバーに属するトレース・ファイルで参照できます。ただし、共有サーバー構成では、ユーザー・セッションが様々なプロセスで対応される場合があります。ユーザー・セッションに関連するトレースは、様々なプロセスに属する各種トレース・ファイル間で分散されます。そのため、セッションの存続期間におけるすべての状況を把握しにくくなります。
trcsessユーティリティの構文は、次のとおりです。
trcsess [output=output_file_name] [session=session_id] [clientid=client_id] [service=service_name] [action=action_name] [module=module_name] [trace_files]
各項目の意味は次のとおりです。
outputは、出力の生成場所となるファイルを指定します。このオプションを指定しない場合、標準出力に書き込まれます。
sessionは、指定されたセッションのトレース情報を統合します。セッション識別子は、セッション索引とセッション・シリアル番号の組合せ(21.2371など)です。これらの値はV$SESSIONビューで見つけることができます。
clientidは、特定のクライアントIDのトレース情報を統合します。
serviceは、特定のサービス名のトレース情報を統合します。
actionは、特定のアクション名のトレース情報を統合します。
moduleは、特定のモジュール名のトレース情報を統合します。
trace_filesは、スペースで区切られたすべてのトレース・ファイル名のリストであり、ここでtrcsessはトレース情報を検索する必要があります。トレース・ファイル名の指定にワイルドカード文字(*)を使用できます。トレース・ファイルを指定しない場合、trcsessは、現在のディレクトリ内のすべてのファイルを入力として受け取ります。
session、clientid、service、actionまたはmoduleオプションのいずれかを指定する必要があります。session、clientid、service、actionまたはmoduleオプションが複数指定されている場合、指定されたすべての基準を満たすトレース・ファイルが出力ファイルに統合されます。
このtrcsessの出力例は、特定のセッションにおけるトレースの統合を示しています。この例では、セッション索引およびシリアル番号は21.2371となります。
様々なオプションを指定してtrcsessを起動できます。次の場合、現在のディレクトリのすべてのファイルが入力データとみなされます。
trcsess session=21.2371
この場合、複数のトレース・ファイルが指定されています。
trcsess session=21.2371 main_12359.trc main_12995.trc
出力例は次のようになります。
[PROCESS ID = 12359] *** 2002-04-02 09:48:28.376 PARSING IN CURSOR #1 len=17 dep=0 uid=27 oct=3 lid=27 tim=868373970961 hv=887450622 ad='22683fb4' select * from cat END OF STMT PARSE #1:c=0,e=339,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=868373970944 EXEC #1:c=0,e=221,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=868373971411 FETCH #1:c=0,e=791,p=0,cr=7,cu=0,mis=0,r=1,dep=0,og=4,tim=868373972435 FETCH #1:c=0,e=1486,p=0,cr=20,cu=0,mis=0,r=6,dep=0,og=4,tim=868373986238 *** 2002-04-02 10:03:58.058 XCTEND rlbk=0, rd_only=1 STAT #1 id=1 cnt=7 pid=0 pos=1 obj=0 op='FILTER ' STAT #1 id=2 cnt=7 pid=1 pos=1 obj=18 op='TABLE ACCESS BY INDEX ROWID OBJ$ ' STAT #1 id=3 cnt=7 pid=2 pos=1 obj=37 op='INDEX RANGE SCAN I_OBJ2 ' STAT #1 id=4 cnt=0 pid=1 pos=2 obj=4 op='TABLE ACCESS CLUSTER TAB$J2 ' STAT #1 id=5 cnt=6 pid=4 pos=1 obj=3 op='INDEX UNIQUE SCAN I_OBJ# ' [PROCESS ID=12995] *** 2002-04-02 10:04:32.738 Archiving is disabled Archiving is disabled
SQLトレース機能およびTKPROFを使用すると、アプリケーションが実行するSQL文の効率を正確に評価できます。最善の結果を得るには、EXPLAIN PLANを単体ではなくこれらのツールとともに使用してください。
SQLトレース機能は、個々のSQL文に関するパフォーマンス情報を提供します。この機能は、文単位に次の統計を生成します。
解析、実行、フェッチのカウント
CPU時間と経過時間
物理読取りと論理読取り
処理された行数
ライブラリ・キャッシュでのミス
それぞれの解析が行われるユーザー名
各コミットおよびロールバック
各SQL文の待機イベント・データおよび各トレース・ファイルの要約
また、SQL文のカーソルがクローズされている場合は、SQLトレースにより次の内容を含む行ソース情報が提供されます。
各SQL文の実際の実行計画を示す行操作
行数、一貫性のある読取りの数、物理読取り数、物理書込み数および行の各操作の経過時間
1つのセッションまたはインスタンスに対してSQLトレース機能を使用可能にできますが、かわりにDBMS_SESSIONまたはDBMS_MONITORパッケージを使用することをお薦めします。セッションまたはインスタンスに対してSQLトレース機能を使用可能にすると、ユーザー・セッションまたはインスタンスで実行されるすべてのSQL文のパフォーマンス統計がトレース・ファイルに格納されます。SQLトレース機能を使用するとパフォーマンスに重大な影響を与えることがあり、システム・オーバーヘッドの増加、過剰なCPU使用率およびディスク領域の不足をもたらす場合があります。
|
関連項目: DBMS_SESSIONまたはDBMS_MONITORパッケージを使用してセッションまたはインスタンスに対するSQLトレースを使用可能にする方法の詳細は、「エンドツーエンド・トレースにおける有効化および無効化」を参照してください。 |
Oracle Databaseには、セッションまたはクライアントIDなどの特定の基準に基づいて複数のトレース・ファイルからトレース情報を統合する、trcsessコマンドライン・ユーティリティがあります。「trcsessユーティリティの使用方法」を参照してください。
TKPROFプログラムを実行すると、トレース・ファイルの内容をフォーマットし判読可能なファイルとして出力できます。TKPROFは次のことも実行します。
統計をデータベースに格納するSQLスクリプトを作成します。
SQL文の実行計画を判断します。
|
注意: SQL文のカーソルがクローズされていない場合、SQL文の実際の実行計画がTKPROF出力に自動的に含まれることはありません。この場合は、TKPROFでEXPLAINオプションを使用して、実行計画を生成できます。 |
TKPROFは、実行した各文を、消費したリソースおよびコールした回数、処理した行数とともにレポートします。この情報を使用すると、リソースを最も多く使用している文を簡単に検出できます。経験、または参考にできる基準をもとに、使用されたリソースが実行された作業に対して妥当であるかどうかを評価できます。
SQLトレース機能およびTKPROFを使用するには、次の手順に従います。
トレース・ファイル管理用の初期化パラメータを設定します。
「手順1: トレース・ファイル管理用の初期化パラメータの設定」を参照してください。
対象とするセッションに対してSQLトレース機能を使用可能にして、アプリケーションを実行します。手順2では、アプリケーションによって発行されたSQL文に関する統計を含むトレース・ファイルが作成されます。
「手順2: SQLトレース機能を使用可能にする方法」を参照してください。
手順2で作成されるトレース・ファイルを判読可能な出力ファイルに変換するために、TKPROFを実行します。手順3ではオプションとして、データベースへの統計の格納に使用できるSQLスクリプトを作成できます。
「手順3: TKPROFによるトレース・ファイルのフォーマット」を参照してください。
手順3で作成した出力ファイルを解釈します。
「手順4: TKPROF出力の解釈」を参照してください。
任意で、手順3で作成したSQLスクリプトを実行してデータベースに統計を格納します。
「手順5: SQLトレース機能統計の格納」を参照してください。
次の項に、各手順の詳細を示します。
セッションに対してSQLトレース機能が使用可能になると、Oracle Databaseはトレース・ファイルを生成します。このファイルには、そのセッションでトレースされたSQL文に関する統計が記録されています。インスタンスに対してSQLトレース機能が使用可能になると、Oracle Databaseはプロセスごとに個別のトレース・ファイルを作成します。SQLトレース機能を有効にする前に、次のことを行ってください。
表21-1に従って、TIMED_STATISTICS、MAX_DUMP_FILE_SIZEおよびDIAGNOSTIC_DEST初期化パラメータの設定をチェックします。
表21-1 SQLトレース機能を有効にする前にチェックする初期化パラメータ
結果のトレース・ファイルを認識する方法を考えます。
トレース・ファイルを名前で区別できるようにしてください。SELECT 'program_name' FROM DUALのような文をプログラムに組み込むことによって、トレース・ファイルにタグを付けることができます。これにより、各ファイルの生成元のプロセスを追跡できます。
TRACEFILE_IDENTIFIER初期化パラメータを設定し、トレース・ファイル名の一部となるカスタム識別子も指定できます。たとえば、次の文によって、後続のトレース・ファイル名にmy_trace_idを追加し、識別しやすくできます。
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'my_trace_id';
|
関連項目: TRACEFILE_IDENTIFIER初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。 |
オペレーティング・システムがファイルの複数のバージョンを保持している場合、SQLトレース機能が生成するトレース・ファイルの数に対して、バージョンの上限が十分に高い値に設定されていることを確認してください。
生成されたトレース・ファイルの所有者は、データベース管理者以外のオペレーティング・システム・ユーザーの場合があります。データベース管理者がTKPROFを実行してこれらのファイルをフォーマットする場合は、このユーザーが前もって、管理者がトレース・ファイルを利用できる状態にしておく必要があります。
|
関連項目:
|
次のいずれかのレベルでSQLトレース機能を使用可能にします。
データベース・インスタンス
DBMS_MONITOR.DATABASE_TRACE_ENABLEプロシージャを使用してトレースを使用可能にし、DBMS_MONITOR.DATABASE_TRACE_DISABLEプロシージャを使用してトレースを使用禁止にします。
データベース・セッション
DBMS_SESSION.SET_SQL_TRACEプロシージャを使用して、トレースを使用可能(TRUE)または使用禁止(FALSE)にします。
|
注意: SQLトレース機能を実行するとシステムのオーバーヘッドが増加するため、この機能はSQL文をチューニングするときにのみ使用可能にし、チューニングが終了してから使用禁止にしてください。 |
データベース・インスタンス・レベルでトレースを使用可能および使用禁止にする手順は次のとおりです。
SQL*Plusを起動し、管理者権限でデータベースに接続します。
データベース・インスタンス・レベルでトレースを使用可能にします。
次の例では、orclインスタンスに対するトレースを使用可能にします。
EXEC DBMS_MONITOR.DATABASE_TRACE_ENABLE(INSTANCE_NAME => 'orcl');
トレースする文を実行します。
データベース・インスタンスに対するトレースを使用禁止にします。
次の例では、orclインスタンスに対するトレースを使用禁止にします。
EXEC DBMS_MONITOR.DATABASE_TRACE_DISABLE(INSTANCE_NAME => 'orcl');
セッション・レベルでトレースを使用可能および使用禁止にする手順は次のとおりです。
SQL*Plusを起動し、必要な資格証明を使用してデータベースに接続します。
現行のセッションに対するトレースを使用可能にします。
次の例では、現行のセッションに対するトレースを使用可能にします。
EXEC DBMS_SESSION.SET_SQL_TRACE(sql_trace => TRUE);
トレースする文を実行します。
現行のセッションに対するトレースを使用禁止にします。
次の例では、現行のセッションに対するトレースを使用禁止にします。
EXEC DBMS_SESSION.SET_SQL_TRACE(sql_trace => FALSE);
|
関連項目: DBMS_MONITOR.DATABASE_TRACE_ENABLEの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 |
TKPROFは、SQLトレース機能によって生成されたトレース・ファイルを入力として受け入れ、フォーマットされた出力ファイルを生成します。TKPROFは、実行計画の生成にも使用できます。
SQLトレース機能によってトレース・ファイルが生成されると、次を実行できるようになります。
トレース・ファイルごとにTKPROFを実行して、フォーマットされた出力ファイルを各セッションに1つずつ作成できます。
トレース・ファイルを連結し、その結果のファイルに対してTKPROFを実行して、インスタンス全体のフォーマットされた出力ファイルを生成できます。
trcsessコマンドライン・ユーティリティを実行して複数のトレース・ファイルからトレース情報を統合し、結果に対してTKPROFを実行します。「trcsessユーティリティの使用方法」を参照してください。
TKPROFは、トレース・ファイルに記録されているCOMMITおよびROLLBACKをレポートしません。
TKPROFの出力例は次のようになります。
SELECT * FROM emp, dept WHERE emp.deptno = dept.deptno; call count cpu elapsed disk query current rows ---- ------- ------- --------- -------- -------- ------- ------ Parse 1 0.16 0.29 3 13 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 1 0.03 0.26 2 2 4 14 Misses in library cache during parse: 1 Parsing user id: (8) SCOTT Rows Execution Plan ------- ---------------------------------------------------
14 MERGE JOIN 4 SORT JOIN 4 TABLE ACCESS (FULL) OF 'DEPT' 14 SORT JOIN 14 TABLE ACCESS (FULL) OF 'EMP'
TKPROFは、トレース・ファイルのユーザー・レベル文と再帰的SQLコールの要約も提供します。
TKPROFは、オペレーティング・システムのプロンプトから実行します。構文は次のとおりです。
tkprof filename1 filename2 [waits=yes|no] [sort=option] [print=n] [aggregate=yes|no] [insert=filename3] [sys=yes|no] [table=schema.table] [explain=user/password] [record=filename4] [width=n]
必要な引数は、入力ファイルと出力ファイルのみです。引数を指定せずにTKPROFを起動すると、オンライン・ヘルプが表示されます。TKPROFを実行するときには表21-2の引数を使用します。
表21-2 TKPROF引数
この項では、TKPROFの2つの使用例を簡単に説明します。TKPROF出力例の詳細は、「TKPROFの出力例」を参照してください。
SORTパラメータとPRINTパラメータの組合せを使用して大規模なトレース・ファイルを処理する場合は、リソースを最も多く使用する文のみを含むTKPROF出力ファイルを生成できます。たとえば、次の文は、トレース・ファイルに格納されている、ほとんどの物理I/Oを生成した10個の文を印刷します。
TKPROF ora53269.trc ora53269.prf SORT = (PRSDSK, EXEDSK, FCHDSK) PRINT = 10
この例では、TKPROFを実行して、examp12_jane_fg_sqlplus_007.trcという名前のトレース・ファイルを取り込み、outputa.prfという名前のフォーマット済の出力ファイルに書き込みます。
TKPROF examp12_jane_fg_sqlplus_007.trc OUTPUTA.PRF EXPLAIN=scott/tiger TABLE=scott.temp_plan_table_a INSERT=STOREA.SQL SYS=NO SORT=(EXECPU,FCHCPU)
この例は、スクリーン上で複数行にわたって表示される可能性があるので、使用しているオペレーティング・システムによっては継続文字を使用する必要があります。
この例で使用されている他のパラメータに注意してください。
EXPLAINの値によって、TKPROFがユーザーscottとして接続され、トレースされた各SQL文の実行計画を生成するためにEXPLAIN PLAN文が使用されます。これを使用してアクセス・パスおよび行ソース行数を取得できます。
|
注意: SQL文のカーソルがクローズされていない場合、SQL文の実際の実行計画がTKPROF出力に自動的に含まれることはありません。この場合は、TKPROFでEXPLAINオプションを使用して、実行計画を生成できます。 |
TABLEの値によって、TKPROFがスキーマscottの表temp_plan_table_aを一時的なPLAN TABLEとして使用します。
INSERTの値によって、TKPROFがトレースされたすべてのSQL文に関する統計をデータベース内に格納するSQLスクリプト、STOREA.SQLを生成します。
SYSパラメータに値NOが指定されていることにより、TKPROFは出力ファイルに再帰的SQL文のリストを作成しません。このため、一時表操作などのOracle Databaseの内部の文は無視できます。
SORTの値によって、TKPROFはSQL文を出力ファイルに書き込む前に、SQL文の実行にかかったCPU時間と行のフェッチにかかったCPU時間の合計値の順にSQL文をソートします。効率を最大にするためには、SORTパラメータを常に使用してください。
この項では、TKPROF出力を解釈するためのヒントを示します。
TKPROFは非常に有用な分析を提供しますが、効率の最も正確なメジャーは、対象アプリケーションの実際のパフォーマンスです。TKPROF出力の最後の部分は、トレース実行期間中にプロセスがデータベース・エンジンで実行した作業のサマリーです。
TKPROFは、SQLトレース機能によって戻されるSQL文の統計のリストを行と列に作成します。各行は、SQL文を処理する3つのステップの1つに対応します。統計は、次に示すCALL列の値によって識別されます。表21-3を参照してください。
表21-3 CALL列の値
| CALLの値 | 意味 |
|---|---|
|
|
適切なセキュリティ認可のチェック、および表、列、その他の参照オブジェクトの存在のチェックを行ってSQL文を実行計画に変換します。 |
|
|
Oracleによって行われる実際の文の実行です。 |
|
|
問合せを満たす行を取得します。フェッチは、 |
SQLトレース機能の出力におけるその他の列は、すべての文の解析、実行、フェッチについての統計です。queryとcurrentの合計が、アクセスされたバッファの総数となります。これは論理I/O(LIO)とも呼ばれます。表21-4を参照してください。
表21-4 解析、実行およびフェッチのSQLトレース統計
処理された行に関する統計は、ROWS列に表示されます。表21-5を参照してください。
SELECT文の場合、戻された行数はフェッチ・ステップに表示されます。UPDATE文、DELETE文およびINSERT文の場合、処理された行数は実行ステップに表示されます。
|
注意: 行ソースの件数は、カーソルがクローズされたときに表示されます。SQL*Plusでは、ユーザー・カーソルは1つしかないため、文が実行されるたびに直前のカーソルがクローズされます。これにより、行ソースの件数が表示されます。PL/SQLには、独自のカーソル処理方法があり、親カーソルがクローズされても子カーソルはクローズされません。終了(または再接続)によって、件数が表示されます。 |
行ソースの操作では、行に対して実行される各操作で処理される行数と、物理読取りおよび書込みなど、行ソースの追加情報が提供されます。出力例は次のようになります。
Rows Row Source Operation
------- ---------------------------------------------------
0 DELETE (cr=43141 r=266947 w=25854 time=60235565 us)
28144 HASH JOIN ANTI (cr=43057 r=262332 w=25854 time=48830056 us)
51427 TABLE ACCESS FULL STATS$SQLTEXT (cr=3465 r=3463 w=0 time=865083 us)
647529 INDEX FAST FULL SCAN STATS$SQL_SUMMARY_PK
(cr=39592 r=39325 w=0 time=10522877 us) (object id 7409)
この例のTKPROF出力では、行ソースの操作の列で次の点に注意してください。
crは、行ソースにより実行される読取り一貫性を指定します。
rは、行ソースにより実行される物理読取りを指定します。
wは、行ソースにより実行される物理書込みを指定します。
timeは、時間をマイクロ秒単位で指定します。
待機イベント情報が存在する場合、TKPROF出力には次のようなセクションが含まれます。
Elapsed times include waiting on following events: Event waited on Times Max. Wait Total Waited ---------------------------------------- Waited ---------- ------------ db file sequential read 8084 0.12 5.34 direct path write 834 0.00 0.00 direct path write temp 834 0.00 0.05 db file parallel read 8 1.53 5.51 db file scattered read 4180 0.07 1.45 direct path read 7082 0.00 0.05 direct path read temp 7082 0.00 0.44 rdbms ipc reply 20 0.00 0.01 SQL*Net message to client 1 0.00 0.00 SQL*Net message from client 1 0.00 0.00
さらに、ファイルの最後でトレース・ファイル全体について待機イベントが要約されます。
待機イベント情報がそのセッションのトレース・ファイルに確実に書き込まれるようにするには、次のSQL文を実行します。
ALTER SESSION SET EVENTS '10046 trace name context forever, level 8';
タイミング統計の精度は100分の1秒であるため、100分の1秒以下のカーソル操作は正確に計測できません。統計を解読するときには、このことを覚えておいてください。非常に高速に実行する単純な問合せの結果を解読するときには特に注意してください。
ユーザーが発行したSQL文を実行するために、Oracle Databaseは内部的に追加の文を発行する必要があります。このような文を再帰的コールまたは再帰的SQL文と呼びます。たとえば、十分な領域のない表に行を挿入しようとすると、Oracle Databaseは再帰的コールを実行して動的に領域を割り当てます。データ・ディクショナリの情報がデータ・ディクショナリ・キャッシュにないため、ディスクから取り出す必要がある場合にも、再帰的コールが生成されます。
SQLトレース機能が使用可能になっているときに、再帰的コールが発生すると、TKPROFは再帰的SQL文の統計を生成し、出力ファイルで再帰的SQL文を明確に示します。SYSコマンドライン・パラメータをNOに設定して、出力ファイルへのOracle Database内部再帰的コール(たとえば、領域管理)のリスト表示を抑止できます。再帰的SQL文の統計は、再帰的コールを発生させたSQL文のリストでなく、再帰的SQL文のリストに表示されます。したがって、SQL文の処理に必要なリソースの合計を計算するときは、その文自体の統計と、その文によって生じる再帰的コールの統計を考慮する必要があります。
|
注意: 再帰的SQL統計は、SQLレベルの操作には組み込まれません。 |
TKPROFは、各SQL文の解析ステップと実行ステップの結果として生じるライブラリ・キャッシュ・ミス回数のリストも作成します。これらの統計は、表形式の統計に続く別の行に表示されます。文でライブラリ・キャッシュ・ミスが発生しなかった場合、TKPROFはその統計のリストを作成しません。「TKPROFの出力例」における解析ステップでは、ライブラリ・キャッシュ・ミスが1回発生し、実行ステップではライブラリ・キャッシュ・ミスは発生しませんでした。
次のSQL文は、SQLトレース・ファイルで25文字に切り捨てられます。
SET ROLE GRANT ALTER USER ALTER ROLE CREATE USER CREATE ROLE
TKPROFは、各SQL文を発行したユーザーのユーザーIDを出力します。SQLトレース入力ファイルに複数のユーザーからの統計が含まれ、文が複数のユーザーによって発行された場合、TKPROFは、文を解析した最後のユーザーのIDを出力します。すべてのデータベース・ユーザーのユーザーIDは、列ALL_USERS.USER_IDのデータ・ディクショナリに表示されます。
TKPROFのコマンドラインにEXPLAINパラメータを指定すると、TKPROFはEXPLAIN PLAN文を使用して、トレースされたSQL文ごとに実行計画を生成します。TKPROFは実行計画の各ステップによって処理された行数も表示します。
|
注意: インスタンスの始動直後に生成されたトレース・ファイルは、スタートアップ・プロセスのアクティビティを反映するデータを含みます。特に、これらは、システム・グローバル領域(SGA)のキャッシュがいっぱいになったときの不均衡な量のI/Oアクティビティを反映します。チューニングを行うときには、このようなトレース・ファイルは無視してください。 |
CPUリソースまたはディスク・リソースを最も消費するSQL文を検出する必要があります。TIMED_STATISTICSパラメータがオンになっている場合は、CPUの高いアクティビティをCPU列で見つけられます。TIMED_STATISTICSがオンになっていない場合は、QUERY列とCURRENT列をチェックします。
ロックの問題と効率の悪いPL/SQLループを除いて、問題の文を発見するためにはCPU時間と経過時間のどちらも必要ありません。重要なのは、問合せモード(すなわち、読取り一貫性の対象)と現行モード(読取り一貫性の非対象)の両方でアクセスするブロックの数です。セグメント・ヘッダーと更新されるブロックは現行モードで獲得されますが、すべての問合せ処理と副問合せ処理は問合せモードでデータを要求します。これらのメジャーは、インスタンス統計CONSISTENT GETSおよびDB BLOCK GETSとまったく同じです。高ディスク・アクティビティはディスク列で見つけられます。
次のリストには、あるSQL文のTKPROF出力が出力ファイルに表示されるときと同じ状態で示されています。:
SELECT * FROM emp, dept WHERE emp.deptno = dept.deptno; call count cpu elapsed disk query current rows ---- ------- ------- --------- -------- -------- ------- ------ Parse 11 0.08 0.18 0 0 0 0 Execute 11 0.23 0.66 0 3 6 0 Fetch 35 6.70 6.83 100 12326 2 824 ------------------------------------------------------------------ total 57 7.01 7.67 100 12329 8 826 Misses in library cache during parse: 0
7.01 CPU秒で、824行を取り出せる場合は、これ以上このトレース出力を検索する必要はありません。事実上、チューニング作業でのTKPROFレポートの主な用途は、詳細なチューニング段階のプロセスを排除することです。
1つの文に対して11の解析コールが存在していたため、10の不要な解析コールが作成され、その配列フェッチ操作が実行されたことも確認できます。これは、フェッチで取り出された行よりも多くの行がフェッチされていることからわかります。CPU時間と経過時間の大きなギャップは、物理I/O(PIO)の存在を示します。
SQLトレース機能によって生成されたアプリケーションに関する統計の履歴を保持し、別の時点でこれらの統計を比較することがあります。TKPROFは、表を作成して、統計の行をその表に挿入するSQLスクリプトを生成します。このスクリプトには、次の内容が記述されています。
TKPROF_TABLEという出力表を作成するCREATE TABLE文
トレースしたSQL文ごとに統計行を1行ずつTKPROF_TABLEに追加するINSERT文
TKPROFの実行後にこのスクリプトを実行すると、統計をデータベースに格納できます。
TKPROFを実行する場合は、INSERTパラメータを使用して、生成されるSQLスクリプトの名前を指定します。このパラメータを指定しないと、TKPROFはスクリプトを生成しません。
TKPROFによってSQLスクリプトが作成された後、SQLスクリプトを実行する前にスクリプトを編集できます。以前に収集した統計の出力表が作成され、新しい統計をこの表に追加する場合は、スクリプトからCREATE TABLE文を削除します。これにより、スクリプトが新しい行を既存の表に挿入します。
異なるデータベースの統計を別々の表に格納するためなど、複数の出力表を作成している場合は、CREATE TABLE文とINSERT文を編集して、出力表の名前を変更してください。
次のCREATE TABLE文はTKPROF_TABLEを作成します。
CREATE TABLE TKPROF_TABLE (
DATE_OF_INSERT DATE, CURSOR_NUM NUMBER, DEPTH NUMBER, USER_ID NUMBER, PARSE_CNT NUMBER, PARSE_CPU NUMBER, PARSE_ELAP NUMBER, PARSE_DISK NUMBER, PARSE_QUERY NUMBER, PARSE_CURRENT NUMBER, PARSE_MISS NUMBER, EXE_COUNT NUMBER, EXE_CPU NUMBER, EXE_ELAP NUMBER, EXE_DISK NUMBER, EXE_QUERY NUMBER, EXE_CURRENT NUMBER, EXE_MISS NUMBER, EXE_ROWS NUMBER, FETCH_COUNT NUMBER, FETCH_CPU NUMBER, FETCH_ELAP NUMBER, FETCH_DISK NUMBER, FETCH_QUERY NUMBER, FETCH_CURRENT NUMBER, FETCH_ROWS NUMBER, CLOCK_TICKS NUMBER, SQL_STATEMENT LONG);
出力表のほとんどの列は、フォーマットされた出力ファイルに記録されている統計と直接対応しています。たとえば、PARSE_CNT列の値は出力ファイルの解析ステップに関するカウント統計に対応しています。
表21-6の列は、統計が入っている行を識別する際に役立ちます。
表21-6 統計の行を識別するTKPROF_TABLE列
文の実行計画は出力表に格納されません。次の問合せは、出力表からの統計を返します。これらの統計は、「TKPROFの出力例」で示したフォーマットされた出力に対応します。
SELECT * FROM TKPROF_TABLE;
Oracle Databaseのレスポンスを次に示します。
DATE_OF_INSERT CURSOR_NUM DEPTH USER_ID PARSE_CNT PARSE_CPU PARSE_ELAP
-------------- ---------- ----- ------- --------- --------- ----------
21-DEC-1998 1 0 8 1 16 22
PARSE_DISK PARSE_QUERY PARSE_CURRENT PARSE_MISS EXE_COUNT EXE_CPU
---------- ----------- ------------- ---------- --------- -------
3 11 0 1 1 0
EXE_ELAP EXE_DISK EXE_QUERY EXE_CURRENT EXE_MISS EXE_ROWS FETCH_COUNT
-------- -------- --------- ----------- -------- -------- -----------
0 0 0 0 0 0 1
FETCH_CPU FETCH_ELAP FETCH_DISK FETCH_QUERY FETCH_CURRENT FETCH_ROWS
--------- ---------- ---------- ----------- ------------- ----------
2 20 2 2 4 10
SQL_STATEMENT
---------------------------------------------------------------------
SELECT * FROM EMP, DEPT WHERE EMP.DEPTNO = DEPT.DEPTNO
この項では、TKPROFの解釈における細かなポイントをいくつか説明します。
実行時にバインドされる値を認識していない場合は、引数トラップに陥る可能性があります。EXPLAIN PLANは、SQL文のテキストからバインド変数の型を判断できないので、型は常にvarcharであると想定されます。バインド変数が実際には番号または日付である場合、TKPROFが暗黙的データ変換を行い、その結果、効率の悪い計画が実行される可能性があります。この状況を回避するには、異なるデータ型を使用して問合せを試みます。
この問題を回避するには、各自で変換を行ってください。
次の例は、読取り一貫性トラップを示しています。コミットされていないトランザクションがNAME列に一連の更新を行ったことを知らないと、多くのブロックがアクセスされる理由を判断することは非常に困難です。
通常、このようなケースは再現可能ではありません。そのプロセスが再度実行された場合に、別のトランザクションが同じようにそのプロセスに影響を及ぼすことはあまりありません。
SELECT name_id FROM cq_names WHERE name = 'FLOOR'; call count cpu elapsed disk query current rows ---- ----- --- ------- ---- ----- ------- ---- Parse 1 0.10 0.18 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 1 0.11 0.21 2 101 0 1 Misses in library cache during parse: 1 Parsing user id: 01 (USER1) Rows Execution Plan ---- --------- ---- 0 SELECT STATEMENT 1 TABLE ACCESS (BY ROWID) OF 'CQ_NAMES' 2 INDEX (RANGE SCAN) OF 'CQ_NAMES_NAME' (NON_UNIQUE)
この例は極端な場合を示しているので、スキーマ・トラップは容易に検出できます。最初は、明らかに単純に索引付けされた問合せが多くのデータベース・ブロックを検索する必要がある理由、または現行モードでブロックにアクセスすることが必要な理由を理解することは困難です。
SELECT name_id
FROM cq_names
WHERE name = 'FLOOR';
call count cpu elapsed disk query current rows
-------- ------- -------- --------- ------- ------ ------- ----
Parse 1 0.06 0.10 0 0 0 0
Execute 1 0.02 0.02 0 0 0 0
Fetch 1 0.23 0.30 31 31 3 1
Misses in library cache during parse: 0
Parsing user id: 02 (USER2)
Rows Execution Plan
------- ---------------------------------------------------
0 SELECT STATEMENT
2340 TABLE ACCESS (BY ROWID) OF 'CQ_NAMES'
0 INDEX (RANGE SCAN) OF 'CQ_NAMES_NAME' (NON-UNIQUE)
2つの統計は、問合せが全表スキャンを使用して実行された可能性があることを示しています。これらの統計は、現行モードでのブロック・アクセスと、実行計画のTable Access行ソースに由来する行数です。これは、トレース・ファイルが生成された後、TKPROFが実行される前に、必要な索引が構築されたことを示しています。
新規トレース・ファイルを生成すると次のデータが与えられます。
SELECT name_id
FROM cq_names
WHERE name = 'FLOOR';
call count cpu elapsed disk query current rows
----- ------ ------ -------- ----- ------ ------- -----
Parse 1 0.01 0.02 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 2 0 1
Misses in library cache during parse: 0
Parsing user id: 02 (USER2)
Rows Execution Plan
------- ---------------------------------------------------
0 SELECT STATEMENT
1 TABLE ACCESS (BY ROWID) OF 'CQ_NAMES'
2 INDEX (RANGE SCAN) OF 'CQ_NAMES_NAME' (NON-UNIQUE)
この正しいバージョンで注目する機能の1つは、解析コールには10ミリ秒のCPU時間と20ミリ秒の経過時間を要する一方で、問合せとフェッチの実行にはまったく時間がかかっていないことです。これらの例外的事態が発生するのは、10ミリ秒というクロック刻みがデータの実行およびフェッチに要する時間と比べて非常に長いためです。このような場合、文を多く実行して統計的に有効な数値を得ることが重要になります。
次の例で示すように、特定の問合せに長時間かかる理由がわからないことがあります。
UPDATE cq_names SET ATTRIBUTES = lower(ATTRIBUTES)
WHERE ATTRIBUTES = :att
call count cpu elapsed disk query current rows
-------- ------- -------- --------- -------- -------- ------- ----------
Parse 1 0.06 0.24 0 0 0 0
Execute 1 0.62 19.62 22 526 12 7
Fetch 0 0.00 0.00 0 0 0 0
Misses in library cache during parse: 1
Parsing user id: 02 (USER2)
Rows Execution Plan
------- ---------------------------------------------------
0 UPDATE STATEMENT
2519 TABLE ACCESS (FULL) OF 'CQ_NAMES'
ここでも、別のトランザクションによる妨害というのが答えです。この場合は、別のトランザクションが更新を発行する前後の数秒間、表cq_namesで共有ロックが保持されています。妨害の影響が発生していることを診断できるようになるにはかなりの経験が必要です。一方で、妨害によって発生する遅延が短時間である(または前の例のようにブロック・アクセスにおける増加がわずかである)場合は、比較用のデータが必要です。ただし、妨害によるオーバーヘッドが少なく、本質的に文が効率的である場合は、統計を分析する必要はありません。
この項では、TKPROF出力の例を示します。簡潔化のために各部分を編集してあります。
TKPROF: Release 10.1.0.0.0 - Mon Feb 10 14:43:00 2003 (c) Copyright 2001 Oracle Corporation. All rights reserved. Trace file: main_ora_27621.trc Sort options: default ******************************************************************************** count = number of times OCI procedure was executed cpu = cpu time in seconds executing elapsed = elapsed time in seconds executing disk = number of physical reads of buffers from disk query = number of buffers gotten for consistent read current = number of buffers gotten in current mode (usually for update) rows = number of rows processed by the fetch or execute call ********************************************************************************
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.01 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2 0.01 0.00 0 0 0 0
Misses in library cache during parse: 1
Optimizer mode: FIRST_ROWS
Parsing user id: 44
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
SQL*Net message from client 1 28.59 28.59
********************************************************************************
select condition
from
cdef$ where rowid=:1
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 2 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 3 0.00 0.00 0 2 0 1
Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 1)
Rows Row Source Operation
------- ---------------------------------------------------
1 TABLE ACCESS BY USER ROWID OBJ#(31) (cr=1 r=0 w=0 time=151 us)
********************************************************************************
SELECT last_name, job_id, salary
FROM employees
WHERE salary =
(SELECT max(salary) FROM employees)
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.02 0.01 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.00 0.00 0 15 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4 0.02 0.01 0 15 0 1
Misses in library cache during parse: 1
Optimizer mode: FIRST_ROWS
Parsing user id: 44
Rows Row Source Operation
------- ---------------------------------------------------
1 TABLE ACCESS FULL EMPLOYEES (cr=15 r=0 w=0 time=1743 us)
1 SORT AGGREGATE (cr=7 r=0 w=0 time=777 us)
107 TABLE ACCESS FULL EMPLOYEES (cr=7 r=0 w=0 time=655 us)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
SQL*Net message from client 2 9.62 9.62
********************************************************************************
********************************************************************************
delete
from stats$sqltext st
where (hash_value, text_subset) not in
(select --+ hash_aj
hash_value, text_subset
from stats$sql_summary ss
where ( ( snap_id < :lo_snap
or snap_id > :hi_snap
)
and dbid = :dbid
and instance_number = :inst_num
)
or ( dbid != :dbid
or instance_number != :inst_num)
)
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 29.60 60.68 266984 43776 131172 28144
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2 29.60 60.68 266984 43776 131172 28144
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: 22
Rows Row Source Operation
------- ---------------------------------------------------
0 DELETE (cr=43141 r=266947 w=25854 time=60235565 us)
28144 HASH JOIN ANTI (cr=43057 r=262332 w=25854 time=48830056 us)
51427 TABLE ACCESS FULL STATS$SQLTEXT (cr=3465 r=3463 w=0 time=865083 us)
647529 INDEX FAST FULL SCAN STATS$SQL_SUMMARY_PK
(cr=39592 r=39325 w=0 time=10522877 us) (object id 7409)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 8084 0.12 5.34
direct path write 834 0.00 0.00
direct path write temp 834 0.00 0.05
db file parallel read 8 1.53 5.51
db file scattered read 4180 0.07 1.45
direct path read 7082 0.00 0.05
direct path read temp 7082 0.00 0.44
rdbms ipc reply 20 0.00 0.01
SQL*Net message to client 1 0.00 0.00
SQL*Net message from client 1 0.00 0.00
********************************************************************************
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 4 0.04 0.01 0 0 0 0
Execute 5 0.00 0.04 0 0 0 0
Fetch 2 0.00 0.00 0 15 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 11 0.04 0.06 0 15 0 1
Misses in library cache during parse: 4
Misses in library cache during execute: 1
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 6 0.00 0.00
SQL*Net message from client 5 77.77 128.88
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 2 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 3 0.00 0.00 0 2 0 1
Misses in library cache during parse: 1
5 user SQL statements in session.
1 internal SQL statements in session.
6 SQL statements in session.
********************************************************************************
Trace file: main_ora_27621.trc
Trace file compatibility: 9.00.01
Sort options: default
1 session in tracefile.
5 user SQL statements in trace file.
1 internal SQL statements in trace file.
6 SQL statements in trace file.
6 unique SQL statements in trace file.
76 lines in trace file.
128 elapsed seconds in trace file.
