SESSION이 정리되는 과정에 대한 설명(SERIAL#, ORA-30)
===================================================

보통, lock 을 잡고 있는 session 을 강제 종료하기 위한 목적 등으로
'alter system kill session ... ' 문을 이용하고 있다.

그런데 이 과정에서 간혹,

alter system kill session 'sid, serial#' ;

을 수행하면 다음과 같은 error가 발생하며,

'ORA-30 user session ID does not exist'

v$session 의 serial# 을 조회하면 계속해서 그 값이 증가하는 경우가 있다.

이 경우 대부분은 'alter system kill session ...' 하기 전에
이미 OS level 에서 server process 가 kill 된 경우로서 pmon 이
해당 dead process 를 정리하면서 serial# 을 계속 증가시키는 경우이다.

따라서 v$session의 serial# 이 증가하는 경우는 우선, killed된 process에
대한 정리 작업이 종료될 때까지 기다리든지, 상황이 급하면 re-startup을
하여 정리를 하도록 해야 한다.

추가로, session 이 정리되는 과정을 다음과 같이 유형별로 나누어서
정리해 본다.

1. 'ACTIVE' session 을 'ALTER SYSTEM KILL SESSION ...' 으로
kill 하는 경우

1) v$session 의 status 는 바로 'KILLED' 로 변경되면서 정리 작업이
시작.

2) 일정 시간 동안(보통 2-3분) 정리 작업이 끝나지 못한다면
'ALTER SYSTEM KILL SESSION ...' 을 수행한 창에서는
'ORA-31 session marked for kill' 가 return된다.

3) 대상이 되는 session 이 모두 정리(transaction rollback 등)가 된
후에는 대상 session 에
'ORA-28 your session has been killed' 가 return 된다.

4) 이 시점에 v$session 에서 해당 session 에 대한 정보는 완전히
삭제된다.

5) 이 경우 해당 session 에서 진행 중이던 transaction 들에 대한
rollback 은 해당 server process 가 직접(background process 가
아닌)
진행하는 것으로 보임.
(다른 경우보다 rollback 속도도 무척 빠름)

2. 'INACTIVE' session 을 'ALTER SYSTEM KILL SESSION ...' 으로
kill 하는 경우

1) v$session 의 status 는 바로 'KILLED' 로 변경되면서 정리 작업이
시작.

2) 대상 session 에서 commit,rollback 하지 않은 transaction 이
있었다면 이들이 정리된다.

3) 이들 transaction 이 모두 정리된 후에도 v$session 의 해당
session 에 대한 정보는 없어지지 않고 남아 있게 된다.
('KILLED' 로 mark 된 채로)

4) 이후 client 에서 추가적인 action (SQL문 수행등)이 수행되는 시점에
'ORA-28 your session has been killed' 가 발생되면서
v$session 에서도 정보가 완전히 삭제됨.

5) 이 경우 해당 session 의 rollback 작업은 background process 가
담당하며 한번에 cleanup_rollback_entries 에 지정된 수 만큼의
row 에 대해서 rollback 이 이루어짐.
(db 전체적인 관리를 동시에 수행해야 하는 background process 가
rollback을 하는 관계로 rollback 진행 속도는 매우 느릴 수 있으며
이에 따라 lock 의 해제가 지연될 수 있다.)

3. OS prompt 에서 'kill -9 ...' 등으로 process 를 kill 한 경우

1) v$session 의 status 는 'KILLED' 로 mark 되지 않고 그대로 남아
있음.
('ACTIVE' 또는 'INACTIVE')

2) pmon 이 dead process 를 detect 한 이후 정리 작업이 진행되면서
v$session 의 serial# 은 계속해서 증가

3) 모든 정리 작업이 끝난 후 v$session 에서 해당 session 정보는
완전히 사라짐.

참조 - : 'KILL된 세션의 CLEAN-UP 작업 예상 시간
추정 방법'
1463 보기 태그: