오라클문제진단 추적을위한 ORADEBUG 사용법 · 2004-10-04 · 9트레이스파일을OS 명령어로지운경우, CLOSE_TRACE 후프로세스재지정하고덤프 수행하면파일이재생성됨

ORADEBUG 사용법

오라클 문제진단/추적을 위한 ORADEBUG 사용법 기술적인 질문은 채팅으로

이상헌, 김경아

한국오라클 (주) 제품지원실

Getting the most out of MetaLink

오라클문제진단/추적을위한ORADEBUG 사용법

이번 iSeminar 에서 다룰 내용은 “오라클 데이터베이스 문제진단 및 추적을 위한 oradebug 사용법”

입니다.

“오라클 데이터베이스에 HANG 이 발생한 것 같다, 특정 프로세스가 루핑을 도는 것 같다 또는 멈춰있다,

이미 수행중인 세션의 SQL 들이 너무 느려졌는데 어플리케이션을 내려서 트레이스를 걸 수 없다.”

이런 상황이 발생하시면 무엇부터 하는지요 ? 고객 여러분의 입장에서 체크 할 것은 모두 체크 했는데도

문제원인을 발견하지 못한 경우, 바로 이때 oradebug 를 사용할 단계입니다.

Oradebug 는 오라클에서 제공하는 디버깅 유틸리티로서 오라클 데이터베이스의 프로세스, 세션, 메모리,

SQL 등의 리소스을 덤프할 수 있고, OS 디버거들과 비슷하게 오라클 레벨의 CALL 단위 디버깅 기능을

제공합니다.

리소스를 개별로 덤프 할 수 있을 뿐만 아니라 전체 인스턴스 상태를 덤프 할 수 있는데, DB HANG 또는

크리티컬 장애 분석 시 가장 중요하고도 기본적인 판단 자료로 사용됩니다.

또한 RAC 이나 OPS 인 경우 한 인스턴스에서 전체 인스턴스 덤프 할 수도 있습니다.

ORADEBUG 사용법


1. oradebug 개요

2. oradebug 사용법

3. oradebug command 카테고리

4. oradebug command 옵션들

5. 참고자료들

목차

세미나 진행 목차는 다음과 같습니다.

1. Oradebug 에 대해서 간단한 개요

2. 그리고 사용법을 살펴보겠습니다.

3. 세번째로 문제분석에 필요한 정보를 얻는데 유용한 7가지 Command 카테고리를 설명 드리겠습니다.

4. 그리고 각각의 Command 옵션을 자세히 설명 드리고 사용 예제를 보여드리는데 소요될 것 입니다.

마지막으로 Metalink 에서 찾아보실 수 있는 참고문서 리스트가 있습니다.

본 세미나에서 설명 드리는 Command 들은 즉시 업무에서 사용할 수 있는 것들이며 포함하지 않은 Command 들의

경우 사용자체가 데이터베이스에 예기치 못한 영향을 줄 수 있으므로 사용 시는 오라클 서포트로부터 도움을

받으시길 권장 드립니다.

ORADEBUG 사용법


대상 : 오라클 데이터베이스 프로세스

기능

프로세스의 덤프 및 트레이싱 START/STOP 일반적인 루틴과 다른 루틴 수행시도

특정 리소스들의 메모리 덤프

모든 플랫폼에서 동일 인터페이스 제공

SQLPLUS 로 접속 후 사용

oradebug 개요

Oradebug 대상은 오라클 데이터베이스에 접속한 프로세스들 입니다.

Oradebug 은 다음과 같은 기능을 수행할 수 있습니다.

1. 프로세스나 세션 또는 특정 리소스에 대한 자세한 정보를 트레이싱 할 수 있습니다.

원하는 시점에 트레이싱을 START 하고 원하는 시점에 STOP 시킬 수 있습니다.

2. 원래 의도된 루틴이 아닌, 예를들면 어떤 조건을 만나면 수행을 STOP 하고 특정 값을 디스플레이 하거나, 또는

특정 에러를 만나면 에러 메시지만 보여주는 것이 아니라, 그 시점의 프로세스/인스턴스 상태를 덤프하도록 수행

루틴을 조정할 수 있습니다.

3. 원하는 시점의 인스턴스 및 개별 리소스의 메모리 내용을 덤프할 수 있습니다.

MVS 와 WINDOWS 제외한 모든 유닉스 플랫폼에서 동일 인터페이스를 제공하므로 한번 익숙해지면 쉽게 사용할

수 있습니다.

제한점으로 SQLPLUS 를 통해 적절한 권한을 가진 DB USER 로 접속해야 사용할 수 있다는 것입니다.

심각한 인스턴스 행의 경우 oradebug 세션조차도 연결되지 않는 경우가 발생합니다.

이런 예외적인 경우는 오라클에 접속하지 않고 OS 디버거에서 오라클 덤프 함수를 직접 CALL 하여

SYSTEMSTATE DUMP 를 생성하는 방법을 설명드리겠습니다.

<Note:121779.1> Taking Systemstate Dumps when You cannot Connect to Oracle

ORADEBUG 사용법


적절한 권한을 가진 DB USER 로 SQLPLUS 접속

반드시 덤프할 오라클 프로세스를 지정한 후 사용

SYNTAX : SQL > oradebug command <option>

SQL> connect / as sysdbaSQL> oradebug helpHELP [command] Describe one or all commandsSETMYPID Debug current processSETOSPID <ospid> Set OS pid of process to debugSETORAPID <orapid> Set Oracle pid of process to debugDUMP <dump_name> <lvl> [addr] Invoke named dump…

oradebug 사용법

Oradebug 기본적인 사용법 자체는 매우 간단합니다.

본 세미나에서는 Oracle 9i 버전 기준으로 하였습니다.

Sqlplus 를 통해 적절한 권한을 가진 DB USER 로 접속합니다.

