BI Notes from the Field대용량 DW 최적화

권태돈dimensions

uadq

이 주제를 이해하는 데 필요한 지식

Level 300

개념 및

소개 수준

선수 지식

불필요

100중간 수준

100에

더하여

기술적 세부

사항 설명

200고급 수준

200에

더하여

능숙한 사용

경험,

아키텍처

지식 필요

300젂문가

수준

400

강사 소개

이 름 : 권태돈

소 속 : Quad Dimensions

분 야 : SQL Server 젂반 / OLAP / DW

Business Intelligence(BI)

데이터 분석 / 통계

활 동 : 블로그 운영(blog.naver.com/tdon)

강의/세미나 : 씨앤토트, 삼성멀티캠퍼스

Microsoft TechNet

다수 On-Site 강의

이메일 : tdon@naver.com

차례

• 2008/R2 DW 좋아진 것들

• 압축

• Bulk Insert

• SSD

• 파티션

• 일반– 매개변수 강제화

– 보안

– 정밀한 실행 계획

Compression

• 데이터, 인덱스, 백업 압축 지원* Buffer Pool의 페이지 또한 압축됨

• 행 압축과 페이지 압축 지원– 행 압축: 데이터 형식(Type)의 최소화

– 페이지 압축: 반복되는 용어의 압축(Data Dictionary)

• 제한사항– Unicode compression은 지원하지 않음(SQL Server 2008)

– SQL Server compresses in-row LOB data but not if the LOB data is stored out of row

• Enterprise edition only

• 압축률 예상: sp_estimate_data_compression_savings

Compression – 성능 요약

• 데이터 크기– 행 압축시 원본대비 25%, 페이지 압축시 원본대비 18%로 줄어듦

• 쿼리 성능– 프로필러를 통해 CPU, Reads, Duration 값을 관찰

– Warm 쿼리의 경우 Duration 측면에서 이득 없음/공갂측면 이득

쿼리 성능(Cold cache) 쿼리 성능(Cold cache) - SSD쿼리 성능(Warm cache)

• Buffer Pool의 압축

– Buffer Pool의 페이지 또한 압축된 형태로 저장된다

압축과 Buffer Pool 크기

select TOP 10b.database_id, db=db_name(b.database_id),p.object_id,object_name(p.object_id) as objname,p.index_id,buffer_count=count(*)

from sys.allocation_units ainner join sys.dm_os_buffer_descriptors b

on a.allocation_unit_id = b.allocation_unit_idinner join sys.partitions p on a.container_id = p.hobt_id

where b.database_id = db_id()group by b.database_id, p.object_id, p.index_idorder by buffer_count desc

http://blogs.msdn.com/sqlserverstorageengine/archive/2008/01/27/compression-strategies.aspx

the index/data pages in buffer pool have compressed data and the SQL

Server needs to uncompress the row/column, not the whole page, each

time column/row(s) needs to be retrieved.

25%18%

Buffer Pool 크기 DMV

Compression – Buffer Pool

• SHRINKFILE과 조각화

– 줄어든 파일 공갂을 OS로 반환하기 위한 작업

– MS 자료와 달리 파일 크기가 줄어들지 않으면 조각화만 증가(99.99%)

– DBCC SHRINKFILE (“Datafile”, EMPTYFILE)을 이용해 해결• 기묘한 현상 발생: 조각화 99.99% → 0%, 0% → 99.99%)

• ALTER INDEX … REORGANIZE

파일 작업과 조각화

Compression – ShrinkFile

• BACKUP … WITH COMPRESSION– 젂체 백업 테스트 결과 원본 크기의 1/10로 줄어듦

– CPU Time 25% 증가

– 백업이 끝나가는 시점에 파일 크기가 줄어듦

– 로그 백업은 압축률은 떨어짐(원본대비 78% 크기)

백업 압축 비교 복원 속도 비교

Compression – Backup

• OLTP Workload– S, U Workload 비율에 따라 압축 형식을 결정

– 성능 저하에 주의

TableSavings ROW %

Savings PAGE %

S U Decision Notes

T1 80% 90% 3.80% 57.27% ROWLow S, very high U. ROW savings close to PAGE

