5. SQL Server 데이터베이스 성능 모니터링 - 현재 요청

온라인 으로 실행 되 는 시스템 에 대해 현재 데이터베이스 성능 모니터링 은 보통 다음 과 같은 몇 가 지 를 감시 합 니 다.
(1) 차단 이 있 는 지 여부 (Blocking);
(2) 대기 (Waiting) 가 있 는 지, 차단 은 잠 금 (Lock) 대기 입 니 다.
(3) 너무 오래 실행 할 지 여부 (Long running);
(4) 자물쇠 가 있 는 지 여부 (Deadlock);
sys.dm_exec_query_stats 와 같은 통계 적 인 정 보 는 보통 실시 간 경고 내용 이 아니 라 성능 최적화 시 참고 로 한다.
 
하나 차단 / 대기 / 장시간 운행
1. SQL Server 2005 향후 버 전 검사

SELECT r.session_id
      ,r.blocking_session_id
      ,DB_Name(r.database_id) as database_name
      ,r.start_time
      ,r.total_elapsed_time
      ,r.[status]
      ,CASE WHEN r.blocking_session_id<> 0 THEN'Blocking'
           WHEN r.blocking_session_id= 0 AND r.wait_type is not null THEN 'Waiting'
           ELSE 'Long-running'
       END as slowness_type
      ,r.percent_complete
      ,r.command
      ,r.wait_type
      ,r.wait_time
      ,r.wait_resource
      ,r.last_wait_type
      ,r.cpu_time
      ,r.reads
      ,r.writes
      ,r.logical_reads
      ,t.[text] as executing_batch
      ,SUBSTRING(t.[text],
                r.statement_start_offset/2,
                (CASE WHENr.statement_end_offset =-1 
                      THENDATALENGTH(t.[text]) --LEN(CONVERT(NVARCHAR(MAX),t.text)) * 2
               ELSE r.statement_end_offset
               END - r.statement_start_offset )/2+ 1) as executing_sql
      ,bt.[text] as blocking_batch
      ,SUBSTRING(bt.[text],
                br.statement_start_offset/2,
                (CASE WHENbr.statement_end_offset = -1 
                      THENDATALENGTH(bt.[text]) --LEN(CONVERT(NVARCHAR(MAX),bt.text)) * 2
               ELSE br.statement_end_offset
               END - br.statement_start_offset )/2+ 1) as blocking_sql
     --,p.query_plan
  FROM sys.dm_exec_requests r
 CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) as t
 CROSS APPLY sys.dm_exec_query_plan(r.plan_handle) as p
  LEFT JOIN sys.dm_exec_requests br
    ON r.blocking_session_id =br.session_id
 OUTER APPLY sys.dm_exec_sql_text(br.session_id) as bt
 WHERE r.session_id > 50 and r.session_id <> @@SPID
   AND r.total_elapsed_time >30 * 60 * 1000
 ORDER BY r.total_elapsed_timeDESC;

이상 스 크 립 트 는 30 분 이상 실행 되 는 문 구 를 되 돌려 줍 니 다. 주의해 야 할 것 은:
(1) 실행 계획 을 되 돌려 주면 상기 스 크 립 트 가 많이 느 려 집 니 다. 되 돌아 오지 않 고 경 고 를 받 은 후에 문 구 를 검사 할 때 실행 계획 을 확인 할 수 있 습 니 다.
(2) TEXT 를 표시 합 니 다. 예 를 들 어 xpcmdshell 이런 문구, startoffset, end_offset 은 모두 0 이 고 캡 처 한 text 는 공백 이 며 TEXT 를 봐 야 어떤 문구 인지 알 수 있 습 니 다.그리고 이 요청 이 어떤 batch 나 저장 과정 에서 왔 는 지 알 아야 할 때 도 있 습 니 다.
(3) TEXT 가 부족 할 때 도 있 고 xp 로cmdshell 의 경우 dbcc input buffer 가 있어 야 완전한 sql 문 구 를 볼 수 있 습 니 다.또한 실행 이 끝 났 지만 commt / rollback 의 업무 가 없습니다. requests 에 없습니다. dbcc input buffer 를 빌려 sql 문 구 를 봐 야 합 니 다.

dbcc inputbuffer(@@SPID)

(4) SQL Agent 작업 은 여기 서 함께 검 사 를 받 을 수도 있 고 msdb. sysjobation 을 통 해 별도로 검사 할 수도 있 습 니 다.

select b.name, * 
  from msdb..sysjobactivity a
 inner join msdb.dbo.sysjobs b
    on a.job_id = b.job_id
 where b.name like '%backup%'

 
2. SQL Server 2000 을 그대로 사용 하 는 방법

