with SQL Server

올해 여름 SQL Server 2016 프리뷰 버전이 공개된다고 하네요.(SQL Server 2014 나온지 얼마 되지도 않은 것 같은데…)

http://blogs.technet.com/b/dataplatforminsider/archive/2015/05/04/sql-server-2016-public-preview-coming-this-summer.aspx

간단히 살펴본 결과 분석쪽 부분을 특히 강화하는 것 같네요. 모바일BI 쪽도 그렇고…

반가운 소식은 JSON도 지원한다고 합니다~

SQL Server 2014부터 Resource Governor(리소스 관리자)에서 물리적 읽기 IO 컨트롤이 가능하다고 합니다.

SQL Server 2008 ~ 2012까지는 CPU와 메모리의 리소스 풀에 한해서만 지원했었는데요.

2014부터는 Physical IO 대해서도 최소 ~ 최대 IOPS를 설정하여 활용 가능합니다.

2008부터 생긴 리소스 관리자를 OLTP에서 얼마나 사용하며, 또한 이점이 있을 까란 생각이 들긴 하지만

이번 1분 이벤트 때와 같이 IOPS가 평소 기준치보다 많이 밀린 상태인 가운데 대량 배치작업(Job이나 관리툴 등…)에서는 조금 유용해 보입니다.

물론 아쉽게도 해당 기능은 64bit 엔터프라이즈에서만 지원합니다..ㅠ (게임DB에 엔터급 이상쓰는 곳이 있을까도 궁금하네요..)

URL : http://www.sql-server-performance.com/2014/performance-sql-server-2014-resource-governer-buffer-pool/

SQL Server 2014 New Features 중에 초 간단 팁 하나 테스트 해 봤습니다.

가끔 SELECT…INTO 을 사용해 테이블 백업 및 복사 작업할 경우가 있는데요.

SQL Server 2014부터 병렬로 풀립니다~ (대량 테이블이면 꽤 속도차이를 보일 것 같습니다..)

MAXDOP 옵션으로 강제로 코어 4개를 태웠고, 해당 쿼리는 2008R2, 2014 에서 똑같이 실행 됐습니다.

SELECT  *

INTO    [Sales].[SalesOrderDetail_TEST]

FROM   [Sales].[SalesOrderDetail]

OPTION(MAXDOP 4);

ü  실행계획 (parallelism : 병렬확인)

n  SQL Server 2014

n  SQL Server 2008 R2

ü  CPU 처리 시간 확인. (처리시간 약 4배 단축 확인가능)

n  SQL Server 2014

n  SQL Server 2008 R2

결론은 CPU를 병렬로 처리하기 때문에 CPU 사용량은 증가되나, 처리시간은 단축됩니다.(심플하네요..ㅎㅎ)

SQL Server 운영하시다 보면 접속세션 정보를 알아보기 위해서 시스템 저장 프로시저인 sp_who 또는 좀 더 세부적인 sp_who2를

많이 사용하시고 계실텐데요.

Sp_who3는 호환성 90. 이상에서 동작하는 점 참고 부탁 드리며 아래는 간단한 데모 결과 입니다.

1.     시나리오 : 2개의 서로 다른 세션에서 한 세션은 대량 업데이트를 발생시키고 다른 세션에서는 데이터 조회를 DB서버에 요청합니다.

2.     2개의 세션이 러닝 될 때 sp_who3를 호출

A.     58번 세션이 53번 세션으로 인해 블로킹이 발생해 대기하는 정보와 각 세션에서 어떤 종류의 DML문이 발생됐는지 확인 가능합니다.

B.      53, 58 세션이 실행한 SQL 구문을 확인 가능하고 53번 세션의 대량 업데이트로 인해

58번 세션에서 LCK_M_IS(공유 잠금 획득 대기)가 발생하고 있는 걸 확인 가능합니다.

Sp_who3는 기존 sp_who[n] 와 같이 실시간 모니터링 용 프로시저이며 해결책을 제시하지는 않습니다.

하지만 원인을 빠른시간 내에 확인 가능하며, 쿼리 플랜 역시 제공하기 때문에 DBA가 이슈를 해결하기에 좋은 도구라고 생각이 듭니다~

아… 추가로 기존 sp_who[n] 시스템 저장 프로시저는 휴무중인 모든 세션을 포함하여 한눈에 확인하기가 힘들었지만

Sp_who3는 휴무 중인 세션과 자신의 세션 정보를 필터링하기 때문에 기존 SP보다 더 나은 정보를 제공합니다.

P.s SP_MS_marksystemobject 를 이용해서 시스템 저장프로시저로 등록하면 인스턴스 내 모든 DB 카탈로그에서 사용 가능합니다.

sp_who3.sql

확장속성 추가 시 아래와 같이 추가되는 해당 개체에서 스키마 잠금(Sch-M) 현상이 순간적으로 발생합니다.

정렬된 파티션의 행을 지정된 수의 그룹으로 분산해줌

http://msdn.microsoft.com/ko-kr/library/ms175126.aspx

아주 오랜만에 포스팅 하는 것 같습니다.

이번 포스팅 주제는 SQL Server 힙 테이블에서 발생할 수 있는 Forwarded Record 입니다.