Sqlplus 접속 후 HELP, DUMPLIST 같은 몇몇 Command 를 제외하고는 덤프할 프로세스를 지정한 후

Oradebug Command 를 사용해야 합니다. 여기서 프로세스는 오라클 백그라운드 또는 셰도우(Shadow)

프로세스여야 합니다. 프로세스 지정하는 자세한 방법은 다음 장에서 설명 드리겠습니다.

기본적인 SYNTAX 는 Oradebug 를 먼저 쓰고 그 다음에 해당 Command, 그리고 Command 에 필요한 옵션들을

추가하면 됩니다.

각 Command 의 자세한 옵션들은 oradebug help 로 확인하실 수 있습니다.

Command 마지막에 ; (세미콜론) 은 필요 없습니다. 버전에 따라 세미콜론이 있으면 에러가 발생하기도 합니다.

[주의 하실점]

Oradebug help 로 보시면 사용 가능한 모든 Command 가 나오지만, “사용 가능한” 리스트를 보여주는 것이지

“사용 권장” Command 가 아니라는 것입니다.

ORADEBUG 사용법


oradebug command 카테고리

1. 프로세스 설정

SETMYPIDSETOSPIDSETORAPID

2. 트레이스파일 관리

FLUSHCLOSE_TRACETRACEFILE_NAMEUNLIMIT

3. Oracle EVENT 설정

EVENTSESSION_EVENT

4. 메모리 덤프

DUMPDUMPSGADUMPLIST

고객 여러분의 이해를 돕기 위해 제가 임의로 Oradebug Command 카테고리를 7개로 나누었습니다.

이 이외에도 다른 Command 들이 있지만 이 Command 들만 익혀두셔도 오라클 데이터베이스 문제진단 및

추적을 위해 oradebug 를 충분히 활용할 수 있습니다.

카테고리는 아래와 같습니다.

1. 프로세스 설정

2. 트레이스파일 관리

3. Oracle Event 설정

4. 메모리 덤프

5. RAC 관련옵션

6. HANG 분석

7. 기타

1, 2 번째 카테고리는 oradebug 사용시 필요한 기본적인 설정에 사용되는 Command 들입니다.

3 번째 카테고리 Oracle Event 설정은 오라클 Number Event 를 설정하여 특정 프로세스/세션을 트레이싱 하는

Command 입니다.

4 번째 카테고리가 oradebug 의 핵심 기능이라고 볼 수 있습니다. 오라클 메모리나 프로세스, 인스턴스 정보를

덤프하는 것입니다.

ORADEBUG 사용법


oradebug command 카테고리

5. RAC 관련

-G-RSETINSTLKDEBUG

6. HANG 분석

HANGANALYZE

7. 기타

COREIPCFLASH FREEZE

5번째 카테고리가 RAC Command 들로, 덤프 할 인스턴스 설정과 RAC 만이 가지고 있는 특정 리소스를 덤프 할 수

있는 LKDEBUG 라는 Command 가 포함됩니다.

6번째는 HANG 발생시 원인 추적에 유용한 HANGANALYZE Command 입니다.

마지막 카테고리는 기타로 CORE 와 IPC Command 입니다.

CORE Command 는 오라클 프로세스를 죽이지 않고 CORE 덤프만 발생시킵니다.

IPC Command 는 말 그대로 Inter Process Communication 정보를 보여줍니다.

오라클이 사용 중인 OS shared memory segment 정보, 세마포어 정보, RAC 인 경우 Interconnect 네트워크

정보를 볼 수 있습니다.

그럼 각 카테고리의 Command 에 대한 자세한 설명으로 넘어가도록 하겠습니다.

ORADEBUG 사용법


[Cat.1] 프로세스 설정

덤프 관련 Command 수행 전에 대상 프로세스 지정

SETMYPID접속한 CURRENT 프로세스를 지정

SETOSPID <ospid>덤프할 오라클 프로세스의 OS PID 지정

V$PROCESS.SPID 값

SETORAPID <orapid> [FORCE]덤프할 오라클 프로세스의 ORACLE PID 지정

V$PROCESS.PID 값

첫번째 카테고리인 프로세스 설정 Command 들입니다.

다른 Command 사용 전에 덤프대상이 되는 오라클 프로세를 지정해야 합니다.

다음과 같이 세가지 방법으로 지정할 수 있습니다.

첫째, 아무 옵션 없이 SETMYPID 로 현재 SQLPLUS 로 접속해있는 프로세스를 지정합니다.

특정 에러가 발생하는 SQL 을 수행하여 에러스택 (Errorstack) 을 생성하거나 EVENT 설정을 테스트해 볼 때사용할 수 있는 가장 간단한 지정 방법입니다.

또한 인스턴스 전체 정보를 덤프 할 때는 아무 프로세스나 지정하면 되므로 수고스럽게 특정 프로세스 찾을 필요없이 SETMYPID 를 지정하면 됩니다.

둘째, SETOSPID 로 OS PROCESS PID 를 지정하는 방법입니다.

예를들어 CPU 를 많이 사용하고 있는 오라클 셰도우 프로세스를 발견한 후 덤프하고 싶으면 SETOSPID 다음에해당 프로세스의 OS PID 를 넣어주면 됩니다.

oradebug 로 덤프할 수 있는 프로세스는 오라클의 백그라운드 프로세스나 셰도우 프로세스로 해당 OS PID 가V$PROCESS.SPID 에 존재해야 합니다.

세번째 지정 방법은, SETORAPID 로 Oracle PROCESS ID 를 이용하는 방법입니다.

특정 세션의 SID 를 알때 V$PROCESS.PID 를 조회하여 oradebug 에 설정할 수 있습니다.

[TIP]

SETOSPID 와 SETORAPID 는 지정하는 속성 값이 다를 뿐이지 결과 트레이스는 동일하므로 어떤 것을사용할지는 고객 여러분이 선호 하시는 대로 사용하면 됩니다.

