Oracle 19c 블로킹 세션 진단: V$SESSION·V$LOCK으로 안전하게 조치하는 순서

Oracle 19c에서 화면이나 배치가 멈췄다면, 기다리는 세션부터 종료하지 말고 V$SESSION의 블로킹 정보로 대기 체인을 먼저 확인해야 합니다. BLOCKING_SESSION_STATUS = 'VALID'인 행이 직접 블로커를 가리키며, 여러 단계의 대기라면 FINAL_BLOCKING_SESSION이 끝단 후보를 보여 줍니다.

이 글은 Oracle Database 19c 단일 인스턴스와 RAC를 대상으로 합니다. ALTER SYSTEM KILL SESSION은 마지막 수단입니다. 활성 트랜잭션은 롤백되고, 네트워크 I/O나 롤백 중인 세션은 바로 끊기지 않을 수 있으므로 업무 소유자와 영향을 확인한 뒤 실행합니다.

적용 조건과 영향 범위

먼저 대기 체인을 좁힌다

V$SESSION의 블로킹 열은 세션 대기를 따라가며 계산됩니다. 직접 블로커와 최종 블로커를 분리해 보면, 단순히 가장 오래 기다린 세션이 아니라 실제로 해소해야 할 세션을 찾기 쉬워집니다.

진단 SQL

목적: 현재 대기 중인 사용자 세션과 직접·최종 블로커를 한 번에 확인합니다. 적용: Oracle 19c. 권한: 일반적으로 V$SESSION 조회 권한이 필요합니다. 예상 결과: 블로커 정보가 확정된 행은 두 상태 열이 VALID로 표시됩니다.

SELECT s.sid,
       s.serial#,
       s.username,
       s.status,
       s.event,
       s.seconds_in_wait,
       s.blocking_instance,
       s.blocking_session,
       s.final_blocking_instance,
       s.final_blocking_session
  FROM v$session s
 WHERE s.type = 'USER'
   AND s.blocking_session_status = 'VALID'
 ORDER BY s.seconds_in_wait DESC;

RAC에서는 같은 열을 GV$SESSION에서 조회하고 INST_ID를 함께 보관합니다. 최종 블로커가 다른 인스턴스에 있을 수 있으므로, 로컬 SID만으로 종료 명령을 만들면 안 됩니다.

락과 업무 대상을 함께 확인한다

세션 대기 정보만으로는 어떤 락이 걸렸는지 충분하지 않을 때가 있습니다. 아래 조회는 요청 중인 락과 이미 보유한 락을 분리해서 봅니다. REQUEST > 0은 획득을 기다리는 쪽이고, LMODE > 0은 보유 중인 쪽입니다.

작업 전 확인표

SELECT l.sid,
       l.type,
       l.id1,
       l.id2,
       l.lmode,
       l.request,
       l.ctime,
       l.block
  FROM v$lock l
 WHERE l.lmode > 0
    OR l.request > 0
 ORDER BY l.type, l.id1, l.id2, l.request DESC;

목적: 락 보유·요청 관계를 보조 증적으로 확인합니다. 적용: Oracle 19c. 권한: 일반적으로 V$LOCK 조회 권한이 필요합니다. 예상 결과: 보유 락은 LMODE, 대기 락은 REQUEST에 0보다 큰 값이 나타납니다. 숫자 6은 배타 모드이며, 숫자만 보고 위험도를 단정하지 말고 세션·업무 정보를 함께 판단합니다.

종료는 증적을 남긴 뒤 마지막에 한다

목적: 검토가 끝난 특정 세션을 종료합니다. 적용: Oracle 19c 단일 인스턴스. 권한: ALTER SYSTEM 권한이 필요합니다. 예상 결과: 세션이 종료되면 활성 트랜잭션은 롤백되고, 보유한 리소스가 해제됩니다.

ALTER SYSTEM KILL SESSION '123,45678';

RAC에서는 GV$SESSION.INST_ID로 인스턴스를 확인한 뒤 해당 인스턴스 정보를 포함한 구문을 사용합니다. 네트워크 I/O 또는 롤백 중인 활성 세션은 즉시 끝나지 않을 수 있으며, Oracle은 일정 시간 뒤 세션을 종료 대상으로 표시할 수 있습니다. 종료 명령을 반복해서 보내지 말고 V$SESSION 상태와 대기 체인을 다시 조회합니다.

실행 후 검증과 롤백 경계

세션 종료 자체를 복구 절차로 오해하면 안 됩니다. 종료된 세션의 미커밋 변경은 Oracle이 롤백하며, 애플리케이션 차원의 재시도·중복 요청·후속 배치 상태는 별도로 점검해야 합니다.

SELECT s.sid,
       s.serial#,
       s.status,
       s.event,
       s.blocking_session_status,
       s.final_blocking_session_status
  FROM v$session s
 WHERE s.type = 'USER'
   AND s.blocking_session_status = 'VALID'
 ORDER BY s.seconds_in_wait DESC;

목적: 조치 뒤에도 블로킹 대기가 남았는지 확인합니다. 적용: Oracle 19c. 권한: V$SESSION 조회 권한이 필요합니다. 예상 결과: 해소된 대기 체인은 결과에서 사라지거나 블로킹 상태가 더 이상 VALID가 아닙니다. 남아 있다면 다음 체인의 최종 블로커와 락 근거를 새로 수집합니다.

자주 하는 실수

• 가장 오래 대기한 세션을 먼저 종료한다. 대기자는 피해자일 수 있습니다.
• SID만 기록하고 SERIAL#를 생략한다. SID는 재사용될 수 있으므로 종료 직전 두 값을 다시 확인해야 합니다.
• RAC에서 인스턴스를 생략한다. GV$SESSION의 INST_ID를 함께 확인합니다.
• 세션 종료 뒤 업무 재시도만 하고 롤백·중복 처리 여부를 확인하지 않는다.

마무리

블로킹 장애의 첫 조치는 종료가 아니라 체인 확인입니다. V$SESSION으로 직접·최종 블로커를 찾고, V$LOCK으로 락 관계를 확인한 뒤, 업무 영향과 롤백을 감당할 수 있을 때만 세션을 종료합니다.

공식 출처

• Oracle Database Reference: V$SESSION
• Oracle Database Reference: V$LOCK
• Oracle Database Administrator’s Guide: Terminating Sessions