새로운 업무간에 MS-SQL 로 운영하면서 느꼈던 점을 정리해본다.
1. 개발자가 운영디비 쿼리 select 시 noclok 으로 조회해야한다.
select 시 nolock없이 무거운 쿼리를 돌리면 운영중인 서비스에 치명적인 lock이 발생할수도 있으니, 조심해야함.
2. lock을 Kill했을때 관련이 없는 비지니스 로직까지 전부 rollback되는 현상
3. 위같은 경우 lock의 원인이 무엇일까 분석결과 ?
운영중인 어플리케이션이 lock이 잘걸려서 여러가지 방법을 통해 해소해보려고 했다.
운영중인 시스템은 select시 전부 nolock 키워드를 이용해서 조회한다.
이런경우 쿼리타임이 길어도 해당 쿼리 때문에 다른 프로세서에 락이 걸리지 않는것이 정상이다.
그러면 왜 lock이 걸리는것인가?
그 이유중 하나는 transaction 처리가 있을 수 있다.
보통은 spring 어노테이션중 @Transactional 을 처리해서 스프링이 알아서 관리해 주지만,
수동으로 관리할수 도 있는데, 이때 항상 프로세스종료후에 commit 또는 rollback이 필수적이다.
하지만 실수로 빼먹거나, 잘못된 예외관리(try_catch)로 인해 구멍이 생긴다면?
해당프로세스는 종료되지 못하고 다른 비지니스 로직과 얽히고 설켜 감당할 수 없을 정도의 락을 유발할수 있다.
이때 디비에서 kill로 강제 종료 시켜버린다면?
연관된 프로세스가 전부 롤백되버릴수도 있다. ( 실제 경험이다..)
결론은 transaction manager를 이용시 절대 주의해야하며, 잘모르면 쓰지말자.
dbcc opentran('db스키마') with tableresults;--열린 트랜잭션이 있는 경우 (예시) :
OLDACT_STARTTIME : 02 16 2022 12:28:12:493PM
이 시간이 오래된 경우 트랜젝션이 종료되지 않고, 비정상적인 경우인 확률이 높다.
관련된 비지니스로직을 검토 해 보자.
정상적인 비지니스 로직이라면, 최근 시간이 조회되야한다.
