Oracle Database Hang 상태의 정의

1. What`s the problem ?

  • 현상 발싱시 상황 인지 시간 필요
  • 현상을 정의하기 어려움
  1. 누가 현상을 분석하는가?
  2. 무엇을 확인하는가?
  • Hang 현상으로 인해 상황 분석 불가
  • 문제 원인을 찾기 보다는 Application / DBMS를 re-startup
  • 2. Monitoring Oracle Continuously
    • 지속적으로 Instance의 동작 상태를 감시하고 logging
    • Performance를 중심으로 한 monitoring이 아닌 장애 인지 및 예방을 목적으로 한 monitoring 실시
    • 미리 정의된 비정상 상태(symptom)이 발생하면 자동으로 alarm, logging, dump 수행
    • 미리 정의된 dump 설정을 통해 상황을 최대한 기록
    • 지속적으로 비정상 조건 update
    3. 비정상 상태의 세션 발생 감시
    • 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으로 확인 할 수 있다.
  • 4. 공유 자원의 비 효율적 사용 감시 및 Leak 감시
    • V$SGASTAT : shared pool에 할당되는 메모리의크기를 표현하고있다.
      • Application의 목적과 동작 형태에 따라 특정 유형의 메모리 할당이지속적으로증가 할 수 있다. 또 code bug에 의한 memory leak이 발생 할 수 있다.
      • Permanent chunk가 지속적으로할당 될 경우, ORA-4031가 발생되며, 이는 instance crash의 원인이 될 수 있다.
      • 특정 유형의 memory(name)의 크기가 지속적으로 증가 한다. (시간 또는 일 비교)
      • 비 정상 상태  : ‘dictionary cache’ 와 ‘sql area’의 크기가 지속적으로 감소한다 
    • V$PROCESS : PGA_ALLOC_MEM은 process가 할당한heap의 크기이다.
      • 특정 상황에서 지속적인 메모리 할당으로 인해 ORA-4030이 발생할 수 있다. 
      • 발생할 수 있는 메모리 크기는 ulimit 과 physical memory에 따라 다르다. 
      • 비정상적으로 클 경우 pga heapdump를 기록한다.
      • 비 정상 상태  : PGA_ALLOC_MEM이 지정한 크기(1000M?)보다 크다.

    5. 비 정상 적인 transaction을 모니터링
    • 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.

    6. Sort segment 및 Enqueue 의 상태 감시
    • 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이상 지속 대기한다.  

    7. Instance 지표 검사
    • 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)’가 대량 발생 했는가?  

    8. Hardware monitoring
    • 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가 발생 한다. 
    9. Identifying a Problem
    • 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 발생시 신규 접속에 수분 이상 소요되기도 한다.

    By haisins

    오라클 DBA 박용석 입니다. haisins@gmail.com 으로 문의 주세요.

    답글 남기기

    이메일 주소를 발행하지 않을 것입니다. 필수 항목은 *(으)로 표시합니다