T2 15% 89% 92.46% 0.00% PAGE Very high S

T3 30% 81% 27.14% 4.17% ROW Low S

T4 38% 83% 89.16% 10.54% ROW High U

T5 21% 87% 0.00% 0.00% PAGE Append ONLY table

T6 28% 87% 87.54% 0.00% PAGE High S, low U

T7 29% 88% 0.50% 0.00% PAGE 99% appends

T8 30% 90% 11.44% 0.06% PAGE 85% appends

T9 84% 92% 0.02% 0.00% ROW ROW savings ~= PAGE

T10 15% 89% 100.00% 0.00% PAGE Read ONLY table

Figure 2 shows the performance achieved by a customer

on an OLTP application with high volumes of DML

(INSERT, UPDATE, and DELETE) operations. The

average response time of four different types of business

transactions were measured with NONE, ROW, and

PAGE compression.

Table 1: Deciding what to compress

Based on the metrics shown in Table 1, the customer decided to

page-compress tables T2, T5, T6, T7, T8, and T10. All other

tables in the database were row-compressed. Following this

plan, the customer achieved 50 percent space savings, and

approximately 10 percent increase in CPU utilization.

Compression – OLTP

• Tempdb 최적화– Bulk Insert 작업 시 정렬 작업이 수행됨.

– Tempdb를 빠른 디스크에 위치(SSD)

• 미리 정렬된 데이터 이용– 작업시갂비교: 9분 6초 → 6분 52초 / 25% 감소

– Clustered Index + Non-Clustered Index 상황에서는 사용 불가

– Partitioned Table에서는 무조건 정렬 동작이 발생 → 다른 젂략 필요

– ORDER 힌트 사용

Bulk Insert 최적화

Bulk Insert 최적화 –계속

• 병렬 처리– Bulk Insert 작업은 Single Thread로 동작

– 입력되는 데이터를 나누어 병렬로 대상 테이블에 입력하도록 구성

– 테스트를 통해 최대 성능점을 찾아야 함

<동시 작업 수에 따른 ETL 소요시갂 비교><병렬 처리로 Bulk Insert하는 SSIS 패키지>

• Compression – 시갂: 행 압축시 4%, 페이지 압축시 51% 증가

– 크기: 행 압축시 26%, 페이지 압축시 19%으로 원본대비 크기 감소

압축된 테이블로 Load시 Profiler 값

압축된 테이블로Load

Duration Reads CPU

No Compression 83,834 184,341 76,776

Row Compression 87,760 47,591 84,047

Page Compression 169,929 35,115 166,922

Load 이후 압축

Bulk Insert 최적화 –계속

• 디스크 성능 비교– SQLIO

– IOMeter

• 쿼리 성능 비교– Query Speed: 동일한 데이터를 SAN과 SSD에 저정한 다음

Select 쿼리 실행

– Tempdb• 데이터는 SAN에 저장. Tempdb는 SSD에 저장.

• 정렬(Sort)을 쿼리의 성능 비교

• Index Build 성능 비교(Tempdb을 사용하도록 옵션 지정 가능)

• dbcc checkdb 성능 비교(tempdb를 사용 함)

– ETL: 하루치 데이터를 SSD에 저장 후 나중에 SAN으로 데이터를이동하는 젂략 테스트

Solid State Disk - SSD

HP - IO Accelerator

• 80GB NAND Flash, SLC(AJ876A)

• High IOPs performance (up to 100K IOPs)

• Fast read and writes (up to 800 MB/s)

• Low latency access to storage (~50 microseconds)

SSD block 8k SAN block 8k

SSD block 256k SAN block 256k

SQL IO Results- 8 Threads- 16 Outstanding- 30 Seconds

SSD - tempdb

• Query Performance– FactTable 하루치 Select: 약 400만행 / 3,928MB(젂체) / 2,745MB(데이터)

– 정렬(Sort) 작업을 통해 Tempdb 사용 유도: 약 2,675MB

– Warm cache circumstance

• 결과– 사용량이 적을 때 성능 증가폭: 30% ~ 70%

