Database system 운영 시 listener 관련 장애들은 크게 두가지입니다.
listener가 죽던지, 멍청하게 멈춰서 아무일도 못하든지..
다음은 listener가 멍청하게 멈춰서 아무일도 못하는 경우에 문제 해결을 위해 정보를 수집하는 방법입니다.
hang 문제가 발생하면 가장 손쉽게 접근할 수 있는 방법이 listener에 log를 설정해서 문제가 발생할 때 어떤 일이 있었는지를 확인하는 방법입니다.
하지만 문제가 언제쯤 발생할지 모르는 상태라면 log의 설정은 문제 발생 전까지 끊임 없는 관리가 필요합니다.
클라이언트에서 접속하는 모든 정보까지 log에 저장하게 되므로 관리해 놓지 않으면 나중에 log file을 vi로 열기도 힘들어 집니다.
따라서 매일 (혹은 몇일마다) listener log를 flush 하기 위해 listener restart(reload) 작업을 해주면서 log file을 관리해야 합니다.
다음의 방법은 log 설정하지 않고 문제가 발생하는 시점에 인지를 할 수 있다면 다소 유용할 수 있는 방법입니다.
즉, hang 상태가 발생했을때 어떤 O/S system call에서 멈춰있는지를 확인할 수 있는 두가지 방법입니다.
process의 stack 정보를 확인하는, PSTACK 명령과 GDB 명령입니다.
1. pstack <listener_pid>
2. gdb $ORACLE_HOME/bin/tnslsnr <listener_pid>
(gdb) info thread
(gdb) thread 1
(gdb) where
(gdb) 반복 (thread 숫자만큼)
(gdb) quit
위와 같이 수행하는 경우 listener가 어떤 call stack에서 멈춰있는지를 확인할 수 있습니다.
이렇게 call stack을 수집하는 이뉴는 발생한 문제가 이미 보고된 bug과 동일한 문제가 있는지의 확인이 쉽기 때문입니다.
만약 call stack으로 bug을 확인했을때 비슷한 문제가 없다면, 새로 분석을 진행해야 하니
listener log의 설정을 다시 요구할 수도 있습니다..만
* 여기저기서 좋다는 책 몇권 추천합니다. 고수가 되는 그날까지.. 파이팅!!
'Oracle Database' 카테고리의 다른 글
| oracle oradebug를 이용해 삭제된 trace file을 다시 만드는 방법 (0) | 2010.07.06 |
|---|---|
| Oracle optimizer statistic gathering 대상 Table 확인하는 script (0) | 2010.07.05 |
| Oracle Datafile 사용 공간 줄이기 (0) | 2010.06.29 |
| Oracle 11gR2 Grid Infrastructure Single Client Access Name (SCAN) .. 이건 또 뭐야? (3) | 2010.06.24 |
| Oracle v$session에서의 AUDSID column이 의미하는 것은 ? (0) | 2010.06.18 |