SQL Server/SQL Server Tip 662

성능분석 7탄 – 프로파일러 대기 유형 및 PREEMPTIVE_OS_WRITEFILEGATHER

성능분석 7탄 – 프로파일러 대기 유형 및 PREEMPTIVE_OS_WRITEFILEGATHER Version : SQL Server 2005, 2008, 2008R2, 2012 SQL Server에서 발생하는 대기 유형 중 프로파일러 사용으로 인한 대기 유형 및 파일 작업으로 인한 대기 유형에 대해서 살펴 본다. TRACEWRITE 이 대기 유형은 SQL Profiler에 의해 차단되고 있음을 나타낸다. 서버에 연결된 프로파일이 있는 경우에만 발생한다. 너무 많은 프로파일 이벤트를 추적할 경우 자주 발생 한다. PREEMTIVE_OS_WRITEFILEGATHER 데이터베이스 파일의 자동증가 트리거가 설정되어 있을 경우 발생 한다. SQL Server에서 파일의 자동 증가는 매우 큰 비용을 발생하는 이벤..

성능분석 6탄 – CPU 경합 및 동시성 관련 대기 유형

성능분석 6탄 – CPU 경합 및 동시성 관련 대기 유형 Version : SQL Server 2005, 2008, 2008R2, 2012 SQL Server에서 발생하는 대기 유형 중 CPU 경합 및 동시성 관련 대기 유형에 대해서 살펴 본다. LCK_* LCK는 잠금으로 인한 대기 정지 작업을 나타낸다. LCK_M_S* 대기 유형은 데이터를 읽기 위해(공유 잠금) 잠금을 획득하려고 할 때 발생 한다. LCK_M_SCH* 대기 유형은 객체의 스키마 잠금을 표시한다. 대기 유형설명LCK_M_BU태스크가 대량 업데이트(BU) 잠금을 획득하려고 대기하는 경우에 발생한다. LCK_M_IS태스크가 내재된 공유(IS) 잠금을 획득하려고 대기하는 경우에 발생한다LCK_M_IU태스크가 의도 업데이트(IU) 잠금을 획..

성능분석 5탄 – 메모리 및 네트워크 관련 대기 유형

성능분석 5탄 – 메모리 및 네트워크 관련 대기 유형 Version : SQL Server 2005, 2008, 2008R2, 2012 SQL Server에서 발생하는 대기 유형 중 메모리 및 네트워크 관련 대기 유형에 대해서 살펴 본다. [메모리 관련 대기 유형] RESOURCE_SEMAPHORE 이 대기 유형은 쿼리가 메모리 부여를 기다리는 것을 나타낸다. 다른 동시 쿼리로 인해 쿼리 메모리 요청을 즉시 허용할 수 없는 경우에 발생 한다. 대기 수가 많고 대기 시간이 길면 동시 쿼리 수 또는 메모리의 양이 과도하게 많은 것이다. SOS_VIRTUALMEMORY_LOW 메모리 할당 리소스 관리자가 가상 메모리를 해제 할 때까지 대기 하는 경우에 발생 한다. 주로 32bit 환경에서 자주 발생 한다. L..

성능분석 4탄 – 디스크 및 IO 관련 대기 유형

성능분석 4탄 – 디스크 및 IO 관련 대기 유형 Version : SQL Server 2005, 2008, 2008R2, 2012 SQL Server에서 발생하는 대기 유형 중 DISK 및 I/O 관련 대기 유형에 대해서 살펴 본다. PAGEIOLATCH_* 전형적인 I/O 대기로 디스크에서 데이터를 읽고 쓰기 위한 대기이다. 데이터가 디스크에서 메모리로 캐시 (버퍼풀) 될 때까지 차단 작업이 발생 하면서 대기가 발생 한다. 대기 유형중 PAGELATCH_* 와 혼동하지 않도록 한다. 대기유형설명PAGEIOLATCH_DT태스크가 I/O 요청에 있는 버퍼를 래치에서 기다리는 경우에 발생한다. 래치 요청이 삭제 모드에 있다. 대기 수가 많으면 디스크 하위 시스템에 문제가 있을 수 있다.PAGEIOLATCH..

성능분석 3탄 – 집계 대기 통계

성능분석 3탄 – 집계 대기 통계 Version : SQL Server 2005, 2008, 2008R2, 2012 SQL Server 집계 통계(Aggregates Statistics)는 DMV 중 sys.dm_os_wait_stats을 통해서 확인 할 수 있다. sys.dm_os_wait_stats에서는 현재 실행 중인 요청 및 대기 작업을 보고 어떤 순간에 대기하고 있는지 보여주며 서버가 시작된 이후 누적된 값을 제공한다. DMV를 통하여 대기 통계를 확인하는 것은 간단하지만 결과를 해석하는 방법에는 약간 까다롭다. select * from sys.dm_os_wait_stats order by wait_time_ms desc; 결과를 살펴 보면 상단에 위치한 목록에 DIRTY_PAGE_POOL, R..

