728x90

select d.name, d.dbid, spid, login_time, nt_domain, nt_username, loginame
from sysprocesses p
inner join sysdatabases d on p.dbid = d.dbid
where d.name = 'DB_Name'

 

or

 

exec sp_who2

kill spid

alter database DB_Name set multi_user;

alter database DB_Name set sigle_user;

728x90
728x90

select   a.session_id as 'BlockedSessionID', b.blocking_session_id

,        b.wait_duration_ms / 1000 as 'WaitDuration(Sec)', b.wait_type

,        c.resource_type, db_name(c.resource_database_id) as 'ResourceDBName', c.request_mode, c.request_type, c.request_status, b.resource_description

,        db_name(e.dbid) as 'BlockedDBName', object_name(e.objectid) as 'BlockedObjectName', e.text as 'BlockedQuery'

,        substring(e.text, (d.statement_start_offset / 2) + 1, ((case d.statement_end_offset when -1 then datalength(e.text) else d.statement_end_offset end - d.statement_start_offset)/2) + 1) as 'BlockedStmt'

,        db_name(g.dbid) as 'BlockingDBName', object_name(g.objectid) as 'BlockingObjectName', g.text as 'BlockingQuery'

,        a.task_address, a.worker_address, b.waiting_task_address, b.blocking_task_address

from            sys.dm_os_tasks a with(nolock)

    inner join  sys.dm_os_waiting_tasks b with(nolock)  on a.task_address = b.waiting_task_address or a.task_address = b.blocking_task_address

    inner join  sys.dm_tran_locks c with(nolock)        on b.resource_address = c.lock_owner_address

    inner join  sys.dm_exec_requests d with(nolock)     on a.session_id = d.session_id and a.request_id = d.request_id

    cross apply sys.dm_exec_sql_text(d.sql_handle) e

    inner join  sys.dm_exec_connections f               on b.blocking_session_id = f.session_id

    cross apply sys.dm_exec_sql_text(f.most_recent_sql_handle) g

where b.blocking_session_id is not null

--  and b.wait_duration_ms > 3000

728x90
728x90

MS-SQL 서비스를 운영하다보면, 특정 쿼리의 Lock 문제로 리소스 낭비 뿐만 아니라 최악에는 서비스까지 영향을 미치는 문제가 발생하는 경우가 있다. 이런 문제가 발생하게 되면 보통 별도의 알람 시스템을 통해 알람을 전달 받고 해당  Lock을 발생하는 SPID를 확인해서 빠르게 Kill 해주는게 좋다.

쿼리창에서 아래 그림의 명령어를 입력해서 현재의 Lock 상태를 확인 합니다.
해당 정보를 이용해서 Lock의 종류를 분류하고 장애를 처리 할 수 있습니다.

 

  • S : 공유 잠금 Lock.
  • U : 업데이트 잠금 Lock.
  • X : 독점 잠금 Lock.
  • IS : 의도 공유 잠금 Lock.
  • IU : 의도 업데이트 잠금 Lock.
  • IX : 독점 의도 잠금 Lock.
  • BU : 대량 업데이트 잠금 Lock.
DBCC Inputbuffer (SPID 번호) 명령을 실행하여 Lock을 발생시킨 원인 쿼리를 확인 합니다.
Lock을 발생시킨 쿼리문이 확인 되었다면, Kill 명령을 통해 해당 작업을 중지 하면 됩니다.

  • Kill(SPID 번호)

 

동일한 문제가 발생할 가능성이 높기 때문에, 아래 명령어를 통해 SPID 확인 및 해당 SPID의 소유자를 먼저 확인 합니다.

  • EXEC SP_WHO
  • EXEC SP_WHO spid

다음으로 어떤 쿼리가 실행 되었는지를 확인 합니다. (아래 명령어 참고)

  • DBCC INPUTBUFFER(spid)

 

위와 같이 수동으로 작업하는 방법 이외에, 스케줄러를 통해 자동 처리하는 방법이 있지만, 혹시 모를 장애를 대비해서 관리자가 직접 해당 쿼리문등을 확인하고 작업하는 걸 추천 드립니다.

728x90

+ Recent posts