1. 特定のプロセスにバインディング
ティパックがoradebugコマンドを使用する理由は特定のプロセスに自由にバインディングできるからです。
-- SYSDBA ユ?ザ?でログイン
sqlplus "/as sysdba"
-- 現在のプロセスにバインディング
SQL> oradebug setmypid
-- 特定のセッションのOS Process IDでバインディング
SQL> select sid, serial#,
(select spid from v$process where addr = paddr) as ospid
from v$session
where sid = (select sid from v$mystat where rownum = 1);
SID SERIAL# OSPID
---------- ---------- ------------
144 2446 4872
SQL> oradebug setospid 4872
Oracle pid: 16, Windows thread id: 4872, image: ORACLE.EXE (SHAD)
特定のプロセスにバインディングするには次の４つの方法があります。
SQL> oradebug help
SETMYPID Debug current process
SETOSPID {ospid} Set OS pid of process to debug
SETORAPID {orapid} ['force'] Set Oracle pid of process to debug
SETORAPNAME {orapname} Set Oracle process name to debug -- 11g에서 추가
...
SETOSPIDコマンドを主に使用する理由はUnix/Linux環境ではProcess ID(PID)を得るのが易いからです。でも、ティパックでは特定のセッションを指定するためにSession ID(SID)をパラメ?タ?で使用します。オラクルではSIDが一番認識しやすい値からです。
2. トレ?スファイルの名前の獲得
ティパックでは特定のプロセスに?してイベントやダンプを行い、その中身を?み?む作業がいくつかあります。したがって、トレ?スファイルの名前を正確にえるのが大事です。oradebug tracefile_name名前がそれに?たります。
SQL> oradebug tracefile_name
c:\oracle\admin\ukja1021\udump\ukja1021_ora_4872.trc
上の作業をティパックでは次のように行なえます。
-- 143番セッションのトレ?スファイルの名前
SQL> select tpack.get_tracefile_name(143) from dual;
c:\oracle\admin\ukja1021\udump\ukja1021_ora_4872.trc
-- レ?スファイルの中身
SQL> select * from table(tpack.get_tracefile_contents('c:\oracle\admin\ukja1021\udump\ukja1021_ora_4872.trc'))
あるいは次のようなクエリを通じても得られます。しかし、ファイル名の正確なフォ?マットはバ?ジョンやＯＳにより?わられます。もう１つの短所は該?プロセスがサ?バ?プロセスなのか、バックグラウンドプロセスなのかを事前に知ることが必要で、プロセスの種類によりどんなディレクトリ?にファイルが書き?まれるのかも判?したければならないということです。このような複?性のためにティパックではoradebug tracefile_nameコマンドを利用します。
select
d.value||'\'||p.value||'_ora_'||s.spid||'.trc' as trace_file_name
from
(
select value
from v$parameter
where name = 'instance_name'
) p,
(
select value
from v$parameter
where name = 'user_dump_dest'
) d,
(
select spid
from v$process
where addr = (
select paddr
from v$session
where sid = {sid here}
)
) s
3. 診?イベントの修行
特定のプロセスにバインディングした後は該?プロセスに?して診?イベントが行なわれます。
-- 診?イベントの活性化
SQL> oradebug event 10046 trace name context forever, level 12
-- 診?イベントの非活性化
SQL> oradebug event 10046 context off
-- トレ?スファイルの確認
SQL> oradebug tracefile_name
SQL> ed {tracefile_name}
上の作業をティパックでは次のように行われます。
-- 診?イベントの活性化
SQL> exec tpack.begin_diag_trace(143, 10046, 12);
-- 診?イベントの非活性化
SQL> exec tpack.end_diag_trace(143, 10046);
-- トレ?スファイルの確認
SQL> select * from table(tpack.get_diag_trace(143));
ティパックを利用すればoradebugを利用するためにテルネットで接?する必要かないし、クライアントでSQL*Plusですべての作業ができます。ティパックのもう１つの長所は診?イベントを活性した後に生成された中身だけを?み?むということです。すなわち、診?イベントを活性する前に、もうほかの作業により書き?まれた多くのデ?タわスキップされ、今度の作業により書き?まれた中身だけを?み?みます。
4. ダンプの修行
特定のプロセスにバインディングした後、該?プロセスに?して多?なダンプファイルを生成できます。次に簡?な例があります。
-- レベル１でCallstackダンプの修行
SQL> oradebug dump callstack 1
-- PGA Heap Dump。Level 0x20000001とは最上位ヒ?プだけではなくてサイズが大きい五つのサブヒ?プに?して再?的にダンプを修行しろという意味です。非常に有?な機能だと言えます。
SQL> oradebug dump heapdump 0x20000001
ティパックではヒ?プダンプファイルから?み?んだデ?タを加工して分析レポ?トを提供します。
-- 143番セッションに?してCallstackダンプを1秒?たり10回行い、その結果を要約してレポ?ト
SQL> select * from table(tpack.callstack_prof_report(143));
-- 143番セッションに?してPGA Heap Dumpをレベル0x20000001で行い、この結果をレポ?ト
SQL> select * from table(tpack.pga_heap_report(143, 2));
ティパックは性能トラブルシュ?ティングに必要な基本的なデ?タの一部を診?イベントやダンプを通じて得ています。PGA Heap DumpやCallstack Dumpが代表的な例です。このようなデ?タを得るための一番易い（もしかしたら唯一
な）方法としてoradebugを使用しています。
1つの技術的な難しさはSQLコマンドからどうすればoradebugを自由に呼び出すのかということです。ティパックではJava Stored Procedureを利用しています。これに?する詳細なお話は次のポストで進める予定です。
性能トラブルシュ?ティングの段階が深まるほどoradebugの魅力におぼれるはずです。特にOracle 11gでは完全に新しく設計されたOracle Debugging Frameworkが提供され、それに連れてoradebugの機能ももっと?くなりました。詳細な?容は次の文書を?考してください。
以前のポスト
Posts
No comments:
Post a Comment