한가지 ORAPID 가 유용할 때는 RAC 에서 노드간에 보통 백그라운드 프로세스들은 OS PROCESS ID 는다를지라도 ORAPID 가 동일합니다.

이러한 특성을 이용하여 한 인스턴스에서 한 ORAPID 를 지정하여 두 인스턴스의 동일 백그라운 프로세스를

덤프 할 수 있습니다. RAC 에서 oradebug 사용은 뒷부분에서 자세히 설명 드리겠습니다.

ORADEBUG 사용법


SQL> oradebug / as sysdba SQL> oradebug setmypidStatement processed.

SQL> oradebug setospid 1673 V$PROCESS.SPID 확인

Oracle pid: 15, Unix process pid: 1673, image: oracle@krind2 (TNS V1-V3)

SQL> oradebug setorapid 15 V$PROCESS.PID 확인

Unix process pid: 1673, image: oracle@krind2 (TNS V1-V3)

[Cat.1] 프로세스 설정 예제

프로세스 설정 Command 들 사용 예제 입니다.

SETMYPID 는 다른 옵션이 필요 없이 단독으로 지정하시면 됩니다.

SETOSPID 1673 으로 오라클 프로세스의 OS PID 를 지정했을 때 성공적으로 지정되면 간단하게 프로세스 정보를보여줍니다.

만약 지정한 OS PID 가 오라클 프로세스가 아니면 에러가 발생합니다.

SETORAPID 는 ORACLE PID 를 지정하면 됩니다. 정상적으로 지정하시면 프로세스 정보를 보여줍니다.

이제 덤프 할 프로세스를 지정하였으므로, 생성될 트레이스 파일에 대한 설정을 체크해야 합니다.

ORADEBUG 사용법


[Cat.2] 트레이스파일 관리

트레이스 파일 크기 설정 및 체크

덤프할 프로세스가 백그라운드 프로세스면 BDUMP 에 , 유저 프로세스면 UDUMP 에 트레이스 생성

FLUSHBUFFER 의 Pending Write 을 파일에 반영

CLOSE_TRACEFLUSH 와 비슷하게 Pending Write 반영

트레이스 파일을 OS 명령어로 지운 경우, CLOSE_TRACE 후 프로세스 재지정하고 덤프수행하면 파일이 재생성 됨

Oradebug 트레이싱 또는 덤프 결과가 쓰여지는 트레이스 파일의 크기 설정 및 체크를 위해 사용되는

Command 들을 살펴보도록 하겠습니다.

기본적으로 트레이스파일은 지정한 프로세스가 백그라운드 프로세스면 BDUMP 에, 셰도우 프로세스면 UDUMP 디렉토리 밑에, 파일이름에 OS PID 를 포함하여 생성되므로 쉽게 찾을 수 있습니다.

FLUSH 는 이름에서 알 수 있듯이 BUFFER 의 Pending Write 를 파일에 반영합니다.

CLOSE_TRACE 는 평상시에는 FLUSH 와 비슷한 기능을 합니다.

이 Command 가 빛을 발할 때는 사용자가 실수로 OS 명령어인 rm 으로 수행중인 프로세스의 트레이스 파일을

지운 경우입니다. 오라클은 아키텍쳐상 한번 rm 으로 지워진 트레이스 파일은 Alert.log 을 제외하고는 이후덤프가 발생해도 트레이스파일이 자동 재생성 되지도 않고, 트레이스 파일이 없다는 에러도 없습니다.

touch 같은 OS 명령어로 파일을 만들어도 덤프 내용이 그 파일로 생성되지 않습니다.

하지만 CLOSE_TRACE 하고 해당 프로세스를 재지정한 후 덤프를 수행하면 새로운 파일이 생성됩니다.

ORADEBUG 사용법


[Cat.2] 트레이스파일 관리

TRACEFILE_NAME현재 사용하고 있는 트레이스 파일명 리턴

파일이 아직 생성되지 않은 경우 리턴 결과 없음

UNLIMT트레이스가 잘리지 않도록 파일크기 무제한 설정

DEFAULT SIZE : MAX_DUMP_FILE_SIZE

TRACEFILE_NAME Command 는 확인 명령어로 현재 덤프가 쓰여지고 있는 파일명을 리턴해줍니다.

아직 트레이스파일에 아무것도 안 쓰여진 경우에는 결과가 리턴되지 않습니다.

UNLIMIT 은 SYSTEMSTATE 덤프나 SGA 덤프, 10046 트레이스 등 많은 양을 덤프하는 경우

덤프 전에 *꼭* 지정할 것을 권장 드립니다. 지원 경험상 크리컬 장애 시 업무 중지도 감수하고 덤프를

수행했는데 MAX_DUMP_FILE_SIZE LIMIT 때문에 트레이스 파일이 잘린 경우가 종종 있습니다.

이 경우 오라클도 트레이스가 온전치 못하므로 명확한 분석을 진행할 수 없습니다.

Oradebug 를 사용하실 때는 프로세스 지정하자마자 UNLIMIT 을 습관적으로 지정할 것을 권장 드립니다.

[TIP]

MAX_DUMP_FILE_SIZE 지정시는 “UNLIMITED” 이고 oradebug 에서는 “UNLIMIT” 입니다.

ORADEBUG 사용법


SQL> oradebug setospid 3058Statement processed.SQL> oradebug tracefile_name No Output

SQL> oradebug dump errorstack 3 Statement processed.SQL> oradebug tracefile_name 한번 쓰여진 후 보여짐

/home//admin/ORA920/bdump/ora920_pmon_3058.trc

$ ls –l -rw-r----- 1 ora920 dba Apr 26 13:28

ora920_pmon_3058.trc$ rm ora920_pmon_3058.trc Delete the tracefile

