1. 덤프
덤프 : 일회성으로 그 순간의 상태정보를 가집니다.
트레이스 : 10046, 10053 등의 이벤트를 걸게 되면 순간의 상태(immediate) 또는
세션이 close될때까지의 정보(trace name context forever) 를 trace로
남깁니다.
참고로 udump 에 없다고 해서 고민하지 말구요. bdump를 찾아보세요.
background process를 이용해서 dump를 뜨는 경우에는 bdump에 나오겠죠.
2. 문제발생시 덤프 뜨는 방법
문제발생 세션에 대한 10046 event, truss output, errorstack dump
OS engineer의 system state dump
system state dump 2~3회
hang analyze dump 2~3회
system state dump 1~2회
hang analyze dump 1~2회
3. 에러스택 뜨기(꼭 수행할 때마다 exit나와서 다시 서버에 접속해서 뜰 것)
oradebug setospid XX
oradebug unlimit
oradebug dump errorstack 3
oradebug tracefile_name
또는
alter system set max_dump_file_size=unlimited;
alter session set tracefile_identifier='error1';
alter session set events 'immediate trace name errorstack level 3';
4. hanganalyze, systemstate dump 뜨기(꼭 수행할 때마다 exit나와서 다시 서버에 접속해서 뜰 것)
- systemstate dump는 database의 전반적인 hang이나 slow performance상황에 요구된다.
또한 데이터베이스 문제가 발생해서 재기동할 때에 , 추후 분석을 위해서 재기동 전에
적절한 systemstate dump를 확보한다.
보통 system state dump는 3~5분 간격으로 3번 수행을 권장하는데, 이 때 매번
새로운 접속을 해야 각각이 각각 다른 파일명으로 생성된다.
같은 세션에서 3번 수행하면, 한 파일에 이어서 생성된다.
- hanganalyze dump는 마찬가지로 hang이나 slow performance 상황에 사용된다.
그러나 hanganalyze dump는 리소스(latch/eueueue등등)을 점유하는 blocker를
보여주므로 , 이 blocker를 정리함으로 문제 해결에 접근할 수 있다.
oradebug setmypid
oradebug unlimit
oradebug hanganalyze 4
oradebug setmypid
oradebug unlimit
oradebug dump systemstate 10
또는
alter system set max_dump_file_size=unlimited;
alter session set tracefile_identifier='sys1';
alter session set events 'immediate trace name systemstate level 10';
alter system set max_dump_file_size=unlimited;
alter session set tracefile_identifier='hang1';
alter session set events 'immediate trace name hanganalyze level 4';
5. oradebug로 event 걸기(10046 event는 sql 트레이스 정보, 10053은 optimizer에 대한 트레이스 정보)
oradebug setospid XX
oradebug unlimit
oradebug event 10046 trace name context forever, level 12;
oradebug event 10053 trace name context forever, level 1;
oradebug tracefile_name
oradebug event 10046 trace name context off;
oradebug event 10053 trace name context off;
6. 문제가 있는 세션의 process state dump 뜨기
oradebug setospid <process ID>
oradebug unlimit
oradebug dump processstate 10
7. 특정 event가 발생할 경우에heap dump 뜨기 ( 4031 에러의 경우 )
init 파라미터에 event name 하나에 trace name을 여러개를 사용 할 경우 ; 를 붙임
init 파라미터에 여러개 event를 붙일 경우 : 을 사용함
event = "4031 trace name heapdump level 1;name errorstack level 3"
또는 sqlplus에서
alter session set events '4031 trace name heapdump level 1
;name errorstack level 3';
8. 연속적으로 event를 붙어 넣기
init 파라미터
event="10015 trace name context forever"
event="10046 trace name context forever, level 4"
또는
event="10015 trace name context forever:
10046 trace name context forever, level 4"
sqlplus 에서
alter session set events '10015 trace name context forever:
10046 trace name context forever, level 4';
9. alter session 명령으로 자신 세션에 event걸기(session 이 logout할때까지 수행됨)
alter session set timed_statistics=true;
alter session set max_dump_file_size=unlimited;
alter session set tracefile_identifier='10046evnt1';
alter session set events '10046 trace name context forever , level 12';
alter session set events '10053 trace name context forever , level 1';
alter session set events '10046 trace name context off';
alter session set events '10053 trace name context off';
10. 전체 시스템에 event 걸기
alter system set timed_statistics=true;
alter system set max_dump_file_size=unlimited;
alter system set tracefile_identifier='10046evnt1';
alter system set events '10046 trace name context forever , level 12';
alter system set events '10053 trace name context forever , level 1';
alter system set events '10046 trace name context off';
alter system set events '10053 trace name context off';
11. alter session 명령으로 ORA-4031 에러에 대한 event 걸기(immediate로 즉각 떨어지도록)
alter session set max_dump_file_size=unlimited;
alter session set tracefile_identifier='4031evnt1';
alter session set events '04031 trace name errorstack level 3';
alter session set events '04031 trace name systemstate level 10';
12. sqlplus 로 접속이 불가능할 경우 백그라운드 프로세스의 systemstate 덤프 뜨기
위험한 명령임, 서비스 중엔 사용금지, 문제 발생으로 DB를 내리기전에 수행
OS debuger를 사용하면 특정 process에게 특정 function을 호출하도록 할 수
있습니다. 이러한 점을 이용하면 ORACLE에서 systemstate dump를 요청할 때
사용하는 ksudss function을 호출할 수 있으며, 절차는 아래와 같습니다.
cf> dbx -> 유닉스에서 사용
gdb -> 리눅스에서 사용
1) 먼저 attach할 ORACLE process에 대한 OS PID를 알아 둡니다.
(여기서는 PMON process를 예를 들었습니다.)
$ ps -ef | grep $ORACLE_SID | grep pmon
aprdbms 1432 1 0 23:14:50 ? 0:00 ora_pmon_APR920U6
2) Pmon process에 debuger를 사용하여 attach합니다.
$gdb $ORACLE_HOME/bin/oracle 1432
3) Ksudss function을 호출합니다.
gdb) call ksudss (10)
4) Pmon은 ksudss를 호출하여 systemstate dump를 받게 됩니다.
attach한 process가 ksudss function call 요청을 받아 들이기 위해서는
system call을 수행 중에 있지 않아야 합니다.
13. Tracing Oracle Process 를 통해서 서버 프로세스 트레이스 확인
- os에서 어떻게 처리하고 있는지를 확인할 경우 사용
- DB를 내릴 것이 아니라면 background 프로세스에 실행하지 말것
- db가 내려갈 수 있으므로 프로세스에 대한 OS trace를 남기고자 할 경우에
세션을 죽이기 전에 수행하기
- where에 나온 부분에서 읽는 방법은 거꾸로 올라가며 읽어야 함
$dbx -a (프로세스id) 또는 gdb $ORACLE_HOME/bin/oracle 11270
(dbx) where
(dbx) detach
- 예>
PROD:/opt/oracle/product/9.2.0/network/admin$script dbx.log
Script started, file is dbx.log
PROD:/opt/oracle/product/9.2.0/network/admin$gdb $ORACLE_HOME/bin/oracle 11270
GNU gdb Red Hat Linux (5.3.90-0.20030710.40rh)
Copyright 2003 Free Software Foundation, Inc.
(gdb) where
#0 0xb71836e1 in fsync () from /lib/i686/libpthread.so.0
#1 0x09826f33 in skgfcfi ()
#2 0x082bf561 in ksfdcls ()
#3 0x08b669ea in kcflckf ()
#4 0x08b66bc3 in kcflbi ()
#5 0x00000003 in ?? ()
#6 0x0ae0bb44 in ?? ()
#7 0x00000010 in ?? ()
#8 0x565fa0cc in ?? ()
#9 0x00080002 in ?? ()
(gdb) detach
ctrl+c
$ script off
14. truss 남기기(db를 내리기 전에 OS에서 수행, 평상시 사용 금지) note 110888.1
(1) hp-ux 의 경우
$ tusc -afpo <output file> <pid> <executable>
(2) AIX 5L
$ truss -aefo <output file> <executable>
(3) LINUX
$ strace -fo <output file> <executable>
(4) solaris
$ truss -aefo <output file> <executable>
예) truss -o truss.txt -p (process pid)
truss -p (process id)
(5) sqlplus통해서 db기동시 에러가 날 경우(예를들어 ORA-27302 failure occured at skgxpvaddr9
truss를 이용해서 sqlplus 에 접속후를 truss 남기기
linux의 경우 strace -o truss.log sqlplus '/as sysdba' 이 명령으로 들어가기
-
$truss -o truss.log -fae sqlplus '/as sysdba'
sql> startup
ORA-27302 failure occured at skgxpvaddr9
...
$cat truss.log
15. 네트워크에 대한 클라이언트 trace 남기기
- 클라이언트에서 sqlnet.ora 파일에서
trace_level_client=16
trace_directory_client=c:\temp (윈도우)
log_directory_client=/tmp (유닉스)
16. dump, error , stack의 종류 및 최대 레벨
10046 event sql trace 남기기, level 12
10053 event 프로세스가 수행한 쿼리의 optimizer에 대한 정보, level 1
hanganalyze 시스템 hang이 걸렸을 경우 dump, level 4
errorstack 시스템 특정 에러 발생에 대해서 간단한 에러 정보 dump, level 3
systemstate dump 전체 시스템 상태에 대한 dump, level 10
heapdump 메모리 에러 발생시 heap영역에 대한 dump, level 3
17. event 종류
10046 sql trace 남기기, level 12는 bind변수 및 plan, tuning statistics 까지 출력
10053 optimizer에 대한 정보까지 출력, level 1 이 최대
10015 rollback segment를 분석 및 사용중지 하도록 하는 event
10233 index opereation 에서 corrupted index block을 skip하기
10061 disable SMON from cleaning temp segment(smon프로세스가 extent정리를 안하도록 설정)
10510 turn off SMON check to offline pending offline rollback segment
10511 turn off SMON check to cleanup undo dictionary
18. 10390 parallel execution
10390, 00000, "Trace parallel query slave execution"
// *Cause:
// *Action: set this event only under the supervision of Oracle development.
// trace level is a bitfield
//
// LEVEL ACTION
//---------------------------------------------------------------------------
// 0x0001 slave-side execution messages
// 0x0002 coordinator-side execution messages
// 0x0004 slave context state changes
// 0x0008 slave rowid range bind variables and xty
//
// 0x0010 slave fetched rows as enqueued to TQ
// 0x0020 coordinator wait reply handling
// 0x0040 coordinator wait message buffering
// 0x0080 slave dump timing
//
// 0x0100 coordinator dump timing
// 0x0200 slave dump allocation file numbers
// 0x0400 terse format for debug dumps
// 0x0800 Trace CRI random sampling
//
// 0x1000 Trace signals
// 0x2000 Trace PX granule operations
// 0x4000 Force compilation by slave 0
/
1. 10046 trace
2. v$ps_sesstat
3. systemstate dump
4. wait.sql
에 추가해서, 다음 정보도 있으면 분석에 큰 도움이 될 것입니다.
5. parallel query parent process (QC process) 및 그 child process (slave process)들에 대해 truss o
utput을 좀 받아주세요. slave process에 대해서는 적어도 3~4 개 정도는 truss를 받아주세요.
방법:
----
% truss -aef -o truss.out.<<qc_pid>> -p <<qc_pid>>
% truss -aed -o truss.out.<<slave_p id>> -p <<slave_pid>>
6. event 10390를 설정하여 둡니다.
방법:
-----
init parameter 화일에,
event = "10390 trace name context forever, level 1166"
* tuning point - parallel_execution_message_size
parallel_execution_message_size - QC 와 PQ slaves 들간의 message buffer에 대한 크기를 조정하는
parameter로 이 값이 크면 parallel execution에 대한 속도가 증가될 수 있
으나 memory 사용량은 증가하게 됩니다. 또한 경험적으로 이 값은 2K에서 4K나 8K 로 증가 시켰을 때 속도 개선이 10% 내외로 되었
으며 그 이상은 크게 변화가 없었습니다. 이 값을 변경하게 되면 large pool의 사용량이 증가 될 수 있으므로 peek time에 v$s
gastat를 monitoring하여 large pool의 free space가 부족하지 않은지 확인하여 보시기 바랍니다.
Ref. oralce 8i tuning manual
---------------------------------------
PARALLEL_EXECUTION_MESSAGE_SIZE
The recommended value for PARALLEL_EXECUTION_MESSAGE_SIZE is 4KB. If PARALLEL_AUTOMATIC_TUNING is TRUE, the default is 4KB. If PARALLEL_AUTOMATIC_T
UNING is FALSE, the default is slightly greater than 2KB.
The PARALLEL_EXECUTION_MESSAGE_SIZE parameter specifies the upper limit for the size of parallel exe
cution messages. The default value is operating system specific and this value s
hould be adequate for most applications. Larger values for PARALLEL_EXECUTION_ME
SSAGE_SIZE require larger values for LARGE_POOL_SIZE or SHARED_POOL_SIZE, depend
ing on whether you've enabled parallel automatic tuning.
While you may experience significantly improved response time by increasing the value for PARALLEL_EX
ECUTION_ MESSAGE_SIZE, memory use also drastically increases. For example, if yo
u double the value for PARALLEL_EXECUTION_ MESSAGE_SIZE, parallel execution requ
ires a message source pool that is twice as large.
Therefore, if you set PARALLEL_AUTOMATIC_TUNING to FALSE, then you must adjust the SHARED_POOL_SIZE to acco
mmodate parallel execution messages. If you have set PARALLEL_AUTOMATIC_TUNING t
o TRUE, but have set LARGE_POOL_SIZE manually, then you must adjust the LARGE_PO
OL_SIZE to accommodate parallel execution messages.
'ORACLE > TroubleShooting' 카테고리의 다른 글
shared pool (0) | 2014.03.23 |
---|---|
SHARED POOL에 대한 점검 사항들 (0) | 2014.03.23 |
11gR2 GI PSU Patch 적용 작업 시 공간 부족 에러 사례 (0) | 2013.05.30 |
2pc pending 처리 사용예 (Two Phase-Commit) (0) | 2012.12.06 |
Block corruption (0) | 2012.08.08 |