1. Hang 발생시 해당 명령어로 접근 후, oradebug 수행

 # sqlplus –prelim “/ as sysdba”

   SQL>alter system set events ‘immediate trace name ashdump level 10’;

   SQL> oradebug setmypid

   SQL> oradebug unlimit

   SQL> oradebug dump ashdump 10 (level 10) --ASHDUMP 생성

   SQL> oradebug tracefile_name

 

2. DB 정상화 후, ASHDUMP파일을 SQL Loader로 테이블 생성 

# sqlldr userid=test/test control='/home/oracle/ashldr.ctl'

data='/u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_28661.trc‘

 

3. ASHDUMP 내역을 확인하여 이슈 분석

 SQL> select * from ashdump;

 

블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,


Oracle oradebug활용 Troubleshoot

   

 1.이슈사항

  • SMON Process가 CPU를 높게 점유하고 archive log file이 많이 쌓여 Disk Full 현상이 발생됨.
  • Session monitoring, alert log에는 이슈가 될만한 에러 및 Session내역은 보이지 않음. 

              

        

  2.원인분석

- Alert log, 실시간 Session으로 보여지는 내용이 없어 Oracle Process Trace 수행

- 특정 Process Hang 발생시 Oracle 분석기법

sqlplus "/as sysdba"

   

oradebug setospid 352612  -- Topas에서 확인된 pid 값

oradebug unlimit 

oradebug dump systemstate 10   --1분당 3번

oradebug tracefile_name 

   

oradebug setospid 352612 -- Topas에서 확인된 pid 값

oradebug unlimit

oradebug hanganalyze 3     --1분당 3번

oradebug tracefile_name 

   

[생성된 Trace 파일]

Trace file /oracle/diag/rdbms/orcl/trace/orcl_smon_352612.trc

   

*** 2015-09-01 13:57:47.068

*** SESSION ID:(571.1) 2015-09-01 13:57:47.068

*** CLIENT ID:() 2015-09-01 13:57:47.068

*** SERVICE NAME:(SYS$BACKGROUND) 2015-09-01 13:57:47.068

*** MODULE NAME:() 2015-09-01 13:57:47.068

*** ACTION NAME:() 2015-09-01 13:57:47.068

   

DISTRIB TRAN orcl.88b119e8.65.16.61955

  is local tran 65.16.61955 (hex=41.10.f203)

  insert pending collecting tran, scn=14418954135276 (hex=d1d.2ca3a6ec)

Serial Transaction recovery caught exception 30319

Serial Transaction recovery caught exception 30319

   

*** 2015-09-01 18:51:50.478

Serial Transaction recovery caught exception 30319

   

*** 2015-09-01 18:55:50.719

Serial Transaction recovery caught exception 30319

  

-2015-09-01 13:57:47.068 시점부터 특정 Transaction에 대한 Recovery 작업을 진행.

-금일 오전, 오후에 대량의 Transaction에 대한 쿼리 수행에 따른 취소로 인한 Transaction Recovery일 수 있을 것으로 보여짐.

   

 3.분석 내용

- alert log를 보면 2015-09-01 13:57경에 Session Kill이 발생된 것이 확인되며 같은 시간에 oradebug를 통하여 SMON을 트레이스를 수행한 결과 enqueue로 인하여  Lock현상에 따른 Session Kill로 확인됩니다.

- 해당 Session Kill에 따른 Transaction Recovery가 발생되면서 SMON의 사용량이 높아지며 많은 양의 Archive log를 내린 것으로 판단됨.

   

[alert log 분석]

 

[oradebug 분석]

   

4. 해결

- 해당 Transaction Recovery 작업이 완료되어 시스템이 정상으로 회복.


'1. IT Story > DB' 카테고리의 다른 글

Fine Grained Auditing의 활용  (0) 2015.09.08
WRAP Utility 활용  (0) 2015.09.08
Corrupt Data Found During RMAN Backup Troubleshoot  (0) 2015.09.08
DATABASE 암호화 기술들  (0) 2015.09.04
Oracle RAC 11gR2 주요 Command(명령어)  (0) 2015.09.04
Oracle Flashback  (0) 2015.09.04
Oracle RAC 11gR2 Management  (0) 2015.09.04
Oracle RAC 11gR2 Failover 구성  (0) 2015.09.04
블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,