[Cat.2] 트레이스파일 관리 예제

Oradebug 트레이스파일 관리 예제입니다.

첫번째 TRACEFILE_NAME 예제에서 보시다시피 프로세스 3058 지정하자마자 트레이스에 내용이 없기 때문에

트레이스 파일명이 리턴되지 않습니다.

한번 덤프 Command 사용한 이후에 트레이스 파일명이 리턴 되는 것을 볼 수 있습니다.

사용자가 실수로 OS 상에서 rm 으로 트레이스파일을 지운 상황을 만들어보았습니다.

ORADEBUG 사용법


SQL> oradebug dump errorstack 3 Statement processed.$ ls –l 파일이 자동재생성 안됨

Total 0SQL> oradebug close_trace Statement processed.SQL> oradebug setospid 3058Statement processed.SQL> oradebug dump errorstack 3 Statement processed.$ ls –l 파일이 재생성 됨

-rw-r----- 1 ora920 dba Apr 26 13:30 ora920_pmon_3058.trc

[Cat.2] 트레이스파일 관리 예제

OS 명령어로 트레이스 파일 지우고 덤프 명령을 날려도 트레이스가 자동 재 생성되지 않습니다.

수행중인 오라클 프로세스의 트레이스를 다시 만들 수 있는 방법은 예제처럼 CLOSE_TRACE 하고 프로세스 지정을

다시 한 후 덤프를 수행하면 보시다시피 해당 트레이스 파일이 재 생성된 것을 볼 수 있습니다.

ORADEBUG 사용법


[Cat.3] Oracle EVENT 설정

Oracle Event 중 NUMBER Event 설정/해제

[참고] 2003년12월9일자 iSeminar 자료

“오라클 데이터베이스의 Event 설정 및 활용방법”

EVENT <text>오라클 프로세스를 대상으로 EVENT 설정/해제

<text> 옵션은 각 EVENT 의 SYNTAX

SESSION_EVENT <text>오라클 세션을 대상으로 EVENT 설정/해제

세번째 Oradebug Command 카테고리는 Oracle Event 설정입니다.

Oracle Event 는 특정 세션을 트레이싱하거나, 일반적인 루틴과는 다른 루틴을 수행하게 위해 사용하는 방법입니다.

Oracle Event 에 대한 자세한 설명과 SYNTAX 는 2003년 12월 9일자 iSeminar 자료 ”오라클데이타베이스의 Event

설정및활용방법” 을 참고하시기 바랍니다.

Oracle Event 는 Number Event 와 Named Event 로 구분되는데, Oradebug 에서 Number Event 는 EVENT

Command 로, Named Event 는 DUMP Command 로 설정합니다.

한번 설정된 Event 는 다시 OFF 옵션으로 Disable 시킬 수 있습니다.

EVENT Command 는 프로세스 대상으로 Number Event 를 설정하고, SESSION_EVENT Command 는 세션을

대상으로 설정한다고 되어있으나, 제가 경험한 바로는 아직까지 사용상의 큰 차이점을 발견하지 못했습니다.

EVENT Command 의 <text> 옵션은 설정하고자 하는 EVENT 의 SYNTAX 를 그대로 사용하시면 됩니다.

그러므로 설정 전에 EVENT SYNTAX 미리 숙지 하셔야 합니다.

각각의 EVENT SYNTAX 는 위에 언급한 자료나 Metalink 에서 EVENT 별로 찾아보셔야 합니다.

ORADEBUG 사용법


CASE 1 : 다른 세션 SQL_TRACE 얻고자 하는 경우

SQL> oradebug setospid 7878 다른 프로세스 OS PID 지정

SQL> oradebug event 10046 trace name context forever, level 12

Statement processed.

SQL> oradebug event 10046 trace name context off

[Cat.3] Oracle EVENT 설정 예제

첫번째 예제는 SQL_TRACE 와 동일 기능을 하는 10046 EVENT 를 이미 수행중인 다른 프로세스에 설정하는

것입니다.

Oradebug setospid 트레이스하고자하는 오라클 프로세스 PID 지정,

Oradebug event 10046 trace name context forever, level 12

이렇게 설정하시고 트레이스파일을 찾아보시면 SQL_TRACE 와 동일한 정보 또는 레벨에 따라 더 자세한

트레이스가 발생하고 있는 것을 확인하실 수 있습니다.

원하는 순간에 예제처럼 트레이싱을 OFF 하실 수도 있습니다.

ORADEBUG 사용법


CASE 2 : ORA 에러 발생시 ERRORSTACK 생성

SQL> oradebug setmypidSQL> oradebug event 942 trace name errorstack level 3SQL> select * from emperror;

*ERROR at line 1:ORA-00942: table or view does not exist

SQL> oradebug tracefile_name ORA-942 트레이스발생

/home/ora817/admin/ORA817/udump/ora_2047.trc

[Cat.3] Oracle EVENT 설정 예제

Oradebug 으로 얻을 수 있는 것 중 중요한 정보가 오라클 프로세스의 에러스택(Errorstack) 입니다.

에러스택이란 당시에 호출 되고 있었던 Oracle Function 들과 매개 변수들을 보여주는 것으로 에러스택을 근거로

문제 당시 오라클이 무엇을 하고 있었는지 소스 레벨에서 추적할 수 있습니다.

예를 들어 기존의 오라클 버그와 고객사의 문제가 동일한지 판단할 때 에러스택이 기존 버그와 동일해야 동일

문제로 결론 내릴 수 있습니다. 다른 조건이 모두 같고 에러스택이 틀리면 새로운 이슈로 진행합니다.

위의 예제는 고객이 생각할 때는 emperror 테이블이 분명히 있는데, 존재하지 않는다는 ORA-942 가 발생하는

경우를 가정했습니다.

Oradeubg event 942 trace name errorstack level 3

