Data Science Lab

성능분석 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탄 – 실행 요청을 기다리는 작업 확인 및 분석 병렬 처리 대기 확인 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탄 – 실행 요청을 기다리는 작업 확인 및 분석 다른 세션에 의한 블록킹 확인 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 고부하 쿼리 추적 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 Version : SQL Server 2005, 2008, 2008R2, 2012 상황은 tempdb 데이터가 30GB에서 120GB로 증가 하였지만 tempdb의 로그 파일은 1GB밖에 증가하지 않았다. 이런 상황이 가능 할까? Tempdb에 대해 고려해야 할 때 tempdb에 로깅하는 것은 매우 효율적이다. tempdb는 다른 데이터베이스처럼 롤백 할 수 있도록 전과 후의 이미지를 필요로 한다. 그래서 업데이트 하기 전 성공적인 롤백이 가능하도록 이미지를 기록 한다. 위의 질문에 대한 답은 tempdb에 발생하는 정렬 유출(sort spill)을 고려하여 설명 할 수 있다. 다음 스크립트는 수 백만 행의 결과를 정렬한다. SELECT S.*, P.* ..

로그 파일이 많으면 왜 안 좋은가 Version : SQL Server 2005, 2008, 2008R2, 2012 SQL Server에서 발생하는 트랜잭션은 트랜잭션 로그 라는 로그 파일에 기록 된다. 기본 설정으로 SQL Server를 설치 하였다면 확장자는 ldf로 표시 되며 하나의 로그 파일이 생성된다. 트랜잭션 로그 파일은 순환 파일이다. 한 개의 물리 파일에 4개의 가상 로그 파일이 있다고 가정 하였을 때 데이터베이스가 생성될 때 물리 로그파일의 시작 부분에서 논리로그 파일이 시작 된다. 새 로그레코드는 논리 로그의 끝 부분에 추가되며 물리 로그의 끝 방향으로 확장 된다. 로그에 물리 로그 파일이 여러 개 있으면 논리 로그는 모든 물리로그 파일을 거친 후 첫 번째 물리로그 파일의 시작 부분으로..

트랜잭션 백업 실패와 전체 백업 성공 그리고 대처 방안 Version : SQL Server 2005, 2008, 2008R2, 2012 SQL Server에서 트랜잭션 로그는 SQL Server에서 발생하는 모든 행동을 기록 한다. 다음 사례는 트랜잭션 백업이 실패하지만 전체 백업은 성공하는 경우에 대해서 알아 본다. 다음과 같이 트랜잭션 로그가 손상되어 백업이 실패하였다. 하지만 전체 백업은 성공하였으며 DBCC CHECKDB 도 성공하였다. 트랜잭션 백업이 실패하였지만 전체 백업이 성공한 이유는 트랜잭션 로그의 아키텍처를 살펴보면 이해 할 수 있다. 트랜잭션 로그 물리 아키텍처 : http://sqlmvp.kr/140187358202 트랜잭션 로그 백업은 마지막 트랜잭션 로그 백업 이후에 생성된 트..

Fast recovery 와 로그 잠금 Version : SQL Server 2005, 2008, 2008R2, 2012 SQL Server 2005 이상의 Enterprise 버전에서는 fast recovery 기능이 도입 되었다. fast recovery는 복구 단계에서도 데이터베이스를 사용 할 수 있다. Fast recovery는 장애가 발생하였을 때 이전의 커밋되지 않은 트랜잭션들에 대해서는 장애 발생 이전으로 잠금을 획득하여 트랜잭션이 롤백 되는 동안 자신의 잠금을 사용자 간섭으로부터 보호 한다. 스토리지 엔진은 응급 복구 시 두 개의 패스로 수행 한다. 첫 번째 패스는(REDO) 로그 레코드를 읽고 두 번째 패스(UNDO)는 잠금을 확인 하고 실제 잠금을 획득 한다. Fast recovery ..

고스트 클린업 Version : SQL Server 2005, 2008, 2008R2, 2012 인덱스가 있는 행을 삭제 할 경우 인덱스의 효율성을 높이기 위해 인덱스의 리프-레벨에 삭제 하려는 행에 대해서는 우선 고스트 레코드(Ghost Record)로 마크한 다음 주기적인 삭제 작업이 실행 된다. GhostRecord(인덱스에서 행 삭제시발생) : http://sqlmvp.kr/140164866348 고스트 클린업 작업은 빈 데이터 할당 또는 인덱스 페이지 작업을 피하기 위해 기록(single record)을 남길 수 있다. 이러한 작업들은 백그라운드에서 실행된다. 고스트 클린업 작업은 삭제 트랜잭션이 완료 될 때까지 물리적으로 삭제 할 수 없다. 왜냐하면 트랜잭션 잠금이 트랜잭션 커밋이 될 때까지 ..