| Oracle Databaseパフォーマンス・チューニング・ガイド 11gリリース1（11.1） E05743-02 |
|
 戻る |
 次へ |
Oracleでは、Oracleデータベースで実行されるアプリケーションの監視および分析に役立つトレース・ツールをいくつか提供しています。
End to End Application Tracingでは、高負荷のSQL文などの過剰なワークロードのソースを、クライアント識別子、サービス、モジュール、アクション、セッション、インスタンスまたはデータベース全体によって識別できます。これによって、問題が特定のユーザー、サービス、セッションまたはアプリケーション・コンポーネントに特定されます。
Oracleでは、特定の基準に基づいてトレース情報を統合するtrcsessコマンドライン・ユーティリティを提供します。
SQLトレース機能およびTKPROFは、Oracleサーバーのもとで実行されるアプリケーションの監視に役立つ2つの基本的なパフォーマンス診断ツールです。
この章には次の項があります。
|
関連項目: 自動トレースを使用したSQL*Plus文のトレースおよびチューニングの詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。 |
End to End Application Tracingを使用すると、複数層環境におけるパフォーマンス問題の診断プロセスが簡素化されます。複数層環境では、エンド・クライアントからのリクエストは中間層により様々なデータベース・セッションにルーティングされるため、異なるデータベース・セッション間でクライアントを追跡しにくくなっています。End to End Application Tracingでは、クライアント識別子により、すべての層を通してデータベース・サーバーまで、特定のエンドクライアントが一意にトレースされます。
この機能では、高負荷のSQL文などの過剰なワークロードのソースを識別でき、担当する特定のユーザーに連絡をとることができます。また、問題のあるユーザーから連絡を受け、データベース・レベルでのユーザーのセッションの動作を識別できます。
さらに、End to End Application Tracingでは、あるサービスの特定のモジュールおよびアクションを追跡することで、アプリケーション・ワークロードの管理が簡素化されます。
End to End Application Tracingによりワークロードの問題を識別できるのは、次のとおりです。
クライアント識別子: HR.HRなどのログオンIDに基づいてエンド・ユーザーを指定します。
サービス: 共通の属性、サービス・レベルのしきい値および優先順位を使用してアプリケーション・グループを指定するか、または会計アプリケーションの場合はACCTGなどのように単一アプリケーションを指定します。
モジュール: 売掛勘定または総勘定元帳など、アプリケーションの機能ブロックを指定します。
アクション: INSERTまたはUPDATE操作など、モジュール内のアクションを指定します。
セッション: 任意のデータベース・セッション識別子（SID）に基づいて、ローカル・インスタンスのセッションを指定します。
インスタンス: インスタンス名に基づいて任意のインスタンスを指定します。
トレース情報がファイルに書き込まれた後、この情報をtrcsessユーティリティによって統合し、TKPROFなどの分析ユーティリティによって診断できます。
単一インスタンスのOracleデータベースでサービスを作成するには、DBMS_SERVICEパッケージのCREATE_SERVICEプロシージャを使用するか、またはSERVICE_NAMES初期化パラメータを設定できます。
モジュール名およびアクション名は、アプリケーション開発者が設定します。たとえば、PL/SQLプログラムでこれらの値を設定するには、DBMS_APPICATION_INFOパッケージのSET_MODULEおよびSET_ACTIONプロシージャを使用します。
End to End Application Tracingの推奨されるインタフェースは、Oracle Enterprise Managerです。Enterprise Managerを使用する場合、各コンシューマ・タイプの上位コンシューマを表示して、特定のコンシューマの統計収集およびSQLトレースを使用可能または使用禁止にできます。可能なかぎり、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』の手順に従って、Enterprise Managerを使用してEnd to End Application Tracingを管理する必要があります。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文に関するパフォーマンス情報を提供します。SQLトレース機能は、文単位に次の統計を生成します。
解析、実行、フェッチのカウント
CPU時間と経過時間
物理読取りと論理読取り
処理された行数
ライブラリ・キャッシュでのミス
それぞれの解析が行われるユーザー名
各コミットおよびロールバック
各SQL文の待機イベント・データおよび各トレース・ファイルの要約
また、SQL文のカーソルがクローズされている場合は、SQLトレースにより次の内容を含む行ソース情報が提供されます。
各SQL文の実際の実行計画を示す行操作
行数、一貫性のある読取りの数、物理読取り数、物理書込み数および行の各操作の経過時間
1つのセッションまたはインスタンスに対してSQLトレース機能を使用可能にできますが、かわりにDBMS_SESSIONまたはDBMS_MONITORパッケージを使用することをお薦めします。セッションまたはインスタンスに対してSQLトレース機能を使用可能にすると、ユーザー・セッションまたはインスタンスで実行されるすべてのSQL文のパフォーマンス統計がトレース・ファイルに格納されます。SQLトレース機能を使用するとパフォーマンスに重大な影響を与えることがあり、システム・オーバーヘッドの増加、過剰なCPU使用率およびディスク領域の不足をもたらす場合があります。
|
関連項目: DBMS_SESSIONまたはDBMS_MONITORパッケージを使用してセッションまたはインスタンスに対するSQLトレースを使用可能にする方法の詳細は、「エンドツーエンド・トレースにおける有効化および無効化」を参照してください。 |
Oracleでは、セッションまたはクライアントIDなどの特定の基準に基づいて複数のトレース・ファイルからトレース情報を統合する、trcsessコマンドライン・ユーティリティが提供されています。「trcsessユーティリティの使用方法」を参照してください。
TKPROFプログラムを実行すると、トレース・ファイルの内容をフォーマットし判読可能なファイルとして出力できます。TKPROFは次のことも実行します。
統計をデータベースに格納するSQLスクリプトを作成します。
SQL文の実行計画を判断します。
|
注意: SQL文のカーソルがクローズされていない場合、TKPROF出力には、SQL文の実際の実行計画は自動的に含められません。この場合は、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はトレース・ファイルを生成します。このファイルには、そのセッションのトレースされたSQL文に関する統計が記録されています。インスタンスに対してSQLトレース機能が使用可能になると、Oracleはプロセスごとに個別のトレース・ファイルを作成します。SQLトレース機能を有効にする前に、次のことを行ってください。
TIMED_STATISTICS、MAX_DUMP_FILE_SIZEおよびUSER_DUMP_DESTの初期化パラメータ設定をチェックします。表21-1を参照してください。
表21-1 SQLトレース機能を有効にする前にチェックする初期化パラメータ
|
関連項目:
|
結果のトレース・ファイルを認識する方法を考えます。
トレース・ファイルを名前で区別できるようにしてください。Oracleは、USER_DUMP_DESTで指定されたユーザー・ダンプ出力先にこれらを書き込みます。ただし、このディレクトリは通常、生成された名前を持つ何百ものファイルですぐにいっぱいになります。このため、トレース・ファイルを生成元のセッションやプロセスに対応づけることは困難な場合があります。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_SESSION.SET_SQL_TRACEプロシージャ
ALTER SESSION SET SQL_TRACE = TRUE;
|
注意: SQLトレース機能を実行するとシステムのオーバーヘッドが増加するため、この機能はSQL文をチューニングするときにのみ使用可能にし、チューニングが終了してから使用禁止にしてください。かわりにDBMS_SESSIONまたはDBMS_MONITORパッケージを使用して、セッションまたはインスタンスに対するSQLトレースを使用可能にすることをお薦めします。これらのパッケージの詳細は、「エンドツーエンド・トレースにおける有効化および無効化」を参照してください。
|
SQLトレース機能を使用禁止にするには、次のように入力します。
ALTER SESSION SET SQL_TRACE = FALSE;
アプリケーションがOracleとの接続を切断すると、そのセッションのSQLトレース機能は自動的に使用禁止になります。
初期化ファイルのSQL_TRACE初期化パラメータの値をTRUEに設定すると、インスタンスに対してSQLトレース機能が使用可能になります。
SQL_TRACE = TRUE
更新済初期化パラメータ・ファイルを使用してインスタンスを再起動すると、インスタンスに対してSQLトレースが使用可能になり、すべてのセッションに関する統計が収集されます。インスタンスに対してSQLトレース機能を使用可能にした場合は、SQL_TRACEパラメータの値をFALSEに設定すると使用禁止にできます。
|
注意: SQL_TRACEをTRUEに設定すると、サーバーのパフォーマンスに重大な影響を与えることがあります。詳細は、『Oracle Databaseリファレンス』を参照してください。 |
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文のカーソルがクローズされていない場合、TKPROF出力には、SQL文の実際の実行計画は自動的に含められません。この場合は、TKPROFでEXPLAINオプションを使用して、実行計画を生成できます。 |
TABLEの値によって、TKPROFがスキーマscottの表temp_plan_table_aを一時的なPLAN TABLEとして使用します。
INSERTの値によって、TKPROFがトレースされたすべてのSQL文に関する統計をデータベース内に格納するSQLスクリプト、STOREA.SQLを生成します。
SYSパラメータに値NOが指定されていることにより、TKPROFは出力ファイルに再帰的SQL文のリストを作成しません。そのため、一時表操作などの内部Oracle文は無視されます。
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は内部的に追加の文を実行する必要があります。このような文を再帰的コールまたは再帰的SQL文と呼びます。たとえば、十分な領域のない表に行を挿入しようとすると、Oracleは再帰的コールを実行して動的に領域を割り当てます。データ・ディクショナリの情報がデータ・ディクショナリ・キャッシュにないため、ディスクから取り出す必要がある場合にも、再帰的コールが生成されます。
SQLトレース機能が使用可能になっているときに、再帰的コールが発生すると、TKPROFは再帰的SQL文の統計を生成し、出力ファイルで再帰的SQL文を明確に示します。SYSコマンドライン・パラメータをNOに設定して、出力ファイルへのOracle内部再帰的コール（たとえば、領域管理）のリスト表示を抑止できます。再帰的SQL文の統計は、再帰的コールを発生させたSQL文のリストでなく、再帰的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によって次のような結果が返されます。
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で共有ロックが保持されています。妨害の影響が発生していることを診断できるようになるにはかなりの経験が必要です。妨害によって発生する遅延が短時間である（または前の例のようにブロック・アクセスにおける増加がわずかである）場合は、比較用のデータが必要です。一方、妨害がわずかなオーバーヘッドの原因にしかならず、本質的に文の効率がよい場合は、統計を分析の対象にする必要はありません。
ある文についてレポートされたリソースには、文が処理されていた間に発行されたすべてのSQL用のリソースが含まれます。したがって、これらには、トリガーで使用されるリソースと、領域割当てで使用されるリソースなど他の再帰的SQLで使用されるリソースが含まれます。リソースが実際に低い再帰レベルで使用されている場合は、DML文をチューニングすることは避けてください。
DML文が予想よりはるかに多くのリソースを消費していると思われる場合は、トリガーと制約についてのSQL文に関連する表をチェックして、トリガーと制約がリソースの使用量を大幅に増やしていないか、調べてください。
この項では、TKPROF出力の例を示します。簡潔化のために各部分を編集してあります。
TKPROF: Release 10.1.0.0.0 - Beta on 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.
