TRACE EVENT 세팅에 대하여

Question

제품 : ORACLE SERVER
작성날짜 : 2003-08-04
trace event를 세팅에 대하여
init.ora에 특별한 파라메터를 세팅하므로서 memory나 디스크 corruption에대해
분석할 수있는 방법이 있다. 이러한 파라메터들은 performance에 영향을 줄 수
있으므로 정상적인 상태에서는 세팅하지 않는다. 여기서는 event information을
모으기 위한 시간을 절약하는데 목적이 있으며 몇개의 event 세팅의 보기를 보여
준다. 여기서 보여지는 것 말고도 많은 event들이 있으며 그것들은 그때그때의
필요에 의해 세팅되어 진다.
Event trace를 하기 위한 방법에는 두 가지가 있다. 첫번째는 init.ora에 세팅
하는 것이며 이것은 모든 세션에 영향을 미친다. 두번째 방법은 alter session
set events 명령어를 이용하는 것이며 현재 세션에만 영향을 미친다.
Syntax는 다음과 같다.
Event = "event syntax | , LEVEL n | : event syntax | , LEVEL n | .. "
sql 문장을 이용한 syntax는 다음과 같다.
SQL> alter session set events 'event syntax LEVEL n: event syntax
LEVEL n: ...';
예를들어 콘트롤 화일의 전체 내용을 보기 위한 syntax는 다음과 같다.
SQL> alter session set events 'IMMEDIATE TRACE NAME CONTROLF LEVEL 10';
event syntax는 여러개의 키워드를 가지고 있다. 첫번째의 키워드는 event
number이거나 special keyword, 즉 IMMEDIATE일 수 있다. Event number는
오라클 에러 번호이거나 internal error code일 수 있다. Event code는
그 값에 따라 action이 발생되는 커널의 logic에 의해 결정된다. 이러한 내부
event code는 /rdbms/mesg/oraus.msg 화일에 있다. 다른 operating system에
서는 상기 화일이 binary format이거나 text가 아닐 수 있다. Internal event
code는 10000 - 20000의 범위에 있다.
만약 IMMEDIATE라는 키워드가 첫번째 나온다면 이것은 unconditional event
임을 나타낸다. 그리고 그 결과는 이 명령어가 사용된 직후 발생된다. 이러한
명령어는 alter session 라. 명령어에서만 효과가 있고 init.ora에서 설정된
문장은 효과가 없다.
두번째와 세번째 키워드는 각각 대부분 TRACE와 NAME이다. TRACE라는 키워드는
output이 trace file로 dump될 것을 의미하며 NAME이라는 키워드는 실제 event
name 바로 앞에 온다. TRACE말고도 다른 키워드가 올 수 있으나 그것들은 오라
클의 개발팀을 위해 사용된다. 마지막 키워드는 event name으로 실제 dump할
내용을 정한다.
만약 IMMEDIATE 키워드를 사용하지 않는다면 얼마나 오래동안 trace를 할지를
지정해야 한다. FOREVER 키워드를 사용했을때에는 해당 session이나 instance가
살아있는 시점까지 event는 살아있게 된다.
Event 문장 다음에는 대부분의 event에서 LEVEL 키워드가 세팅된다. 만약 level
이 없다면 errorstack을 dump하는 동안 exception이 발생할 수 있다. 일반적
으로 LEVEL은 1에서 10까지의 범위를 갖는다. 10은 그 event에 대해서 전체
내용을 전부 dump할 것을 의미한다.
예를들어 LEVEL을 1로 했을때에는 control file을 dump할때 control file
header만을 dump하지만 10이면 전체 내용을 dump한다. BLOCKDUMP키워드 일때
에는 LEVEL은 특별한 의미를 가지며 그것은 datablock의 실제 주소가 십진수로
표시된다.
이제 몇개의 예를 들어 보자. 다음은 init.ora 에 세팅될 수 있는 내용이다.
EVENT = "604 TRACE NAME ERRORSTACK FOREVER"
EVENT = "10210 TRACE NAME CONTEXT FOREVER, LEVEL 10"
첫번째 문장은 process가 ORA-604를 만날때마다 error stack을 dump하게 될 것
이다. 두번째 문장은 디스크에서 캐쉬로 블록을 읽을때 block integrity를 체크
하는 event이다.
다음 문장들은 SQL을 통해서 event를 세팅하는 예를 보인다.
SQL> ALTER SESSION SET EVENTS 'IMMEDIATE TRACE NAME BLOCKDUMP
LEVEL 67109037';
SQL> ALTER SESSION SET EVENTS 'IMMEDIATE TRACE NAME CONTROLF
LEVEL 10';
SQL> ALTER SESSION SET EVENTS 'IMMEDIATE TRACE NAME SYSTEMSTATE
LEVEL 10';
첫번째 문장은 데이타블록 67109037을 trace file로 dump할 것이다. 모든
오라클 데이타베이스의 데이타블록은 block number와 file number의 유일한
값으로 되어 있다. 상기예에서 67109037은 block number와 file number와의
십진표현법이다. 이러한 정보는 operating system dependent하다. 두번째
문장은 전체 콘트롤화일의 내용을 trace file로 dump한다.
세번째 문장은 system state 를 trace로 dump한다. (system state는 현재
RDBMS에 의해 잡혀있는 object에 대한 정보를 보여주며 process state dump는
특정 process에 잡혀있는 object에 대한 process state dump를 보여준다)
이러한 정보는 system hang problem과 같은 문제의 분석에 유용할 수 있다.
EVENT NAMES
여기서는 사용가능한 event에 대한 감각을 익히기 위해서 몇개의 event name을
들어 설명한다.
- ERRORSTACK
오라클은 어떤 process가 특별한 에러를 만났을때 그에 관련된 정보를 저장하기
위해 "error stack"을 생성한다. Oracle foreground process는 에러 메세지를
받는다. Application 운영중에는(Developer/2000 Forms) 에러와 관련된 자세한
정보를 foreground process는 받지 못한다.
이 event는 전체 에러 스택을 trace로 dump해 주며 oracle error를 debugging
하는데 유용하게 이용할 수 있다. 예를들어 application이 ora-604와 함께
실행이 중단되면
SQL> alter session set events '604 trace name errorstack forever';
은 에러 스택을 trace file로 생성시켜 줄 것이다.
- SYSTEMSTATE
이 event는 전체 system state를 dump하며 이것은 모든 프로세스의 state dump
를 포함한다.
Performance degradation, process hang이나 system hang을 분석하는데 있어서
유용하다.
SQL> alter session set events 'immediate trace name systemstate
level 10';
- EVENT CODE 10013 AND 10015
이것들은 corrupted rollback segment 문제를 분석하는데 사용될 수 있다.
이러한 경우에 데이타베이스는 startup 할 수 없고 ora-1578에러를 발생한다.
만약 원인이 rollback에 있는 것으로 판단됐을때 init.ora에 상기 event를 세팅
하면 trace 화일을 생성할 것이다. syntax는 다음과 같다.
Event = "10015 trace name context forever"
- EVENT CODES 10210 AND 10211
이것들은 block checking,가 event checking event들이다. 일반적으로 디스크
블록이 캐쉬로 읽어들여질때 기본적인 integrity checking이 수행된다. 상기
event들을 세팅하므로서 오라클은 부가적인 check을 하게되며 이것은 block
corruption을 분석하는데 결정적이다. PMON은 항상 block checking을 가능한
상태로 유지하고 있다. 정상적인 상태에서도 block-checking이나 index-
checking을 수행하는 것이 좋을 수도 있으나 over head가 있다.
Event = "10210 trace name context forever, level 10"
- EVENT CODES 10231 AND 10232
정전으로 인해 디스크의 한 블록 전체의 내용이 없어질 수 있다. 그런 상황에서
그 테이블의 자료를 살려내기 위해 일반적으로 export를 받는다. 그러나 full
table scan은 bad block을 만났을때 실패할 것이다. 이러한 상황을 피해가기
위해 event 10231의 세팅이 필요하다. 이 event는 full table scan시
corrupted block을 skip할 것이다. Event 10232가 세팅된다면 corrupted
block을 trace file로 dump된다. 이러한 event를 세팅하기 위해서는 몇몇 조건
들이 필요하다.
. 이러한 블록은 오라클에 의해 soft-corrupted되어야 한다. 즉 오라클이
corrupt block을 발견할 때 그 블록에 어떤 bit을 세팅하므로서 손상되었다고
표시한다. 오라클이 soft-corrupt block을 하기 위해서는 event 10210을 세팅
해야 한다. 그러므로 event 10210과 함께 10231이 쓰이는 것이 권장된다.
. 인덱스를 이용하여 해당 블록을 접근하는 것은 안되며, 단지 full table
scan만이 수행 되어야 한다. 만약 손상된 테이블을 export하려면 이러한 event
를 init.ora에 세팅해 놓아야 한다.
SQL> alter session set events *10231 trace name context off*;
Event = "10231 trace name context forever, level 10"
첫번째 문장은 세션에서 lock-checking 을 더 이상 하지 않게 하며 두번째는
block-checking을 실행하게 된다.
Reference Documents
<Note:1051056.6>
<Note:21184.1>

Answer 1

Thanks Ray.
I was wrong. The event is fired even if i enable it before the callback VI registration.
The problem was that, just to discover if the callback VI was called, i put some code in its block diagram that would have changed the state of a boolean control placed on its front panel, every time the callback VI was called.
Apparently this is not allowed and the boolean didn't change its state.
I solved linking the code in the callback VI to a boolean placed on another front panel (in this case on the main VI one). In this way i succeded whatching the boolean state change.