좀전에 잠깐 서비스가 안되던데..

RDBMS Lock 관련 내용으로서, 개발자와 DBA의 협업이 상당히 중요한 영역입니다.
Lock 발견/분석/해결 과정은 개발자/DBA간 직접(?) 소통의 시간이 적지 않게 이루어지고,
서로간의 간단한 질문 부터 시작해서  급기야 애플리케이션 소스까지 같이 inspect하는 상황까지
가는 직접 소통의 계기를 만들어 줍니다. 
* 참고로 가장 많은 시간을 사용하는 부분은 아마 메타시스템을 통한 간접 소통일 것입니다. 
 
대다수의 DBA에게 해당 되지 않을 것이다.
제 주위에는 되도록 개발자와의 소통/대화를 지양하려는 DBA분들이  있었으며, 시간이 지나면 지날수록
DBA와 개발자의 보이지 않는 벽이 점점 더 높아지는 걸 보았습니다. 
그런 DBA분들 조차도 RDBMS Lock관련 이슈/장애가 발생하면 개발자와의 평균 1년치 대화 시간을
여기에 소비하는 경우를  목격하기도 하였습니다. ^^
 이유인즉 Lock의 원천이유(개발자) 및 대응(DBA)간의 명확한 책임소재가 모호하기에 개발자 및 DBA 
모두 신경을 많이 쓰는 영역이며,  잘못 스탠스를 가져갔다가 모든 책임을 받아 올 수 있는 개연성의 소지가
다분이 있어서입니다. 그래서, 항상 긴장을 끈을 놓지 않게 하는 부분이기도 합니다. ^^ 
 
대다수의 DBA들은 실시간 락 모니터링을 솔루션(맥스게이즈,셀파 등)을 통해 수행하고 있을 것입니다.
보기 좋은 Lock Tree 형태로 보여주고, 락 홀더의 정보 또한 자세하게 보여줄 것입니다. 
그리고 솔루션에서는 실시간 뿐만 아니라  과거의 시점에서의 Lock 경합 상황도 연출시켜주어 DBA에게
많은 도움을 제공할 것입니다. 

여기에 +하여
실시간 모니터링을 놓쳤거나, 솔루션을 보유하고 있지 않거나, CLI(터미널)에서 확인하고 싶은 니즈가 있을 경우
과거 시간대의 락을 조회하는 화면 샘플을 공유드립니다.
(스크립트는 추후 필요시 공유드림)
해당 스크립트는 현재 운영시스템에 사용 중이며, gv$active_session_history 및 재귀호출을 통해 구현되었습니다.
(현 사이트는 DB 모니터링 솔루션으로 맥스게이즈 사용 중임)

락 관련 유발인자는 대부분 개발프로그램에서의 락처리 미흡으로 발생하는 경우가 많습니다. 그러나 DBA분들도 이런 락 현상을 즉시 공유하여 오랫동안 DB 서비스가 꼼짝달싹하지 못한 상황은 피해야할 겁니다.
트랜잭션 로우건수(1 commit, commit/1000 rows 등), 락 대기시간(nowait, wait 1 등) 등의 세부 고려사항들은 애플리케이션의 상황에 맞게 조정해서 최적의 락 프리 상황을 구현해야겠습니다.