sqlplus를 이용하여 sysdba 계정에서 아래의 파일을 실행합니다.

SQL> @dbmsutil.sql <== ORACLE_HOME\rdbms\admin 에 파일이 존재함
SQL> @prvtutil.plb <== ORACLE_HOME\rdbms\admin 에 파일이 존재함

SQL> grant execute on dbms_system to system;

- DBMS_SYSTEM.set_sql_trace_in_session(sid, serial#, TRUE)
지정된 session에 대해 SQL trace를 실행하여 user_dump_dest parameter에 지정된 위치에 trace file이 생성된다.

- DBMS_SYSTEM.set_sql_trace_in_session(sid, serial#, FALSE)
지정된 session에 대한 SQL trace를 해제한다.

[예제] system user에서 scott user를 지정하여 SQL trace 생성하기.

sqlplus system/manager

SQL> select sid, serial#
from v$session
where username = 'SCOTT';

SID SERIAL#
--------- ---------
8 12

SQL> exec sys.dbms_system.set_sql_trace_in_session(8, 12, TRUE);

-> scott user에 대한 SQL trace가 실행된다.

SQL> exec sys.dbms_system.set_sql_trace_in_session(8, 12, FALSE);

-> scott user에 걸린 SQL trace가 해제된다.

==> 위와 같이 trace 처리된 내역은 DBMS가 설치된 server의 user_dump_dest 경로에 trc 파일로 생성됩니다.

이렇게 해서 생성된 trace 파일을 TKPROF를 이용하여 가독이 용이한 형태로 내용을 변환하여 확인하면 됩니다.

ex) tkprof '원본파일' '변환파일' [option] sys=no aggregate=no explain=계정ID/계정PWD
--> tkprof C:\oracle\admin\orcl\udump\orcl_ora_3012.trc c:\test.text sys=no aggregate=no explain=scott/tiger

SQL 튜닝, 대기현상(내부 매커니즘)을 분석 할때 사용하는 툴

즉, 개발환경에서 문제없이 수행 되는 SQL 문장이 운영환경에서 느린 성능을 보이는 경우 SQL Trace 를 이용하면 원인 분석이 가능하다.

10046 이벤트를 사용하며 4가지 레벨로 제어 한다

LEVEL 1 : SQL 문장의 실행정보(Parse, Execute, Fetch 단계와 Row source operation 결과)만을 제공한다

LEVEL 4 : LEVEL 1 + 바인드 변수값을 제공한다

LEVEL 8 : LEVEL 1 + 대기정보를 제공한다

LEVEL 12 : LEVEL 4 + LEVEL 8, 즉 SQL 문장의 실행정보와 바인드 변수 값, 대기정보를 제공한다

현재 세션 Trace

SQL> ALTER SESSION SET sql_trace=TRUE; -- trace file 시작
SQL> ALTER SESSION SET sql_trace=FALSE; -- trace file 종료

SQL> ALTER SESSION SET EVENTS '10046 trace name context forever, level 12';
SQL> ALTER SESSION SET EVENTS '10046 trace name context off';

다른 세션 Trace

- dbms_system 사용

SQL> EXEC DBMS_SESSION.set_sql_trace(sql_trace => TRUE);
SQL> EXEC DBMS_SESSION.set_sql_trace(sql_trace => FALSE);

SQL> EXEC DBMS_SYSTEM.set_sql_trace_in_session(sid=>123, serial#=>1234, sql_trace=>TRUE); --sql trace 입장
SQL> EXEC DBMS_SYSTEM.set_sql_trace_in_session(sid=>123, serial#=>1234, sql_trace=>FALSE);

SQL> EXEC DBMS_SYSTEM.set_ev(si=>123, se=>1234, ev=>10046, le=>8, nm=>' '); -- 이벤트 입장

SQL> EXEC DBMS_SYSTEM.set_ev(si=>123, se=>1234, ev=>10046, le=>0, nm=>' '); -- nm은 name이다.

--SQL> exec dbms_system.set_ev(7, 10, 65535, 10, 'controlf');
--SQL> exec dbms_system.set_ev(8,1056,65535,10,'PROCESSSTATE');

- oradebug 사용

SQL> CONN sys/password AS SYSDBA; --반드시 sysdba 권한 유저로 실행
(SQL> ORADEBUG SETMYPID; -- Debug current session.)

or
SQL> ORADEBUG SETOSPID 1234; -- Debug session with the specified OS process.

or
SQL> ORADEBUG SETORAPID 123456; -- Debug session with the specified Oracle process ID.

SQL> ORADEBUG unlimit; -- Trace file 크기제한 無

SQL> ORADEBUG EVENT 10046 TRACE NAME CONTEXT FOREVER, LEVEL 12;
SQL> ORADEBUG TRACEFILE_NAME; -- Display the current trace file.

/u01/app/oracle/product/10.2.0/db_1/rdbms/log/dhdb_ora_10803.trc
SQL> ORADEBUG EVENT 10046 TRACE NAME CONTEXT OFF;

10g 부터 SQL Trace 로 캡쳐 불가능한 작업을 dbms_monitor 패키지를 사용하여 Client ID, Service/Module/Action 등을 Trace 할 수 있다

이때, 여러 개의 세션에 대한 Trace 파일이 생성되며, trcsess 툴을 이용해 하나의 Trace 파일로 만들 수 있다

exec dbms_monitor.client_id_trace_enable(client_id=>'12345', waites=>true, binds=>true);

exec dbms_monitor.serv_mod_act_trace_enable(123456);

exec dbms_monitor.session_trace_enable(1234567);

또한, dbms_monitor 패키지를 이용하면 세션이 아닌 Client ID 나 Service/Module/Action 명을 기준으로 통계정보(Statistics)를 수집 할 수 있다

client_id_stat_enable, serv_mod_act_stat_enable 을 통해 수집된 정보는 V$CLIENT_STATS, V$SERV_MOD_ACT_STATS 뷰를 통해 관찰 가능하다

cf.alter session set events 'immediate trace name controlf level 10; --> 이 경우는 event 번호가 없으므로 name으로 trace를 생성한다.

=====================================================

출처 및 참고자료 : Advanced Oracle Wait Interface in 10g

=====================================================

special thank's to eddy

TECH: SQL*Net V2 on Unix - A Quick Guide to Setting Up Client Side Tracing [ID 16564.1]
		Modified 20-OCT-2005 Type REFERENCE Status PUBLISHED

( For a more detailed discussion of SQL*Net V2 tracing see Note:16658.1 )

Client Tracing
~~~~~~~~~~~~~~
1) Set the environment variable TNS_ADMIN to the directory where the 
   tnsnames.ora and listener.ora files exist.

   The default location is $ORACLE_HOME/network/admin. Set $TNS_ADMIN to this
   if it is not set. This ENSURES you know which files you are using.

2) Start the listener:          lsnrctl
                                > set password <password>
                                > start

   Note any errors. If you do not have a password set then ignore the 
   set password command.

3) If the listener started, start the database.

4) Create a file in $HOME called .sqlnet.ora and add the lines:

        trace_level_client= 16
        trace_file_client=client
        trace_directory_client= /tmp            (or similar)
        trace_unique_client=true

5) Try to connect from SQL*Plus thus:

        sqlplus username/password@alias

   or
        sqlplus username/password

   substituting a suitable alias.

6) If you get an error we may need to see the client trace file
   /tmp/client_<PID>.trc where <PID> is the process ID of the 
   client process (*1).
   This will be quite large so it is best to FAX or EMAIL it.

*1 Note: On earlier versions of SQL*Net the filename may NOT have
         the process ID appended to it.


Listener Tracing:
~~~~~~~~~~~~~~~~~

1) Edit your $TNS_ADMIN/listener.ora file and add the lines:

        TRACE_LEVEL_LISTENER     = 16    
        TRACE_DIRECTORY_LISTENER = /tmp
        TRACE_FILE_LISTENER      = "listener"   

2) Stop and restart the listener:

        lsnrctl stop
        lsnrctl start

   Output should go to /tmp/listener.trc

In this Document
  Goal
  Solution
     Launch the Net Manager utility
     Enabling Oracle Net Client / Server tracing (or both).
      Enabling Oracle SQLNet Listener tracing.
     Cyclic Tracing
     Tracing Kerberos
     Tracing Externel Procedures (Extproc)
     Tnsping Trace
     Enabling Dynamic Listener Tracing
     Only for 11g
  References

---

Applies to:

Oracle Net Services - Version: 9.2.0.1.0 to 10.2.0.2.0
Information in this document applies to any platform.

Goal

This document covers how to use Oracle Net Manager tool to enable Oracle SQLNet Client, Server, Listener, Kerberos and External Procedure tracing.  It also includes how to control the size and amount of trace files produced and steps to start dynamic listener tracing.

Solution

Launch the Net Manager utility

 

Windows : Go to Start button, select the Oracle Home on which we are going to generate the tracing for. Net Manager is located under 'Configuration and Migration Tools' of the Oracle Home menu.

Unix : The tool can also be started remotely from a Microsoft Windows system with the help a terminal emulation software. You need to ensure this software is up and running first.  Ensure that the $DISPLAY, $ORACLE_HOME, and $PATH environment variables are properly set. The Net Manager tool is started by the command "netmgr".

 

 