오라클 에러 번호를 942 를 EVENT NUMBER 로 사용하여 ORA-942 에러가 발생하면 에러스택을 덤프 하도록

EVENT 를 설정한 것입니다.

이와 같은 에러스택을 오라클 지원 요청 시 같이 제공해주시면 경우에 따라서는 문제해결이 더 신속하게 진행될 수

있습니다.

ORADEBUG 사용법


[Cat.4] 메모리 덤프

오라클 메모리 영역인 SGA, PGA 정보 덤프

Oradebug 의 가장 중요하고 강력한 기능

DUMPSGA [bytes]Fixed SGA 내용을 지정한 bytes 만큼 덤프

DUMPLISTDUMP command 에 사용할 수 있는 “Named Event”리스트

오라클 인스턴스가 사용 중인 SGA, PGA 등의 메모리 내용을 트레이스 파일로 덤프하는 기능이 카테고리

4번째에 해당하는 Command 들입니다.

이 중 DUMP Command 가 Oradebug 에서 많이 사용되는 것으로 고객분들도 이미 사용 경험이 있을 것입니다.

먼저 DUMPSGA 부터 살펴보겠습니다.

SGA 중에서 각 변수의 초기 어드레스를 저장한 부분을 FIXED SGA 라고 하는데, SQLPLUS 에서 show sga 로

보시면 “Fixed Size” 라는 부분입니다.

DUMPSGA 는 이 부분만을 덤프합니다.

DUMPLIST 는 Oradebug 에서 덤프할 수 있는 Named Event 를 보여줍니다.

$ SQL > Oradebug dumplist

세번째 카테고리인 EVENT Command 가 Number Event 설정에 사용되고, DUMP Command 가 Named Event

설정할 때 사용한다는 것을 다시 말씀 드립니다.

ORADEBUG 사용법


[Cat.4] 메모리 덤프

DUMP <dump_name> <lvl> [addr]Named Event 의 덤프시 사용

옵션들

dump_name : Named Event lvl : dump_name 에 따라 적절한 level 지정

addr : ADDRESS 필요시 지정

DUMP Command 의 기본적인 SYNTAX 는 다음과 같습니다.

DUMP Command 뒤에 Oracle Named Event 인 DUMP NAME 을 지정하고,

해당 Named Event 에 따라 적절한 LEVEL 을 지정해줍니다.

어떤 Named Event (heapdump_addr) 는 특정 HEXA MEMORY ADDRESS 를 지정해야 합니다.

알아두시면 유용한 몇 가지 DUMP Command 를 케이스 스터디 형식으로 설명 드리겠습니다.

ORADEBUG 사용법


CASE 1 : 특정 프로세스가 SPIN 또는 HANG SQL> oradebug dump errorstack 3 3분단위 3번수행

SQL> oradebug dump processstate 10 비교1

SQL> oradebug event 942 errorstack 10 비교2

CASE 2 : 데이터베이스 SPIN 또는 HANGSQL> oradebug dump systemstate 10 3분간격 3번수행

= alter session set events'immediate trace name SYSTEMSTATE level 10';

[Cat.4] 메모리 덤프 예제

CASE 1 은 특정 프로세스가 SPIN 또는 HANG 으로 보이는 경우입니다.

(1) Oradebug setospid 해당 프로세스를 덤프대상으로 지정하고

(2) Oradebug dump errorstack 3 으로 ERRORSTACK 을 2-3번 떠서

(3) CALL STACK 부분이 변하고 있는지 비교해봅니다.

변하고 있으면 SPIN 이고, 변하지 않고 있으면 HANG 이라고 결론 내릴 수 있습니다.

ERRORSTACK LEVEL 3 에 PROCESSSTATE DUMP 가 포함되므로

PROCESSSTATE DUMP 를 별도로 수행할 필요가 없습니다.

EVENT Command 에서 ERRORSTACK 를 설정할 때와 비교해보면, EVENT Command 는 해당 에러가 발생하는

시점에 에러스택이 생성되는 것이고, DUMP Command 는 Oradebug Command 를 수행하자마자 에러스택이

생성됩니다.

케이스 두번째, 드디어 SYSTEMSTATE DUMP 입니다.

이 Command 는 아마도 oradebug 에서 가장 많이 사용되는 명령어로

alter session set events 'immediate trace name SYSTEMSTATE level 10'; 과 같습니다.

보시다시피 Oradebug Command 가 훨씬 간단하고 Rule 만 알면 외울 필요도 없습니다.

인스턴스 HANG 시 3분 간격으로 3번을 수행한 결과가 있어야 Slow Performance 인지, 진짜 HANG 이였는지 판단할

수 있습니다.

ORADEBUG 사용법


CASE 3 : 프로세스 메모리가 비정상 증가하는 경우

SQL> oradebug dump heapdump 5 PGA+UGA

CASE 4 : SGA 부족으로 ORA-4031 가 발생하는 경우

SQL> oradebug dump heapdump 2 SGA

event="4031 trace name HEAPDUMP level 2" in initSID.ora


CASE 3 은 특정 오라클 프로세스의 메모리가 지속적으로 증가만하거나, 한번 증가한 후 줄어들지 않는 경우 메모리

정보를 덤프하여, 어느 메모리 세그먼트 부분이 많이 차지하는지 분석하기 위해 HEAPDUMP 를 수행하는 것입니다.

Oradebug dump heapdump 원하는 레벨 형식으로 사용할 수 있습니다.

HEAPDUMP 의 LEVEL 은

LEVEL 1 : PGA

LEVEL 2 : SGA

LEVEL 4 : UGA

서로 조합해서 사용할 수 있습니다.

CASE 4 는 SGA 가 부족하다는 ORA-4031 가 발생하는데 정확한 원인을 찾지 못하는 경우, SGA DUMP 를

주기적으로 받아 비교해 볼 수 있습니다.