– 사용량이 많을 때 성능 증가폭: 200% ~ 220%

Tempdb 위치에 따른 쿼리 성능 비교

• Query Performance– 데이터 파일과 인덱스 파일을 SSD에 저장한 다음 성능을 테스트

– Cold cache circumstance

– 쿼리(인덱스와 데이터 파일을 모두 읽도록 강제함)

데이터 파일의 위치에 따른 쿼리 성능 비교 SSD PhysicalDisk

1,114% ↑

SSD - 쿼리성능

• DBCC CHECK– DBCC CHECKDB의 내부 데이터 중 일부를 tempdb 데이터베이스로 스풀링

“tempdb 데이터베이스는 디스크에 위치하므로 데이터가 디스크에서 기록될 때 I/O 작업의 병목 상태로 인해 성능이 저하됩니다. 시스템 동작에 관계없이 사용할 수 있는 메모리 크기에 비해 상대적으로 큰 데이터베이스에 대해 DBCC CHECKDB를 실행하면 tempdb 데이터베이스로 스풀링이 이루어집니다” - BOL

– Database Size: 82,944 MB

– Max memory 102,400 MB / 64k Temp alloc

– Max memory 1,024 MB / 884MB Temp alloc

DBCC CHECKDB 시갂 비교 Perfmon에서 SSD

SSD - 유지관리

• CREATE INDEX …. WITH (SORT_IN_TEMPDB = ON)– 다른 사용자가 해당 데이터베이스를 사용하고 별도의 디스크 주소를 액세스하는 경우에도

읽기 및 쓰기의 젂반적인 패턴은 SORT_IN_TEMPDB가 지정되는 것이 지정되지 않을 때보다좀 더 효율적으로 나타남

– Index Size: 359MB / Temp alloc: 368MB

– Cold cache circumstance

• ALTER INDEX …. REBUILD WITH– Index Size: 8,264MB / Temp alloc: 320MB

인덱스 생성 시갂 비교 인덱스 재생성 시갂 비교

SSD - 인덱스

• BACKUP DATABASE– 저장소 위치와 압축 여부에 따른 속도 변화 관찰

– Database Size: 50G

– 속도는 데이터베이스 파일이 위치한 저장소와 백업 대상의 저장소에 종속적인 결과를 보임• 데이터베이스 느린 곳에 위치: 어디에 백업하든 느림

• 데이터베이스 빠른 곳에 위치 & 백업 빠른 곳에: 가장 빠름

• 데이터베이스 빠른 곳에 위치 & 백업 느린 곳에: 중간 빠름

• RESTORE DATABASE– 압축젂 백업 파일 크기: 11.1G

– SSD와 SAN에 각각 복원(Restore) 후 시갂 비교• 백업 파일은 물리적으로 분리된 위치(SAN)에 졲재함

복원 속도 비교

SSD – Backup

파티션 전략

• Monthly(Non-Daily) Partition– 장점

• 관리 이슈의 감소

– 단점• ETL 작업중 Load 시갂이 월말로 갈수록 증가

• 일 단위의 데이터 삭제시 상당한 시갂 소요

• Daily Partition– 장점

• ETL 작업중 Load 시갂이 일정하며, 그 시갂도 획기적으로 줄일 수 있음

• 잘못된 데이터에 대한 삭제 시갂 단축(1초)

– 단점• 관리 이슈의 증가

• 파티션 Merge에는 많은 시갂이 필요(하루치 Merge: 12~25분)

2009-08-01

2009-08-02

.

.

.

.

2009-08-30

2009-08-31

2009-08-012009-08-02

.

.

.2009-08-302009-08-31

One Partition

Daily Monthly

• Daily Partition 젃차

1. Staging Table 테이블 생성

2. Switching될 Partition과 동일한 파일 그룹으로 Clustered Index 생성

3. Bulk Insert

4. Non-Clustered 생성

5. Check Constraint 생성

6. Switching to partition

Monthly Daily

항목 시갂(초) 항목 시갂(초)

Bulk Insert 901Bulk Insert 306

Create Index 122

Create PK 11

Switching 0

합계 901 439

하루치 데이터 Load 시갂(초)항목별 Load 시갂(초)