가변형 컬럼에 기존 값보다 큰 값이 저장되면 Clustered Index 테이블에서는 페이지 분할이 발생하지만

Heap 테이블에서는 기존 페이지에 Forwarding Pointer만 저장되고 데이터는 새로운 곳에 저장 됩니다.

결국 테이블 조회시 기존 보다 훨씬 많은 페이지를 조회해야 되기 때문에 IO가 증가 됩니다.

Forwarded Record가 발생했을 때 해결 방법이 몇 가지 있는데 

데모를 통해 확인하고 방법을 공유해 보도록 하겠습니다.

▶ 테스트용 테이블을 만들고 DMV를 통해 해당 테이블 내  Forwarded Record 카운트를 확인

USE AdventureWorks2008R2;

GO

IF EXISTS    (

                      SELECT  1

                      FROM   sys.tables

                      WHERE  NAME = 'Address2'

                      AND       SCHEMA_ID = 1

                  )

           DROP TABLE dbo.Address2;

GO

-- 테이블복사

SELECT  *

           ,          CONVERT(VARCHAR(500), 'comments') AS comments

INTO    Address2

FROM   Person.Address;

GO

-- Address2 테이블forwarded_record_count 조회

SELECT           index_type_desc

           ,          page_count

           ,          avg_page_space_used_in_percent

           ,          avg_record_size_in_bytes

           ,          forwarded_record_count

FROM   sys.dm_db_index_physical_stats(DB_ID('AdventureWorks2008R2'), OBJECT_ID('Address2'), NULL, NULL, 'detailed');

GO

▷ 변경사항이 없기 때문에 Forwarded Record 카운트가 0 인 것 을 확인 가능

▶ 가변형 컬럼에 기존 값 보다 큰 값을 업데이트하고 IO 확인

-- 기존저장된값보다큰값으로업데이트

UPDATE         Address2

SET               comments = REPLICATE('a', 500);

GO

-- Address2 테이블forwarded_record_count 조회

SELECT           index_type_desc

           ,          page_count

           ,          avg_page_space_used_in_percent

           ,          avg_record_size_in_bytes

           ,          forwarded_record_count

FROM   sys.dm_db_index_physical_stats(DB_ID('AdventureWorks2008R2'), OBJECT_ID('Address2'), NULL, NULL, 'detailed');

GO

▷ Forwarded Record 카운트가 증가 확인

-- IO 확인

SET STATISTICS IO ON;

SELECT  *

FROM   Address2;

SET STATISTICS IO OFF;

▷ 테이블 검색 시 논리적 읽기 수(page_count + forwarded_record_count) 확인

    Logical IO가 증가되어 성능에 영향을 미칠 수 있습니다.

★ Solution

▶ 증가되어 있는 값을 축소 시킨다.

-- 기존값은제거

UPDATE Address2

SET                 comments = '';

GO

SELECT           index_type_desc

           ,          page_count

           ,          avg_page_space_used_in_percent

           ,          avg_record_size_in_bytes

           ,          forwarded_record_count

FROM   sys.dm_db_index_physical_stats(DB_ID('AdventureWorks2008R2'), OBJECT_ID('Address2'), NULL, NULL, 'detailed');

GO

▷ 많이 감소 하였지만 완전한 해결책은 되지 못한다.

▶ Forwarded Record는 Heap 테이블에서 발생하므로 Clustered Index를 생성한다. 

-- 클러스터인덱스생성BEST

CREATE CLUSTERED INDEX cix_Address2_AddressID ON Address2(AddressID);

GO

SELECT           index_type_desc

           ,          page_count

           ,          avg_page_space_used_in_percent

           ,          avg_record_size_in_bytes

           ,          forwarded_record_count

FROM   sys.dm_db_index_physical_stats(DB_ID('AdventureWorks2008R2'), OBJECT_ID('Address2'), NULL, NULL, 'detailed');

GO

▷ Clustered Index가 생성되면서 Forwarded Record 해결

▶ SQL Server 2008 이상 버전이라면 테이블 리빌드 작업으로 해결 가능하다. 

-- 테이블리빌드SQL Server 2008 이상가능

ALTER TABLE Address2 REBUILD;

GO

SELECT           index_type_desc

           ,          page_count

           ,          avg_page_space_used_in_percent

           ,          avg_record_size_in_bytes

           ,          forwarded_record_count

FROM   sys.dm_db_index_physical_stats(DB_ID('AdventureWorks2008R2'), OBJECT_ID('Address2'), NULL, NULL, 'detailed');

GO

▷ 테이블 리빌드로 해결 가능 확인

관리중인 서버에 Forwarded Record가 증가된 힙 테이블이 존재한다면

위에서 제시한 방법을 통해 해결하시는 것도 고려해 보시길 바랍니다.

Reference : http://sqlblog.com/blogs/kalen_delaney/archive/2008/05/25/whats-worse-than-a-table-scan.aspx

SQL Server 2012에서 Identity 컬럼이 Restart 후 점프 이슈가 있다.

해결방법 :

 1. Identity 속성을 제거하고 시퀀스 열을 사용

 2. 시작 매개변수 -t272 추가