ORA-4031발생시 HEAPDUMP 권장 방법은 event 를 initSID.ora 파라미터 파일에 설정하는 것입니다.

그래야 ORA-4031 발생하는 시점의 정확한 SGA HEAPDUMP 를 얻을 수 있기 때문입니다.

event="4031 trace name HEAPDUMP level 2"

ORADEBUG 사용법


CASE 5 : 특정 리소스때문에 ORA-600 발생, 성능 저하시

SQL> oradebug dump library_cache 11SQL> oradebug dump row_cache 10

CASE 6 : 리커버리시 데이터파일 상태 불일치 에러시

SQL> oradebug dump controlf 10SQL> oradebug dump file_hdrs 10


DUMP Command 에 대한 5번째 케이스는 오라클 특정 리소스에 대한 자세한 덤프 생성입니다.

예를 들어 V$SESSION_WAIT 에 library cache 관련 wait event 들이 많이 걸리는데, 자세한 정보를 얻을 수 없거나

library cache 관련한 ORA-600 에러가 발생하는 경우 Oradebug Command 를 사용하여 Librarcy cache dump 를

얻을 수 있습니다.

LIBRARY_CACHE DUMP 의 일반적인 LEVEL 은 11 이고 덤프동안 인스턴스의 지체현상이 발생할 수 있고 트레이스

양도 많으므로 덤프 할 알맞은 시간을 선택하셔야 합니다.

6번째 케이스는 이전 케이스들과는 달리 메모리 덤프가 아니고 데이터파일과 콘트롤파일 헤더를 덤프 하는 것입니다.

리커버리시 혹은 데이터베이스 오픈시 파일들 상태가 일치하지 않는다는 ORA-1113, ORA-376 등의 에러가

발생하는 경우 CONTROLF 와 FILE_HDRS 를 사용하여 각 파일의 헤더를 덤프하여 파일들의 상태와 업데이트

시간을 비교할 수 있습니다.

ORADEBUG 사용법


[Cat.5] RAC 관련

RAC 에서 Command 가 동시 수행될 인스턴스 지정

-G <Inst-List | Def | All > Oradebug command 동시 수행될 인스턴스 지정

각 인스턴스 덤프는 각 DIAG 트레이스로 분리되어생성

옵션들 Inst-List : INSTANCE_NUMBER 로 지정

Def : Default 인스턴스

All : 모든 인스턴스들

SQL> oradebug -g “1 2” lkdebug -a lock

다섯번째 카테고리는 RAC 환경에서 사용할 수 있는 Command 들입니다.

Oradebug Command 한번 수행으로 모든 인스턴스를 덤프 하고자 할 때 –G 옵션이나 –R 옵션을 사용할 수있습니다.

두개의 옵션이 동일한 기능을 하나, –G 옵션은 지정한 인스턴스들의 덤프 결과가 각 인스턴스의 DIAG 프로세스의

트레이스 파일로 분리되고, -R 은 한곳으로 떨어집니다.

-G 옵션에서 인스턴스 지정하는 방법은 INSTANCE_NUMBER 를 이중따옴표(“”) 안에 나열하거나, Def 로 Default

인스턴스를 지정하던지, 간단히 ALL 이라고 지정하면 모든 인스턴스들이 포함됩니다.

ORADEBUG 사용법


[Cat.5] RAC 관련

-R <Inst-List | Def | All >-G 옵션 처럼 oradebug command 를 동시 수행

모든 덤프가 한 인스턴스의 DIAG 트레이스로 생성

트레이스 양 많은 경우 –G 권장

SQL> oradebug -r “1 2” lkdebug -a lock

SETINST <instance# .. | all>Default 인스턴스 스위치 시 사용

다수 인스턴스 지정시 INSTANCE_NUMBER 나열

SQL> oradebug setinst “1 2“

-R 옵션은 –G 옵션과 비슷하나 Command 를 수행한 한 인스턴스의 DIAG 트레이스에 모든 덤프가 발생합니다.

결국 리모트 인스턴스에서 Oradebug Command 수행한 인스턴스로 트레이스 정보가 전달 되어야 하므로

트레이스양이 많은 경우 –G 옵션을 사용하시기를 권장드립니다.

SETINST 는 Default Instance 를 스위치할 때 사용합니다.

인스턴스 넘버를 나열하거나 ALL 이라고 지정할 수 있습니다.

ORADEBUG 사용법


[Cat.5] RAC 관련

LKDEBUGRAC 에서 사용되는 DLM (Distributed Lock Manager) 관련 RESOURCE 와 LOCK 정보 등 덤프

oradebug lkdebug help -l [r|p] 'lock pointer' -r 'resource pointer'-p 'process id'-P 'process pointer'-O 'i1 i2 types' -a 'res/lock/proc/pres/rdom'…

LKDEBUG 는 RAC 에서 필요한 DLM 관련 RESOUCE, LOCK 에 대한 덤프 시 사용 됩니다.

특히 RAC 환경에서 HANG 또는 LOCKING 문제 발생시 특정 리소스 트레이스를 위해 사용됩니다.

실제 고객 여러분이 LKDEBUG 를 직접 취합하실 경우는 거의 없고 트레이스 내용도 오라클 소스 개발자들이

소스레벨에서 분석 가능한 내용들입니다.

옵션들을 참고로 말씀드리겠습니다.

SQL> oradebug lkdebug help 로 보실 수 있고 다음과 같습니다.-l [r|p] 'lock pointer' -r 'resource pointer' Resource Object-p 'process id' DLM client pid-P 'process pointer' Process Object-O 'i1 i2 types' Oracle Format resname-a 'res/lock/proc/pres/rdom' all pointers

ORADEBUG 사용법


[Cat.6] HANG 분석

프로세스 또는 인스턴스 HANG 진단 및 분석시 유용

HANGANALYZE [level] 1-2 Only HANGANALYZE output, no process dump

