Oracle DB Hang 상태

Oracle Database Hang 상태의 정의

1. What`s the problem ?

• 현상 발싱시 상황 인지 시간 필요
• 현상을 정의하기 어려움

1. 누가 현상을 분석하는가?
2. 무엇을 확인하는가?

Hang 현상으로 인해 상황 분석 불가

문제 원인을 찾기 보다는 Application / DBMS를 re-startup

• 지속적으로 Instance의 동작 상태를 감시하고 logging
• Performance를 중심으로 한 monitoring이 아닌 장애 인지 및 예방을 목적으로 한 monitoring 실시
• 미리 정의된 비정상 상태(symptom)이 발생하면 자동으로 alarm, logging, dump 수행
• 미리 정의된 dump 설정을 통해 상황을 최대한 기록
• 지속적으로 비정상 조건 update

• V$SESSION_WAIT : 모든 세션의 현재 대기 상태를 표현한 것으로 모니터링의 기준으로 삼기에 충분한 데이터를 표현하고 있다.
• 비 정상 상태  : PMON이 ‘pmon timer’ 상태며 seconds_in_wait이 증가하지 않는다.

1. Critical Wait Event가 30초 이상 지연되고 있다.
2. Normal Wait Event가 60초 이상 지연되고 있다.

5초 간격으로 active session의 wait event를 기록한다.

1. Critical Wait event : row cache lock, free buffer waits, library cache pin, log file sync, latch free 등
2. Normal Wait event : db file sequential read,SQL*Net message to client(or dblink) 등.
3. Idle wait event는 모니터링 제외
4. STATE가 ‘WAITING’인 것만을 대상

Wait event는 idle, non-idle로 논리적 구분할 수 있으며, 그 종류는 v$event_name으로 확인 할 수 있다.

• V$PROCESS : PGA_ALLOC_MEM은 process가 할당한heap의 크기이다.
• 특정 상황에서 지속적인 메모리 할당으로 인해 ORA-4030이 발생할 수 있다. 
• 발생할 수 있는 메모리 크기는 ulimit 과 physical memory에 따라 다르다. 
• 비정상적으로 클 경우 pga heapdump를 기록한다.
• 비 정상 상태  : PGA_ALLOC_MEM이 지정한 크기(1000M?)보다 크다.

• V$ROLLSTAT : RBS 의 30%를 차지하는undo가 존재하는지또 active transaction이존재하는지를 감시한다. 발생할 경우, 해당 세션의 정보를 기록한다.
• 비 정상 상태  : 특정 rollback(or undo)의 크기가 rbs의 30%를 초과하며 xacts가 0이 아니다.  

• V$TRANSACTION : Long transaction과large transaction을감시, 기록한다.
• 비 정상 상태  : START_TIME이 현재보다 60분 이전이다. USED_UBLK가 일정 수치 이상이다.  

• X$KTUXE : undo header이다. Dead transaction 및 비정상 상태의 transaction이 발생하는지 감시한다.
• 비 정상 상태  : KTUXESTA의 값이 ‘ACTIVE’ 이고, KTUXECFL이 ‘NONE’이 아닌 다른 값이다.  
• Dead transaction : ktuxesta = ‘ACTIVE’, ktuxecfl = ‘DEAD’
• Dead transaction 의 발생 원인: kill session, kill process.

• V$SORT_USAGE : Sort segment 할당이 매우 크고 지속적으로 커질 수 있다. 그 크기는 SQL에 따라 결정 되어예측이 불가능하다. 매우 커진다면, 그 작업이 정상인지점검할 필요가 있다
• 비 정상 상태  : BLOCKS가 일정 수치 이상이다.  

• V$LOCK : Lock request 상태가 30초 이상 지속될 경우 holder를 비정상 상태로 간주하고 세션 정보를 기록한다. Waiting하는 lock type이 ‘TX’, ‘TM’, ‘UL’이 아닌 경우, holder에 대해 errorstack을 dump한다.
• 비 정상 상태  : Lock request 상태가 30초 이상 지속(CTIME > 30) 지속된다. ‘TX’,’TM’,’UL’이 아닌 lock type에 대해 30이상 지속 대기한다.  

• V$SYSSTAT : Active transaction이 발생하는 production 의 ‘redo size’는 지속적 으로 증가 해야 한다. 
• LGWR 에 문제를 만난다면 증가하지 않을 수 있다.
• 평균 redo write시간은 Delta(redo write time)/Delta(redo writes) 이다.
• RAC : global cache blocks lost 와 corrupt은 0또는 0에 가까워야 한다. 다량 발생시 장애로 이어질 수있다.
• Hard parse의발생량은 초당 0회를 이상적으로하나 현실적으로불가능하다. 0에 가깝게 유지하는 것을 목표로 한다.
• 비 정상 상태  
• ‘redo entries’가 지속적으로 증가하지 않는다. 
• 평균 redo write 시간이 1초 이상 소요 된다.
• RAC : global cache blocks lost, corrupt 값이 증가 했는가?
• ‘Parse count(hard)’가 대량 발생 했는가?  

• Tnsping명령을 통해 listener가 정상적으로 응답하고 있는지 확인한다. Listener가 응답 한다고 session이 정상 연결되는것을 의미하지는않는다.
• Alert log는 bdump에 기록되지만, 세션 접속을 완료하지못한 상태에서는 ?/rdbms/log에 기록될 수있다. 양 쪽 모두를 계속 확인해야 한다.
• 주기적으로 ps 정보를 기록 : process의 status 도포함하도록한다.
• Sar 등 으로통해서 이미 기록되고 있을 것으로 예상.
• SYSTEM의 상태 정보 기록 : 일정간격으로 ‘ps’ 정보 기록 / CPU utilization , run queue length,Swa pinfo 등
• 비 정상 상태  

• tnsping  응답하지 않거나, 수초 이상 소요 된다
• ALert log에 log switch가 아닌 다른 log가 발생 한다. 

• Instance Crash : Alert log 확인
• Instance Hang : 신규 접속 불가 / V$VIEW 조회 불가 =접속 불가 현상이 반드시 instance hang을 의미하는 것 아니다. 많은 수의 경우 slowdown이다. 
• Session Hang(Spin) : Query에 대해 응답하지 않는 상태를 포괄적으로 말한다.
• Spin : 특정  process가 cpu를 100% 점유한다(Wait하는 event가 없다)
• 특정 process가 불특정 lock/resource를 점유 후 응답하지 않음.
• Process Spinning : process가 특정 코드를 반복 수행하며종료하지못해 CPU를 과다 점유하는 현상이다. Session hang의 현상 중 하나이다.
• Slowdown : long transaction등으로인해 block되는 session이발생하는 경우, 그 session이 점유하는 resource로 인해 새로운 session들이추가로 block되어 나갈 수 있다. 이렇게blocking이 확대되어지면 결국은 신규 접속이 허용되지 못할 수 있다.
• 시스템 자원의 고갈 또는 비정상 상태의 process 발생으로 인해 매우 느리게 진행되는 세션이 발생
• Very long transaction 또는 query로 인해 block 된 session이 다수 발생 할 경우
• 다수의 session이 busy하게 동작중인 instance에 DDL등이 요구되는 경우
• Slowdown 발생시 신규 접속에 수분 이상 소요되기도 한다.