성능분석 2탄 – 실행 요청을 기다리는 작업 확인 및 분석 - 병렬 처리 대기 확인

성능분석 2탄 – 실행 요청을 기다리는 작업 확인 및 분석 병렬 처리 대기 확인 Version : SQL Server 2005, 2008, 2008R2, 2012 지난 아티클에서 실행 요청을 기다리는 작업에 대해 확인 하는 방법에 대해서 알아 보았다. 성능분석 1탄 – 실행 요청을 기다리는 작업 확인 및 분석 : http://sqlmvp.kr/140207603501 또 다른 예제를 한번 살펴 보자. 세션 53의 상태는 COMMIT TRANSACTION 작업을 기다리고 있다. 세션 54의 상태는 SELECT 작업으로 세션 55에 의해 대기 하고 있다. 세션 55의 상태는 SELECT 작업으로 세션 53에 의해 대기 하고 있다. 세션 56의 상태는 SELECT 작업으로 세션 55에 의해 대기하고 있다. 세션..

성능분석 1탄 – 실행 요청을 기다리는 작업 확인 및 분석 - 다른 세션에 의한 블록킹 확인

성능분석 1탄 – 실행 요청을 기다리는 작업 확인 및 분석 다른 세션에 의한 블록킹 확인 Version : SQL Server 2005, 2008, 2008R2, 2012 SQL Server에서 요청한 작업의 결과가 느리게 반환될 때가 있다. 이는 요청 된 작업의 처리량이 많아서 처리 속도가 오래 걸릴 수도 있지만 다른 작업에 의해 대기가 발생하여 작업이 기다리게 되는 상황이 발생 할 수도 있다. 현재 실행을 위해 대기하는 요청을 확인 하기 위해서는 DMV 함수 sys.dm_exec_requests 를 사용할 수 있다. Sys.dm_exec_requests 결과에서 wait_time 및 wait_type 열을 확인 하여 현재 어떤 작업이 대기 하고 있는지 또는 실행되고 있는지 확인 할 수 있다. Sele..

확장이벤트를 사용하여 데드락 정보 확인

확장이벤트를 사용하여 데드락 정보 확인 Version : SQL 2008, 2008R2, 2012 SQL Server extenede event(확장이벤트)를 사용하여 데드락 정보를 확인해보자. 다음 스크립트를 사용하여 교착 상태를 유발 한다. 그리고 데이터를 조회해 보면 이 중 하나는 교착 상태 모니터에 의해 제거 된다. 세션1세션2CREATE TABLE t1 (c1 INT); INSERT INTO t1 VALUES (1); GO BEGIN TRAN UPDATE t1 SET c1 = 2; GO CREATE TABLE t2 (c1 INT); INSERT INTO t2 VALUES (1); GO BEGIN TRAN UPDATE t2 SET c1 = 2; GO SELECT * FROM t2; GO SELEC..

확장 이벤트를 사용한 CPU 고부하 쿼리 추적

확장 이벤트를 사용한 CPU 고부하 쿼리 추적 Version : SQL Server 2005, 2008, 2008R2, 2012 SQL Server를 운영 할 때 일부 쿼리에서 과도한 자원을 점유하여 성능에 문제를 발생 시킨다. 다음은 CPU를 많이 사용하는 쿼리를 추적 하는 기술에 대해서 알아본다. 다음 스크립트를 사용하여 실습용 데이터베이스 및 테이블을 생성한다. 데이터베이스 ID는 사용자마다 다를 수 있다. CREATE DATABASE production; GO USE production; GO CREATE TABLE t1 (c1 INT IDENTITY, c2 UNIQUEIDENTIFIER ROWGUIDCOL DEFAULT NEWID(), c3 CHAR (5000) DEFAULT 'a'); CREA..

데이터에 대한 이해와 spill in tempdb

데이터에 대한 이해와 spill in tempdb Version : SQL Server 2005, 2008, 2008R2, 2012 상황은 tempdb 데이터가 30GB에서 120GB로 증가 하였지만 tempdb의 로그 파일은 1GB밖에 증가하지 않았다. 이런 상황이 가능 할까? Tempdb에 대해 고려해야 할 때 tempdb에 로깅하는 것은 매우 효율적이다. tempdb는 다른 데이터베이스처럼 롤백 할 수 있도록 전과 후의 이미지를 필요로 한다. 그래서 업데이트 하기 전 성공적인 롤백이 가능하도록 이미지를 기록 한다. 위의 질문에 대한 답은 tempdb에 발생하는 정렬 유출(sort spill)을 고려하여 설명 할 수 있다. 다음 스크립트는 수 백만 행의 결과를 정렬한다. SELECT S.*, P.* ..