--- Problem
사용자는 다음과 같은 상황에서 session 을 kill 하려는 시도를 하게 된다.
1. os 에는 process 가 존재하지 않지만, v$session 에는 active 로 존재하고 있을 경우
2. shadow process 는 살아 있는데, client machine 을 rebooting 한 경우
3. session 이 걸고 있던 lock 을 release 해야 할 경우
4. OS 나 Oracle 의 자원을 지나치게 많이 사용하여 성능을 저하시키는 process
2. shadow process 는 살아 있는데, client machine 을 rebooting 한 경우
3. session 이 걸고 있던 lock 을 release 해야 할 경우
4. OS 나 Oracle 의 자원을 지나치게 많이 사용하여 성능을 저하시키는 process
그런데, alter system kill session ('sid, serial#'); 후에 다음과 같은 에러가 발생할 경우가 있다.
ORA-00030: User session ID does not exist.
// *Cause: The user session id no longer exists, probably because the
// session was logged out.
// *Action: Use a valid session ID.
// session was logged out.
// *Action: Use a valid session ID.
--- 원인과 대책
kill session을 할 수 없는 이유는 PMON이 이미 이 session을 delete하고 있는 중이기 때문이다.
즉, PMON 이 dead session 을 clean-up 하고 있는 중에는 serial number의 값이 증가한다.
문제는 PMON이 process를 kill하는 시간인데, transaction의 크기에 따라, PMON의 rollback 시간이 결정된다.
먼저 PMON은 dead process를 찾아내어, 이 process가 사용한 resource를 release하는 시도를 한다.
PMON은 계속 이 작업을 시도하다가 마침내, free buffer의 부족으로 더 이상 resource를 free-up 하지 못하게 된다.
이 때, 이 process를 delete하고 있다는 message를 trace file에 출력하는데, 이것은 process를
delete하는 데
필요한 resource(data cache 내의 free buffer)의 부족으로 위의 작업이 지연되고 있다는 의미이다.
PMON이 process 를 clean-up 할 때 걸리는 시간은, 5분에서 24 시간까지 소요 될 수 있다.
문제는 이 process가 hold 하고 있는 lock으로 인해 특정 작업이 수행되지 못하는 데 있다.
MTS 를 사용할 때는 configuration MTS setting, sqlnet.expire_time 사용)에 따라 다르지만,
clean-up 작업을 하는데 72 시간이 소요된 경우도 있다.
아직까지는 PMON이 작업을 마칠 때까지 기다리는 방법 또는 db를 restartup하는 방법 밖에는 없다.
즉, PMON 이 dead session 을 clean-up 하고 있는 중에는 serial number의 값이 증가한다.
문제는 PMON이 process를 kill하는 시간인데, transaction의 크기에 따라, PMON의 rollback 시간이 결정된다.
먼저 PMON은 dead process를 찾아내어, 이 process가 사용한 resource를 release하는 시도를 한다.
PMON은 계속 이 작업을 시도하다가 마침내, free buffer의 부족으로 더 이상 resource를 free-up 하지 못하게 된다.
이 때, 이 process를 delete하고 있다는 message를 trace file에 출력하는데, 이것은 process를
delete하는 데
필요한 resource(data cache 내의 free buffer)의 부족으로 위의 작업이 지연되고 있다는 의미이다.
PMON이 process 를 clean-up 할 때 걸리는 시간은, 5분에서 24 시간까지 소요 될 수 있다.
문제는 이 process가 hold 하고 있는 lock으로 인해 특정 작업이 수행되지 못하는 데 있다.
MTS 를 사용할 때는 configuration MTS setting, sqlnet.expire_time 사용)에 따라 다르지만,
clean-up 작업을 하는데 72 시간이 소요된 경우도 있다.
아직까지는 PMON이 작업을 마칠 때까지 기다리는 방법 또는 db를 restartup하는 방법 밖에는 없다.
--- PMON 의 작업
PMON은 network failure 나 기타의 원인으로 생긴 old process connection을 clean-up 하는 역할을 한다.
그런데, PMON 은 clean-up 해야 하는 connection 중에 정해진 개수 만큼의 transaction 을 rollback 할 수 있는데,
이 값은 initSID.ora 의 cleanup_rollback_entries(default = 20) 에 의해 결정된다.
예를 들어, 1000 개의 uncommitted update가 있다면, 일정한 시간마다 cleanup_rollback_entries
의 개수 만큼의
record 만 rollback 할 수 있으므로 이 작업 동안에 lock 은 그대로 유지된다.
PMON 은 위의 작업 이외에 DB maintenance 역할이 있으므로, 위의 rollback 이 비교적 빠르게 처리되지 못할 수도 있다.
이러한 rollback을 빠르게 처리하기 위하여 cleanup_rollback_entries 를 늘릴 수도 있다.
그러나, 그 만큼 일정시간 동안 PMON 의 작업이 많아지게 되므로, 다른 사용자들의 작업 요청이 느려지게 되는
trade-off 가 있으므로, 신중히 고려한 후에 수정하는 것이 바람직하다.
alter system kill session 에 의해서도 위와 같이 rollback 이 이루어지는데, 이 session 이 완전히 clean-up 되기
전까지 v$session, v$process에 남아 있게된다.
그런데, PMON 은 clean-up 해야 하는 connection 중에 정해진 개수 만큼의 transaction 을 rollback 할 수 있는데,
이 값은 initSID.ora 의 cleanup_rollback_entries(default = 20) 에 의해 결정된다.
예를 들어, 1000 개의 uncommitted update가 있다면, 일정한 시간마다 cleanup_rollback_entries
의 개수 만큼의
record 만 rollback 할 수 있으므로 이 작업 동안에 lock 은 그대로 유지된다.
PMON 은 위의 작업 이외에 DB maintenance 역할이 있으므로, 위의 rollback 이 비교적 빠르게 처리되지 못할 수도 있다.
이러한 rollback을 빠르게 처리하기 위하여 cleanup_rollback_entries 를 늘릴 수도 있다.
그러나, 그 만큼 일정시간 동안 PMON 의 작업이 많아지게 되므로, 다른 사용자들의 작업 요청이 느려지게 되는
trade-off 가 있으므로, 신중히 고려한 후에 수정하는 것이 바람직하다.
alter system kill session 에 의해서도 위와 같이 rollback 이 이루어지는데, 이 session 이 완전히 clean-up 되기
전까지 v$session, v$process에 남아 있게된다.
--- ALTER SYSTEM KILL SESSION 을 하기 전에 ...
kill session 을 원할 경우는 다음의 순서대로 작업하는 것이 좋다.
1. kill the user process first
2. wait for 3 - 4 minutes
3. query v$session
4. if any information find in v$session, query v$lock
like
select count(*) from v$lock where SID ='sid';
2. wait for 3 - 4 minutes
3. query v$session
4. if any information find in v$session, query v$lock
like
select count(*) from v$lock where SID ='sid';
위의 count(*) 가 0 이 아니라면, 아직 PMON 이 rollback을 끝내지 못한 경우이므로 다시 얼마 후에 v$lock 을 조회하여
lock 의 개수가 감소하였는지 반복적으로 확인한다.
만약, 이 값이 전혀 변하지 않았다면, ALTER SYSTEM KILL SESSION 을 수행하고 v$session,
v$lock을 query 하여
변화가 있는지 확인하여 변화가 있다면, 좀 더 기다린다.
그래도, v$lock 의 count(*) 가 0 이 되지 않을 경우, 마지막으로 수행할 수 있는 유일한 방법은 instance 를 restartup 하는 것이다.
lock 의 개수가 감소하였는지 반복적으로 확인한다.
만약, 이 값이 전혀 변하지 않았다면, ALTER SYSTEM KILL SESSION 을 수행하고 v$session,
v$lock을 query 하여
변화가 있는지 확인하여 변화가 있다면, 좀 더 기다린다.
그래도, v$lock 의 count(*) 가 0 이 되지 않을 경우, 마지막으로 수행할 수 있는 유일한 방법은 instance 를 restartup 하는 것이다.