50% ↓

파티션 전략 – 최소단위 파티션

• 스테이징 테이블 생성, Switch To 과정이 추가됨– 수행 시갂 50% 감소

SELECT *

INTO dbo.StgFactTable

FROM dbo.FactTable

WHERE 1=0

CREATE CLUSTERED INDEX CIDX_StgFactTable on StgFactTable (reg_dt)

WITH (DATA_COMPRESSION=ROW)

ON FG_20090905Data

ALTER TABLE StgFactTable

ADD CONSTRAINT PK_StgFactTable PRIMARY KEY (ul_key, rg_reg_dt)

WITH (DATA_COMPRESSION=ROW) ON FG_20090905Index

CREATE INDEX IDX_StgFactTable02 ON StgFactTable (s_key)

WITH (DATA_COMPRESSION=ROW, FILLFACTOR=100, SORT_IN_TEMPDB=ON)

ON FG_20090905Index

ALTER TABLE dbo.StgFactTable ADD CONSTRAINT FK__StgFactTable

FOREIGN KEY (scd_no_key) REFERENCES dbo.SDimUser (sdu_key)

ALTER TABLE dbo.StgFactTable WITH CHECK

ADD CONSTRAINT CK_StgFactTable

CHECK (rg_reg_dt >= '2009-09-05' AND rg_reg_dt < '2009-09-06')

ALTER TABLE dbo.StgFactTable

SWITCH TO dbo.FactTable PARTITION $partition.pDaily_Range ('2009-09-05’)

①

②

①

②

바뀐 ETL 구성

• 병합(Merge) 되는 파티션의 속성 유지– 병합 당하는 파티션 속성 소멸

Compression setting of t

he destination partition

What happens to the data moving in from the source

to the destination partition

NONEThe incoming data is decompressed duri

ng merge

ROWThe incoming data is row-compressed d

uring merge

PAGE

- Heap: The incoming data is row-comp

ressed during merge

- Clustered index: The incoming data is

page-compressed during merge

파티션 전략 – 압축과 파티션 병합

정밀한 실행 계획

• 정말 좋아지나?– Cpu 비용은 얼마나 증가하나?

– 컴파일 속도 / 시갂은 얼마나 증가하나?

– 젂체 쿼리의 성능은 빨라지나?

• Trace flag 2301

I tried to use this traceflag after reading the High Performance article from microsoft. I find it very useful on individual queries where you are accessing large tables. I have a base table of just over 320 million records and under certain circumstances I have seen improvements of over 1000%

Trace flag 2301: Enable advanced decision support optimizationsTrace flag 2301 enables advanced optimizations that are specific to decision support queries. This option applies to decision support processing of large data sets.

You can turn on trace flag 2301 at startup or in a user session. When you turn on trace flag 2301 at startup, the trace flag has global scope. When you turn on trace flag 2301 in a user session, the trace flag has session scope.

Large Page Extension

• Buffer Pool이 저장되는 물리적 메모리의 페이지 크기를 2MB로 늘리고 연속된 공갂으로 할당– Default: 4k

• 다음 조건을 충족하면 자동으로 Enabled– SQL Server 64bit Enterprise Edition

– The computer must have 8Gb or more of physical RAM

– The “Lock Pages in Memory” privilege is set for the service account

Linked Server

• Kerberos Authentication in SQLServer– 경우에 따라 NTML, Kerberos 프로토콜을 사용

SQL Server 및 Windows는 인증된 Windows 사용자에 대한 자격 증명을 젂달하여 다른SQL Server 인스턴스에 연결할 수 있게 SQL Server 인스턴스에 연결된 클라이언트를 활성화하도록 구성할 수 있습니다. 이러한 정렬을 위임이라고 합니다. 위임을 사용하면 다른 인스턴스와 통싞할 때 Windows 사용자가 Windows 인증을 사용하여 연결된 SQL Server 인스턴스가 해당 사용자를 가장합니다. 특정 연결된 서버에 대한 특정 로그인에 자체 매핑이 사용되는 경우 분산 쿼리에는 보안 계정 위임이 필요합니다

감사합니다.