Enabling Oracle Net Client / Server tracing (or both).

 

A. Click on Profiles in the left panel. The right panel of Net Manager will now show more details.

B. Select General from drop down menu on the right panel of the Net Manager.

C. Select Tracing tab in the right panel. Client Information and Server Information is now seen.

D. Select the required Trace Level. Oracle Support usually requests level SUPPORT (also known as level 16). It is optional to provide a value for the Trace Directory and Trace File. If you do,  ensure that the directory exists and that the owner of the Oracle software is able to write to that directory. The default location for the trace files is the $ORACLE_HOME/network/trace directory. Default name is CLI.TRC

The Unique Trace File Name option for the Client Information section, will make unique trace files for every connection. Without this option selected, all client tracing goes into the one file.  If running Microsoft Windows, always set this parameter or there is the potential that the trace file with the error will be overwritten.  The Server does not have this parameter available.

E. If tracing is to be done on the Server and the connection model is Shared Server, then the Instance will have to be restarted for the Dispatchers to pick up the changes to the SQLNET.ORA file.

The SQLNET.ORA will now look like the following :

 Enabling Oracle SQLNet Listener tracing.

A. In the left panel of the Net Manager, select Listeners view.

B. Select the Listener you want to trace. Once selected the right hand panel will show more details.

C. Select General Parameters from the drop down button, in the right hand panel.

D. Select Logging & Tracing tab.

E. Click the Tracing Enabled radio button and select Trace Level. SUPPORT level is normally requested by Oracle Support.

Select a directory for the trace to be generated.

G. Listener will need to be restarted or reloaded to enable or disable tracing.
 

 

The LISTENER.ORA will now have the following lines.

Cyclic Tracing

Adding parameters TRACE_FILENO_ and TRACE_FILELEN_ to the SQLNET.ORA or LISTENER.ORA files enables Oracle Net trace files to be limited a certain size and a certain number of files. Following example is for Listener traces of 10 MB, with a maximum of 10 files for a maximum of 100 Mb of trace files. Cyclic tracing can be configured for the Client, Server and Listener

TRACE_FILENO_{CLIENT/SERVER/listener_name}: When this parameter is set it will determine the maximum number of trace files that will be generated. Trace data will continue to generate but in a cyclic fashion. The maximum size of each file is set by configuring the appropriate TRACE_FILELEN parameter.

TRACE_FILELEN_{CLIENT/SERVER/listener_name}: When set determines the maximum size of each trace file before either starting a new trace file (if the TRACE_FILENO parameter is set) or will overwrites an existing file (cyclic tracing). Once the last trace file has been written, up to the size specified by TRACE_FILELEN_<CLIENT/SERVER/listener_name>, tracing will continue by overwriting the first trace file in the cycle.

Tracing Kerberos

Kerberos can be traced using the following parameters in the SQLNET.ORA file.
See Note 185897.1 Kerberos Troubleshooting Guide for more details.

 

Tracing Externel Procedures (Extproc)

External procedure can be traced using the following parameter in the SQLNET.ORA file, where extproc is setup.

 

Tnsping Trace

 

Enabling Dynamic Listener Tracing

There might be situations when you cannot reload or restart the listener to enable the traces.Such times, you can fmake use of the dynamic tracing for the listener .

This would create sqlnet support level tracing on the listener under directory /home/oracle with name listener.trc

Only for 11g

11g has new method of tracing Automatic Diagnostic Repository(ADR)  which will create the trace to the ADR directories
Reference
Note 454927.1Using and Disabling the Automatic Diagnostic Repository (ADR) with Oracle Net for 11g

To create the trace files to the desired directory,
For client tracing & server tracing add:


For listener tracing:

Unable to start Net Manager

If Net Manager is unable to start, check that you are able to launch other GUI tools from the same server, where Net Manager is failing. For example the X-Window utility "xclock". If you are not able to launch xclock, you need to address this problem, before attempting to start Oracle GUI tools. If xclock works, check other Oracle GUI tools, like DBCA before reporting the issue to Oracle Support.

References

NOTE:374116.1 - How to Match Oracle Net Client and Server Trace Files
NOTE:454927.1 - Using and Disabling the Automatic Diagnostic Repository (ADR) with Oracle Net for 11g

---

In this Document
  Goal
  Solution
  References

---

Applies to:

Oracle Net Services - Version: 9.2.0.1.0 to 11.2.0.1 - Release: 9.2 to 11.2
Information in this document applies to any platform.
Checked for relevance on 7-MAY-2010.

Goal

