행위

오라클 덤프 oradebug

DB CAFE

Dbcafe (토론 | 기여)님의 2024년 4월 28일 (일) 20:13 판 (→‎덤프)
thumb_up 추천메뉴 바로가기

1 프로세스 서브펜딩[편집]

  • sysdba 권한 필요
  • DBWR 과 LGWR 수행을 이해 하기 위해서는 해당 프로세스를 stop 시킬필요가 있음.
  • Oradeb 를 이용 하여 suspend , resume 시킴.

1) 오라클 프로세스 Attach 시키기 위해 v$process에서 pid 확인 

-- oracle process attach 
select prc.pid
  from v$bgprocess bgp
     , v$process prc 
 where bgp.name = 'LGWR'
   and prc.addr = bgp.paddr
;
       PID
----------
	20
SQL> oradebug setorapid 20
Oracle pid: 20, Unix process pid: 2977, image: oracle@b4eb0743df57 (LGWR)

2) suspend 

oradebug suspend

3) 다른 세션에서 sql 을 수행하고 commit 을 수행함.

-- commit 작업은 hang에 걸리게 됨. log file sync 대기이벤트를 대기 하게 됨.

4) resume 

oradebug resume

2 덤프[편집]

  • 메모리 구조를 트레이스 파일로 덤프
SQL> oradebug setmypid
Statement processed.


SQL> alter session set tracefile_identifier = DBCAFE;
Session altered.
SQL> oradebug tracefile_name
/u01/app/oracle/diag/rdbms/mongo/MONGO/trace/MONGO_ora_30886_DBCAFE.trc
옵션 수행결과
buffers N
  • 버퍼,버퍼헤더 및 다양한 링크디 리스트 정보 덤프
    • 1 = 버퍼 헤더
    • 2 = 1 + 블록의 raw 덤프 + 드랜잭션 헤더
    • 3 = 2 + 완벽한 블록의 심볼릭 덤프
    • 4 = Working data sets,버퍼헤더 및 해시 체인 내의 raw 블럭
file_hdrs N
  • 데이터 파일 헤더 덤프 , 체크포인트 확인 및 scn 점검
    • 1 = standard
    • 2 = v10-형식의 헤더정도
    • 3 = 테이블스페이스 정보 와 Extended 파일 정보
redohdr N
  • 온라인 리두 로그 파일의 헤더 덤프, 레벨이 증가할수록 출력 정보가 증가함
  • 첫번째와 다음 scn을 획득하려면 레벨 1로도 충분함
    • 1 = standard
    • 2 = 파일 헤더 호환성 정보 추가
    • 3 = 그 밖의 약간의 상세 내용 추가
controls N
  • 컨트롤 파일 정보 덤프, 레벨 10은 가공되지 않는 정보 제공
  • 레벨 1 ~ 9까지,11은 가공된 형태로 두 많은 정보 제공
  • 레벨 2는 몇개의 중요한 son 과 RBA (Redo Block Address) 제공함.
library_cache N
  • 라이브러리 캐시 정보 덤프
  • 비트맵 덤프 전략 이용
    • 1 = v$librarycache 뷰 와 주요구조를 위해 할당된 permanent 영역의 정보
    • 2 = 해시 체인 요약 와 permanent 영역의 정보
    • 4 = 오브젝트에 대한 헤더 구조를 가진 버킷 목록 및 해시 체인의 링크드 리스트. 오브젝트의 lock , pin , mutex 상세보기에 적함
    • 8 = 4 + Dependencies, 데이터 블록,accesses,transaction 등.
    • 16 = 8 + 각 오브젝트의 힙 덤프. 데이터 블록. 출력파일이 매우 크다
    • 32 = 16 + 힙 내의 모든 청크의 완벽한 raw 덤프. 출력 파일이 매우 크다.
library_cache_object {level} {address}
  • 라이브러리 캐시 오브젝트 상세 내용 덤프. Address는 {x$kglob.kglhdadr} (예를 들어 v$sql.child_address ) , x$kglob.kglhdpar} (예를들어 , v$sql.address)를 이용하면된다. 16진수 주소는 앞부분에 '0x'를 붙이고,10진수로 변환하여 입력해도 된다.
    • 0 = 단순,간단 덤프
    • 16 = 상세 덤프
    • 48 = 매우 상세한 덤프. parent 주소가 제공되면 child 상세 정보도 포함됨
heapdump N
  • Top-Level 힙 정보 덤프
  • Free memory 해시 체인 , 사용된 메모리에 대한 LRU 리스트를 확인하기 위해 SGA힘을 덤프
  • SGA를 대상으로 명령어 수행시 매우 조심해야함. 시스템 hang이 발생함. 몇분간 극심한 래치 경합 유발 가능성 존재.
    • 1 = PGA heap 덤프
      1024(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 call heap (메모리 청크의 raw 덤프를 포함)
    • 32 (32800/0x8020)= large pool heap (메모리 청크의 raw 덤프를 포함)
    • 64 (65600/0x10040)= streams pool heap (메모리 청크의 raw 덤프를 포함)
    • 128 (131200/0x20080)= java pool heap (메모리 청크의 raw 덤프를 포함)

3 메모리 덤프[편집]

  • 특정한 메모리 위치에 대한 정보를 조사하기 위해 사용
  • 이름을 확인 한후 메모리르 덤프함
  • 만약 오라클 변수의 이름을 알고 있다면 dumpvar 명령을 사용 하여 값을 확인할수 있음.
oradebug <영역> <변수명>
  • 예시 ) kcb는 버퍼캐시, nchk는 ??? 변수를값을 조회시
SQL> oradebug dumpvar sga kcbnchk
boolean kcbnchk_ [060019FD4, 060019FD8) = 00000001


  • 예시 ) 현재 세션의 use_stored_outlines 값을 알고 싶다면 , ugauso_p라른 변수명 사용
SQL> alter session set use_stored_outlines = rule_based;

Session altered.

SQL> oradebug setmypid
Statement processed.
SQL> oradebug dumpvar uga ugauso_p
qolprm ugauso_p [7F197A4EFC48, 7F197A4EFCD0) = 00000001 5552000A 425F454C 44455341 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ...

4 SGA내 변수 찾기 - x$ksmfsv (Kernel Services Memory Fiexed SGA Variables )[편집]

SQL> select ksmfsnam from x$ksmfsv where ksmfsnam like 'kcbn%'
  2  ;

KSMFSNAM
----------------------------------------------------------------
kcbncbh_
kcbnwp_
kcbnbf_
kcbnpg_
kcbnchkl_
kcbnchk_
kcbnumaactive_
kcbnvmenabled_
kcbnbcscv_

9 rows selected.
원본 주소 "http://dbcafe.co.kr/wiki/index.php?title=오라클_덤프_oradebug&oldid=11507"