kjwon:ora11g:SYS >
> 1 select prc.pid
2 from v$bgprocess bgp,
3 v$process prc
4 where bgp.name = 'LGWR'
5 and prc.addr = bgp.paddr;
PID
----------
11
1 row selected.
Elapsed: 00:00:00.04
kjwon:ora11g:SYS >
> 1 oradebug setorapid 11
Oracle pid: 11, Windows thread id: 4888, image: ORACLE.EXE (LGWR)
kjwon:ora11g:SYS >
> 1 oradebug suspend
Statement processed.
kjwon:ora11g:SYS >
> 1 oradebug resume
Statement processed.
kjwon:ora11g:SYS >
> 1 select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE 11.2.0.3.0 Production
TNS for 64-bit Windows: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
kjwon:ora11g:SYS >
> 1 oradebug setmypid
Statement processed.
kjwon:ora11g:SYS >
> 1 oradebug tracefile_name
C:\ORACLE\diag\rdbms\ora11g\ora11g\trace\ora11g_ora_5036.trc <-- 11g에서는 출력된다.
kjwon:ora11g:SYS >
> 1 alter session set tracefile_identifier = xxx;
Session altered.
Elapsed: 00:00:00.00
kjwon:ora11g:SYS >
> 1 oradebug tracefile_name
C:\ORACLE\diag\rdbms\ora11g\ora11g\trace\ora11g_ora_5036_XXX.trc
kjwon:ora11g:SYS >
> 1 oradebug dumplist
TRACE_BUFFER_ON
TRACE_BUFFER_OFF
LATCHES
PROCESSSTATE
SYSTEMSTATE
INSTANTIATIONSTATE
REFRESH_OS_STATS
CROSSIC
CONTEXTAREA
HANGDIAG_HEADER
HEAPDUMP
HEAPDUMP_ADDR
POKE_ADDRESS
POKE_LENGTH
POKE_VALUE
POKE_VALUE0
GLOBAL_AREA
REALFREEDUMP
FLUSH_JAVA_POOL
POOL_SIMULATOR
PGA_DETAIL_GET
PGA_DETAIL_DUMP
PGA_DETAIL_CANCEL
PGA_SUMMARY
MODIFIED_PARAMETERS
EVENT_TSM_TEST
ERRORSTACK
CALLSTACK
TEST_STACK_DUMP
TEST_GET_CALLER
RECORD_CALLSTACK
EXCEPTION_DUMP
BG_MESSAGES
ENQUEUES
KSTDUMPCURPROC
KSTDUMPALLPROCS
KSTDUMPALLPROCS_CLUSTER
SIMULATE_EOV
KSFQP_LIMIT
KSKDUMPTRACE
DBSCHEDULER
LDAP_USER_DUMP
LDAP_KERNEL_DUMP
DUMP_ALL_OBJSTATS
DUMPGLOBALDATA
HANGANALYZE
HANGANALYZE_PROC
HNGDET_MEM_USAGE_DUMP
HANGANALYZE_GLOBAL
GES_STATE
CGS
OCR
CSS
CRS
SYSTEMSTATE_GLOBAL
GIPC
MMAN_ALLOC_MEMORY
MMAN_CREATE_DEF_REQUEST
MMAN_CREATE_IMM_REQUEST
MMAN_IMM_REQUEST
DUMP_ALL_COMP_GRANULE_ADDRS
DUMP_ALL_COMP_GRANULES
DUMP_ALL_REQS
DUMP_TRANSFER_OPS
DUMP_ADV_SNAPSHOTS
ADJUST_SCN
NEXT_SCN_WRAP
CONTROLF
FLUSH_CACHE
FULL_DUMPS
BUFFERS
RECOVERY
SET_TSN_P1
GLOBAL_BUFFER_DUMP
BUFFER
PIN_BLOCKS
BC_SANITY_CHECK
PIN_RANDOM_BLOCKS
SET_NBLOCKS
CHECK_ROREUSE_SANITY
DUMP_PINNED_BUFFER_HISTORY
KCBO_OBJ_CHECK_DUMP
KCB_WORKING_SET_DUMP
KCBS_ADV_INT_DUMP
KCBI_DUMP_FREELIST
REDOLOGS
ARCHIVE_ERROR
LOGHIST
REDOHDR
LOGERROR
OPEN_FILES
DATA_ERR_ON
DATA_READ_ERR_ON
DATA_ERR_OFF
BLK0_FMTCHG
UPDATE_BLOCK0_FORMAT
TR_SET_BLOCK
TR_SET_ALL_BLOCKS
TR_SET_SIDE
TR_CRASH_AFTER_WRITE
TR_READ_ONE_SIDE
TR_CORRUPT_ONE_SIDE
TR_RESET_NORMAL
TEST_DB_ROBUSTNESS
LOCKS
GC_ELEMENTS
FILE_HDRS
KRB_CORRUPT_INTERVAL
KRB_CORRUPT_SIZE
KRB_CORRUPT_REPEAT
KRB_CORRUPT_OFFSET
KRB_PIECE_FAIL
KRB_OPTIONS
KRB_FAIL_INPUT_FILENO
KRB_SIMULATE_NODE_AFFINITY
KRB_TRACE
KRB_BSET_DAYS
KRB_SET_TIME_SWITCH
KRB_OVERWRITE_ACTION
KRB_CORRUPT_SPHEADER_INTERVAL
KRB_CORRUPT_SPHEADER_REPEAT
KRB_CORRUPT_SPBITMAP_INTERVAL
KRB_CORRUPT_SPBITMAP_REPEAT
KRB_CORRUPT_SPBAD_INTERVAL
KRB_CORRUPT_SPBAD_REPEAT
KRB_UNUSED_OPTION
KRBMRSR_LIMIT
KRBMROR_LIMIT
KRBABR_TRACE
KRDRSBF
KRC_TRACE
KRA_OPTIONS
KRA_TRACE
FBTAIL
FBINC
FBHDR
FLASHBACK_GEN
KTPR_DEBUG
DUMP_TEMP
DROP_SEGMENTS
TEST_SPACEBG
TREEDUMP
LONGF_CREATE
KDLIDMP
ROW_CACHE
LIBRARY_CACHE
LIBRARY_CACHE_OBJECT
CURSORDUMP
CURSORTRACE
CURSOR_STATS
XS_SESSION_STATE
SHARED_SERVER_STATE
LISTENER_REGISTRATION
JAVAINFO
KXFPCLEARSTATS
KXFPDUMPTRACE
KXFPBLATCHTEST
KXFXSLAVESTATE
KXFXCURSORSTATE
KXFRHASHMAP
WORKAREATAB_DUMP
KUPPLATCHTEST
OBJECT_CACHE
SAVEPOINTS
RULESETDUMP
RULESETDUMP_ADDR
FAILOVER
OLAP_DUMP
SELFTESTASM
ASMDISK_ERR_ON
ASMDISK_READ_ERR_ON
ASMDISK_ERR_OFF
ASM_EVENREAD
IOERREMUL
IOERREMULRNG
ALRT_TEST
AWR_TEST
AWR_FLUSH_TABLE_ON
AWR_FLUSH_TABLE_OFF
ASHDUMP
ASHDUMPSECONDS
MMON_TEST
ATSK_TEST
HM_FW_TRACE
HM_FDG_VERS
IR_FW_TRACE
KSDTRADV_TEST
옵션 | 수행결과 |
---|---|
buffer N | 버퍼, 버퍼 헤더 및 다양한 링크드 리스트에 대한 정보를 덤프한다. 버퍼 캐 시의 크기가 작더라도, 레벨2 부터는 덤프크기가 크다.8Mb 캐시인 경우에, 레벨2로 수행하면 28Mb의 덤프가 발생하고, 레벨 3 으로수행하면 49Mb 의 덤프가 발생한다. 안타깝게도, working data set 으로부터 모든 링크드리스트의 정보를 획득할 수 있는 것은 레벨4 뿐이다. 1 = 버퍼 헤더 2 = 1+블록의머W 덤프+ 트랜잭선 헤더 3 = 2+ 란벽한 블록으 Isymbolic 덤프 4 = working data sets, 버퍼 헤더 및 해시 체인 내의 raw 블록 |
enqueues N | 리소스와 enqueue 에 대한 정보를 덤프한다. 레벨 3이 가장 유용하며, 필자가 4 장에서 사용한 레벨이다. 결과 파일의 크기는 v$lock 뷰에서 보여지는 로우의 수에 의해 결정되며, 대부분 1Mb 미만이다. 1 = enqueue 리소스 해시 테이블 2 = 1+ 현재 사용되는 리소스의 목록 3 = 2+ 각 리소스내의 active enqueue |
file_hdrs N | 데이터 파일헤더를 덤프한다. 대부분 볼일은 없지만, 체크포인트의 효과를 점검하기를 원한다면, checkpoint SCN 을 확인하기 위해 파일 헤더를 덤프 할 필요가 있다. 데이터 파일당 몇 Kb 정도이다. 1 = standard 2 = v10-형식의 헤더의 정보를 약간 추가 3= 테이블스페이스 정보와 extended 파일 정보를 추가 이 레벨은 sys.bootstrap$(부트스트랩 테이블)의 위치를 잦을 수 있는 file 0내의 root dba:를 제공한다. |
redohdr N | 온라인 리두 로그 파일의 헤더를 덤프한다. 레벨이 증가할수록 제공되는정보의 앙이 조금씩 증가한다. 젓 번째와다음 번 SCN 을획득하려면 레벨 1로도 중분하다. 1 = standard 2= 파일 헤더 호환성 정보 추가 3= 그 밖의 약간의 상세 내용 추가 |
controlf N | 컨트롤 파일의 정보를 덤프한다. 레벨10은 가공되지 않는 정보를 제공한다. 반면에, 레벨 1부터 9, 그리고 레벨 11 은 가공된 형태로 점점 더 많은 정보를 제공한다. 레벨2 는 몇 개의 중요한 SCN 과 RBA (redo block address)를 제공한다. |
library_cache N | 라이브러리 캐시 정보를 덤프한다. 이 덤프는비트맵 전략을 사용한다. 덤프 레벨을 더함으로써 덤프 내용이 결합된다. 이상하게도, 동일한 레벨에서 11g 덤프의 일부 결과가 더 적은 정보를 포함한다. 1 = v$liblaryache 뷰와(10g 인 경우) 주요 구조를 위해 할당된 permanent 영역에 대한 요약 2 = 해시 체인 요약과(10g 인 경우) permanent 할당 요약 4 = 오브젝트에 대한 헤더 구조를 가진 버킷 목록 및 해시 체인의 링크드 리스트 (오브젝트에 대한 lock/pin/mutex 의 상세 정보를 보기에 충분함) 8 = 4 + dependencies, "데이터"블록, accesses, translations, 등. 16 = 8 + 각 오브젝트의 힘 덤프 "데이터"블록. 결과 파일이 매우 크다. 32 = 16 + 힘 내의 모든 청크의 완벽한 raw 덤프. 결과 파일이 매우 크다. |
library_cache_object {level} {address} | 11.2에서만 동작한다(11.1 에서도 수행이 가능하나, 항상"in-flux" 에러가 발생한다). 이것은 11g 에서 10g의 오브젝트 레벨 덤프를 대치한 것이다. 이것은 라이브러리 캐시 오브젝트의 상세 내용을 덤프한다. Address는 { x$kglob.kglhdadr} (예를들어, v$sql.child_address), 또는 {x$kglob.kglhdpar} (예를들어,v$sql.address) 를 이용하면 된다. 16진수 주소는 앞부분에 "0x"를 붙여야하고, 10 진수로 변환하여 입력해도 된다. 레벨은 비트업 방식으로 사용되며, 필자가 발견한 유용한 레벨은 다음과 같다. 0 - 단순하고l 간단한 덤프 16 - 상세한 덤프 48 - 매우 상세한 덤프. 만일 parent 주소를 제공한다면,chiId 상세 정보도 포함한다. |
heapdump N | Top-Ievel 힙의 정보를 덤프한다. 이 덤프도 비트맙 방식을 사용한다. 이 경우에는 각 비트는 서로 다른 힙 영역을 대표한다. 필자가 이 덤프를 사용하는 주된 이유는 free memory 해시 체인과, 사용된 메모리에 대한 LRU 리스트를 확인하기 위해 SGA 힙을 덤프하는 것이다.SGA를 대상으로 이 명령어를 수행하는 것은 매우 조심해야 한다. 이것은 시스템 hang 을 야기할 수 있으며, 적어도 몇 분간은 극심한 래지 경합을 야기할 수 있다. 1 = PGA heap 덤프 1025 (0x401) = 메모리 청크의 raw 덤프를 포함한 PGA heap 2 = SGA heap 덤프 2050 (0x802) = 메모리 청크의 raw 덤프를 포함한 SGA heap 4 = 세선 (UGA) heap 덤프 4100 (0x1004) = 메모리 청크의 raw heap 을 포함한 세션 heap 8 (8200/0x2008) = current call heap (메모리 청크의 raw 덤프를 포함) 16 (16400/0x4010) = user cal heap (메모리 청크의 raw 덤프를 포함) 32 (32800/0x8020) = large pool heap (메모리 청크의 raw 덤프를 포함) 64 (65600/0x10040)=streams pool heap (메모리 청크의 raw 덤프를 포함) 128 (131200/0x20080) = java pool heap (메모리 청크의 raw 덤프를 포함) |
oradebug dumpvar {영역} {변수 명}
kjwon:ora11g:SYS >
> 1 oradebug setmypid
Statement processed.
kjwon:ora11g:SYS >
> 1 oradebug dumpvar sga kcbnhb
uword kcbnhb_ [1492D9E3C, 1492D9E40) = 00020000
kjwon:ora11g:SYS >
> 1 col KSMFSNAM for a30
kjwon:ora11g:SYS >
> 1 set line 250
kjwon:ora11g:SYS >
> 1 select *
2 from x$ksmfsv
3 where ksmfsnam like 'kcbn%';
ADDR INDX INST_ID KSMFSNAM KSMFSTYP KSMFSADR KSMFSSIZ
---------------- ---------- ---------- ------------------------------ ---------------------------------------------------------------- ---------------- ----------
000000014799D880 3151 1 kcbnbh_ sword 00000001492D78D8 4
000000014799D8C0 3153 1 kcbnwp_ sword 00000001492D78E8 4
00000001479A0BE0 3562 1 kcbnbf_ sword 00000001492D9E34 4
00000001479A0C00 3563 1 kcbnhb_ uword 00000001492D9E3C 4
00000001479A0C20 3564 1 kcbnhbsft_ uword 00000001492D9E44 4
00000001479A0CE0 3570 1 kcbnhl_ uword 00000001492D9E74 4
00000001479A0F80 3591 1 kcbnpg_ ub4 00000001492D9F88 4
00000001479A1020 3596 1 kcbnl2b_ uword 00000001492D9FB0 4
00000001479A1100 3603 1 kcbnchkl_ ub1 00000001492D9FF4 1
00000001479A1120 3604 1 kcbnchk_ int 00000001492D9FF8 4
00000001479A1240 3613 1 kcbnumaactive_ ub1 00000001492DA0C4 1
00000001479A14E0 3634 1 kcbnbcscv_ sword 00000001492DA198 4
00000001479A3E80 3967 1 kcbnf01_ uword 00000001492DB078 4
00000001479A3EA0 3968 1 kcbnf02_ uword 00000001492DB080 4