When attempting to limit the amount of trace generated when TNS listener tracing is enabled, cyclic tracing can be used. But to further restrict the amount of time TNS listener is enabled, tracing can be enabled and disabled, dynamically via the listener control, lsnrctl. This means tracing can be enabled only when required and allows the listener to run without generating trace until required.But when enabled via this method, Time stamp is missing from the trace file(s) generated. The following steps explain how to workaround the time stamp restriction.

Solution

To workaround the current restriction of TNS listener tracing enabled via listener control, generating traces without time stamp, the following steps can be used. Steps 1 to 3 must be inplaced before attempting to capture any problem with tracing.

 1. Backup the Listener.ora file, add the following parameters and save.

TRACE_LEVEL_<Listener Name> = 16
TRACE_FILE_<Listener Name> = <File Name>
TRACE_DIRECTORY_<Listener Name> = <Directory>
TRACE_TIMESTAMP_<Listener Name> = ON
TRACE_FILELEN_<Listener Name> = <Size in KiloBytes>
TRACE_FILENO_<Listener Name> = <Number>

TRACE_FILELEN and TRACE_FILENO are the cyclic tracing parameters.Ensure values used for these are large enough to capture information,without being overwritten.

2.Reload the listener, with command lsnrctl reload <listener name>

With a default listener name of "listener", the listener name can be excluded from commands.

3. Stop listener tracing, run set trc_level 0 via lsnrctl

If your listener name is not using the default name of "listener", then run command "set current_listener <listener name> in listener control, before any other command is used.

4. When TNS listener tracing is required to be re-enabled. run set trc_level 16 via lsnrctl.

 
5. Turn off tracing as soon as the problem / issue has been captured with command "set trc_level 0" from lsnrctl. (As per step 3). Remove or hash out the parameters added to the listener.ora in Step 1 and run reload command. This will stop tracing from being re-activated.

UNIX: EXAMPLE OF TURNING ON LISTENER TRACE
==========================================

PURPOSE

---

RDBMS Manual, Oracle Note에서 Oracle Net Listener Trace File 생성 방법을
설명하고 있으나 실예가 고객에 이해를 돕는데 유용하여
아래와 같이 그 실제 상황에 가까운 예를 적습니다.

Explanation

---

Example

---

listener trace를 생성하는 절차는 다음과 같습니다.

a. 문제가 발생하는 database server에서:
prompt$ echo $TNS_ADMIN

b. TNS_ADMIN 환경 변수가 설정되어 있으면
prompt$ cd $TNS_ADMIN

설정되어 있지 않으면
prompt$ cd $ORACLE_HOME/network/admin

prompt$ vi listener.ora
...
TRACE_LEVEL_<listener name>=16
TRACE_FILE_<listener name>=<filename>
TRACE_DIRECTORY_<listener name>=<directory>
TRACE_TIMESTAMP_<listener name>=ON
:wq
prompt$ lsnrctl stop <listener name>
prompt$ lsnrctl start <listener name>

Production 환경에서 trace file로 인한 disk full 없도록 trace file을 재사용할 수도 있습니다.

TRACE_LEVEL_<listener name>=16
TRACE_FILE_<listener name>=<filename>
TRACE_DIRECTORY_<listener name>=<directory>
TRACE_TIMESTAMP_<listener name>=ON
TRACE_FILENO_<listener name>=<# of trace files to switch>
TRACE_FILELEN_<listener name>=<length of each trace file in KB>

예)
TRACE_LEVEL_listener1=16
TRACE_FILE_listener1=listener1
TRACE_DIRECTORY_listener1=/u01/app/oracle/rdbms/10.2.0/network/trace
TRACE_TIMESTAMP_listener1=ON
TRACE_FILENO_listener1=3
TRACE_FILELEN_listener1=1024768

3. Reproduction
문제 발생 후 trace를 중단 하시기 바랍니다.

4. Stopping Oracle Net listener Tracing:
prompt$ vi listener.ora
...
TRACE_LEVEL_listener=0
...
:wq
prompt$ lsnrctl stop <listener name>
prompt$ lsnrctl start <listener name>
prompt$

4. Listener가 내려간 동안은 기존의 database session들은
Oracle Server Process의 의하여 계속 처리가 됩니다.
새로운 database connection request는 listener가 내려간 동안
처리되지 않아 그 동안 client는 database에 연결할 수 없습니다.

5. TAR를 통한 진행 중에는 생성된 Oracle Net Server Trace file들을
WinZip 또는 Unix의 compress (.tar.Z), GNU zip (tar.gz)으로
묽어 올려주시기 바랍니다.

6. TAR를 통한 진행 중에는 문제가 발생한 시:분도 같이 알려 주시면
Net engineer가 Trace 중에 해당 시간에 기록된 내용을 중심으로 보게 됩니다.

Reference Documents

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>