select p.dbid, p.spid, p.blocked, p.waittime/1000.0/60.0 as wait_minutes, 
       ISNULL(DATEDIFF(MI, p.last_batch, GETDATE()), 0)elapsed_minutes, 
       p.last_batch, p.status, p.program_name, 
       (select [text] FROM::fn_get_sql(p.sql_handle)) sql_text
  from master..sysprocesses p
 where spid > 50 and spid <> @@SPID
  AND(status <> 'sleeping' AND ISNULL(DATEDIFF(MI, p.last_batch, GETDATE()), 0) > 30)

이상 스 크 립 트 는 30 분 이상 실행 되 는 문 구 를 되 돌려 줍 니 다. 주의해 야 할 것 은:
sysprocesses 에서 connection / session / request 정 보 를 하나 로 합 쳤 습 니 다. 그 중에서 시작 할 구체 적 인 시간 을 요청 하지 않 았 습 니 다. last 를 통 해batch 감시 운행 시간 이 정확 하지 않 습 니 다.테스트 는 다음 과 같 습 니 다:
(1) ISQL 을 통 해 SQL Server 에 연결 합 니 다. 현재 연결 에 어떠한 요청 도 하지 않 았 다 면 lastbatch 의 시간 은 1900 - 01 - 01 00: 00: 00 입 니 다. 이 연결 에 요청 할 때 last 를 통 해batch 는 현재 요청 실행 시간 이 정확 하지 않 음 을 계산 합 니 다.
(2) SQL Analyzer / SMS 에 새 검색 창 을 만 들 고 검색 이 시작 되 지 않 았 을 때 lastbatch 와 logintime 은 1900 - 01 - 01 00: 00: 00 이 아니 라 last 를 통 해batch 는 현재 요청 실행 시간 이 정확 하지 않 음 을 계산 합 니 다.또는 현재 창 에서 요청 이 끝 났 지만 창 / 연결 이 닫 히 지 않 으 면 이 연결 에서 다시 요청 합 니 다. lastbatch 는 지난번 요청 이 끝 난 시간 을 위해 last 를 통 해batch 계산 현재 요청 실행 시간 도 정확 하지 않 습 니 다.
(3) SQL Agent 작업 이 끝나 면 sysprocesses 의 연결 을 닫 고 다음 실행 시 연결 을 다시 만 듭 니 다. 새 연결 에서 lastbatch 는 logintime, lastbatch 계산 작업 운행 시간 이 정확 합 니 다.
 
오래된 방법 으로서 더 이상 깊이 연구 하지 않 지만 sysprocesses 로 차단 / 기다 림 을 감시 하 는 것 은 문제 가 없습니다. 또한 작업 의 운행 시간 도 감시 할 수 있 습 니 다. 스 크 립 트 가 바 뀌 면 다음 과 같 습 니 다.

select p.dbid, p.spid, p.blocked, p.waittime/1000.0/60.0 as wait_minutes, 
       ISNULL(DATEDIFF(MI, p.last_batch, GETDATE()), 0)elapsed_minutes, 
       p.last_batch, p.status, p.program_name, 
       (select [text] FROM::fn_get_sql(p.sql_handle)) sql_text
  from master..sysprocesses p
 where spid > 50 and spid <> @@SPID
   and(
       (p.program_name like 'SQLAgent - TSQL JobStep (Job %' AND ISNULL(DATEDIFF(MI, p.last_batch, GETDATE()), 0) > 30)
       or 
       (p.blocked <> 0 and p.waittime/1000.0/60.0 > 30)
       )

이렇게 되면 차단 되 지 않 았 지만 장시간 실행 되 는 sql 요청 만 감시 되 지 않 습 니 다.전면적으로 감시 해 야 한다 면 추적 을 켜 고 추적 파일 을 분석 할 수 있다.
 
둘. 자물쇠
잠 금 감 시 는 SQL Server 의 ERRORLOG 를 감시 함으로써 가능 하지만 잠 금 추적 표 시 를 미리 열 어야 합 니 다.스 크 립 트 는 다음 과 같 습 니 다:

--sql server 2000
dbcc traceon(1204,-1)
 
--sql server 2005 +
dbcc traceon(1222,-1)

이렇게 생사 의 자 물 쇠 를 보 낼 때 자물쇠 의 상세 한 정 보 는 ERRORLOG 에 기록 되 고 deadlock 이나 victim 키 워드 를 검사 하면 모니터링 할 수 있다.
 
작은 매듭
각 문장의 운행 시간 / 기선 이 다 르 기 때문에 통 일 된 밸브 값 을 설정 하기 가 쉽 지 않 습 니 다. 가끔 은 제3자 도 구 를 빌려 서로 다른 요청 에 대해 서로 다른 시간 밸브 값 을 설정 하고 경고 하기 때문에 데이터 베이스 이 층 에서 대부분 경고 가 막 히 면 됩 니 다. 대체적으로 다음 과 같 습 니 다.
(1) 데이터베이스 메 일 배치;
(2) 배치 작업: 정시 에 차단 을 검사 하고 메 일 로 경고 합 니 다.