2017.07.20
Oracle Dump
目次
インデックスツリーダンプ
インデックスのツリー構造を取得します。
ALTER SESSION SET EVENTS ‘immediate trace name treedump level ';
----- begin tree dump
branch: 0x8405dde 138436062 (0: nrow: 3, level: 3)
branch: 0xdc11022 230756386 (-1: nrow: 219, level: 2)
branch: 0x8405f15 138436373 (-1: nrow: 138, level: 1)
leaf: 0x8405ddf 138436063 (-1: nrow: 21 rrow: 21)
leaf: 0x8405de0 138436064 (0: nrow: 18 rrow: 13)
leaf: 0x8405de2 138436066 (1: nrow: 15 rrow: 15)
上記のDump内容の項目の意味は次の通りです。
- Node Type：branch/ leafノードかどうか
- DBA：ブロックアドレス。0x8405de2 138436066（16進数、10進数）
- Relative Position：親ノードからの相対的な位置（-1,0,1,2、…）
- Entry数：row=全Entry（Deleted Entryを含む）、row= Real Entry（Deleted Entryを除く）
DBAをRelative File NumberとBlock Numberに変換する方法は以下の通りです。
SQL> SELECT dbms_utility.data_block_address_file(138436066) as file_no, -- 十進数
dbms_utility.data_block_address_block(138436066) as block_no -- 十進数
FROM dual;
インデックス ツリー ダンプを実行するプロシジャーを次のように作成して使用すると便利です。
create or replace procedure tree_dump(v_name in varchar2)
is
v_obj_id number;
begin
for r_id in (select object_id from all_objects
where object_name = upper(v_name) order by object_id) loop
execute immediate
'alter session set events ''immediate trace name treedump level '||r_id.object_id||'''';
end loop;
end;
/
Partitioned Indexの場合には、次のように特定のPartitionを指定することもできます。
create or replace procedure tree_dump2(v_name in varchar2, v_part_name in varchar2)
is
v_obj_id number;
begin
for r_id in (select object_id from user_objects
where object_name = upper(v_name)
and subobject_name = upper(v_part_name)
order by object_id) loop
execute immediate
'alter session set events ''immediate trace name treedump level '||r_id.object_id||'''';
end loop;
end;
/
ヒープダンプ
ヒープ構造を取得します。ヒープに関する障害（バグ）をトラブルシューティングするとき多く使用されます。
alter session set events 'immediate trace name heapdump level '; oradebug dump heapdump ;
Level値の意味は以下の通りです。
- Level = 1: Top PGA
- Level = 2: Top SGA
- Level = 3: Top UGA
- Level = 8: Current Call
- Level = 16: User Call
- Level = 32: Large Pool
上のレベルの値には、次のようなLevel Bitを追加すると、最大5つのサブヒープまでDumpを実行します。
- 0×10000000：最大5つのサブヒープを共にダンプ
- 0x20000000：最大5つのサブヒープについて子サブヒープまでダンプ（Recursive）
つまり、次のようにヒープ ダンプを実行すると、
oradebug dump heapdump 0x20000002
Top SGAと最大5つのサブヒープについて再帰的にヒープダンプを出力してくれます。ただし、サブダンプまでダンプを実行すると、ダンプ ファイルのサイズが非常に大きくなることがあることに注意してください。しかし、ほとんどのメモリリークの問題は、サブヒープレベルで発生するためサブヒープまでダンプを実行することを推奨します。
ヒープ ダンプは、次のような形式になります。
****************************************************** HEAP DUMP heap name="pga heap" desc=09701D30 extent sz=0x206c alt=92 het=32767 rec=0 flg=2 opc=2 parent=00000000 owner=00000000 nex=00000000 xsz=0xfff8 EXTENT 0 addr=08520008 Chunk 8520010 sz= 18880 perm "perm " alo=8020 Chunk 85249d0 sz= 2824 free " " Chunk 85254d8 sz= 8036 freeable "Alloc environm " ds=08427B34 Chunk 852743c sz= 20572 freeable "Fixed Uga " Chunk 852c498 sz= 180 freeable "ldm context " Chunk 852c54c sz= 180 freeable "ldm context " Chunk 852c600 sz= 180 freeable "ldm context " Chunk 852c6b4 sz= 180 freeable "ldm context " Chunk 852c768 sz= 180 freeable "ldm context " Chunk 852c81c sz= 180 freeable "ldm context "
ヒープ ダンプの結果のうち、以下のようにds（Heap Descriptor）の値を持つ場合は、そのチャンク(chunk)がサブヒープを指すことを意味します。
EXTENT 3551 addr=0A080004
Chunk a08000c sz= 48 free " "
Chunk a08003c sz= 65476 recreate "session heap " latch=00000000
ds a067600 sz=498960112 ct= 3552
サブヒープをダンプするためには次のような命令を使用します。
oradebug dump heapdump_addr
SYS@ukja10> oradebug dump heapdump_addr 1 0xa067600
Levelは、次のような意味を持ちます。
- Level=1：Data構造のみ出力
- Level=2：Data内容まで出力
Level2は非常に多くのデータを出力するので、パフォーマンスに大きな悪影響を与える可能性があるため、必要な場合にのみ使用します。ほとんどの場合、Level1だけで必要な結果を得ることができます。
ライブラリ・キャッシュ・ダンプ
ライブラリ キャッシュ構造を取得します。SQL カーソルParent/ Child）の構造を把握しようとするとき多く使用されます。
ALTER SESSION SET EVENTS 'immediate trace name library_cache level 10'; -- バージョンに応じて、16、32などの値を使用することで完璧な範囲のライブラリ キャッシュダンプが実行されます。
...
-- Parent Cursor
BUCKET 89106:
LIBRARY OBJECT HANDLE: handle=84ad91c0 mtx=0x84ad92f0(2) cdp=2
name=SELECT * FROM SHARE_TEST WHERE NAME = ：x
hash=8f5a0aa420c69c69f3dc950037b95c12 timestamp=11-09-2007 14:17:12
namespace=CRSR flags=RON/KGHP/TIM/PN0/SML/KST/DBN/MTX/[120100d0]
kkkk-dddd-llll=0000-0001-0001 lock=0 pin=0 latch#=3 hpc=0000 hlc=0000
lwt=0x84ad9268[0x84ad9268,0x84ad9268] ltm=0x84ad9278[0x84ad9278,0x84ad9278]
pwt=0x84ad9230[0x84ad9230,0x84ad9230] ptm=0x84ad9240[0x84ad9240,0x84ad9240]
ref=0x84ad9298[0x84ad9298,0x84ad9298] lnd=0x84ad92b0[0x84ad92b0,0x84ad92b0]
LIBRARY OBJECT: object=833e5518
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
CHILDREN: size=16
child# table reference handle
------ -------- --------- --------
0 833010c0 83300d30 858bd9b0
1 833010c0 83300fc0 8212fdf8
-- Child Cursor
LIBRARY OBJECT HANDLE: handle=858bd9b0 mtx=0x858bdae0(0) cdp=0
namespace=CRSR flags=RON/KGHP/PN0/[10010000]
kkkk-dddd-llll=0000-0041-0041 lock=0 pin=0 latch#=3 hpc=0000 hlc=0000
lwt=0x858bda58[0x858bda58,0x858bda58] ltm=0x858bda68[0x858bda68,0x858bda68]
pwt=0x858bda20[0x858bda20,0x858bda20] ptm=0x858bda30[0x858bda30,0x858bda30]
ref=0x858bda88[0x83300d30,0x83300d30] lnd=0x858bdaa0[0x858bdaa0,0x858bdaa0]
CHILD REFERENCES:
reference latch flags
--------- ----- -------------------
83300d30 0 CHL[02]
LIBRARY OBJECT: object=833008f0
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
DEPENDENCIES: count=1 size=16
dependency# table reference handle position flags
----------- -------- --------- -------- -------- -------------------
0 7f751c70 7f751b08 84a04420 14 DEP[01]
AUTHORIZATIONS: count=1 size=16 minimum entrysize=16
00000000 37000000 00020000 00000000
ACCESSES: count=1 size=16
dependency# types
----------- -----
0 0009
TRANSLATIONS: count=1 size=16
original final
-------- --------
84a04420 84a04420
DATA BLOCKS:
data# heap pointer status pins change whr
----- -------- -------- --------- ---- ------ ---
0 85beb878 83300a48 I/-/A/-/- 0 NONE 00
6 7f7518e0 845c7780 I/-/A/-/- 0 NONE 00
ハング分析
Oracle ハングが発生した場合, ハング分析に必要な情報を取得します。使用方法は、以下のようになります。
SQL> connect /as sysdba SQL> oradebug setmypid SQL> oradebug hanganalyze -- 例: oradebug hanganalyze 3
Levelによる出力については、以下の通りです。
- 10 – すべてのプロセスをダンプします。（IGN状態）
- 5 – レベル4 +待機チェーンに含まれるすべてのプロセスをダンプします。（NLEAF状態）
- 4 – レベル3 +待機チェーン（LEAF、LEAF_NW、IGN_DMP状態）のリーフノード（ブロッカー）をダンプします。
- 3 – レベル2 +ハング状態にあると考えられるプロセスのみをダンプします。（IN_HANG状態）
- 1-2 – ハング分析出力のみ、プロセスダンプは全くありません。
RACで他の インスタンスとの連関された内容まで分析するためには次のような命令文を使わなければなりません.
SQL> oradebug setinst all SQL> oradebug -g def hanganalyze 1
ハング分析で生成されたダンプファイルの例は以下のようになります。
*** 2006-04-06 14:17:29.050 Open chains found: Chain 1 :: <0/118/36478/1093/PL/SQL lock timer> -- <1/132/29546/1113/enq: TX - row lock contention> -- <1/127/16507/1041/enq: TX - row lock contention> Chain 2 : : <1/156/1/14747/rdbms ipc message> -- <0/110/58858/enq: TC - contention> Chain 3 : : <0/113/43663/single-task message> -- <0/145/49269/library cache pin> Chain 4 : : <0/158/1/control file parallel write> -- <1/131/33219/1095/enq: TC - contention>
システム/プロセス状態ダンプ
システムやプロセスの現在の状況を取得します。 使用法は以下の通りです。
alter session set events 'immediate trace name processstate level 10'; alter session set events 'immediate trace name systemstate level 10'; alter session set events 'immediate trace name systemstate level 266';
または
oradebug dump processstate 10; oradebug dump systemstate 10; -- oradebug dump systemstate 266; -- 10gから(short stack を含む)
エラースタックダンプ
プロセスのエラースタックダンプを実行します。 スタックの情報加えて、PL / SQL、SQLなどの情報出力されます。
alter session set events 'immediate trace name errorstack level 3'; alter session set events '1652 trace name errorstack level 3';
あるいは
oradebug setospid oradebug dump errorstack 3
出力結果は、以下のようになります。
----- PL/SQL Call Stack -----
object line object
handle number name
2CD21218 169 package body SYS.DBMS_PIPE
2CD215EC 6 package body UKJA.PKG_SYNC
2CD215EC 17 package body UKJA.PKG_SYNC
2CD98678 1 anonymous block
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
_ksedst+38 CALLrel _ksedst1+0 1 1
_ksedmp+898 CALLrel _ksedst+0 1
_ksdxfdmp+847 CALLreg 00000000 3
_ksdxcb+1481 CALLreg 00000000 887FB20 11 3 887FA80 887FAD0
_ssthreadsrgruncall CALLrel _ksdxcb+0 1
back+428
_OracleOradebugThre CALLrel _ssthreadsrgruncall 887FF84
adStart@4+795 back+0
7C80B710 CALLreg 00000000
00000000 VIRTUAL 7C93E4F4
7C80253D CALLrel 7C802550
_skgpwwait+124 CALL??? 00000000
_ksliwat+843 CALLrel _skgpwwait+0 817C564 B818088 3424CE88
4C4B40 0
_kslwaitns+24 CALLrel _ksliwat+0 1F4 1 E7 0 2CD20E44 1000
5265C00
_kskthbwt+159 CALLrel _kslwaitns+0 1F4 1 E7 0 2CD20E44 1000
5265C00
_kslwait+52 CALLrel _kskthbwt+0
_kkxpgetr+916 CALLrel _kslwait+0 1F4 E7 0 2CD20E44 1000
5265C00
_kkxpget+663 CALLrel _kkxpgetr+0 4BFFFE8 6 4FAEF10 1000
817C844 5265C00 3D
_pevm_icd_call_comm CALLreg 00000000 4F7CBE0 4 4D04828
on+722
...
----------------------------------------
Cursor#1(04F60C24) state=BOUND curiob=04F67C5C
curflg=46 fl2=0 par=00000000 ses=3432A014
sqltxt(2CD987BC)=select * from t1
where c1 = :b1 and c2 = :b2
and pkg_sync.f_wait_for_signal = 1
hash=59ca9b387f72d09556b17be170c424e0
parent=305B8518 maxchild=02 plk=31B534D4 ppn=n
cursor instantiation=04F67C5C
child#0(2CD98678) pcs=305B871C
clk=31BB2B50 ci=305BF038 pn=31B520F4 ctx=303E7E24
kgsccflg=0 llk[04F67C60,04F67C60] idx=0
xscflg=c0110676 fl2=d100008 fl3=42222008 fl4=0
sharing failure(s)=10
Bind bytecodes
Opcode = 2 Bind Twotask Scalar Sql In (may be out) Copy
oacdef = 305a03ac Offsi = 36, Offsi = 0
Opcode = 2 Bind Twotask Scalar Sql In (may be out) Copy
oacdef = 305a03d0 Offsi = 36, Offsi = 20
kkscoacd
Bind#0
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000000 frm=00 csi=00 siz=56 off=0
kxsbbbfp=04f78304 bln=22 avl=02 flg=05
value=1
Bind#1
oacdty=01 mxl=32(10) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000000 frm=01 csi=846 siz=0 off=24
kxsbbbfp=04f7831c bln=32 avl=01 flg=01
value="x"
Frames pfr 04F7AB28 siz=2288 efr 04F7AB70 siz=1916
Cursor frame dump
enxt: 3.0x00000044 enxt: 2.0x00000028 enxt: 1.0x00000710
pnxt: 2.0x00000004 pnxt: 1.0x00000170
kxscphp 04F6608C siz=1000 inu=0 nps=744
kxscehp 04F66194 siz=1000 inu=0 nps=160
...
ASHダンプ
SGAのASH（Active Session History）情報を取得します。
alter session set events 'immediate trace name ashdump level '; oradebug dump ashdump ;
Levelは過去数分間の履歴を取得するかを指定します。もしlevel10に指定すると、過去10分間の情報を取得することになります。ASH情報はアクティブセッションのリストを保存するため、Oracle ハングのような現象が発生したとき、事後分析用途に有用です。
トレースファイルに記録されているダンプの内容の例は、以下のようになります。
Processing Oradebug command 'dump ashdump 10' ASH dump <<>> **************** SCRIPT TO IMPORT **************** ------------------------------------------ Step 1: Create destination table ------------------------------------------ CREATE TABLE ashdump AS SELECT * FROM SYS.WRH$_ACTIVE_SESSION_HISTORY WHERE rownum < 0 ---------------------------------------------------------------- Step 2: Create the SQL*Loader control file as below ---------------------------------------------------------------- load data infile * "str '\n####\n'" append into table ashdump fields terminated by ',' optionally enclosed by '"' ( SNAP_ID CONSTANT 0 , DBID , INSTANCE_NUMBER , SAMPLE_ID , SAMPLE_TIME TIMESTAMP ENCLOSED BY '"' AND '"' "TO_TIMESTAMP(:SAMPLE_TIME ,'MM-DD-YYYY HH24:MI:SSXFF')" , SESSION_ID , SESSION_SERIAL# , SESSION_TYPE , USER_ID , SQL_ID , SQL_CHILD_NUMBER , SQL_OPCODE , FORCE_MATCHING_SIGNATURE , TOP_LEVEL_SQL_ID , TOP_LEVEL_SQL_OPCODE , SQL_PLAN_HASH_VALUE , SQL_PLAN_LINE_ID , SQL_PLAN_OPERATION# , SQL_PLAN_OPTIONS# , SQL_EXEC_ID , SQL_EXEC_START DATE 'MM/DD/YYYY HH24:MI:SS' ENCLOSED BY '"' AND '"' ":SQL_EXEC_START" , PLSQL_ENTRY_OBJECT_ID , PLSQL_ENTRY_SUBPROGRAM_ID , PLSQL_OBJECT_ID , PLSQL_SUBPROGRAM_ID , QC_INSTANCE_ID , QC_SESSION_ID , QC_SESSION_SERIAL# , EVENT_ID , SEQ# , P1 , P2 , P3 , WAIT_TIME , TIME_WAITED , BLOCKING_SESSION , BLOCKING_SESSION_SERIAL# , CURRENT_OBJ# , CURRENT_FILE# , CURRENT_BLOCK# , CURRENT_ROW# , CONSUMER_GROUP_ID , XID , REMOTE_INSTANCE# , TIME_MODEL , SERVICE_HASH , PROGRAM , MODULE , ACTION , CLIENT_ID ) --------------------------------------------------- Step 3: Load the ash rows dumped in this trace file --------------------------------------------------- sqlldr userid/password control=ashldr.ctl data= errors=1000000 --------------------------------------------------- <<>> <<>> #### 58646642,1,12519562,"04-26-2010 09:44:01.822000000",160,1,2,0, "",0,0,0,"",0,0,0,0,0, 0,"",0,0,0,0,0,0,0, 3213517201,9858,0,3,1,0,69788,4294967295,0, 4294967295,0,0,0,0,,0,0,165959219, "ORACLE.EXE (CKPT)","", "","" #### 58646642,1,12519486,"04-26-2010 09:42:45.808000000",160,1,2,0, "",0,0,0,"",0,0,0,0,0, 0,"",0,0,0,0,0,0,0, 3213517201,9767,1,1,1,0,38825,4294967295,0, 4294967295,0,0,0,0,,0,0,165959219, "ORACLE.EXE (CKPT)","", "","" #### 58646642,1,12519416,"04-26-2010 09:41:35.770000000",160,1,2,0, "",0,0,0,"",0,0,0,0,0, 0,"",0,0,0,0,0,0,0, 4078387448,9683,3,3,3,0,11083,4294967295,0, 4294967295,0,0,0,0,,0,0,165959219, "ORACLE.EXE (CKPT)","", "","" #### 58646642,1,12519384,"04-26-2010 09:41:03.774000000",163,1,2,0, "",0,0,0,"",0,0,0,0,0, 0,"",0,0,0,0,0,0,0, 3176176482,40612,5,1,1000,999888,0,4294967291,0, 4294967295,0,0,0,0,,0,0,165959219, "ORACLE.EXE (DIA0)","", "","" #### 58646642,1,12519304,"04-26-2010 09:39:43.719000000",160,1,2,0, "",0,0,0,"",0,0,0,0,0, 0,"",0,0,0,0,0,0,0, 3213517201,9551,1,1,1,0,38798,4294967295,0, 4294967295,0,0,0,0,,0,0,165959219, "ORACLE.EXE (CKPT)","", "","" #### 58646642,1,12519265,"04-26-2010 09:39:04.663000000",163,1,2,0, "",0,0,0,"",0,0,0,0,0, 0,"",0,0,0,0,0,0,0, 3176176482,40493,5,1,1000,999941,0,4294967291,0, 4294967295,0,0,0,0,,0,0,165959219, "ORACLE.EXE (DIA0)","", "","" #### 58646642,1,12519183,"04-26-2010 09:37:42.554000000",160,1,2,0, "",0,0,0,"",0,0,0,0,0, 0,"",0,0,0,0,0,0,0, 3213517201,9406,0,1,1,0,54077,4294967295,0, 4294967295,0,0,0,0,,0,0,165959219, "ORACLE.EXE (CKPT)","", "","" #### <<>> *** 2010-04-26 09:45:51.625 Oradebug command 'dump ashdump 10' console output:
