API가 DB에서 데이터를 조회하는데, 데이터의 양 때문에 혹은 여러 이유로 시간이 오래 걸리는 경우가 있다. (없는게 베스트이겠지만..)
만약 그런 경우 해당 API를 반복해서 호출하는 경우 Lock이 걸리게 되고, API가 영영 끝나지 않을 수 있다.
그렇다면 급히 Lock 걸린 프로세스 세션을 강제로 종료해야하는 경우가 있을텐데 그때 사용할 수 있는 방법이다.
Lock이 걸린 프로세스 세션을 강제로 종료하려면...
총 3개의 명령어로 Lock을 확인 및 처리할 수 있다. (명령어는 모두 SQL Server에서 실행할 수 있다.)
1. exec sp_lock;
Lock이 걸린 프로세스 세션 목록을 보여준다.
spid: 프로세스 세션의 id이다.
ObjId: 프로세스 세션에서 참조하고 있는 테이블의 고유 ID이다.
Lock이 걸린 프로세스 세션의 특징은 다음과 같다.
- 동일한 spid를 지니는 row가 2개 이상 존재하는 경우
- 동일한 spid를 지니는 row들을 묶었을 때, 각 집합이 유사한 ObjId들을 지니고 있는 경우
위 특징을 지닌 spid들의 값을 복사한 뒤, 다음 명령어를 통해 어떤 쿼리를 실행하는 프로세스 세션인지 확인한다.
2. dbcc inputbuffer(spid);
- 예시. dbcc inputbuffer(9999);
해당 spid가 어떤 쿼리를 실행 중인지 보여주는 명령어다.
1번 명령어를 통해 확인한 spid 값들을 각각 2번 명령어의 괄호에 넣어줘서 실행한다.
Lock을 유발하는 쿼리들의 특징은 다음과 같다.
- SELECT로 시작하는 쿼리로 FROM절에 포함된 테이블의 사이즈가 큰 경우
해당 쿼리들을 실행하는 spid들은 Lock이 걸린 프로세스 세션일 가능성이 높다.
3. kill spid;
- 예시. kill 9999;
해당 spid로 실행중인 프로세스 세션을 강제로 종료하는 명령어다. 이 때, 반드시 spid를 잘못 입력하지 않도록 주의해야 한다.
프로세스 세션을 강제로 종료하게 되면, 1번 명령어를 재실행했을 때 해당 spid의 상태가 초기화된 것을 확인할 수 있다. (즉, 같은 spid를 지니는 row가 하나 밖에 없는 상태)
Lock이 걸린 프로세스 세션을 모두 종료했다면, 해당 API를 재호출해서 평상시와 비슷한 속도로 응답이 온다면 성공적으로 Lock들을 처리한 것이다.
예시)