3 Level 2 + HANG 으로 추정되는 프로세스 덤프4 Level 3 + WAIT CHAIN 의 BLOCKER 프로세스

5 Level 4 + WAIT CHAIN 의 모든 프로세스

10 모든 프로세스 덤프

SQL> oradebug hanganalyze 3 권장레벨, 또는 1

Hang Analysis in /home/ora920/ora920_1190.trc

6번째 카테고리인 HANG 분석입니다.

HANGANALYZE 는 HANG 발생시 세션들 간의 관계를 한눈에 판단하기 쉽게 CHAIN 형식으로 보여주므로 HANG

진단 시 매우 유용한 툴입니다.

HANGANALYZE 결과만 정확히 분석할 수 있어도 HANG 에대한 신속한 조치를 취할 수 있습니다.

이미 말씀드렸던 SYSTEMSTATE DUMP 도 HANG 발생시 사용하는 명령이기 하나, 이것은 주로 오라클 서포트에서

사후 정밀 분석을 위한 것이지 고객 여러분께서 덤프내용을 직접 분석하고 진단할 수 없습니다.

Oradebug hanganalyze level 형식으로 사용합니다.

LEVEL은 1 ~ 10 인데 LEVEL 별로 얻을 수 있는 정보의 수준이 다릅니다.

일반적으로 LEVEL 3 으로 충분하고 그 이상의 레벨 사용 시는 오라클 서포트의 도움을 받으시길 바랍니다.

ORADEBUG 사용법


[Cat.6] HANG 분석

HANGANALYZE TRACEFILE SECTIONS 설명

CYCLES : Deadlock 관계 세션들의 CHAIN

BLOCKER OF MANY SESSIONS : 10개 이상의 세션을blocking 하는 BLOCKER 제시

OPEN CHAINS : 1개 이상의 타 세션들을 blocking 하는세션이 포함된 WAIT CHAIN

OTHER CHAINS : OPEN CHAIN 의 세션들과 간접적으로관련있는 프로세스 리스트

HANGANALYZE 트레이스 결과를 보고 문제상황을 신속히 판단하는 것이 중요합니다.

간단하게 HANGANALYZE 트레이스 파일에 대해 살펴보겠습니다.

트레이스 결과는 섹션들로 구분되어 있고, 각 섹션의 내용들은 모두 CHAIN 형식으로 보여지므로 세션간의 WAITER-

HOLDER 관계를 명확하게 구분할 수 있습니다.

각각의 섹션에 대해 살펴보도록 하겠습니다.

첫번째 섹션은 CYCLES 섹션입니다.

이 섹션에 어떤 결과가 있다면 바로 그 CHAIN 이 HANG 의 원인일 가능성이 높습니다.

CYCLES 이라는 말 그대로 프로세스들끼리 서로 리소스를 기다리는 DEADLOCK 상태라는 것입니다.

두번째 섹션은 BLOCKER OF MANY SESSIONS 입니다.

10개 이상의 세션들이 기다리는 리소스를 점유하고 있는 BLOCKING 세션을 찾아줍니다.

BLOCKER 세션이 왜 특정 리소스를 점유하고 있는지 원인을 해결 해주어야 합니다.

세번째 섹션은 OPEN CHAINS 입니다.

하나라도 다른 세션을 WATITNG 하게 만드는 세션이 있으면 해당 BLOCKING 세션과

WAITING 세션간의 관계를 CHAIN 으로 보여줍니다.

네번째는 OTHER CHAINS 섹션입니다.

OPEN CHAINS 의 BLOCKING 세션에 의해 직접적으로 영향을 받지않으나

간접적으로 WAITING 세션들 때문에는 결국에 기다리는 세션 정보들 입니다.

ORADEBUG 사용법


[Cat.6] HANG 분석

EXTRA INFORMATION : 덤프 레벨에 따른 프로세스Errorstack 등의 추가 정보

STATE OF NODES : 모든 세션들 DEPENDENCY GRAPHIN_HANG - HANGIGN - IGNORELEAF - A waiting leaf nodeLEAF_NW - A running leaf nodeNLEAF - STUCK

EXTRA INFORMATION 섹션은 덤프 레벨에 따라 추가되는 프로세스덤프, 에러스택 등을 포함합니다.

마지막으로, 주목해서 봐야할 STATE OF NODES 섹션 입니다.

HANGANALYZE 시 연결 되어있던 모든 세션들의 DEPENDENCY GRAPH 와 세션 STATE 를 보여줍니다.

문제의 소지가 있는 세션이나, 세션들간의 WAITING-BLOCKING 관계를 추정할 수 있습니다.

예를들어 DEADLOCK 세션은 IN_HANG 상태이고, BLOCKER 세션은 LEAF, LEAF_NW 상태이면서 OPEN CHAINS

에서 맨앞에 있는 세션입니다.

NLEAF 인 세션은 다른 세션이 리소스를 잡고 안 풀어주어서 발생하므로 Performance문제를 의심해 보아야 합니다.

세션 STATE 설명입니다.

-IN_HANG : 심각한 상태로, 이 상태의 세션은 DEADLOCK 가능성이 있습니다 .

-IGN and IGN_DMP : IDLE 상태이므로 무시하셔도 됩니다.

-LEAF and LEAF_NW : 이 상태로 Wait Chain 의 가장 앞에 있으면, 바로 이 세션이 Blocker 세션입니다.

-NLEAF : STUCK 세션으로, 다른 세션이 리소스를 잡고 안 놓아 주는 상태로 Performance 이슈일

가능성이 높습니다.

ORADEBUG 사용법


[Cat.6] HANG 분석 예제

HANG ANALYSIS:Chain 1 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> : <0/1730/23902/ 0x6ab747f8 23189/enqueue>-- <0/714/34403/0x6ab747dd/24051/library cach lock> -- <0/1924/5394/ 0x6ab747ac/17206/library cache lock>

State of Nodes [nodenum]/cnode/sid/sess_srno/session/ospid/state/start/finih/[adjlist]/predecessor[16]/0/17/154/0x24617be0/26800/IN_HANG/29/32/[185]/19

[185]/1/16/4966/0x24617270//IN_HANG/30/31/[16]/16

HANGANALYZE 트레이스파일 예제입니다.

체인의 기본적인 구성은 아래 노트에 자세히 설명되어있습니다.

Nodenum - Node ID

cnode - Node number (Only available since Oracle9i)

sid - Session IDsess_srno - Serial#ospid - OS Process Id

wait_event - wait event namestate - State of the nodeadjlist - adjacent node (Usually represents a blocker node)predecessor - predecessor node (Usually represents a waiter node)

첫번째 예제는 OPEN CHAINS 섹션 정보로, 세개의 세션이 연결되어 있습니다.

두번째 컬럼인 SID 즉 세션ID 로 설명하면 SID=1730 이 enqueue 를 기다리고 있고,

다른 두 세션은 첫번째 세션이 잡고있는 Library cache lock 을 기다리고 있다는 것을 보여줍니다.

첫번째 세션 1730 이 왜 enqueue 를 못잡고 있는지 찾아서 해결해주어야 두개 세션들의 WAIT 도 풀립니다.

두번째 예제는 State of Nodes 섹션입니다. 여기서는 첫번째 컬럼이 노드번호인데 세션개념이라고 보시면 됩니다.

첫번째 라인에서 16번 노드 즉 SID=17 번이 노드 185번 을 기다리고 있는 것을 라인 끝에서 볼 수 있습니다.

두번째 라인에서 노드 185 는 노드 16을 기다리고 있습니다.

세션 관계로 보아도 DEADLOCK 이고 세션 상태들도 IN_HANG 입니다.

ORADEBUG 사용법


[Cat.7] 기 타

CORE : 오라클 프로세스 다운없이 CORE 만 발생

SQL> oradebug core

IPC : 오라클에서 사용 중인 Shared Memory, Semapore, Network 등 IPC 정보 덤프

SQL> oradebug ipc

기타로 유용하게 사용하실 수 있는 것이 CORE 와 IPC Command 입니다.

CORE Command 는 오라클 프로세스를 죽이지않고 CORE 덤프만 발생시킵니다.

IPC Command 는 말 그대로 Inter Process Communication 정보를 보여줍니다.

오라클이 사용 중인 OS shared memory segment 정보, 세마포어 정보, RAC 인경우 Interconnect 네트워크

정보를 볼 수 있습니다.

ORADEBUG 사용법


데이터베이스 HANG : DB 연결될 때

SQL> oradebug setmypidSQL> oradebug unlimitSQL> oradebug hanganalyze 1 빨리 Blocker 찾으세요

SQL> oradebug dump systemstate 10 다른세션에서 3분3번

데이터베이스 HANG : DB 연결안 될 때

$ dbx –a PID $ORACLE_HOME/bin/oracle Oracle PID

dbx) call ksudss(10) or print ksudss(10)dbx) detach

DB HANG 이것만은 알아두세요!!!

세미나를 끝내기 전에 DB HANG 발생시 oradebug 를 어떻게 이용할지 중요한 TIP 을 정리해드리겠습니다.

HANGANALYZE 와 SYSTEMSTATE DUMP 을 취합해주셔야 신속한 문제해결 및 정확한 분석이 진행될 수 있습니다.

한 세션에서 Hanganalyze 1 을 수행하신 후, 결과 트레이스 열어서 CYCLES 와 Blocker of Many Sesssions 섹션을

보셔서 Blocker 로 보이는 세션을 정리하실 수 있는지 판단해주십시오.

Hanganalyze 1 은 수행하자마자 Output 이 발생하므로 기다릴 필요가 없습니다.

그러는 동안 다른 세션에서 SYSTEMSTATE 덤프를 LEVEL 10 으로 3분 간격으로 3번 취합해주셔야 합니다.

만약 Sqlplus 가 전혀 접속이 안되는 경우 OS 디버거를 이용하여 SYSTEMSTATE 덤프 할 수 있습니다.

Dbx –a 오라클셰도우프로세스 OS PID $ORACLE_HOME/bin/oracle

Dbx> call ksudss(10) or print ksudss(10)

Dbx> detach

오라클 셰도우 프로세스의 OS PID 찾은 후 dbx 나 gdb 로 ATTACH 하여

오라클 덤프 함수를 직접 CALL 덤프 하시면 BDUMP 또는 UDUMP 에 트레이스 떨어집니다.

OS 디버거인 dbx, gdb 사용법은 OS 매뉴얼을 참고하시기 바랍니다.

메타링크에서 아래 문서 참고하시기 바랍니다.

<Note:121779.1> Taking Systemstate Dumps when You cannot Connect to Oracle

ORADEBUG 사용법


참고문서

Note.29786.1 SUPTOOL ORADEBUG 7.3+

Note.105395.1 How to find PID for setospid in oradebug

Note.61552.1 DIAGNOSING DATABASE HANGING ISSUES

Note.68738.1 No Response from the Server, Does it Hang or Spin?

Note.121779.1 Taking Systemstate Dumps when You cannot …

Note.175006.1 Steps to generate HANGANALYZE trace files

Note.215858.1 Interpreting HANGANALYZE trace files …

Note.1066814.6 How to take OPS-Aware ORADEBUG dump

위의 문서들은 모두 http://metalink.oracle.com 의 지식검색에서 찾으실 수 있습니다.

Documents

오라클문제진단 추적을위한 ORADEBUG 사용법 · 2004-10-04 · 9트레이스파일을OS 명령어로지운경우, CLOSE_TRACE 후프로세스재지정하고덤프 수행하면파일이재생성됨