2011년 4월 20일 수요일

db lock 많을때

그림과 같이 sp_lock 를 실행하세요 ..



5가지 정보를 보시면 되는데요



spid / db_id / object_id / mode / status



spid 는 할당된 프로세스 ID 이구요 ( spid가 여러개일 경우 특정 처리임계치를 넘어서 병열처리로 넘어갔다고 보면 됩니다. 이놈들이 현재 리소스를 잡아먹고 있다고 보시면 됩니다. )



dbid 는 어떤 db로 접근했는가



object_id 는 어떤 객체를 건들이고 있는가 .. table ? index ? sp ??



mode 는 s / is / x /ix 그외에 여러가지가 있는데요



s는 select 처리시 발생되는 공유락 정도로 보시면 되구요 ( 100% 정확한건 아니구요 )

x 는 트랜잭션 처리중 발생하는것이거나 데이터가 커져서 데이터 페이지 분할이나 확장으로 인한 객체 단위의 배타락일수 있구요 ( 100% 아니구요) 배타락의 경우 다음 프로세스가 락을 유발하는 경우 wait 상태로 빠트려서 현재 처리하는 작업이 끝날때까지 다른 작업은 계속 wait 이구요



상황은 여러가지와 엮기는데요 .. 암튼 ..



가장 심플한것은 spid가 심하게 겹치는 애들을 살펴 보시면 되요



sp_who2 79 << 이런식으로 ..

kill 79

상위 명령을 내리시기 전에 .. 고민해보셔야 하는게 ... select 쿼리라면 ... 사용자가 혹은 배치가 돌다가 끝나도 문제는 안되는데 ..

트랜잭션일 경우 문제가 될수 있다는거죠 .. 그래서 kill 시키기 전에 어느 db 인지 어떤 객체 인지 그리고 sp_who2 를 통해서

1. 어떤 웹서버에서 요청이 왔는지

2. 스케줄이 돌았는지

3. 미친 개발자가 있는지?

대충 sp_who2 에 나오는 hostname 으로 해당 PC 나 서버를 파악하고 application 의 정보를 보고 IIS 인지 SQL 서버인지도 판단을 하구요

select 쿼리 였는지 트랜잭션 인지 ... 등 정보들을 파악하고 kill 시켰을때의 영향에 대해서 보셔야 하구요 ...



대충 여기까지요 ^^;;