fast track data warehouse reference guide for...
TRANSCRIPT
SQL Server 2012 를 위한 Fast Track 데이터 웨어하우스 참조 가이드
SQL Server 기술 문서
작성자: Eric Kraemer, Mike Bassett, Eric Lemoine, Dave Withers
기술 관련 검토자: Claude Lorenson, Susan Price, Ralph Kemperdick, Henk van der Valk, Alexi Khalyako, Oliver Chiu
게시일: 2012 년 3 월
적용 대상: SQL Server 2012
요약: 이 백서에서는 리소스 부하 분산 방식을 사용하여 데이터 웨어하우스 작업에 대해 성능 및 확장성이 입증된 SMP(대칭적 다중 프로세서) 기반의 SQL Server 데이터베이스 시스템 아키텍처를 구현하는 참조 구성 모델(Fast Track 데이터 웨어하우스)을 정의합니다. Fast Track 데이터 웨어하우스 참조 아키텍처의 목표는 SQL Server 데이터 처리 능력과 실제 구성 요소 하드웨어 처리량 간에 효율적으로 리소스 부하를 분산하는 것입니다.
저작권
이 문서는 "있는 그대로" 제공됩니다. URL 및 기타 인터넷 웹 사이트 참조를 포함하여 이 문서의 내용 및 의견은 예고 없이 변경될 수 있습니다. 본 문서의 사용으로 발생하는 위험은 귀하의 책임입니다.
이 문서는 Microsoft 제품의 지적 재산에 대한 법적 권한을 제공하지 않습니다. 이 문서는 내부 참조용으로만 복사 및 사용할 수 있습니다.
© 2012 Microsoft. All rights reserved.
2
목차저작권.........................................................................................................................................................2
FTDW 변경 내역.........................................................................................................................................6
소개.............................................................................................................................................................6
대상.........................................................................................................................................................6
Fast Track 데이터 웨어하우스...................................................................................................................7
Fast Track.................................................................................................................................................7
가치 제안................................................................................................................................................7
방법론.........................................................................................................................................................8
전체적인 구성 요소 아키텍처..............................................................................................................8
작업 최적화 방법...................................................................................................................................8
유효성이 확인된 SQL Server Fast Track 참조 구성...............................................................................9
요약.........................................................................................................................................................9
FTDW 작업..................................................................................................................................................9
데이터 웨어하우스 작업 패턴..............................................................................................................9
작업 평가..............................................................................................................................................10
질적 데이터 웨어하우스 작업 특성...................................................................................................12
FTDW 참조 구성 선택..............................................................................................................................13
방법 1: 기본 평가.................................................................................................................................13
1 단계: 고객 사용 사례 평가...............................................................................................................13
2 단계: 게시된 FTDW 참조 아키텍처 선택.....................................................................................15
방법 2: 전체 평가.................................................................................................................................15
프로세스 개요..................................................................................................................................15
1 단계: 고객 사용 사례 평가...........................................................................................................15
2 단계: 평가 메트릭 설정................................................................................................................16
3 단계: Fast Track 데이터 웨어하우스 참조 아키텍처 선택..........................................................17
방법 3: 사용자 정의 참조 아키텍처...................................................................................................17
1 단계: 작업 정의.............................................................................................................................17
3
2 단계: 구성 요소 아키텍처 벤치마크 설정..................................................................................17
FTRA 선택 요약.....................................................................................................................................18
FTDW 표준 구성.......................................................................................................................................19
하드웨어 구성 요소 아키텍처............................................................................................................19
구성 요소 요구 사항 및 구성..........................................................................................................20
응용 프로그램 구성.............................................................................................................................21
Windows Server 2008 R2...................................................................................................................21
SQL Server 2012 Enterprise...............................................................................................................22
저장 시스템......................................................................................................................................23
SQL Server FTDW 의 최선의 구현 방법...................................................................................................27
데이터 아키텍처..................................................................................................................................28
테이블 구조......................................................................................................................................28
테이블 파티션..................................................................................................................................29
인덱싱...............................................................................................................................................29
xVelocity 인메모리 Columnstore 인덱스.........................................................................................30
데이터베이스 통계..........................................................................................................................31
압축...................................................................................................................................................32
데이터 조각화 관리.............................................................................................................................32
파일 시스템 조각화.........................................................................................................................33
여러 파일 그룹.................................................................................................................................35
데이터 로드..........................................................................................................................................35
증분 로드..........................................................................................................................................35
데이터 마이그레이션......................................................................................................................38
벤치마킹 및 유효성 검사.......................................................................................................................39
기준 FTDW 유효성 검사 수행.............................................................................................................40
기준 SQLIO 테스트...........................................................................................................................41
Fast Track 데이터베이스 벤치마크 수행............................................................................................43
MCR 계산..........................................................................................................................................44
BCR 계산............................................................................................................................................46
게시된 FTDW 참조 아키텍처..................................................................................................................48
4
결론...........................................................................................................................................................48
부록...........................................................................................................................................................49
FTDW 시스템 크기 조정 도구.............................................................................................................49
사용자 정의 FTRA 유효성 검사...........................................................................................................49
가상 I/O 테스트................................................................................................................................49
SQLIO 테스트 파일 생성..................................................................................................................50
작업 테스트..........................................................................................................................................52
서버에 대한 MCR 측정( 선택 사항).................................................................................................52
작업에 대한 BCR 측정.....................................................................................................................53
쿼리 사용률에 영향을 주는 요인...................................................................................................57
5
FTDW 변경 내역다음 표에는 Fast Track 데이터 웨어하우스 참조 가이드의 버전별 릴리스에 대한 중요 변경 내용 또는 업데이트에 대한 내용이 나와 있습니다.
설명 버전 참고 위치SQL Server 2012 의 새 기능
4.0기타 SQL Server 최선의 구현 방법에 대한 링크
중요
SQL Server 2012 의 새 기능
4.0 벤치마킹 및 유효성 검사 주의
SQL Server 2012 의 새 기능
4.0 메모리 요구 사항 RAM
SQL Server 2012 의 새 기능
4.0xVelocity 메모리 최적화 columnstore 인덱스
columnstore 인덱스
SQL Server 2012 의 새 기능
4.0 반도체 저장소 반도체
SQL Server 2012 의 새 기능
4.0유효성 검사 및 columnstore 인덱스
유효성 검사
SQL Server 2012 의 새 기능
4.0 기준 I/O 의 유효성 검사 SQLIO
표 1: 변경 내역
소개이 문서에서는 SQL Server FTDW(Fast Track 데이터 웨어하우스) 프로그램의 구성 요소 아키텍처 및 방법론에 대해 정의합니다. 이 방법으로 소프트웨어 및 하드웨어를 비롯한 최소한의 Microsoft SQL Server 데이터베이스 시스템 아키텍처의 유효성을 검사할 수 있으며, 이는 많은 데이터 웨어하우징 작업에 대한 기본적인 성능 수준을 달성하고 유지하는 데 필요합니다.
대상이 문서는 FTDW 를 준수하는 SQL Server 작업을 위해 입증된 표준 시스템 아키텍처를 선택하려는 IT 기획자, 설계자, DBA 및 BI(비즈니스 인텔리전스) 사용자를 대상으로 합니다.
6
Fast Track 데이터 웨어하우스 SQL Server Fast Track 데이터 웨어하우스 이니셔티브에서는 데이터 웨어하우징 작업을 위해 부하가 분산된 하드웨어 및 데이터베이스 구성을 배포하는 기본적인 방법론과 구체적인 예제를 다룹니다. 자세한 내용은 이 문서의 FTDW 작업 섹션을 참조하십시오.
SQL Server 설치 시 저장소, 서버, 저장소 네트워크, 데이터베이스, 운영 체제와 같은 핵심 시스템 구성 요소 간에 부하를 분산하는 것이 중요합니다. 이러한 각 구성 요소는 최적의 구성을 위해 조정됩니다. 목표는 SQL Server 데이터 처리 능력 및 하드웨어 구성 요소 리소스 간에 기본적인 부하 분산을 효율적으로 잘 유지하는 것입니다. 이렇게 하면 최소한의 시스템 하드웨어로 데이터 웨어하우징 작업을 위한 저장소 및 성능 요구 사항을 충족할 수 있습니다.
Fast TrackSQL Server Fast Track 브랜드는 FTDW 참조 아키텍처(FTRA)의 원칙을 따르는 구성 요소 하드웨어 구성을 식별합니다. 각 FTRA 는 작업과 핵심 구성 집합, 유효성 검사 및 데이터베이스 최선의 구현 방법 지침으로 정의됩니다. Fast Track 프로그램의 핵심 원리는 다음과 같습니다.
작업 관련 벤치마크. 시스템 설계 및 구성은 실시간 동시 쿼리 작업을 기반으로 합니다. 유효성이 검증된 상세한 하드웨어 구성 요소 사양 데이터베이스 기능 및 핵심 하드웨어 리소스 간의 구성 요소 아키텍처 부하 분산
가치 제안FTDW 가치 제안의 기초 원리는 다음과 같습니다.
시스템의 핵심 구성 요소 간 예정된 부하 분산. 이를 통해 응용 프로그램 수준에서 인식되지 않는 CPU 또는 저장소 리소스의 과용 위험을 최소화합니다.
예측 가능한 기본 성능. Fast Track 구성은 선택한 서버 및 작업을 위한 SQL Server 응용 프로그램의 기능에 맞게 설정되었습니다.
작업 중심. 데이터베이스 구성에 대해 범용 접근 방식 대신 FTDW 접근 방식을 사용하여 데이터 웨어하우스 사용 사례에 맞춥니다.
7
방법론
전체적인 구성 요소 아키텍처SQL Server FTDW 참조 아키텍처는 데이터베이스 시스템 아키텍처 핵심 구성 요소 간에 복잡한 관계를 균형 있게 조정하는 실용적인 프레임워크를 제공합니다. 그림 1 에는 일반적으로 스택이라고 하는 구성 요소 아키텍처가 나와 있습니다.
그림 1: Fast Track 데이터베이스 구성 요소 아키텍처의 예
스택의 각 구성 요소는 SQL Server 의 데이터를 처리하는 데 필요한 일련의 작업에서 서로 연결됩니다. 스택을 통합 시스템으로 평가하면 각 구성 요소에 대해 실제 대역폭을 설정하는 벤치마킹이 가능합니다. 이렇게 함으로써 개별 구성 요소에서 SQL Server 응용 프로그램의 기능에 맞는 충분한 처리량을 정해진 스택에 제공할 수 있습니다.
작업 최적화 방법다양한 데이터베이스 응용 프로그램 작업에서 최적으로 리소스 부하를 분산하려면 매우 다양한 구성 요소 아키텍처가 필요할 수 있습니다. 전형적인 예는 소규모 요청, 조회 기반 OLTP(의 온라인 트랜잭션 처리) 작업, 집중적인 검사, 대규모 요청, 분석 데이터 웨어하우징 간의 비교에서 찾을 수 있습니다. OLTP 작업에서는 데이터 집합의 기록 데이터 볼륨이 거의 없는 경우 적은 수의 행을 적은 대기 시간으로 검색하도록 많은 인덱스를 사용합니다. 이러한 유형의 데이터베이스 작업에서는 상당한 디스크 헤드 이동이 이루어지며 전형적인 임의 I/O 검사 패턴이 생성됩니다. 데이터 웨어하우징 등과 같은 분석 작업에서는 훨씬 많은 데이터 요청이 발생하므로 순차 디스크 검사의 총 처리량이 증가하면 상당한 효과를 볼 수 있습니다.
8
이렇게 비교해 볼 때 구성 요소 스택의 부하 분산은 중요한 의미를 가집니다. 평균적으로 최신 SAS 디스크 드라이브에 대한 디스크당 임의 I/O 검사 속도는 동일한 하드웨어를 순차적으로 검사하는 속도에 비해 10 배 느릴 수 있습니다. Fast Track 데이터 웨어하우징 작업은 초당 작업 속도(IOPS)에 중점을 두는 기존의 방식과 달리 I/O 검사 속도(MB/s)를 높게 유지하는 데 중점을 둡니다.
작업이 매우 다양하더라도 고객 작업의 특성을 명확하게 정의하여 처리할 수 있습니다. SQL Server Fast Track 작업은 일반적인 데이터베이스 응용 프로그램 용도를 고유하게 정의하는 질적 특성 목록으로 구성됩니다. 또한 각 작업은 표준 벤치마크 쿼리를 포함한 양적 측정으로 나타납니다. 작업 관련 벤치마킹은 데이터베이스 구성, 모범 사례 및 구성 요소 하드웨어 권장 사항의 유효성을 검사하는 데 사용됩니다.
유효성이 확인된 SQL Server Fast Track 참조 구성게시된 모든 Fast Track 참조 아키텍처는 이 참조 가이드에 나와 있는 일련의 원칙 및 지침에 따라 유효성이 확인되었습니다. 이 프로세스의 예는 이 문서의 뒷부분에 나와 있습니다.
요약이 참조 가이드에 설명된 SQL Server FTDW 사양은 작업 중심으로 구성 요소 간 부하를 분산합니다. 이 접근 방법은 범용 프로비전이 여러 데이터베이스 사용 사례에서 비효율적이며 비용이 많이 들 수 있음을 보여 줍니다. 점점 까다로워지는 비즈니스 요구 사항과 빠르게 증가하는 데이터 볼륨을 충족하려면 보다 현실적인 접근 방식이 필요합니다. 이 문서에서는 규범적인 참조 아키텍처의 조합을 제시하고 하드웨어 및 소프트웨어 구성 요소를 벤치마킹하며 대상 작업을 명확하게 규정함으로써 구성 요소 아키텍처 간에 부하를 분산할 수 있는 실용적인 접근 방식을 설명합니다.
FTDW 작업
데이터 웨어하우스 작업 패턴일반적으로 데이터 웨어하우스에 질의하려면 대용량 데이터에 액세스해야 합니다. 데이터 웨어하우스는 금융, 마케팅, 운영 및 연구 팀과 같은 다양한 사용자의 광범위한 쿼리를 지원해야 합니다.
기존 데이터 웨어하우스 시스템의 한계를 극복하기 위해 조직에서는 인덱스 작성, 데이터 사전 집계, 하위 수준의 데이터 액세스 제한 등 기존의 RDBMS 최적화 기술을 사용하여 재정렬했습니다. 이러한 접근 방법과 관련된 과다한 유지 관리 오버헤드로 인해 충분한 일괄 처리 시간이 종종 부족해질 수 있습니다. 데이터 웨어하우스가 더 커지고 사용자 수가 증가하면 이러한 사용 사례별 최적화는 더 어려워지며 수신이 지연되는 데이터나 데이터 수정의 경우 특히 더 그렇습니다.
9
이 문제에 대한 일반적인 솔루션은 단순히 드라이브를 추가하는 것입니다. 검색 기반 I/O 인프라를 스캔 기반 작업으로 매핑할 때 I/O 성능 한계를 극복하기 위해 비교적 작은 데이터웨어 하우스를 지원하는 수백 개의 디스크를 사용하는 것은 보기 드문 일이 아닙니다. 이는 기존의 검색에 최적화된 대규모 공유 SAN(저장 영역 네트워크) 환경에서 자주 볼 수 있습니다. 임의 I/O 액세스를 권장하는 많은 저장소 I/O 참조 패턴 및 기술 덕분에 디스크 대기 시간이 도입되었으며 검사를 집중적으로 실행하는 데이터 웨어하우스 작업에 대한 전반적인 저장소 하위 시스템 처리량이 줄어들었습니다.
Fast Track 데이터 웨어하우스는 이와 다른 방식으로 데이터 웨어하우스 작업을 최적화합니다. 검색 대신 효율적인 디스크 검사 액세스를 통해 데이터베이스 파일과 구성을 조정함으로써 개별 디스크에서 얻을 수 있는 성능을 훨씬 높일 수 있습니다. 이렇게 디스크당 성능이 높아지면 적은 수의 디스크로도 주어진 작업의 데이터를 처리하기 위한 SQL Server 의 기능을 충족하는 I/O 처리량을 달성할 수 있습니다. 또한 디스크 검색 성능을 높이는 데 사용되는 인덱스 기반의 일부 최적화 기술을 사용하지 않아도 됩니다.
작업 평가FTDW 기반 시스템에 대한 작업을 분석할 때 이 문서에 설명된 시스템 구성 및 실례와 맞는지 고려해야 합니다. 데이터 웨어하우스 요구 사항은 고객별로 다를 수 있으며 데이터베이스 복제와 같은 특정 요구 사항은 일부 FTDW 설계 시스템에 적합하지 않을 수도 있습니다. 여기서는 이러한 유형의 작업 평가를 위한 핵심적인 기본 조건을 설명합니다.
집중적인 검사
데이터 웨어하우스 작업의 쿼리는 많은 행을 빈번하게 검사합니다. 따라서 디스크 검색 시간이 많이 걸리는 트랜잭션 작업에 비해 디스크 검사 성능의 중요도가 높습니다. FTDW 참조 아키텍처는 하드웨어 및 데이터베이스 소프트웨어 구성 요소를 핵심 우선순위인 디스크 검사 성능에 맞게 최적화합니다. 따라서 순차 디스크 읽기의 효율성이 높고 상관된 드라이브당 디스크 I/O 처리량이 증가합니다.
비변동성
작성된 데이터가 거의 변경되지 않습니다. SQL 업데이트와 같이 동일한 데이터베이스 테이블과 연결된 페이지를 인접 정렬 밖으로 이동하는 DML 작업은 주의해서 관리해야 합니다. 일반적으로 이러한 변동성 작업은 FTDW 와 조화를 이루지 않을 수 있습니다. 변동성 작업이 수행될 경우 조각화를 최소화하기 위해 정기적으로 유지 관리를 수행하는 것이 좋습니다.
10
인덱스 라이트
비클러스터형 인덱스를 추가하면 일반적으로 한 개 또는 몇 개의 레코드를 조회할 수 있는 성능이 추가됩니다. 상당 수의 행을 검색할 테이블에 비클러스터형 인덱스를 적용하면 임의 디스크 검색 작업이 증가하여 전체 시스템 성능이 저하될 수 있습니다. 인덱스 유지 관리는 상당한 데이터 관리 오버헤드를 가중시킬 수 있으며 이로 인해 SLA(서비스 수준 계약) 및 데이터베이스 로드 시간을 충족하지 못할 위험이 발생할 수 있습니다.
반면, 순차 검사 속도는 임의 액세스 속도보다 10 배 이상 높아질 수 있습니다. 임의 검색 사용을 최소화하고 보조 인덱스 사용을 유도하는 시스템은 일반적으로 평균 지속 I/O 속도가 훨씬 높습니다. 이는 저장소 I/O 리소스를 보다 효율적으로 사용하고 대규모 검사 유형의 쿼리 성능을 더 잘 예측할 수 있다는 의미입니다.
FTDW 방법론에서는 대상 작업의 특성에 맞는 데이터베이스 최적화 기술을 규정합니다. 클러스터형 인덱스와 범위 분할은 효율적인 검사 기반 디스크 I/O 를 지원하는 데이터 구조의 예이며, FTDW 환경에서 데이터 아키텍처 기반 최적화를 위해 이러한 기능을 기본 도구로 사용하는 것이 좋습니다.
파티션 정렬
FTDW 작업의 일반적인 특징 중 하나는 SQL Server 분할 활용 기능입니다. 분할은 데이터 수명 주기 관리를 간소화하고 시간이 지나면서 발생하는 조각화를 최소화할 수 있습니다. 또한 대규모 검사를 위한 쿼리 패턴은 범위 파티션 기능을 활용하여 조각화나 디스크 I/O 처리량에 영향을 주지 않고 테이블 검사의 크기를 크게 줄일 수 있습니다.
추가 고려 사항
다음은 데이터베이스 작업을 평가할 때 고려해야 할 추가 고려 사항입니다.
인덱스 라이트 데이터베이스 최적화 전략의 구현 및 관리는 FTDW 작업에 대한 기본 요구 사항입니다.
데이터 웨어하우스 내에서 데이터 조각화가 최소한으로 유지된다고 가정합니다. 이는 다음을 의미합니다.
o 주요 조각화 유형을 조각 크기로 측정할 수 있습니다. 조각은 8K 데이터베이스 페이지의 연속 할당을 나타냅니다.
o 저장소를 추가하여 서버를 확장하려면 이 문서에서 설명한 지침에 따라 성능에 민감한 모든 테이블을 다시 채워야 합니다.
o 정기적으로 행 수준 업데이트를 수행하는 테이블과 같은 변동성 데이터 구조를 구현하려면 자주 유지 관리(예: 조각 모음 또는 인덱스 다시 작성)하여 조각화를 줄여야 합니다.
11
o 조각화를 유발하는 흔한 사례는 기존 범위와 겹치는 일괄 클러스터 키 ID 를 포함하는 클러스터 인덱스 테이블을 로드하는 것입니다. 따라서 이 참조 가이드에 나와 있는 최선의 구현 방법에 따라 신중하게 모니터링하고 관리해야 합니다.
데이터 웨어하우징은 사용자마다 중요한 요소가 다를 수 있으므로 FTDW 작업 특성에 대한 고객의 요구 사항을 평가할 때는 주의를 기울여야 합니다.
질적 데이터 웨어하우스 작업 특성데이터베이스 작업과 관련된 다음 영역의 속성을 통해 FTDW 작업을 정의할 수 있습니다.
사용자 요구 사항 및 액세스 패턴 데이터 모델 데이터 아키텍처 데이터베이스 최적화
다음 표에는 데이터 웨어하우스 작업 특성이 요약되어 있으며 OLTP 또는 ODS(운영 데이터 저장소) 작업과의 비교를 통해 차이를 설명합니다.
특성 작업 선호도:데이터 웨어하우스 OLTP/ODS
사용 사례 설명 읽기 위주(90%-10%) 업데이트는 일반적으로 데이터
품질 요구 사항으로만 제한 대량 대규모 삽입 전반적인 쿼리 동시 실행
(보통-적음), 최고 동시 쿼리 요청 범위(10-30)
분석 및 보고 요구 사항에 따라 구별된 동시 쿼리 처리량
큰 범위의 검사 및/또는 집계 복합 쿼리(필터, 조인, 그룹별,
집계)
부하 분산된 읽기 업데이트 비율(60%-40%)
운영 요구에 따라 다른 동시 쿼리 처리량
세분화된 삽입 및 업데이트 높은 트랜잭션 처리량
(예: 10s K/초) 전반적인 사용자 동시 실행(보통
-많음), 최고 동시 쿼리 요청 범위(50-100)
일반적으로 매우 짧은 트랜잭션(예: 개별 최소 행 조회)
데이터 모델 고도로 정규화된 중앙 집중식 데이터 웨어하우스 모델
SQL Server Analysis Services 와 같은 BI 응용 프로그램에서 보통 제공되는 보고 요구 사항을 지원하는 비정규화
상대적으로 동시 실행성이 낮고 대량 분석 요청이 있는 데이터베이스에 호스팅되는 차원 데이터 구조
대규모 범위 검사가 일반적임
고도로 정규화된 운영 데이터 모델
의사 결정 지원에 대한 빈번한 비정규화, 높은 동시 실행성, 낮은 불연속 조회 대기 시간
데이터의 기록 보존이 제한됨 운영 이벤트 의사 결정을
지원하는 다른 원본 시스템에서 추출된 비정규화 데이터 모델
12
특성 작업 선호도:데이터 웨어하우스 OLTP/ODS 임시 분석 용도
데이터 아키텍처 힙 테이블 구조를 많이 사용 범위 제한 검사를 지원하는 클러스터형 인덱스를 포함하는 분할된 큰 테이블
매우 큰 팩트 테이블(예: 수백 기가바이트 - 수 테라바이트)
매우 큰 데이터 크기(예: 수백 테라바이트 - 1페타바이트)
힙 테이블 구조 최소 사용 상세한 레코드 조회(요청당 1 행
이상)를 지원하는 클러스터형 인덱스 테이블 구조
작은 팩트 테이블(예: 100GB 미만)
상대적으로 작은 데이터 크기(예: 2-3 테라바이트)
데이터베이스 최적화
보조 인덱스(앞에서 설명한 인덱스 라이트) 최소 사용
분할이 일반적임
보조 인덱스 최적화를 많이 사용
표 2: 데이터 웨어하우스 작업 특성
FTDW 참조 구성 선택이 문서에서는 FTDW 방법론을 사용하는 일반적인 세 가지 접근 방식을 다룹니다. 처음 두 접근 방식은 데이터 웨어하우징을 위한 게시된 Fast Track 참조 아키텍처를 준수하는 제품 사용 시에만 해당됩니다. 이러한 접근 방식을 사용하면 FTDW 프로그램의 일부로 게시되는 사전 설계된 시스템을 선택할 수 있습니다. 세 번째 접근 방식은 사용자 정의 데이터 웨어하우징 시스템을 만드는 지침으로 핵심 Fast Track 방법론을 다룹니다. 이 마지막 접근 방식에서는 구매 또는 배포에 앞서 상세한 작업 프로파일링 및 시스템 벤치마킹이 필요합니다. 이를 위해서는 엔터프라이즈 서버 및 저장소 구성뿐만 아니라 SQL Server 데이터베이스 최적화에 대한 고도의 기술적 지식이 요구됩니다.
방법 1: 기본 평가이 시나리오에서는 고객이 FTDW 참조 구성 대상을 정했거나 서버 및 CPU 요구 사항을 확인하기 위한 대안을 가지고 있습니다. 이 방법을 사용할 경우 전체 플랫폼 평가(개념 증명)를 수행할 필요가 없습니다.
1 단계: 고객 사용 사례 평가Fast Track 데이터 웨어하우스 참조 구성은 소프트웨어와 하드웨어의 범용 구성이 아니라, 데이터 웨어하우징 작업의 특징에 맞게 구성됩니다. 구성 선택의 첫 번째 단계에서는 이러한 특징을 식별하고 고객의 요구 사항과 사용 패턴의 핵심 영역을 조사합니다.
작업 FTDW 작업 정의에서는 사용 사례 평가를 대한 두 가지 핵심 포인트를 제공합니다. 첫째는 SQL Server 성능과 관련된 작업의 핵심 요소를 정의하는 일련의 핵심 원칙입니다. 충돌할 경우 대상
13
작업이 FTDW 참조 아키텍처에 적합하지 않음을 나타낼 수 있으므로 해당 사용 사례에 대해 이러한 원칙을 신중하게 측정해야 합니다.
작업의 둘째 구성 요소는 대상 사용 사례에 대한 일반적인 설명입니다. 여기서는 작업 적합성 평가를 위한 합리적인 출발점뿐 아니라 사용 사례에 대한 자세한 정보를 제공합니다.
작업 평가다음은 고객의 작업 평가를 위한 기본 절차를 간략하게 설명한 것입니다. 이 프로세스는 질적 평가이므로 지침을 고려해야 합니다.
1. 대상 작업 요구 사항을 정의합니다. FTDW 작업 특성을 비교하고 대조합니다. 자세한 내용은 이 문서의 FTDW 작업 섹션을 참조하십시오.
2. FTDW 와 관련된 최선의 구현 방법을 평가합니다. 데이터베이스 관리와 데이터 아키텍처 및 시스템 최적화 관련 구현 방법은 대상 사용 사례 및 운영 환경을 대상으로 평가해야 합니다.
의사 결정이 작업 평가의 목적은 유효성이 확인된 FTDW 참조 아키텍처를 선택할 때 충분한 정보를 바탕으로 의사 결정을 내릴 수 있도록 하는 것입니다. 실제로 대부분의 데이터 웨어하우스 시나리오에는 FTDW 작업에 대하여 일치하는 특성과 충돌하는 특성이 모두 포함되어 있습니다. Fast Track 참조 구성에 아주 적합한 최우선 순위의 작업 특성은 아래 설명되어 있습니다. 이러한 특성과 정면으로 충돌하는 주요 고객 사용 사례는 방법론이 사용 사례에 부적합함을 나타낼 수 있기 때문에 신중하게 평가해야 합니다.
작업다음은 최우선 순위의 작업 특성입니다.
중요한 작업이 검사 집중적인 데이터 액세스 패턴(즉, 순차 데이터 배치에 유용한 패턴)을 갖습니다. 일반적으로 개별 쿼리 요청에 수만 개에서 수백만 개 이상의 행 읽기가 포함됩니다.
일반 OLTP 작업에 비해 데이터 용량이 많고 동시 실행이 적습니다. 데이터 변동성이 낮습니다. 빈번한 업데이트/삭제 DML 작업은 전체 데이터 웨어하우스
공간의 극히 일부로만 제한해야 합니다.
데이터베이스 관리데이터베이스 관리에는 데이터베이스 관리, 데이터 아키텍처(데이터 모델 및 테이블 구조) 및 데이터 통합 절차가 포함됩니다.
인덱스 라이트, 분할된 데이터 아키텍처. 적절한 로드, ETL 전략 및 정기적 유지 보수를 통해 데이터베이스 조각화를 신중하게
관리합니다.
14
예측 가능한 데이터 증가 요구 사항. FTDW 시스템은 완전히 부하가 분산된 용량으로 미리 구축됩니다. 저장소 확장 시 데이터 마이그레이션이 필요합니다.
2 단계: 게시된 FTDW 참조 아키텍처 선택예산 또는 경험에 따라 간단한 평가를 수행할 때 고객이 염두에 둔 서버가 있을 수 있습니다. 또는 대역폭 요구 사항의 분석 기준이 되는 기존 시스템이 있거나 작업 용량에 대한 계획을 세워 놓았을 수도 있습니다. 어떤 경우에도 FTDW 기본 평가에서는 전체 플랫폼 평가를 수행하지 않습니다. 대신 고객이 추정한 요구 사항과 일치하는 적절한 FTDW 구성을 선택합니다.
방법 2: 전체 평가Fast Track 을 준수하는 참조 아키텍처에서는 정의된 고객 작업에 적합한 하드웨어 구성 요소 구성을 제공합니다. 다음 방법론을 사용하면 사용 사례 요구 사항, 성능, 확장성 간에 균형을 보장하는 데이터베이스 구성 요소 아키텍처를 간단히 선택할 수 있습니다. 이 접근 방법은 데이터베이스 시스템 아키텍처 및 데이터 웨어하우스 배포에 대한 높은 수준의 전문 지식을 전제로 합니다. 일반적으로 이 프로세스에는 Fast Track 파트너와 Microsoft 기술 영업 담당자가 관여합니다.
프로세스 개요다음 절차는 FTDW 전체 평가 선택 프로세스를 요약한 것입니다.
1. 대상 사용 시나리오에 대해 Fast Track 작업 특성을 평가합니다.2. 고객 사용 사례에 대한 대역폭 요구 사항 및/또는 서버를 파악합니다. 평가를 시작하기
전에 게시된 FTDW 참조 구성을 선택해야 합니다.3. 고객의 작업 요구 사항을 나타내는 쿼리를 파악합니다.4. 쿼리를 위한 SQL Server 의 BCR(벤치마크 사용률)을 계산합니다.5. 필요한 UDC(사용자 데이터 용량)를 계산합니다.6. BCR 및 UDC 등급을 Fast Track 참조 아키텍처를 준수하는 게시된 MCR(최대 CPU
사용률) 및 용량 등급과 비교합니다.
다음은 전체 평가 절차의 개별 단계를 자세히 설명한 것입니다.
1 단계: 고객 사용 사례 평가
작업 평가이 프로세스는 방법 1: 기본 평가와 동일합니다.
FTDW 평가 하드웨어 선택전체 시스템 평가를 시작하기 전에 테스트를 위해 게시된 FTDW 참조 구성을 선택하고 배포해야 합니다. 몇 가지 방법을 사용하여 적합한 참조 구성을 파악할 수 있습니다. 다음은 일반적인 방법입니다.
15
예산. 고객이 사용 가능한 예산에 맞춰 최대 용량의 시스템 및/또는 최고 성능의 시스템을 구매하기로 선택합니다.
성능. 고객이 사용 가능한 최고 성능의 시스템을 구매하기로 선택합니다. 내부 분석. 고객이 기존 하드웨어에서 실행한 작업 분석을 기반으로 의사 결정을 합니다. 임시 분석. FTDW 크기 조정 도구 는 대상 데이터베이스 작업에 대한 기본 가정을
기반으로 FTDW 시스템 요구 사항을 계산하는 기본적인 방법을 제공합니다. 이 스프레드시트 도구는 http://download.microsoft.com/download/D/F/A/DFAAD98F-0F1B-4F8B-988F-22C3F94B08E0/Fast%20Track%20Core%20Calculator%20v1.2.xlsx 에서 다운로드할 수 있습니다.
2 단계: 평가 메트릭 설정다음은 전체 FTDW 평가에 중요한 세 가지 메트릭으로서 하드웨어 평가를 위한 주요 의사 결정 기준을 구성합니다.
MCR(최대 CPU 코어 사용률) BCR(벤치마크 사용률) 필요한 UDC(사용자 데이터 용량)
이러한 메트릭 계산에 대한 자세한 내용은 이 문서의 벤치마킹 및 유효성 검사 섹션을 참조하십시오.
MCR이 메트릭은 특정 서버와 CPU 조합에서 데이터 집합 및 표준 쿼리에 대한 최대 SQL Server 데이터 처리 속도를 측정합니다. 이는 코어당 속도로 제공되며 메모리 캐시를 통한 쿼리 기반 검사로 측정됩니다. MCR 은 Fast Track 시스템 설계의 출발점으로서 서버, CPU 및 작업의 I/O 대역폭에 필요한 예상 최대 값을 나타냅니다. MCR 은 최소한의 로컬 저장소와 데이터베이스 스키마만으로 지정된 CPU 의 잠재적인 처리량을 예측할 수 있기 때문에 초기 설계 지침으로 유용합니다. MCR 이 시스템 설계를 위한 출발점으로 사용되도록 강조하는 것은 중요하지만 시스템 성능의 척도는 아닙니다.
BCRBCR 은 FTDW 작업에서 결정적인 것으로 간주되는 일련의 쿼리를 통해 측정됩니다. BCR 은 캐시에 대해서만 계산되는 MCR 과 달리 디스크 및 캐시의 총 읽기 대역폭에 대해 계산됩니다. BCR 을 사용하면 고객 작업 패턴에 맞는 쿼리 집합에 대해 측정함으로써 해당 고객 사용 사례에 맞게 인프라를 조정할 수 있습니다. 또는 파트너 유효성이 확인된 FTRA 사례에서 일련의 벤치마크 쿼리를 사용하여 시스템이 스트레스가 많은 작업에 맞게 설계되었는지 확인할 수 있습니다. BCR 은 간단히 말해서 큰 데이터 볼륨에 대한 동시 작업에서 여러 쿼리를 사용하는 실제 데이터 처리 기준입니다.
16
UDC(사용자 데이터 용량)
사용자 데이터 용량은 SQL Server 데이터베이스에 대한 예상 데이터베이스 용량입니다. Fast Track 사용자 데이터 용량은 로드 후 데이터베이스 압축을 설명하며, Fast Track 시스템에 로드할 수 있는 비압축 사용자 데이터 파일 또는 스트림의 예상 크기를 나타냅니다. FTDW 에 사용되는 표준 압축 비율은 3.5:1 입니다.
초기 배포 이상으로 저장소를 확장하려면 기존 데이터를 새 데이터베이스 파일 위치에 효율적으로 스트라이프하는 데이터 마이그레이션이 필요할 수 있습니다. 따라서 적절한 참조 아키텍처를 선택할 때 예상되는 데이터베이스 확장 및 시스템 기대 수명을 고려해야 합니다.
3 단계: Fast Track 데이터 웨어하우스 참조 아키텍처 선택계산이 완료되면 게시된 각 FTRA 에 대해 Fast Track 파트너가 제공한 게시된 MCR 및 용량 등급을 BCR 과 비교할 수 있습니다. 파트너에 대한 자세한 내용은 Fast Track 데이터 웨어하우징(http://www.microsoft.com/sqlserver/en/us/solutions-technologies/data-warehousing/fast-track.aspx)을 참조하십시오.
게시된 구성에 대해 테스트/평가 시스템의 결과를 평가하는 일반적인 참조점으로 BCR 메트릭을 사용할 수 있습니다. 고객은 BCR 데이터로 시작하여 테스트 결과와 가장 잘 맞는 Fast Track 옵션을 선택할 수 있습니다.
방법 3: 사용자 정의 참조 아키텍처이 접근 방법은 FTDW 방법론을 활용하여 특정 작업 또는 하드웨어 집합에 맞게 시스템을 조정합니다. 이 접근 방법을 사용하려면 SQL Server 와 SQL Server 가 실행되는 하드웨어 구성 요소를 완전히 이해해야 합니다. 다음 단계는 FTDW 원칙을 따르는 사용자 정의 참조 아키텍처를 개발하기 위한 일반적인 방법의 개요를 설명합니다.
1 단계: 작업 정의FTDW 구성의 핵심은 대상 데이터베이스 사용 사례를 이해하는 것이며, 이는 이 문서에 제공된 지침의 모든 사용자 지정 응용 프로그램에서도 마찬가지입니다. FTRA 에 대한 지침 중 특히 작업 항목에 대한 지침은 작업 평가를 구성 요소 아키텍처 디자인으로 통합하기 위한 참조 모델로 사용할 수 있습니다.
2 단계: 구성 요소 아키텍처 벤치마크 설정다음 프레임워크는 미리 정의된 작업에 대한 참조 아키텍처를 개발하기 위한 기본 프레임워크를 제공합니다.
1. 선택한 서버 및 CPU 에 대한 MCR(최대 CPU 코어 사용률)을 설정합니다. 이 문서의 벤치마킹 및 유효성 검사 섹션에서 설명한 방법을 사용하여 MCR 을 계산합니다. FTDW
17
구성에 대해 게시된 MCR 등급을 사용할 수도 있습니다. 일반적으로 동일한 제품군의 CPU 는 SQL Server 데이터베이스에 대한 CPU 코어 사용률이 비슷합니다.
2. MCR 값을 사용하여 저장소 및 저장소 네트워크 요구 사항을 예측하고 초기 시스템 디자인을 작성할 수 있습니다.
3. 초기 시스템 디자인 기반의 테스트 시스템을 확보합니다. 전체 구성이 지정된 시스템이 좋습니다.
4. BCR(벤치마크 사용률)을 설정합니다. 작업 평가를 바탕으로 쿼리를 파악하도록 합니다. 일련의 대표적인 쿼리를 파악하는 것이 가장 좋습니다. 이 문서의 작업에 대한 BCR 측정 섹션에 설명된 절차를 따르십시오.
5. 결과에 따라 시스템 디자인을 조정합니다.6. 최종 서버 및 저장소 구성을 설정합니다.
3 단계: 시스템 유효성 검사시스템 벤치마킹의 목표는 2 단계에서 파악한 하드웨어 구성 요소 구성에 대해 구성 및 처리량 유효성을 검사하는 것입니다. 이 프로세스에 대한 자세한 내용은 이 문서의 사용자 정의 FTRA 유효성 검사 섹션을 참조하십시오. 시스템의 유효성을 검사하려면 다음 단계를 따릅니다.
1. 설정된 성능 요구 사항에 대해 구성 요소의 처리량을 평가합니다. 이를 통해 실제 시스템 처리량이 기대치에 부합하도록 할 수 있습니다.
2. 최종 구성을 다시 지정하고 최종 벤치마크를 실행하여 시스템 처리량을 확인합니다. 일반적으로 최종 BCR 은 시스템 MCR 의 80% 이상을 달성해야 합니다.
FTRA 선택 요약다음 표에는 세 가지 FTRA 선택 옵션에 대한 요약이 나와 있습니다.
옵션 장점 단점기본 평가 시스템 설정 및 공급이
매우 빠름(며칠에서 몇 주 정도 걸림)
디자인 및 평가 비용 최소화
인프라 기술 요구 사항이 낮음
사양 초과 저장소 또는 사양 미달 CPU 사용 가능
전체 평가 미리 정의된 참조 아키텍처를 예상 작업에 맞게 조정
하드웨어에 대한 비용 절약 가능
솔루션에 대한 신뢰성 향상
평가에 노력과 시간이 많이 걸림(몇 주에서 몇 달 정도 걸림)
대상 작업에 대한 자세한 이해 필요
사용자 정의 참조 아키텍처 기존 하드웨어의 재사용 프로세스에 몇 개월 소요
18
가능성 최신 하드웨어의 통합
가능성 사용 사례에 맞게
구체적으로 시스템 조정
상당한 인프라 전문 지식 필요
상당한 SQL Server 전문 지식 필요
표 3: 다양한 평가 방법 비교
FTDW 표준 구성
하드웨어 구성 요소 아키텍처현재 FTDW 참조 아키텍처는 전용 저장소 구성을 기반으로 합니다. 현재 게시된 옵션에는 SAN 전환, SAN 직접 연결, SAS 직접 연결, SAS RBOD 및 iSCSI 가 포함됩니다. 독립적인 전용 저장소 인클로저 및 프로세서를 사용하여 디스크 I/O 처리량을 달성할 수 있습니다. 추가 정보 및 구성은 각 Fast Track 공급업체에서 게시합니다. 그림 2 에서는 SAN 저장소 기반의 FTDW 참조 아키텍처를 구성하는 구성 요소 수준의 요소를 보여 줍니다.
그림 2: 2 소켓, 12코어 서버에 대한 저장소 구성의 예
19
구성 요소 요구 사항 및 구성
서버 메모리총 RAM: 최대 논리 처리량(시간별 디스크와 버퍼에서 읽은 총 페이지)과 CPU 사용률의 부하 분산을 유지하기 위해 벤치마크 결과에 따라 FTRA 에 대한 RAM 할당이 수행됩니다. 표 4 에는 SQL Server 2012 참조 아키텍처에 대한 권장 메모리 할당이 나와 있습니다. 제공된 최대 메모리 값은 절대적인 제한은 아니지만 성공적으로 유효성이 확인된 시스템에 대한 평균값을 나타냅니다.
서버 크기 최소 메모리 최대 메모리1 소켓 64GB 128GB2 소켓 128GB 256GB4 소켓 256GB 512GB8 소켓 512GB 768GB표 4: SQL Server 2012 에 대한 권장 메모리 할당
다음은 시스템 메모리 요구 사항을 평가할 때 중요한 고려 사항입니다.
캐시의 쿼리: 캐시에서 많은 쿼리를 처리하는 작업은 작업이 증가함에 따라 RAM 할당이 증가하여 전반적인 혜택을 볼 수 있습니다.
해시 조인 및 정렬: 대규모 해시 조인을 사용하거나 대규모 정렬 작업을 수행하는 쿼리는 실제 메모리 크기를 늘리면 혜택을 얻을 수 있습니다. 메모리가 작은 경우 이러한 작업은 디스크로 확산되고 tempdb 를 아주 많이 사용하므로 서버의 데이터 드라이브 간에 임의 I/O 패턴을 유발합니다.
로드: 사용 가능한 메모리에서 대량 삽입을 처리될 수 없는 경우 tempdb 를 사용하는 정렬 작업이 생성될 수도 있습니다.
xVelocity 메모리 최적화 columnstore 인덱스: columnstore 인덱스 쿼리 계획을 아주 많이 선호하는 작업은 표 4 에 나열된 메모리 풀의 상한 범위가 클 때 보다 효율적으로 실행됩니다.
파이버 채널 SAN
HBA – SAN: 모든 HBA 및 SAN 네트워크 구성 요소는 제조업체와 모델에 따라 어느 정도씩 다릅니다. 또한 저장소 인클로저 처리량은 SAN 구성과 PCIe 버스 기능의 영향을 많이 받을 수 있습니다. 이 권장 사항은 일반적인 지침이며 FTDW 참조 구성 개발 중에서 수행한 테스트와 일치합니다.
영역 지정을 사용할 경우 영역에는 Fast Track 용 포트만 있어야 합니다. 자세한 FC 네트워크 토폴로지 및 구성은 각 Fast Track 파트너에서 제공하는 기술 구성 가이드에 나와 있으며 게시된 각 FTRA 별로 다릅니다.
20
다중 경로 I/O(MPIO): MPIO 를 구성해야 합니다. 전용 저장소 배열에서 호스팅되는 각 볼륨에 활성 경로가 하나 이상 있어야 합니다.
하위 집합을 포함하는 라운드 로빈은 Fast Track 구성에 사용되는 기본 정책이지만 FTDW 파트너 엔지니어링 팀에서는 보다 최적화된 구성을 파악하고 있기 때문에 파트너 참조 아키텍처에 거의 사용되지 않습니다. 파트너 전용 DSM 및/또는 문서는 종종 설정이 다르게 규정되어 있으므로 구성 전에 검토해야 합니다.
저장소로컬 디스크: 2 디스크 RAID1 배열은 Windows Server 와 SQL Server 설치를 위한 최소 할당입니다. 가상 RAM 요구 사항과 페이징 요구 사항을 위해 충분한 디스크 공간을 할당해야 합니다. 일반적으로 250GB 이상 또는 시스템 RAM 의 1.5 배 이상의 사용 가능한 디스크 공간이 있어야 합니다. 나머지 디스크 구성은 작업과 고객의 선호에 따라 다릅니다.
논리적 파일 시스템: 많은 Fast Track 시스템의 볼륨 수로 인해 드라이브 문자 대신 Windows 의 탑재 지점 폴더 경로로 LUN 을 탑재하는 것이 좋습니다.
또한 이렇게 하는 것이 어떤 Windows 운영 체제 드라이브 할당이 스토리지 인클로저에서 어떤 LUN(볼륨), RAID 디스크 그룹, Windows Server 탑재 지점을 나타내는지 이해하는 데 도움이 될 수 있습니다. Windows 폴더에 LUN 을 탑재할 때 탑재 지점과 볼륨에 대해 이름 지정 체계를 사용할 수 있습니다. 장치 이름 지정 체계에 대한 자세한 내용은 Fast Track 파트너 기술 구성 지침을 참조하십시오.
공급업체별 도구를 사용하여 권장되는 볼륨 이름 지정 체계를 적용할 수 있습니다. 적절한 도구가 없을 경우 드라이브 이름을 할당할 때 저장소 배열에서 한 번에 하나의 디스크를 Windows 에서 사용할 수 있도록 하면 정확한 물리 및 논리 토폴로지를 만들 수 있습니다.
물리적 파일 시스템: 세부 지침을 포함한 자세한 내용은 이 문서의 응용 프로그램 구성 섹션을 참조하십시오.
저장소 인클로저 구성: Fast Track 파트너 기술 문서에서 달리 설명하지 않는 한 모든 인클로저 설정은 기본값을 유지합니다. 파일 시스템 구성에 대한 FTDW 사양에는 특정 구성의 RAID 그룹화 및 LUN 할당을 허용하는 저장소 인클로저가 필요합니다. FTDW 참조 구성 하드웨어를 대체하거나 사용자 지정 하드웨어를 평가할 때 이를 고려해야 합니다.
응용 프로그램 구성
Windows Server 2008 R2달리 명시되지 않는 한 Windows Server 2008 R2 Enterprise 운영 체제에 대해 기본 설정을 사용해야 합니다. 최신 서비스 팩 및 중요 업데이트를 모두 적용해야 합니다. 많은 참조 아키텍처에는 다중 경로 I/O 기능이 필요합니다. 세부적인 MPIO 구성에 대한 자세한 내용은
21
해당 참조 아키텍처에 대한 Fast Track 파트너 기술 구성 가이드를 참조하십시오. 적절한 .NET 프레임워크 설치 및 기본값을 보장하려면 Windows Server 2008 R2 가 응용 프로그램 서버 역할로 설치되었는지 확인합니다.
SQL Server 2012 Enterprise
시작 옵션시작 옵션에 -E 를 추가해야 합니다. 이렇게 하면 데이터베이스가 커짐에 따라 데이터베이스에 할당되는 각 파일 내 연속 범위의 수가 늘어나며 따라서 순차적 디스크 액세스가 향상됩니다. 이 옵션에 대한 자세한 내용은 Microsoft 기술 자료 문서 329526 (http://support.microsoft.com/kb/329526)을 참조하십시오. 데이터베이스 시작 시 -E 옵션을 적용해야 합니다. 이 옵션은 대/소문자 및 형식을 구분합니다. 옵션 앞 뒤에 공백이 있을 경우 초기화되지 않을 수 있습니다.
시작 옵션에 -T1117 도 추가해야 합니다. 이 추적 플래그는 자동 증가가 설정된 경우 파일 그룹에 있는 모든 파일이 균일하게 증가하도록 합니다. 데이터베이스 파일 증가에 대한 표준 FTDW 권장 사항은 자동 증가 대신 사전 할당하는 것입니다. 단, tempdb 는 예외입니다. 자세한 내용은 이 문서의 저장소 구성 세부 정보 섹션을 참조하십시오.
메모리의 페이지 잠금 옵션을 사용하도록 설정합니다. 자세한 내용은 방법 : 메모리의 페이지 잠금 옵션 설정(http://go.microsoft.com/fwlink/?LinkId=141863)을 참조하십시오.
-T834 는 사례별로 평가해야 합니다. 이 추적 플래그는 많은 데이터 웨어하우스 작업에 대한 처리율을 높일 수 있습니다. 이 플래그를 사용하면 메모리에 SQL Server 버퍼 풀을 위해 대용량 페이지를 할당할 수 있습니다. 이 추적 플래그 및 기타 추적 플래그에 대한 자세한 내용은 Microsoft 기술 자료 문서 920093 (http://support.microsoft.com/kb/920093)을 참조하십시오.
참고: 현재 SQL Server 2012 에서는 데이터베이스에 columnstore 인덱스가 사용될 경우 –T834의 사용이 지원되지 않습니다. columnstore 인덱스를 사용하려면 이 추적 플래그를 사용하지 마십시오.
SQL 최대 메모리SQL Server 2012 에서는 총 서버 RAM 의 92% 이하만 SQL Server 에 할당할 수 있습니다. 추가 응용 프로그램에서 서버를 공유하려면 운영 체제에 남아 있는 사용 가능한 RAM 의 크기를 적절히 조정해야 합니다. 이 설정은 최대 서버 메모리 옵션을 통해 제어합니다. 유효성이 확인된 참조 아키텍처용 메모리 설정에 대한 자세한 내용은 FTDW 파트너 설명서를 참조하십시오.
리소스 관리자데이터 웨어하우스 작업에는 일반적으로 대용량의 데이터에 대해 수행되는 복합 쿼리가 포함됩니다. 이러한 쿼리는 많은 양의 메모리를 사용할 수 있으며 메모리가 제한된 경우
22
디스크로 확산될 수 있습니다. 이 동작은 리소스 관리에 영향을 줍니다. SQL Server 2012 의 리소스 관리자 기술을 사용하여 리소스 사용을 관리할 수 있습니다.
SQL Server 의 기본 설정에서 리소스 관리자는 각 세션에 최대 25%의 SQL Server 메모리 리소스를 제공합니다. 즉, 최악의 경우 세 개의 큰 쿼리가 사용 가능한 메모리의 25% 이상을 사용하여 메모리를 많이 사용하는 다른 쿼리를 차단합니다. 이 상태에서 실행하는 데 메모리를 많이 받아야 하는 추가 쿼리가 있으면 리소스를 사용할 수 있을 때까지 대기됩니다.
리소스 관리자를 사용하여 쿼리당 사용되는 최대 메모리를 줄일 수 있습니다. 그러나 결과적으로 많은 양의 메모리를 사용하는 동시 쿼리는 오히려 tempdb 를 대신 사용하여 더 많은 임의 I/O 를 생성하므로 이로 인해 전체 처리량이 줄어들 수 있습니다. 이는 많은 데이터 웨어하우스 작업에서 개별 세션이 사용할 수 있는 시스템 리소스의 양을 제한하는 데 도움이 될 수 있지만, 동시 쿼리 작업의 분석을 통해 측정하는 것이 가장 좋습니다. 리소스 관리자를 사용하는 방법에 대한 자세한 내용은 리소스 관리자를 사용하여 SQL Server 작업 관리(http://msdn.microsoft.com/ko-kr/library/bb933866.aspx)를 참조하십시오.
공급업체의 지침과 Fast Track 솔루션에 대한 사례도 검토해야 합니다. 특히 대규모의 4 소켓 및 8 소켓 Fast Track 솔루션은 특정 리소스 관리자 설정을 사용하여 최적의 성능을 달성할 수 있습니다.
간단히 말해서 개별 쿼리에 고성능을 제공하는 제약 조건 완화와 동시 실행할 수 있는 쿼리 수를 보장하는 보다 제약 조건 강화 사이에는 상충 관계가 존재합니다.
리소스 관리자에 대한 일반적인 시나리오 및 최선의 구현 방법에 대한 자세한 내용은 리소스 관리자 사용(http://msdn.microsoft.com/ko-kr/library/ee151608.aspx) 백서를 참조하십시오.
저장 시스템주 데이터베이스 저장소를 HDD(하드 디스크 드라이브)에 배치하는 FTDW 참조 아키텍처에서 조각화 관리는 시간이 지남에 따라 시스템 성능에 매우 중요합니다. 따라서 세부적인 저장소 및 파일 시스템 구성이 지정됩니다.
저장 시스템 구성 요소그림 3 에서는 통합 데이터베이스 스택을 위한 저장소 구성의 기본 레이어 3 개를 결합하여 보여 줍니다. 구체적 토폴로지는 Fast Track 파트너에 따라 크게 다르기 때문에 이 아키텍처는 참조 사례로 고려해야 합니다. 일반적인 데이터베이스 스택에는 다음 요소가 포함됩니다.
물리적 디스크 배열:4 스핀들 RAID 1+0 은 그림 3 에 나와 있는 표준 방법입니다. RAID 5와 RAID 6 도 SQL Server 2008 R2 및 SQL Server 2012 에 대한 일부 파트너 참조 아키텍처에 사용되었습니다.
운영 체제 볼륨 할당(LUN)
23
데이터베이스: 사용자, 시스템 임시, 시스템 로그
그림 3: 디스크 그룹당 LUN(볼륨)이 한 개인 저장소 인클로저 3 개를 기반으로 하는 FTDW 시스템의 포괄적 저장소 아키텍처의 예
저장소 구성 세부 정보각 저장소 인클로저에 대해 다음을 수행합니다.
1. RAID 1+0(RAID 10)을 사용하여 각각 디스크 4 개로 구성된 디스크 그룹을 만듭니다. 저장소 인클로저당 정확한 디스크 그룹의 수는 공급업체에 따라 다를 수 있습니다. 자세한 내용은 공급업체별 설명서를 참조하십시오. 일반적으로 이 수는 LFF(대형 폼 팩터) 인클로저의 경우 (2) RAID10 및 (1) RAID1 디스크 그룹이고, SFF(소형 폼 팩터) 인클로저의 경우 (5) RAID10 디스크 그룹입니다.
24
주 데이터의 파일 그룹 위치로 사용되는 총 볼륨은 32 개를 초과할 수 없습니다. 저장 시스템 LUN 의 총 수가 이 임계값을 초과할 경우 더 큰 디스크 그룹을 사용하여 비슷한 I/O 처리량을 유지하면서 LUN 수를 줄일 수 있습니다. 예를 들어 LUN 이 1 개인 4 디스크 RAID 10 디스크 그룹을 사용하는 대신 LUN 이 1 개인 8 디스크 RAID 10 디스크 그룹을 사용합니다. 큰 디스크 그룹을 사용하면 처리량과 효율성이 약간 감소합니다. 이는 저장소 기술에 따라 다릅니다.
2. 하나의 디스크 그룹을 제외한 모든 디스크 그룹을 PRI(기본 사용자 데이터) 전용으로 지정합니다. 기본 사용자 데이터 위치는 SQL Server 데이터베이스 파일 그룹 위치와 동일합니다.모든 FTRA 는 PRI 디스크 그룹당 하나 또는 두 개의 LUN 을 호출합니다. 선택한 참조 아키텍처에 대한 공급업체별 지침을 참조하십시오. 이러한 LUN 은 SQL Server 데이터베이스 파일(.mdf 및 .ndf 파일)을 저장하는데 사용됩니다.
3. 저장소 인클로저의 기본 데이터에 할당되는 각 디스크 볼륨의 기본 저장소 프로세서 할당이 균일하게 분산되도록 합니다. 예를 들어 기본 데이터에 4 개의 디스크 볼륨이 할당된 저장소 인클로저는 저장소 프로세서 "A"에 할당되는 볼륨 2 개와 저장소 프로세서 "B"에 할당되는 볼륨 2 개를 갖게 됩니다.
4. 나머지 디스크 그룹에 데이터베이스 트랜잭션 로그를 호스팅하기 위한 한 개의 LUN 을 만듭니다. 일부 큰 Fast Track 구성의 경우 로그는 시스템의 처음 몇 개의 저장소 인클로저에만 할당됩니다. 이 경우 추가 디스크 그룹은 데이터베이스와 관련되지 않은 준비 용도로 사용되거나 비용을 줄이기 위해 빈 채로 남겨집니다.
각 데이터베이스에 대해 다음을 수행합니다.
1. PRI LUN당 한 개의 데이터 파일을 포함하는 파일 그룹을 하나 이상 만듭니다. 모든 파일을 동일한 크기로 만들어야 합니다. 로드를 지원하는 준비 데이터베이스처럼 한 데이터베이스의 여러 파일 그룹을 사용하여 개체를 분리하려면 모든 PRI LUN 을 각 파일 그룹의 위치로 포함해야 합니다.
2. 각 파일 그룹의 파일을 만들 경우 예상 개체를 충분히 보유할 수 있는 최대 예상 크기로 파일을 미리 할당합니다.
3. 데이터 파일의 자동 증가 옵션을 사용하지 않도록 설정하고 현재 크기 제한에 도달할 경우 모든 데이터 파일을 수동으로 증가시킵니다.
4. 사용자 데이터베이스 및 파일 그룹 권장 사항에 대한 자세한 내용은 이 문서의 데이터 조각화 관리 섹션을 참조하십시오.
tempdb 에 대해 다음을 수행합니다.
1. 공간을 미리 할당한 다음 LUN당 한 개의 데이터 파일을 추가합니다. 모든 파일을 동일한 크기로 만들어야 합니다.
25
2. 임시 로그 파일을 로그 파일 전용 LUN 중 하나에 할당합니다.3. 자동 증가를 사용하도록 설정합니다. 일반적으로 데이터 웨어하우스 작업에는 큰 증분을
사용하는 것이 적합합니다. 초기 파일 크기의 10%에 해당하는 값으로 시작하는 것이 좋습니다.
4. 데이터베이스에 대한 표준 SQL Server 최선의 구현 방법 및 tempdb 크기 조정 고려 사항을 따릅니다. 마이그레이션 단계 중에 또는 웨어하우스의 초기 데이터를 로드하는 동안 큰 공간 할당이 필요할 수 있습니다. 자세한 내용은 SQL Server 온라인 설명서의 tempdb 의 용량 계획 (http://msdn.microsoft.com/ko-kr/library/ms345368.aspx)을 참조하십시오.
트랜잭션 로그에 대해 다음을 수행합니다.
1. 트랜잭션 로그 공간에 할당된 LUN 중 하나에 데이터베이스당 한 개의 트랜잭션 로그 파일을 만듭니다. 여러 데이터베이스의 로그 파일을 사용 가능한 LUN 에 분산시키거나 필요할 경우 로그 증가를 위해 여러 개의 로그 파일을 사용합니다.
2. 로그 파일에 대해 자동 증가 옵션을 사용합니다. 3. 로그 용량을 표 5 에 나와 있는 요구 사항에 맞춥니다. 시스템별 설계 특성에 따라 약간
변경할 수 있습니다.
시스템 RAM(GB) FT 정격 용량(테라바이트) 권장되는 최소 로그 할당미러된 사용 가능 공간(GB)
<= 96 <=10 300GB X 1볼륨
<= 128 >10 <=40
300GB x 2볼륨또는600GB x 1볼륨
표 5: 로그 할당 권장 사항
SQL Server 트랜잭션 로그 할당 및 관리를 위한 기존의 최선의 구현 방법을 참조하십시오.
반도체 저장소기본(PRI) 데이터에 대해 반도체 저장소를 사용하는 FTDW 참조 아키텍처는 간편한 관리, 운영 비용 절감, 예측 가능한 유지 보수 등 많은 이점이 있습니다.
간편한 관리: 반도체 저장소는 조각화 관리가 필요 없습니다. SQL Server 시작 옵션 -E 는 사용해야 하지만 더 이상 페이지 할당을 최적화하거나 관리할 필요는 없습니다. 따라서 FTDW 환경의 장기적인 관리가 상당히 간편해집니다. 또한 LUN당 볼륨이 적고 디스크 그룹이 커도 성능이 저하되지 않습니다. 이러한 장점으로 인해 파일 그룹을 만들고 유지 관리하는 작업이 간단해집니다.
26
I/O 복구: 반도체 저장소는 동시 실행이나 페이지 조각화가 많은 상태에서 성능 저하를 최소화합니다. 또한 복합 임의 읽기(검색) 작업이 큰 요청(검사) I/O 패턴에 부정적인 영향을 주지 않습니다.
예측 가능한 유지 관리: 다양한 반도체 저장소 옵션을 통해 소프트웨어 기반 수명 기록 모니터링 시 예측하기 어렵고 빈도가 낮은 물리적 결함을 발견할 수 있습니다.
운영 비용 절감: 반도체 저장소는 가격은 비싸지만 단위당 용량에 대해 보다 효율적인 I/O 처리량 부하 분산을 제공합니다. 300GB 10k SAS HDD 의 효과적인 FTDW 작업 I/O 속도는 평균 50MB입니다. Enterprise MLC SSD 는 600GB 용량에서 150MB - 200MB 의 속도를 제공합니다. 또한 반도체 저장소는 전력 소비가 훨씬 적고 적은 열을 생성하며 고밀도 솔루션을 지원하는 경우도 많습니다.
반도체 저장소 구성PRI 볼륨에 반도체 저장소를 사용할 경우 표준 FTDW 저장소 구성 지침을 다음과 같이 조정할 수 있습니다.
미러링이 필요할 경우 RAID1+0 또는 RAID5 를 사용할 수 있습니다. RAID5 는 반도체 관련 FTDW 작업에 대해 성능 손실 없이 최고의 용량을 제공합니다.
LUN 및 볼륨 수를 저장 단위당 PRI 볼륨 한 개까지 줄일 수 있습니다. PRI 볼륨 수를 CPU 코어 수의 배수로 하면 도움이 되는 경우가 있습니다. 최소 PRI 볼륨 수는 2개입니다.
반도체 메모리에 트랜잭션 로그를 저장할 수도 있지만 FTDW 작업은 일반적으로 로그에 바인딩되지 않습니다. 기존의 HDD 에 로그를 저장함으로써 비용을 줄일 수 있습니다. 이는 Windows Server 와 SQL Server 설치를 위한 로컬 저장소에서도 마찬가지입니다.
논리 데이터베이스 조각화는 반도체 I/O 성능에 영향을 주지 않으므로 페이지 조각화 관리 및 클러스터 인덱스 병렬 로드에 대한 권장 사항은 무시해도 됩니다.
SQL Server FTDW 의 최선의 구현 방법Fast Track 작업 사례는 두 가지 경우에 대해 유효성 검사 후 문서로 기록되었습니다. 첫 번째 경우는 Fast Track 사례가 설정된 SQL Server 최선의 구현 방법과 사실상 다른 경우입니다. 두 번째 경우는 기존 사례가 없거나 쉽게 액세스할 수 없는 상황에서 발생합니다. SQL Server 데이터베이스 배포에 대해서는 기존에 설명서가 많이 제공되므로 여기 설명된 사례에서는 포괄적인 내용을 다루지 않습니다. 기존 SQL Server 기술 문서 및 최선의 구현 방법은 FTDW 배포와 관련된 다양한 항목을 참조해야 합니다.
중요: 이 가이드에는 SQL Server 2008 R2 에 대해 작성된 다양한 설명서의 링크가 포함되어 있습니다. 이 지침의 대부분은 SQL Server 2012 사용과 관련하여 여전히 중요하며, 이러한
27
문서가 업데이트되면 업데이트된 버전을 확인해야 합니다. 이 참조 가이드의 이후 버전에서는 해당될 경우 링크가 업데이트됩니다.
데이터 아키텍처
테이블 구조데이터를 데이터베이스에 저장하기 위해 사용하는 테이블 형식은 순차 액세스 성능에 상당한 영향을 줍니다. 쿼리 계획을 통해 순차적 I/O 를 가능한 한 많이 유도할 수 있도록 물리적 스키마를 디자인하는 것이 중요합니다.
테이블 형식을 선택하는 것은 대부분의 경우 테이블의 데이터를 어떻게 액세스할지를 선택하는 것입니다. 다음 정보는 저장되는 데이터의 세부 정보를 바탕으로 테이블 유형을 결정하는 데 사용할 수 있습니다.
힙 테이블힙 테이블은 테이블 검사에 완전한 순차 I/O 를 제공하며 테이블 조각화와 관련하여 일반적으로 적은 오버헤드를 제공합니다. 클러스터형 인덱스 테이블에서 볼 수 있는 최적화된(직접 액세스) 범위 기반 검사는 기본적으로 허용되지 않습니다. 범위 검사 시 힙 테이블은 전체 테이블(또는 분할이 적용될 경우 해당 범위 파티션)을 검사합니다.
힙 테이블 검사는 32 개 파일에서 최대 처리량에 도달하므로 LUN(32 개 초과) 또는 코어(16 개 초과) 수가 많은 시스템에서 큰 팩트 테이블에 대한 힙을 사용하려면 리소스 관리자나 DOP 제약 조건을 사용해야 하거나 표준 Fast Track 데이터베이스 파일 할당을 변경해야 합니다.
다음 경우에 힙 테이블을 사용하는 것이 좋습니다.
테이블 참조에 대한 대부분의 최우선 순위 쿼리에 다양한 개별 열을 참조하거나 열 조건자가 없는 조건자가 포함될 경우
Analysis Services 큐브를 채우는 데 전용으로 사용되는 테이블과 같이 범위 제한적 검사와 상반되는 대규모 검색을 쿼리에서 일반적으로 수행하는 경우. 이 경우 힙 테이블은 채울 Analysis Services 큐브와 동일한 세분성으로 분할되어야 합니다.
쿼리 작업 요구 사항을 인덱스 관리 증분 오버헤드 없이 충족할 수 있거나 로드 성능이 가장 중요할 경우(힙 테이블은 로드 속도가 빠름)
클러스터형 인덱스 테이블데이터 웨어하우스 환경에서 키가 범위 제한적인 열(예: 날짜)이어서 적절한 쿼리 작업의 제한에 자주 사용되는 경우 클러스터형 인덱스가 가장 효과적입니다. 이 경우 인덱스를 사용하여 데이터를 제한하고 최적화하여 검사할 수 있습니다.
28
다음과 같은 경우 클러스터형 인덱스 테이블을 사용하는 것이 좋습니다.
테이블에 대한 최우선 순위 쿼리 작업 시나리오 대부분에서 쿼리 제한에 사용되는 범위 한정적 열이 테이블에 있는 경우. FTDW 구성의 경우 클러스터형 인덱스의 분할된 날짜 열도 클러스터형 인덱스 키여야 합니다.참고: 클러스터형 인덱스 테이블의 날짜 분할 열이 아닌 클러스터형 인덱스 키를 선택하는 것이 유용한 경우도 있습니다. 그러나 기존의 클러스터형 인덱스 키 범위와 겹치는 새 데이터는 페이지 분할을 만들기 때문에 파티션이 완전히 로드되지 않으면 조각화가 발생할 수 있습니다.
테이블에 대한 쿼리가 정상적으로 세분화되거나 범위가 제한된 조회를 수행하며 전체 테이블 또는 대규모 다중 범위를 검사하지 않을 경우.
테이블 파티션테이블 분할은 FTDW 데이터베이스의 조각화를 관리하는 데 중요한 도구가 될 수 있습니다. 예를 들어 테이블의 다른 부분을 다루지 않고 테이블에서 큰 블록의 범위 기반 사용자 데이터를 업데이트하거나 삭제하기 위해 분할을 사용할 수 있습니다. 반면 클러스터 인덱스에서 행 단위로 삭제하면 상당한 익스텐트 조각화를 유발할 수 있습니다. 일반적인 시나리오는 파티션이 오래되고 데이터 범위에 대한 DML 작업의 빈도가 줄어들면 새 파티션을 다시 작성하는 것입니다. 이렇게 하면 DML 작업에 대해 파티션이 안정적이고 익스텐트 조각화도 최소화됩니다.
또한 SQL Server Analysis Services 큐브를 채우는 데 주로 사용되는 큰 테이블을 큐브 분할에 맞춰 테이블이 분할된 힙 테이블로 만들 수 있습니다. 이 테이블을 액세스할 경우 큰 테이블의 해당 파티션만 검사됩니다. (Analysis Services ROLAP 모드를 지원하는 파티션은 클러스터형 인덱스로 더 구조적일 수 있습니다.)
테이블 분할에 대한 자세한 내용은 분할된 테이블 및 인덱스에 대한 SQL Server 2008 의 전략 (http://msdn.microsoft.com/ko-kr/library/dd578580(v=SQL.100).aspx) 백서를 참조하십시오.
인덱싱FTDW 인덱스를 만들 경우 다음 지침을 고려하십시오.
날짜 범위 또는 일반 제한 사항에 대해 클러스터형 인덱스를 사용합니다. 가능한 경우 columnstore 인덱스를 사용합니다. 다음 섹션에서는 FTDW 환경에서
columnstore 인덱스를 사용하는 최선의 구현 방법을 설명합니다. 세부적인 조회가 필요하며 테이블 분할이 충분한 성능을 제공하지 않을 경우를 위해
비클러스터형 인덱스를 예약합니다. 가능할 경우 비클러스터형 인덱스 대신 columnstore 인덱스를 사용합니다.
비클러스터형 포함 인덱스는 일부 데이터 웨어하우스 작업에 값을 제공할 수 있습니다. 이를 사례별로 평가하고 columnstore 인덱스와 비교해야 합니다.
29
xVelocity 인메모리 Columnstore 인덱스SQL Server 2012 에는 열 형식 기술을 기반으로 하는 새로운 데이터 웨어하우스 쿼리 가속 기능인 columnstore 인덱스가 도입되었습니다. 이러한 새 인덱스는 향상된 쿼리 처리 능력과 함께 광범위한 분석 쿼리에 대한 데이터 웨어하우스 쿼리 성능을 높입니다.
xVelocity 메모리 최적화 columnstore 인덱스는 포함된 열에 대한 모든 데이터를 별도 페이지에 저장하기 때문에 "순수한" columnstores(혼합 아님)입니다. Columnstore 인덱스는 I/O 검사 성능과 버퍼 적중률을 높이며 FTDW 디자인 방법론에 매우 잘 맞습니다.
최선의 구현 방법Columnstore 인덱스 개체는 테이블과 함께 있으며 비클러스터형 인덱스와 유사한 방식으로 만들어집니다. 이는 증분 저장 용량이 필요함을 의미합니다. 인덱스의 대상 테이블을 자주 변경할 것 같으면 별도의 파일 그룹에 Columnstore 인덱스를 만드는 것이 좋습니다. 별도의 파일 그룹에 columnstore 인덱스를 유지하면 변동성이 높은 환경에서 시간 경과에 따른 페이지 조각화를 관리할 수 있습니다.
정규화된 데이터 모델을 위한 Columnstore 인덱스 만들기일반 데이터 모델(3NF)은 두 개 이상의 큰(팩트) 테이블 간에 조인을 트리거하는 경우가 많습니다. 이러한 유형의 조인은 현재 columnstore 인덱스 처리에 적합하지 않으며 non-columnstore 인덱스 쿼리 계획과 관련하여 성능 저하를 표시할 수 있습니다. 다음 방법을 통해 일반 데이터 모델에서 이러한 문제를 방지할 수 있습니다.
쿼리 수준 힌트를 사용하여 columnstore 인덱스 처리가 사용되는 것을 차단합니다. OPTION(IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX)을 사용합니다. 쿼리를 다시 작성합니다. 자세한 내용은 이 문서의 Columnstore 인덱스에 대한 일반적인
최선의 구현 방법 섹션에 나와 있는 자료를 참조하십시오. non-columnstore 인덱스 쿼리 계획의 성능 저하를 표시하는 SQL 조인과 관련된 한
테이블에서 일반 조인 키를 생략합니다. 한 테이블의 columnstore 인덱스에서 조인 키를 생략하면 생략된 열에 조인하는 쿼리에 columnstore 인덱스가 사용되지 않을 수 있습니다. 이 방법은 쿼리 수준 옵션을 적용할 수 없는 환경에서 유용할 수 있습니다. columnstore 인덱스에서 열을 생략하더라도 쿼리 계획이 향상되지 않을 수 있으며 columnstore 인덱스로부터 성능상의 이점을 얻는 다른 쿼리에 영향을 줄 수 있습니다. 이 옵션을 사용할 경우 관련된 작은 테이블에서 열을 선택하면 다른 쿼리 성능에 미치는 영향을 줄일 수 있습니다. columnstore 인덱스에는 선언된(DDL) 기본 키가 포함되어야 하며 이를 통해 사용 가능한 조인 열을 제한할 수 있습니다. Columnstore 인덱스 정의에서 기본 키 열을 생략하더라도 모든 기본 키 열은 columnstore 인덱스를 만들 때 자동으로 추가됩니다.
30
현재 릴리스에서 columnstore 인덱스에 대한 일반 데이터 모델이 완벽하게 최적화되지 않았지만 FTDW 벤치마킹은 정규화된 모델인 TPC-H 의 수정 버전을 기반으로 합니다. 경우에 따라 전체 작업 성능의 거의 두 배에 달한 FTDW 정격 처리량을 포함하여 columnstore 인덱스와 non-columnstore 인덱스 쿼리 계획이 모두 혼합된 동시 작업에서 여전히 상당한 효과가 있었습니다.
차원 데이터 모델을 위한 Columnstore 인덱스 만들기별모양 스키마와 같은 차원 모델에 대한 표준 columnstore 인덱스 최선의 구현 방법 을 따릅니다. 이는 columnstore 인덱스 처리에 대한 최상의 사례 시나리오가 될 수 있습니다.
Columnstore 인덱스에 대한 메모리 관리일반적으로 SQL Server 2012 에 대해 유효성이 확인된 FTRA 에는 SQL Server 2008 R2 의 유사한 구성보다 전체 시스템 RAM 이 더 많습니다. 주된 이유는 columnstore 인덱스 확장 작업이 큰 메모리 풀에서 보다 효율적으로 실행되기 때문입니다. columnstore 인덱스를 활용하려는 FTDW 환경에서 세션당 메모리 크기를 최대로 설정하려면 항상 리소스 관리자를 사용해야 합니다. 유효성이 확인된 FTRA 는 FT 정격 성능을 얻는 데 사용되는 리소스 관리자 설정을 문서화하며 이러한 값을 출발점으로 사용할 수 있습니다. 시스템 설치 후 설정을 평가하고 고객의 작업에 맞게 조정하는 것이 가장 좋습니다.
다음 SQL 명령은 이러한 권장 사항에 맞게 SQL Server 리소스 관리자를 구성합니다. 이 경우 세션당 최대 메모리 크기는 19%로 설정됩니다.
ALTER RESOURCE GOVERNOR RECONFIGURE;
ALTER WORKLOAD GROUP [default] WITH(request_max_memory_grant_percent=19);
xVelocity 메모리 최적화 Columnstore 인덱스에 대한 일반적인 최선의 구현 방법FTDW 참조 지침에서는 Fast Track 에 대한 사례만 다룹니다. columnstore 인덱스에 대한 자세한 내용은 SQL Server 2012 CSI 튜닝 가이드 (http://social.technet.microsoft.com/wiki/contents/articles/sql-server-columnstore-performance-tuning.aspx) 및 SQL Server 2012 CSI FAQ(http://social.technet.microsoft.com/wiki/contents/articles/sql-server-columnstore-index-faq.aspx)를 참조하십시오.
데이터베이스 통계통계 실행 시기와 업데이트 주기는 여러 요인을 고려해서 결정해야 합니다. 일반적으로 데이터베이스 통계 문제를 다루는 두 가지 주 이유는 사용 가능한 유지 관리 시간과 시스템 성능의 전반적인 저하 때문입니다.
자세한 내용은 SQL Server 2008 에 대한 통계 (http://msdn.microsoft.com/ko-kr/library/dd535534.aspx)를 참조하십시오.
31
최선의 구현 방법데이터베이스 통계에 대한 다음 최선의 구현 방법을 따르는 것이 좋습니다.
통계에 AUTO CREATE 및 AUTO UPDATE(동기 또는 비동기) 옵션을 사용합니다(SQL Server 의 시스템 기본값). 이 기법을 사용하면 통계를 수동으로 실행해야 할 필요성이 최소화됩니다.
통계를 수동으로 수집해야 할 경우 테이블의 모든 열에 대해 통계를 수집하는 것이 좋습니다. 모든 열에 대해 통계를 실행할 수 없으면 적어도 WHERE 또는 HAVING 절과 조인 키에서 사용되는 모든 열에 대해서라도 통계를 수집해야 합니다. 인덱스 생성은 인덱스 키에 통계를 작성하므로 명시적으로 수행할 필요가 없습니다.
복합(여러 열) 통계는 많은 조인 시나리오에 유용합니다. 복합 조인 키를 포함하는 팩트 차원 조인은 복합 통계가 없을 경우 만족스럽지 못한 중첩 루프 최적화 계획을 유발할 수 있습니다. 자동 통계에서는 복합 통계를 작성하거나 새로 고치거나 바꿀 수 없습니다.
증가하는 키 값(예: 팩트 테이블의 날짜)을 포함하는 통계는 각 증분 로드 작업 후 수동으로 업데이트해야 합니다. 다른 경우에는 통계 업데이트 빈도를 줄일 수 있습니다. AUTO_UPDATE_STATISTICS 옵션으로 충분하지 않을 경우 정기적으로 통계를 실행하십시오.
압축FTDW 구성은 페이지 압축을 사용하도록 설계되었습니다. 모든 팩트 테이블에 페이지 압축을 사용하는 것이 좋습니다. 작은 차원 테이블(행이 백만 개 미만인 테이블)의 압축은 선택 사항입니다. 큰 차원 테이블에서는 페이지 압축을 사용하는 것이 일반적으로 유용합니다. 두 경우 모두 작업을 기반으로 차원 테이블의 압축을 평가해야 합니다. 행 압축은 추가 옵션이며 특정 유형의 데이터를 합리적인 비율로 압축할 수 있습니다.
SQL Server 페이지 압축은 테이블의 데이터, 인덱스 및 파티션을 축소합니다. 따라서 사용자 테이블을 저장하는 데 필요한 물리적 공간이 감소되어 SQL Server 버퍼 풀(메모리)에 더 많은 데이터를 수용할 수 있습니다. 이점의 하나로 물리적 저장소에서 처리되는 I/O 요청 수가 감소됩니다.
실현할 수 있는 실제 압축량은 저장되는 데이터 및 데이터 내 중복 데이터 필드의 빈도에 따라 다릅니다. 데이터가 매우 불규칙한 경우 압축의 장점이 매우 제한적입니다. 최상의 상태에서도 압축을 사용하면 CPU 에서 데이터를 압축하고 압축 해제하기 위한 수요가 증가하지만 물리적 디스크 공간 요구 사항 또한 감소하며 대부분의 상황에서 메모리 버퍼의 I/O 요청을 처리하여 쿼리 응답 시간이 향상됩니다. 일반적으로 페이지 압축의 압축 비율(원래 크기/압축 크기)은 2:1 - 7:1 이며 일반적인 예상치는 3:1 입니다. 결과는 데이터의 특성에 따라 다릅니다.
데이터 조각화 관리조각화는 여러 수준에서 발생할 수 있으며 순차 I/O 를 보존하기 위해 이러한 수준을 모두 제어해야 합니다. FTDW 의 주 목표는 근본적인 조각화를 제한하면서 데이터를 가능한 한 순차적으로 유지하는 것입니다. 조각화가 발생할 수 있으면 전반적인 시스템 성능이 저하됩니다.
32
조각 모음은 주기적으로 수행해야 하지만 다음 지침을 통해 시간이 오래 걸리는 조각 모음을 수행하는 횟수를 최소화할 수 있습니다.
파일 시스템 조각화 데이터베이스 파일당 디스크 블록은 NTFS 파일 시스템의 물리적 플래터에 인접하게 유지해야 합니다. 파일 생성 시 파일의 최대 예상 크기를 미리 할당하여 이 수준의 조각화를 예방할 수 있습니다.
NTFS 파일 시스템의 조각 모음 도구를 사용하지 않도록 합니다. 이러한 도구는 운영 체제 수준에서 작동하도록 설계되었으며 내부 SQL Server 데이터 파일 구조를 인식하지 않습니다.
익스텐트 조각화SQL Server 내에서는 테이블 연결과 상관없이 파일 내 모든 페이지가 익스텐트 크기(2M) 또는 페이지 수준(8K)으로 인터리브될 수 있습니다. 이는 일반적으로 동시 DML 작업, 과도한 행 수준 업데이트 또는 과도한 행 수준 삭제로 인해 발생합니다.
테이블 또는 해당 테이블을 완전히 재작성하는 것이 파일 내 최적의 페이지 할당을 보장하는 유일한 방법입니다. 이러한 유형의 데이터베이스 조각화를 해결하기 위한 대체 방법은 없습니다. 따라서 SQL Server 구성에 대한 지침 및 최선의 구현 방법에 따라 데이터를 로드하고 DML 을 관리하는 것이 중요합니다.
다음 쿼리에서 제공하는 핵심 정보로 FTDW 테이블에 대한 논리적 조각화를 평가할 수 있습니다. 최우선 순위 메트릭은 평균 조각 크기입니다. 이 값은 연속 범위에 클러스터된 SQL Server 의 평균 페이지 수를 나타내는 정수입니다.
SELECT db_name(ps.database_id) as database_name
,object_name(ps.object_id) as table_name
,ps.index_id
,i.name
,cast (ps.avg_fragmentation_in_percent as int) as [Logical Fragmentation]
,cast (ps.avg_page_space_used_in_percent as int) as [Avg Page Space Used]
,cast (ps.avg_fragment_size_in_pages as int) as [Avg Fragment Size In Pages]
,ps.fragment_count as [Fragment Count]
,ps.page_count
,(ps.page_count * 8)/1024/1024 as [Size in GB]
FROM sys.dm_db_index_physical_stats (DB_ID() --NULL = All Databases
, OBJECT_ID('$(TABLENAME)')
, 1
33
, NULL
, 'SAMPLED') AS ps --DETAILED, SAMPLED, NULL = LIMITED
INNER JOIN sys.indexes AS i
on (ps.object_id = i.object_id AND ps.index_id = i.index_id)
WHERE ps.database_id = db_id()
and ps.index_level = 0;
다음 표에는 평균 조각 크기 값을 해석하기 위한 일반적인 지침이 나와 있습니다.
평균 조각 크기 상태 작업>400 이상적 이상적인 값이며 일부 데이터 구조를 유지하기
어려울 수 있습니다. 300-399 녹색 테이블에서 우수한 I/O 성능을 제공하며 논리적
조각화에 대한 유지 보수가 필요하지 않습니다.150-299 노랑 논리적 조각화가 I/O 효율성에 영향을 줄 가능성이
높습니다. 조각 수를 개선하기 위해 유지 관리를 수행하는 것이 좋습니다.
10-149 빨강 논리적 조각화가 심각합니다. 이 구조에서 큰 I/O 요청을 실행할 경우 상당한 디스크 헤드 이동을 유발하며 전체 시스템 I/O 효율성이 감소할 수 있습니다.
<10 빨강 이렇게 낮은 평균 조각 크기 값은 일반적으로 SQL Server 시작 옵션 -E 가 설정되지 않았거나 시작 시 인식되지 않은 것을 의미합니다.
표 6: 평균 조각 크기 값
500MB보다 작은 파티션이나 테이블에 대한 평균 조각 크기 결과는 평가할 수 없습니다. 작은 데이터 구조에는 효율성이 높은 조각 수를 얻을 수 있는 총 페이지가 부족합니다. 또한 이러한 작은 데이터 구조는 일반적으로 비교적 작은 데이터 요청을 나타내며 전반적인 시스템 I/O 효율성에 제한적인 영향을 미칩니다. 대부분의 경우 데이터 웨어하우스 환경에서 가장 크고 자주 액세스하는 테이블만 관리하여 최상의 효과를 볼 수 있습니다.
인덱스 조각화인덱스는 물리적(페이지) 순서와 논리적(인덱스) 순서가 다를 수 있습니다.
ALTER INDEX REORGANIZE 명령을 사용하여 이러한 유형의 조각화를 해결하면 큰 할당의 효과를 얻지 못할 수 있으므로 이 명령을 사용하지 마십시오. 인덱스를 다시 작성하거나 INSERT…SELECT 를 사용하여 인덱스의 새 복사본에 데이터를 삽입하면 재정렬이 방지되므로 이 문제를 해결할 수 있습니다. 대상 파일 그룹의 조각화를 방지하려면 ALTER INDEX REBUILD
34
프로세스에서 SORT_IN_TEMPDB=TRUE 를 지정해야 합니다. MAXDOP 값은 1 이 가장 좋지만 로드 속도가 매우 느려질 수 있습니다. 경우에 따라 MAXDOP 값을 8까지 설정할 수 있습니다. 자세한 내용은 이 문서의 데이터 로드 섹션을 참조하십시오.
여러 파일 그룹다음과 같은 변동성 데이터 작업에 대한 논리적 조각화를 최소화하기 위해 개별 파일 그룹을 만들 수 있습니다.
자주 삭제하고 다시 만드는 인덱스 및 테이블(다른 개체에 의해 다시 채워지는 저장소 레이아웃에 간격 두기)
기존의 클러스터형 인덱스 키 범위와 많이 겹치는 증분 데이터가 자주 로드되는 경우와 같이 페이지 분할로 인해 심하게 조각화될 수 밖에 없는 인덱스
차원 테이블과 같이 비교적 조금씩 로드되는 작은 테이블(변동성 파일 그룹에 배치하면 해당 행이 큰 트랜잭션 또는 팩트 테이블과 인터리브되는 것을 방지할 수 있음)
최종 대상 테이블에 삽입되는 데이터의 준비 데이터베이스
다른 테이블은 비변동성 파일 그룹에 배치할 수 있습니다. 또한 매우 큰 팩트 테이블도 개별 파일 그룹에 배치할 수 있습니다.
데이터 로드Fast Track 구성 요소 아키텍처는 순차적 디스크 액세스에 보이는 더 높은 평균 검사 속도에 맞게 부하가 분산됩니다. 이러한 검사 속도를 유지하려면 SQL Server 파일 시스템 내에서 데이터가 연속 배치되어야 합니다.
이 섹션은 다음 두 가지 고급 접근 방법과 증분 로드 및 데이터 마이그레이션으로 구성됩니다. 이 가이드는 Fast Track 데이터 웨어하우징에 대한 것이지만 이 부분으로만 제한되지는 않습니다.
SQL Server 대량 로드에 대한 자세한 내용은 데이터 로드 성능 가이드(http://msdn.microsoft.com/ko-kr/library/dd425070.aspx)를 참조하십시오.
또 다른 유용한 리소스는 Fast Track 3.0 데이터 로드 최선의 구현 방법 가이드입니다. 이 Microsoft PowerPoint 프레젠테이션은 SQL Server Fast Track DW 포털 (http://msdn.microsoft.com/ko-kr/library/dd425070.aspx)에서 확인할 수 있습니다. 이 문서는 기본적으로 SQL Server 2008 R2 를 기반으로 하며 SQL Server 2012 에도 적용됩니다.
증분 로드이 섹션에서는 데이터 웨어하우스 환경에서 일상적으로 수행되는 일반적인 로드 시나리오를 다룹니다. 이 섹션에는 다음 특성 중 하나 이상에 해당되는 로드 시나리오가 포함되어 있습니다.
사용 가능한 시스템 메모리에 비해 작은 크기
35
사용 가능한 메모리에 적합한 정렬 작업 로드 대상 로드 개체의 전체 행에 비해 작은 크기
힙 및 클러스터형 인덱스 테이블을 로드하는 경우 다음 지침을 고려해야 합니다.
힙 테이블 로드 프로세스힙 테이블의 대량 삽입은 직렬 또는 병렬 프로세스로 수행할 수 있습니다. 다음 팁을 사용하십시오.
대상 힙 테이블로 데이터를 이동하려면 TABLOCK 옵션과 함께 BULK INSERT 를 사용합니다. 분할된 테이블에 로드하면 tempdb 에 대한 정렬이 수행되므로 최종 영구 테이블이 분할된 경우 BATCHSIZE 옵션을 사용합니다.
로드 시간 성능을 개선하려면 대량 데이터 집합을 가져올 때 여러 대량 삽입 작업을 동시에 실행하여 대량 프로세스의 병렬 처리를 활용합니다.
클러스터형 인덱스 로드 프로세스테이블 조각화를 최소화하면서 클러스터형 인덱스 테이블을 로드하는 방법에는 일반적으로 두 가지가 있습니다.
방법 1BULK INSERT 를 사용하여 대상 테이블에 데이터를 직접 로드합니다. 최상의 성능을 얻으려면 로드할 전체 데이터 집합이 인메모리 정렬에 적합해야 합니다. BATCHSIZE 값으로 0 을 사용하여 로드된 모든 데이터를 단일 커밋 작업으로 처리해야 합니다. 이 설정을 사용하면 여러 일괄 처리에서 데이터가 인터리브되거나 페이지 분할이 생성되는 것을 방지할 수 있습니다. 이 방법을 사용할 경우 로드를 단일 스레드로 수행해야 합니다.
방법 2대상 테이블의 구조(분할 포함)와 일치하는 준비 테이블을 만듭니다.
0 이 아닌 보통 일괄 처리 크기 값을 사용하여 빈 클러스터형 인덱스 준비 테이블로 직렬 또는 다중 스레드를 대량 삽입함으로써 정렬이 tempdb 로 확산되지 않도록 합니다. 몇 가지 수준의 병렬 처리를 사용하여 최상의 성능을 얻을 수 있습니다. 이 단계의 목적은 성능을 높이는 것이므로 병렬 및/또는 동시 삽입에 의한 논리적 조각화와 페이지 분할은 고려하지 않습니다.
MAXDOP 값을 1 로 지정한 하나의 INSERT…SELECT 문을 사용하여 준비 테이블에서 대상 클러스터형 인덱스 테이블로 삽입합니다. MAXDOP 값 1 은 익스텐트 조각화를 최소화하지만 성능 저하를 가져올 경우가 많습니다. 최대 8까지 지정할 수 있는 MAXDOP 설정을 사용하여 로드 성능을 높일 수 있지만 병렬 처리가 증가함에 따라 익스텐트 조각화의 증가가 나타납니다. 이러한 상충 관계에서 효율적인 부하 분산은 사례별로 평가하는 것이 가장 좋습니다.
36
방법 3이 방법을 사용하려면 두 개의 파일 그룹과 두 개 이상의 테이블이 필요합니다. 이 방법에는 분할된 클러스터 인덱스 테이블이 필요하며 이전 파티션에 대해 변경 작업이 거의 없는 최신 파티션에서 높은 수준의 논리적 조각화를 찾는 테이블에 가장 적합합니다. 전체 목표는 변동성 파티션을 전용 파일 그룹에 배치하고 새 레코드 또는 기존 레코드 변경 사항을 받는 것을 중지한 후 해당 파티션을 에이징하거나 정적 그룹에 전환하는 것입니다.
다음 FTDW 지침에 따라 파일 그룹 2 개를 만듭니다. 하나는 변동성 파티션 전용이고 다른 하나는 정적 파티션 전용입니다. 변동성 파티션은 시간이 지남에 따라 10%를 초과하는 행이 변경되는 파티션입니다. 정적 파티션은 변동되지 않는 파티션입니다.
정적 파일 그룹의 주 클러스터 인덱스 분할 테이블을 작성합니다. 일반적인 다음 두 가지 방법 중 하나를 사용하여 테이블을 작성합니다.
o 기본 테이블의 파티션 구성표를 미러링하는 제약 조건이 있는 힙 테이블 한 개. 이 제약 조건은 기본 데이터 집합의 변동 범위를 나타내야 하며, 하나 이상의 기본 테이블 구성표 파티션 범위에 걸쳐 있을 수 있습니다. 힙에 로드하면 일반적으로 클러스터 인덱스에 로드하는 것보다 효율적이기 때문에 핵심 결정 기준이 초기 로드 성능일 경우 이 방법이 가장 유용합니다.
o 기본 테이블 파티션과 일치하는 파티션 구성표를 가진 클러스터 인덱스 테이블 한 개. 이러한 테이블을 만들면 변동 파티션 에이징으로서 기본 테이블에 낮은 DOP(병렬 처리 수준)로 직접 삽입할 수 있습니다. 삽입을 통해 기본 테이블에 에이징되면 파티션이 삭제되고 새 범위가 추가됩니다.
두 테이블을 함께 통합하는 뷰를 작성합니다. 사용자 관점에서 볼 때 두 테이블이 하나의 개체로 통합됩니다.
변동 데이터 범위가 변경 데이터 관점에서 정적으로 되면 파티션 전환과 같은 적절한 에이징 프로세스를 사용합니다.
o 제약 조건이 있는 힙 테이블을 사용할 경우 준비 테이블에 삽입하는 방법으로 파티션 범위의 데이터를 정적 파일 그룹으로 이동합니다. CREATE INDEX 및 파티션 전환을 사용하여 데이터를 기본 테이블로 이동합니다. FTDW 구성에서 이 작업 유형에 대한 자세한 내용은 이 문서의 데이터 마이그레이션 섹션을 참조하십시오.
o 분할된 클러스터형 인덱스를 사용할 경우 8 이하의 DOP 를 사용한 다음 파티션 범위로 제한된 INSERT 를 기본 테이블에 직접 수행합니다. 전체 시스템 동시성에 따라 DOP 를 최저 1 로 설정하여 조각화를 방지해야 할 수도 있습니다.
37
데이터 마이그레이션여기서는 데이터 웨어하우스 환경에서 대규모의 일회성 또는 빈도가 낮은 로드 시나리오를 다룹니다. 이러한 상황은 플랫폼 마이그레이션 중이나 시스템 벤치마킹에 대한 테스트 데이터를 로드하는 동안 발생할 수 있습니다. 다음 특성 중 하나 이상에 해당되는 로드 시나리오를 제공합니다.
사용 가능한 시스템 메모리를 초과하는 로드 작업 사용 가능한 메모리에 부하를 주는 높은 동시성의 대용량 로드 작업
힙 테이블 로드 프로세스증분 로드 처리에 대해서는 앞에서 제공한 지침을 따릅니다.
클러스터형 인덱스 로드 프로세스테이블 조각화를 최소화하면서 클러스터형 인덱스 테이블을 로드하는 일반적인 방법에는 여러 가지가 있습니다.
방법 1BULK INSERT 를 사용하여 클러스터형 인덱스 대상 테이블에 데이터를 직접 로드합니다. 최상의 성능을 위해 정렬 작업과 전체 커밋 크기는 메모리 크기에 맞아야 합니다. 로드되는 개별 일괄 데이터에 겹치는 인덱스 키 범위가 없도록 주의해야 합니다.
방법 2동일한 구조의 빈 클러스터형 인덱스 준비 테이블로 직렬 또는 다중 스레드를 대량 삽입합니다. 0 이 아닌 보통 일괄 처리 크기를 사용하여 메모리 내 정렬을 유지합니다. 그런 다음 MAXDOP 값을 1 로 지정한 하나의 INSERT…SELECT 문을 사용하여 빈 클러스터형 인덱스 테이블에 데이터를 삽입합니다.
방법 3
힙 준비 테이블에 맞는 파티션으로 다중 스레드를 대량 삽입하고 0 이 아닌 보통 일괄 처리 크기 값을 사용하여 메모리 내 정렬을 유지합니다. 그런 다음 각 파티션 범위에 걸쳐 있는 직렬 또는 병렬 INSERT…SELECT 문을 사용하여 클러스터형 인덱스 테이블에 데이터를 삽입합니다.
방법 4
일반적으로 대규모 로드 작업에 최상의 결과를 제공하는 다단계 프로세스에서 파티션 전환 작업을 사용합니다. 이 방법은 전체 프로세스의 복잡성을 높이며, 원시 로드 성능에 최적화된 방법을 제공하도록 설계되었습니다. 이 방법의 기본 목표는 논리적 조각화를 사용하지 않고 클러스터 인덱스 작업에 삽입하는 모든 단계에서 병렬 쓰기 작업을 사용할 수 있도록 하는 것입니다. 이는 최종 대상 테이블에 데이터를 삽입하기 전에 여러 파일 그룹의 테이블을 준비함으로써 실현할 수 있습니다.
1. 최종 대상 클러스터 인덱스 테이블의 파티션 구성표를 파악합니다.
38
2. 준비 파일 그룹을 만듭니다.3. 준비 파일 그룹에 압축되지 않고 분할되지 않은 힙 "기본" 준비 테이블을 만듭니다.4. WITH TABLOCK 을 사용하여 기본 준비 테이블에 데이터를 대량 삽입합니다. 여러 원본
파일을 선택할 수 있을 경우 가장 효율적인 방법은 여러 개의 대량 복사 작업을 병렬로 수행하는 것입니다. 최대 처리량을 얻기 위한 병렬 로드 작업의 수는 서버 리소스(CPU 및 메모리) 및 로드되는 데이터에 따라 다릅니다.
5. 지원할 기본 파일 그룹의 수를 파악합니다. 이 수는 대상 테이블에 있는 총 파티션 수의 배수여야 합니다. 또한 이후 단계에서 동시에 실행될 INSERT 및 CREATE INDEX 작업의 총 수를 나타냅니다. 예를 들어 파티션이 24 개인 테이블과 코어가 8 개인 서버의 경우 기본 파일 그룹이 8 개인 데이터베이스를 나타냅니다. 이 구성을 사용하면 8 개의 기본 파일 그룹과 CPU 코어 각각에 대해 다음 단계에서 8 개의 병렬 삽입을 수행할 수 있습니다. 이 경우 각 파일 그룹에는 3 개 파티션 범위의 데이터가 포함됩니다.
6. 앞서 결정한 개수의 기본 파일 그룹을 만듭니다.7. 압축하지 않은 각 파티션 범위에 대한 각 주 파일 그룹에 준비 힙 테이블 한 개를
만듭니다. 준비 테이블에 대상 테이블의 해당 파티션 범위와 일치하는 제약 조건을 만듭니다. 앞의 예를 사용하면 이 단계에서 만든 주 파일 그룹당 3 개의 준비 테이블이 있습니다.
8. 페이지 압축을 사용하는 대상, 분할된 클러스터 인덱스 테이블을 만듭니다. 이 테이블은 모든 주 파일 그룹에 분할됩니다. 파티션은 힙 준비 테이블 제약 조건 범위와 일치해야 합니다.
9. 기본 준비 테이블에서 각 주 파일 그룹에 대한 준비 파일 그룹 테이블로 하나의 INSERT 또는 SELECT 문을 실행합니다. 이 작업은 병렬로 수행해야 합니다. INSERT 또는 SELECT 문에 대한 조건자는 해당 파티션 범위와 일치해야 합니다. 파일 그룹당 INSERT 또는 SELECT 문을 동시에 두 개 이상 실행하지 마십시오.
10. 파일 그룹당 새로 채워진 준비 테이블에 대해 페이지 압축이 포함된 CREATE CLUSTERED INDEX 명령을 한 번 실행합니다. 이 작업은 병렬로 수행할 수 있지만 DOP는 8보다 높을 수 없습니다. 파일 그룹당 CREATE INDEX 를 동시에 두 개 이상 실행하지 마십시오. 주 파일 그룹의 조각화를 방지하기 위해 CREATE INDEX 작업을 수행할 때마다 SORT_IN_TEMPDB 옵션을 사용해야 합니다. 최적의 동시 생성 인덱스 작업 수는 서버 크기, 메모리 및 데이터 자체에 따라 다릅니다. 일반적으로 모든 코어에서 과다 사용 없이(총 사용률 85-90%) 높은 CPU 사용률을 얻도록 합니다.
11. 준비 테이블에서 대상 테이블로 직렬 파티션 전환 작업을 수행합니다. 각각의 준비 CREATE INDEX 작업이 완료되면 이 작업도 수행할 수 있습니다.
벤치마킹 및 유효성 검사이 섹션에서는 SQL Server FTDW 참조 아키텍처를 설계하고 한정하는 데 사용되는 프로세스의 기본적인 설명을 제공합니다. 이러한 정보를 제공하는 목적은 FTDW 방법론을 기반으로 사용자
39
정의 또는 사용자 지정 참조 아키텍처를 지원하기 위한 것입니다. 게시되고 미리 확인된 파트너 참조 아키텍처에 대한 벤치마킹, 문제 해결 또는 확인에 대한 내용은 해당 공급 파트너(H-P, Dell, EMC, IBM, Cisco 등)에게 문의하십시오.
FTDW 유효성 검사 프로세스는 여기서 설명한 두 가지 범주로 나눌 수 있습니다.
기준 하드웨어 유효성 검사하드웨어 유효성 검사의 목적은 Fast Track 참조 아키텍처의 핵심 하드웨어 구성 요소에 대해 규정된 성능 메트릭 대신 실제 성능 메트릭을 설정하는 것입니다. 이 프로세스는 데이터베이스 스택에 있는 핵심 하드웨어 구성 요소의 실제 기준 성능 특성을 결정합니다.
Fast Track 데이터베이스 유효성 검사FTDW 작업을 기반으로 SQL Server 성능 특성을 설정하면 기준 하드웨어 평가 프로세스에서 제공된 성능 가정과 비교할 수 있습니다. 일반적으로 데이터베이스 작업 처리량 메트릭은 유효성이 확인된 Fast Track 참조 아키텍처에 대해 기준 속도의 80% 이상을 반영해야 합니다. 이 프로세스에서 계산된 성능 메트릭은 게시된 FTDW 성능 값의 근거가 되며 Fast Track 참조점 벤치마킹 도구를 통해 실행된 동시 SQL 쿼리 작업을 기반으로 합니다.
Reference Point 는 Fast Track 하드웨어 파트너에게 배포되는 Microsoft 소프트웨어 도구이며 Microsoft 에서 공식적인 Fast Track 참조 아키텍처의 유효성을 검사하고 승인하는 데 사용하는 유일한 인프라입니다. 이 도구는 참조 데이터베이스 스키마를 인스턴스화하는 한편, 병목을 파악하고 핵심 시스템 성능 측정을 설정하도록 설계된 여러 개의 동시 쿼리 작업을 수행합니다.
xVelocity 메모리 최적화 Columnstore 인덱스와 Fast Track 유효성 검사SQL Server 2012 는 기존의 테이블에 대한 비클러스터형 인덱스 옵션으로 columnstore 인덱스 기술을 구현합니다. 개별 쿼리는 쿼리 구조에 따라 columnstore 인덱스 최적화 계획을 사용하거나 사용하지 못할 수 있습니다. 즉, 어떤 정해진 기간에 FTDW 환경에 대한 기존 행과 새로운 열 형식 쿼리 계획의 혼합을 예측할 수 없습니다.
따라서 SQL Server 2012 시스템 설계 및 유효성 검사에 대한 FTDW 는 non-columnstore 인덱스 벤치마크를 기반으로 합니다. FTDW 시스템은 지정된 기간 동안 열 형식 최적화가 이루어지지 않을 경우에 효과적으로 실행되도록 설계되었습니다. columnstore 인덱스 쿼리 계획을 활성화하면 일반적으로 성능이 상당히 향상되며 이 성능은 기본 시스템 디자인의 강화로 볼 수 있습니다.
SQL Server 2012 용 Fast Track 의 파트너 입증 참조 아키텍처는 columnstore 인덱스 확장 벤치마크에 대한 추가 논리 처리량 등급을 추가로 제공하며 이러한 수치를 사용하여 고객이 동시 쿼리 작업에서 기대할 수 있는 쿼리 성능에 대한 긍정적인 영향을 예측할 수 있습니다. 이러한 수치는 모든 시스템 유효성 검사에 사용된 동일한 FTDW 벤치마크와 스키마를 기반으로 합니다.
40
기준 FTDW 유효성 검사 수행기준 유효성 검사는 운영 체제 수준에서 SQLIO 와 같은 도구를 사용하여 수행됩니다. 이 단계에서는 SQL Server 응용 프로그램 테스트를 수행하지 않으며 모든 테스트는 최선의 가상 시나리오입니다. 목표는 하드웨어 및 운영 체제 구성이 정확한지 확인하고 설계 및 개발 벤치마크를 바탕으로 기대한 결과를 제공하는 것입니다.
Windows 서버 성능 및 안정성 모니터(perfmon)를 사용하여 I/O 성능을 추적하고 기록하며 보고할 수 있습니다. I/O 대역폭은 SQLIO 와 같은 도구를 사용하여 테스트를 할 수 있습니다. SQLIO 지침, 다운로드 위치 및 자세한 내용은 SQLCAT 백서 배포 전 I/O 최선의 구현 방법 (http://sqlcat.com/sqlcat/b/whitepapers/archive/2007/11/21/predeployment-i-o-best-practices.aspx)을 참조하십시오.
다음 구성 요소 및 유효성 검사 프로세스는 기준 하드웨어 벤치마크를 생성하는 데 사용됩니다.
기준 SQLIO 테스트SQLIO 사용 방법은 최선의 구현 방법 문서에 자세히 설명되어 있습니다. 읽기 테스트의 일반적인 형식은 다음과 같습니다.
sqlio –kR –fSequential -s30 -o120 -b512 d:\iobw.tst –t1
여기서 R 은 읽기 테스트, 30 은 테스트 지속 시간(초), 120 은 대기 중인 실행 요청 수, 512 는 요청된 블록 크기(kb), d:\iobw.tst 는 테스트 파일의 위치, 1 은 스레드 수를 의미합니다.
집계 대역폭 시나리오를 테스트하려면 여러 SQLIO 테스트를 병렬로 실행해야 합니다. 주 데이터 탑재 지점(디스크 볼륨) 각각에 대해 하나의 SQLIO 인스턴스를 사용해야 합니다. Windows PowerShell 또는 다른 스크립팅 방법을 사용하여 SQLIO 인스턴스를 병렬화할 수 있습니다. 유효성이 확인된 FTDW 파트너 참조 아키텍처의 경우 파트너가 제공하는 기준 I/O 유효성 검사 스크립트를 사용할 수 있습니다.
배포 전 최선의 구현 방법 문서에서는 Windows 서버 성능 및 안정성 모니터를 사용하여 테스트를 추적하는 방법에 대해서도 설명합니다. 이러한 테스트 결과를 기록하고 저장하면 앞으로의 성능 분석 및 문제 해결에 대한 기준을 얻을 수 있습니다.
1 단계 - I/O 대역폭 유효성 검사FTDW 구성 유효성 검사의 첫 단계는 저장소 I/O 네트워크와 서버 간에 달성할 수 있는 최대 총 처리량을 확인하는 것입니다. 이 단계에는 병목 디스크 제거가 포함되며 디스크 외 구성 요소(HBA, 스위치 인프라 및 배열 컨트롤러)에 초점을 맞춥니다. 다음 단계에 따라 SQLIO 를 사용하여 이 작업을 수행하십시오.
1. 데이터베이스 파일에 사용되는 각 LUN 에 작은 데이터 파일을 생성합니다. 모든 데이터 파일이 배열 컨트롤러의 읽기 캐시에 적합하도록 이러한 파일의 크기를 조정해야 합니다(예: 파일당 50MB).
41
2. SQLIO 에서 큰 블록 I/O 크기(512K)와 파일당 최소 2 개 이상의 읽기 스레드를 사용하여 파일에 대한 순차적 읽기를 동시에 실행합니다. 대기 중인 총 읽기를 계산해야 합니다. 예를 들어 대기 중인 요청이 50 개인 읽기 스레드 2 개는 대상 LUN 에 대해 대기 중인 총 요청 수가 100 개로 계산됩니다.
3. 미해결 I/O(-o)에 대한 값을 비교적 낮게 시작하여 총 처리량의 한계에 도달할 때까지 이 값을 늘리면서 테스트를 반복합니다.
이 테스트의 목적은 서버와 저장소 간 경로에서 구성 요소의 이론적 한계와 비교하여 합리적인 총 처리량을 얻는 것입니다. 이 테스트는 서버와 SAN 저장소 프로세서 간 대역폭, 즉 다중 경로 파이버 채널 경로의 유효성을 검사합니다.
2 단계 - LUN/볼륨 대역폭 유효성 검사이 테스트는 앞의 테스트와 유사합니다. 그러나 컨트롤러 캐시의 배열 캐시에서 얻을 수 있는 이점을 제거하기 위해 큰 파일이 사용됩니다. 이러한 테스트 파일은 볼륨당 대상 데이터베이스 파일 크기(예: 볼륨당 25GB)를 시뮬레이션할 수 있을 만큼 커야 합니다. 1 단계에서 설명한 대로 SQLIO 에 대해 유사한 매개 변수를 사용해야 합니다.
큰 블록(512KB) 순차 읽기를 각 볼륨의 테스트 파일에 대해 실행해야 합니다. 최대 처리량을 얻을 때까지 대기 중 요청 수준을 4 부터 16까지 늘리면서 파일당 한 스레드를 사용하는 것이 좋습니다. 먼저 각 볼륨을 개별적으로 테스트한 후 두 볼륨을 동시에 테스트합니다. 디스크 그룹 처리량은 저장소 공급업체와 구성에 따라 다르지만 항상 단일 HDD 읽기 속도를 비교할 수 있습니다. 예를 들어 4디스크 RAID1+0 디스크 그룹에서 이 유형의 기본 읽기 패턴에 대해 단일 HDD 읽기 속도보다 4 배 가까이 빠른 최고 읽기 속도를 얻을 수 있습니다. RAID 1 또는 1+0 성능은 일부 공급업체 기술에서 "미러 읽기"가 허용됨에 따라 저장소 제품에 따라 달라질 수 있으며 따라서 연속 요청을 받을 경우 I/O 를 통해 미러된 양쪽 모두에서 처리될 수 있습니다.
3 단계 - 총 대역폭 유효성 검사이 테스트에서는 2 단계에 사용된 동일한 파일에 대해 사용 가능한 모든 데이터 볼륨에서 동시에 순차 읽기를 실행해야 합니다. SQLIO 는 앞의 테스트에서 결정된 테스트 파일당 두 개의 스레드, 512K 의 I/O 크기 및 미해결 I/O 의 적정 수를 사용하여 실행해야 합니다.
이 테스트 결과는 물리적 디스크에서 데이터를 읽을 때 얻을 수 있는 최대 총 처리량을 보여 줍니다.
앞의 테스트와 마찬가지로 각 볼륨에 있는 큰 데이터 파일에서 동시에 데이터를 읽습니다.
디스크의 총 성능은 부하 분산된 FTDW 시스템의 총 저장소 I/O 대역폭의 80% - 90% 영역에 있어야 합니다.
42
구성 요소 등급 다음 다이어그램에서는 유사한 Fast Track 참조 아키텍처의 값과 일치하는 가상의 벤치마크 결과를 보여 줍니다.
그림 4: 가상 벤치마크의 예에서는 12 개의 4디스크 RAID1+0 기본 데이터 볼륨과 3 개의 8Gbps 이중 포트 HBA 카드가 탑재된 2 소켓, 12코어 서버에 대한 대역폭을 실현했습니다.
요약기준 하드웨어 벤치마킹은 데이터베이스 스택의 핵심 하드웨어 구성 요소에 대한 실제 대역폭 능력의 유효성을 검사합니다. 이러한 작업은 SQLIO 와 같은 도구를 통해 실행되는 일련의 최선의 구현 방법 가상 테스트를 통해 수행됩니다.
43
Fast Track 데이터베이스 벤치마크 수행이 FTRA 평가 단계에서는 두 가지 핵심 메트릭의 측면에서 FTDW 작업에 대한 SQL Server 성능을 측정합니다. 그 중 하나인 MCR(최대 CPU 사용률)은 최고 I/O 처리량의 측정값이고, 다른 하나인 BCR(벤치마크 CPU 사용률)은 쿼리 또는 쿼리 기반 작업에 대한 실제 I/O 처리량의 측정값입니다.
MCR 이란?
MCR 계산을 통해 초당 MB 또는 GB 단위로 코어당 I/O 처리량 값을 구할 수 있습니다. 이 값은 버퍼 캐시에서 미리 정의된 읽기 전용의 최적화되지 않은 쿼리를 실행하고, MB 또는 GB 의 데이터 양에 대한 실행 시간을 구하여 측정됩니다. MCR 은 캐시에서 실행되기 때문에 평가하는 시스템에 대한 SQL Server 를 통해 얻을 수 있는 최적화되지 않은 최고의 검사 속도를 나타냅니다. 따라서 MCR 을 통해 초기 디자인을 위한 최고 기준 속도를 얻을 수 있습니다. MCR은 실제 작업의 평균 또는 예상 결과를 나타내기 위한 것이 아닙니다. 유효성이 확인된 FTDW 아키텍처에는 종합적인 기준 I/O 처리량 결과가 있으며 이는 서버 등급 MCR 의 100% 이상입니다. 이를 다르게 설명하면 MCR 에서 최악의 합리적인 작업에 대해 가능한 최상의 SQL Server 처리 속도를 낸다는 것입니다.
MCR 은 게시되고 유효성이 확인된 다른 SQL Server 2012 용 FTDW 참조 아키텍처와 비교할 때 참조 프레임으로 사용할 수도 있습니다.
요약하면 다음과 같습니다.
MCR 은 고객 작업에 대한 확정적인 실제 결과는 아닙니다. MCR 은 SQL Server 및 Fast Track 작업과 관련된 단일 쿼리에 대한 최대 데이터 처리 속도 기준을 제공합니다.
MCR 은 CPU 와 서버에 따라 달라집니다. 일반적으로 특정 CPU 의 속도 평가는 서버 및 마더보드 아키텍처에 의해 크게 바뀌지 않지만 최종 MCR 은 실제 테스트를 통해 파악해야 합니다.
MCR 처리량 등급은 기존에 게시된 FTDW 참조 아키텍처와의 비교 값으로 사용할 수 있습니다. 이는 구성 요소와 응용 프로그램을 테스트하기 전에 하드웨어를 선택하는 데 도움이 됩니다.
MCR 계산SQL Server 응용 프로그램에 대한 기준 CPU 사용률은 FTDW 프로그램에 대해 정의된 표준 SQL 쿼리를 실행하여 설정됩니다. 이 쿼리는 작업 유형(여기서는 데이터 웨어하우스)의 일반 쿼리를 비교적 간단하게 나타내도록 설계되었으며 버퍼 캐시에서 실행됩니다. 결과 값은 쿼리가 실행되는 CPU 및 서버에 따라 달라집니다. 다음 방법을 사용하여 MCR 을 계산합니다.
1. TPC-H lineitem 테이블 또는 유사한 데이터 집합을 바탕으로 참조 데이터 집합을 만듭니다. 테이블 크기는 SQL Server 버퍼 풀에 완전히 캐시되면서 여기 제공된 쿼리에 대해 1 초 이상의 실행 시간을 유지할 수 있는 정도여야 합니다.
44
2. FTDW 의 경우 SELECT sum([정수 필드]) FROM [테이블] WHERE [해당 데이터 볼륨으로 제한] GROUP BY [열] 쿼리가 사용됩니다.
3. 환경은 다음과 같아야 합니다.o 리소스 관리자 설정을 기본값으로 두어야 합니다.o 버퍼 캐시에서 쿼리를 실행해야 합니다. 쿼리를 한 번 실행하면 페이지가 버퍼에 추가되고 다음 쿼리 실행 시 버퍼를 통해 전부 읽어야 합니다. 쿼리 통계 출력에 물리적 읽기가 없어야 합니다.
o STATISTICS IO 및 STATISTICS TIME 을 ON 으로 설정하여 결과를 출력합니다.4. MAXDOP = 4 로 쿼리를 여러 번 실행합니다. 5. 각 쿼리 실행에 대한 통계 출력에서 CPU 시간 및 논리적 읽기 수를 기록합니다.6. 다음 수식을 사용하여 MCR(MB/s)을 계산합니다.
( [논리적 읽기 수] / [CPU 시간(초)] ) * 8KB / 10247. 최소 5 개 이상의 쿼리 실행을 통해 일관된 범위의 값(+/- 5%)이 나타나야 합니다.
이상값이 크면(+/- 20% 이상) 구성에 문제가 있을 수 있습니다. FTDW MCR 은 5 개 이상의 계산된 결과에 대한 평균입니다.
MCR 계산을 기반으로 구성 요소 아키텍처 처리량 다이어그램을 생성할 수 있습니다. MCR 평가 시스템을 위한 구성 요소 처리량은 공급업체 정격 대역폭을 기반으로 합니다. 이 다이어그램은 시스템 디자인, 선택 및 병목 분석 시 유용할 수 있습니다. 그림 5 에는 이러한 예가 나와 있습니다.
45
그림 5: Intel Westmere CPU 기반의 2 소켓, 12코어 서버의 정격 구성 요소 대역폭 및 MCR(최대 CPU 사용률)의 예
MCR 측정에 대한 자세한 내용은 부록에서 작업 테스트를 참조하십시오.
BCR 계산SQL Server 응용 프로그램에 대한 벤치마크 CPU 사용률은 적절한 동시성 수준에서 해당 데이터 웨어하우스 작업의 기준 SQL 쿼리 집합을 실행하여 설정됩니다. 사용되는 동시성 수준과 쿼리 수는 해당 사용 사례에 따라 완전히 달라집니다. 쿼리 작업은 MCR 과 마찬가지로 SQL Server 버퍼 풀이 아니라 디스크에서 처리해야 합니다. 결과 값은 작업이 실행되는 CPU, 서버 및 작업에 따라 달라집니다. BCR 작업 벤치마크를 작성하는 자세한 예는 부록의 작업 테스트에 자세한 나와 있습니다.
다음 방법을 사용하여 BCR 을 계산합니다.
1. 하나 이상의 테이블을 포함하는 참조 데이터 집합을 만듭니다. 테이블 크기는 SQL Server 버퍼 풀이나 SAN 배열 캐시에 완전히 캐시되지 않을 정도로 커야 합니다. 고객
46
데이터가 없으면 가상 데이터 집합을 사용할 수 있습니다. 대상 사례의 데이터 특성에 대한 근사치를 내야 합니다.
2. FTDW 의 경우 SELECT sum([정수 필드]) FROM [테이블] WHERE [해당 데이터 볼륨으로 제한] GROUP BY [열] 쿼리가 사용됩니다. 고객 쿼리가 준비되지 않을 경우 이 쿼리를 쿼리 작업 설계의 출발점으로 사용할 수 있습니다. TPC-H 는 참조 쿼리 집합으로 사용할 수 있는 또 다른 일반적인 쿼리 벤치마크입니다.
3. FTDW 고객 벤치마크의 경우 항상 대상 작업을 대표하는 쿼리를 선택하는 것이 가장 좋습니다. 고객 환경의 최고 기록 작업이나 예상 작업을 대표하는 여러 동시 세션에서 쿼리를 실행하도록 예약해야 합니다. 쿼리 선택 시 다음과 같은 조건을 고려할 수 있습니다.
평균 대상 작업 요구 사항을 나타냅니다. 이는 기본 쿼리 형식의 복잡성 증가 또는 감소, 조인 추가 및/또는 예측 및 제한을 통한 다소의 데이터 삭제를 의미할 수 있습니다.
이 특성이 대상 작업의 중요한 부분이 아닌 경우 쿼리가 tempdb 에 데이터를 쓰지 않도록 해야 합니다.
쿼리가 최소 행을 반환해야 합니다. 이를 위해 SET ROWCOUNT 옵션을 사용할 수 있습니다. 100보다 큰 ROWCOUNT 값을 사용해야 합니다. Fast Track 벤치마킹의 표준은 105 입니다. 또는 집계를 사용하여 대규모 무제한 검사에서 반환되는 레코드를 줄일 수 있습니다.
4. 환경은 다음과 같아야 합니다. 리소스 관리자 설정을 기본값으로 설정해야 합니다. 쿼리를 실행하기 전에 DBCC dropcleanbuffers를 사용하여 캐시를 지워야
합니다. STATISTICS IO 및 STATISTICS TIME 을 ON 으로 설정하여 결과를 출력합니다.
5. MAXDOP 8 에서 시작하여 쿼리 또는 작업을 여러 번 실행합니다. 쿼리를 실행할 때마다 쿼리에 대한 MAXDOP 설정을 늘려서 각 실행 간 캐시를 지웁니다.
통계 출력에서 CPU 시간 및 논리적 읽기 수를 기록합니다. 다음 수식을 사용하여 BCR(MB/s)을 계산합니다.
( [논리적 읽기 수] / [CPU 시간(초)] ) * 8KB / 1024 이는 BCR 에 대한 범위를 제공합니다. 여러 개의 쿼리를 사용할 경우 가중 평균을
사용하여 BCR 을 확인합니다.
47
BCR 결과그림 6 에서는 유사한 Fast Track 데이터 웨어하우스 참조 아키텍처의 값과 일치하는 SQL Server 작업 기반 벤치마크 결과를 보여 줍니다.
그림 6: 가상 벤치마크의 예에서는 12 개의 4디스크 RAID1+0 기본 데이터 LUN 과 3 개의 8Gbps 이중 포트 HBA 카드를 탑재한 2 소켓, 12코어 서버에 대한 대역폭을 실현했습니다.
BCR 해석평균 쿼리에 대한 BCR 이 FTRA 에 대한 표준 MCR 벤치마크보다 훨씬 낮을 경우 CPU 바인딩될 가능성이 높습니다. 이에 대처하려면 배열 수를 줄이거나 배열당 디스크를 더 많이 적용하거나 또는 디스크 크기를 늘려서 저장소 처리량을 줄이면 됩니다. 이러한 단계를 통해 저장소 인프라의 비용을 균형 잡힌 수준으로 줄일 수 있습니다. 또는 높은 저장소 I/O 처리량 효과를 볼 수 있는 고성능 CPU 나 소켓 수가 많은 서버를 사용해 볼 수도 있습니다. 두 경우 모두 목표는 저장소 I/O 처리량을 통해 데이터베이스 처리 능력의 부하를 분산하는 것입니다.
48
상대적으로 BCR 이 MCR보다 높으면 부하를 분산하여 쿼리 작업을 처리하는 데 더 많은 I/O 처리량이 필요할 수 있습니다.
게시된 FTDW 참조 아키텍처자세한 하드웨어 참조 아키텍처 사양은 참여하는 각 Fast Track 데이터 웨어하우스 파트너가 제공합니다. 각 파트너에 대한 링크 등 자세한 내용은 Fast Track 데이터 웨어하우징 (http://www.microsoft.com/sqlserver/en/us/solutions-technologies/data-warehousing/fast-track.aspx)을 참조하십시오.
FTDW 용량은 데이터베이스에 로드할 수 있는 압축되지 않은 사용자 데이터 파일의 크기를 추정하여 평가합니다. 이를 UDC(사용자 데이터 용량)라고 합니다. 이를 계산할 때는 모든 테이블에 대해 페이지 압축이 설정되어 해당 데이터 볼륨이 미러링되는 것으로 가정합니다. 평균 압축비는 3.5:1 을 사용합니다. 또한 UDC 를 계산하기 전에 압축되지 않은 용량의 최대 30% 할당량이 tempdb 에 할당됩니다. 총 용량이 더 큰 대용량 구성의 경우 이 비율은 최저 20%로 감소합니다.
tempdb 크기에 대한 자세한 내용은 tempdb 의 용량 계획 (http://msdn.microsoft.com/ko-kr/library/ms345368.aspx)을 참조하십시오.
결론SQL Server Fast Track 데이터 웨어하우스는 데이터 웨어하우스의 디자인에서 배포까지 사용되는 도구와 템플릿을 제공합니다. 이 문서에서는 Fast Track 데이터 웨어하우스에 대한 방법론, 구성 옵션, 최선의 구현 방법, 참조 구성 및 벤치마킹과 유효성 검사 기법을 설명합니다.
참조 항목:
SQL Server 웹 사이트
SQL Server Fast Track 웹사이트
SQL Server TechCenter
SQL Server 온라인 리소스
대규모 관계형 데이터 웨어하우스를 구축하기 위한 상위 10 개의 최선의 구현 방법 (SQLCAT 팀)
방법 : 메모리의 페이지 잠금 옵션 설정 (Windows)
고성능 작업을 위한 SQL Server 2005 및 SQL Server 2008 튜닝 옵션
방법 : 소프트 NUMA 를 사용하도록 SQL Server 구성
49
데이터베이스 파일 초기화
방법 : 데이터베이스의 복구 모델 보기 또는 변경 (SQL Server Management Studio)
메모리 사용 모니터링
SAN( 저장소 영역 네트워크 ) 문제 해결
MPIO 설치 및 구성
SQL Server 2000 I/O 기본 백서
데이터 압축 : 전략 , 용량 계획 및 최선의 구현 방법
이 문서가 도움이 되었습니까? 여러분의 의견을 알려 주십시오. 1점(나쁨)부터 5점(최고)까지의 점수 범위가 있다면 이 문서에 몇 점을 주시겠습니까? 그러한 점수를 주신 이유는 무엇입니까? 예를 들면 다음과 같습니다.
적절한 예, 훌륭한 스크린샷, 분명한 문체 또는 다른 이유 때문에 높은 점수를 주셨나요? 도움이 되지 않는 예, 애매한 스크린샷 또는 불분명한 문체 때문에 낮은 점수를 주셨나요?
이 의견은 앞으로 발행할 백서의 품질을 개선하는 데 유용하게 활용됩니다.
사용자 의견 보내기
부록
FTDW 시스템 크기 조정 도구FTDW 시스템 크기 조정 도구는 FTDW 시스템 처리량 측면에서 고객 작업 요구 사항의 계산 작업을 지원하는 스프레드시트 계산기입니다. 테스트 플랫폼이 없거나 고객의 요구 사항을 평가할 때 출발점으로 이 도구를 사용할 수 있습니다. 이 도구는 Fast Track 데이터 웨어하우징 (http://www.microsoft.com/sqlserver/en/us/solutions-technologies/data-warehousing/fast-track.aspx)에서 찾을 수 있습니다. 또한 일부 파트너 공급업체는 자체 표준에 맞는 Fast Track 크기 조정 도구를 만들었습니다. 이러한 도구는 파트너 웹 사이트에서 찾을 수 있습니다.
사용자 정의 FTRA 유효성 검사
가상 I/O 테스트SQLIO 는 SQL Server 와 독립적으로 I/O 하위 시스템을 테스트할 수 있는 도구이며 Microsoft에서 다운로드할 수 있습니다.
50
SQLIO 테스트 파일 생성SQLIO 실행 시 테스트 파일이 존재하지 않을 경우 적합한 테스트 파일이 생성됩니다. 특정 크기의 파일을 생성하려면 –F 매개 변수를 사용합니다. 예를 들어 다음을 포함하는 매개 변수 파일(param.txt)을 사용합니다.
C:\stor\pri\1\iobw.tst 1 0x0 50
–F 매개 변수를 사용하여 SQLIO 를 실행하면 첫 번째 실행 시 50MB 의 파일이 생성됩니다.
Eq sqlio -kW -s60 -fsequential -o1 -b64 -LS -Fparam.txt
파일이 클 경우 이 프로세스를 실행하는 데 다소 시간이 걸릴 수 있습니다. SQL Server 데이터 및 tempdb 파일을 호스팅할 각 데이터 디스크에 파일 하나를 만듭니다. 이 작업은 매개 변수 파일에 줄을 추가하여 수행할 수 있으며 이렇게 하면 필요한 파일이 하나씩 만들어집니다. 동시에 여러 개의 파일을 만들려면 매개 변수 파일을 여러 개 만든 다음 여러 SQLIO 세션을 동시에 실행합니다.
캐시에서 저장소 대역폭 유효성 검사읽기에 몇 분 정도 걸리는 작은 테스트 파일을 사용하면 파일이 저장소 캐시에 완전히 상주되도록 할 수 있습니다. 그림 7 은 대기 중인 요청 수와 블록 크기가 다양한 예제 Fast Track 시스템에 대한 Logical Disk > Read Bytes / sec 카운터가 나와 있습니다. 테스트는 일관된 성능을 위해 적어도 몇 분 동안 실행해야 합니다. 다음 그림에서는 최적의 성능을 얻으려면 파일당 적어도 요청이 4 개 이상인 미해결 요청 큐가 필요함을 보여 줍니다. 각 개별 디스크가 총 대역폭에 일조해야 합니다.
그림 7: Logical Disk > Read Bytes / sec 카운터
51
디스크에서 LUN/볼륨 대역폭 유효성 검사이러한 테스트를 통해 디스크 배열에서 Windows 에 제공하는 모든 디스크 볼륨이 한 번에 한 개씩 각 볼륨에서 읽어 전체 총 대역폭에 일조할 수 있는지 확인합니다. 일부 LUN 이 다른 LUN보다 다소 빠른 것처럼 보일 수 있습니다. 이는 정상적인 현상이지만 15% 이상 차이가 나는 경우 확인해야 합니다.
그림 8: LUN\볼륨 및 RAID 쌍 대역폭 유효성 검사
동일한 디스크 그룹을 공유하는 하나 이상의 볼륨에 대해 동시 테스트를 실행합니다. 다음 그림은 디스크 그룹 8 개에 대한 테스트의 출력을 보여 줍니다.
그림 9: 디스크 그룹을 공유하는 LUN 테스트
52
디스크에서 총 대역폭 유효성 검사다음 테스트에서는 일정한 간격으로 테스트에 볼륨을 추가하는 I/O 처리량의 단계적 증가 효과를 보여 줍니다. 각 테스트는 설정된 간격으로 실행되며 단계적 감소를 볼 수 있습니다. 유사한 패턴을 관찰해야 합니다. 디스크의 최고 총 대역폭은 첫 번째 단계의 캐시에서 보여 준 대역폭의 80 - 90%에 도달해야 합니다. 그래프는 여러 블록 크기(512K 및 64K)에서의 테스트를 보여 줍니다.
그림 10: 다양한 블록 크기에서의 총 대역폭
작업 테스트
서버에 대한 MCR 측정( 선택 사항)
MCR 의 목표는 I/O 병목 문제 없이 SQL Server 를 실행하는 단일 CPU 코어의 최대 처리량을 예측하는 것입니다. MCR 은 코어당 평가합니다. 다음은 자체 서버의 MCR 을 계산하기로 한 경우 MCR 계산에 대한 방법론을 설명하는 추가 정보입니다.
1. TPC-H lineitem 테이블 또는 유사한 데이터 집합을 바탕으로 참조 데이터 집합을 만듭니다. 테이블 크기는 SQL Server 버퍼 풀에 완전히 캐시되면서 여기서 제공하는 쿼리에 대해 2 초 이상의 실행 시간을 유지할 수 있는 정도여야 합니다.
2. FTDW 의 경우 SELECT sum([정수 필드]) FROM [테이블] WHERE [해당 데이터 볼륨으로 제한] GROUP BY [열] 쿼리가 사용됩니다.
3. 환경은 다음과 같아야 합니다. 리소스 관리자를 기본값으로 설정해야 합니다. 버퍼 캐시에서 쿼리를 실행해야 합니다. 쿼리를 한 번 실행하면 페이지가 버퍼에 추가되고 다음 쿼리 실행 시 버퍼를 통해 전부 읽어야 합니다. 쿼리 통계 출력에 물리적 읽기가 없어야 합니다.
STATISTICS IO 및 STATISTICS TIME 을 ON 으로 설정하여 결과를 출력합니다.
53
4. MAXDOP = 4 로 쿼리를 여러 번 실행합니다. 각 쿼리 실행에 대한 통계 출력에서 CPU 시간 및 논리적 읽기 수를 기록합니다. 다음 수식을 사용하여 MCR(MB/s)을 계산합니다.
( [논리적 읽기 수] / [CPU 시간(초)] ) * 8KB / 1024 최소 5 개 이상의 쿼리 실행을 통해 일관된 범위의 값(+/- 5%)이 나타나야 합니다.
이상값이 크면(+/- 20% 이상) 구성에 문제가 있을 수 있습니다. FTDW MCR 은 5개 이상의 계산된 결과에 대한 평균입니다.
작업에 대한 BCR 측정BCR 측정은 데이터가 캐시가 아니라 디스크에서 처리된다는 점을 제외하면 MCR 측정과 유사합니다. BCR 에 대한 데이터 집합 및 쿼리는 대상 데이터 웨어하우징 작업을 대표합니다.
BCR 을 구하는 한 가지 방법은 작업에서 간단한 쿼리, 평균 쿼리 및 복합 쿼리를 가져오는 것입니다. 복합 쿼리는 CPU 를 더 많이 사용하는 쿼리입니다. 간단한 쿼리는 MCR 과 비교할 수 있도록 MCR 과 유사하고 작업량이 비슷해야 합니다.
데이터베이스 만들기다음은 데이터 LUN 이 16 개인 8코어 FTDW 시스템에 대한 CREATE DATABASE 문의 예입니다.
CREATE DATABASE FT_Demo ON PRIMARY Filegroup FT_Demo( NAME = N 'FT_Demo_.mdf' , FILENAME = N'C:\FT\PRI\SE1-SP1-DG1-v1' , SIZE = 100MB , FILEGROWTH = 0 ),( NAME = N 'FT_Demo_v1.ndf' , FILENAME = N'C:\FT\PRI\SE1-SP1-DG1-v1' , SIZE = 417GB , FILEGROWTH = 0 ),( NAME = N 'FT_Demo_v2.ndf' , FILENAME = N'C:\FT\PRI\SE1-SP1-DG2-v2' , SIZE = 417GB , FILEGROWTH = 0 ),( NAME = N 'FT_Demo_v3.ndf' , FILENAME = N'C:\FT\PRI\SE1-SP2-DG3-v3' , SIZE = 417GB , FILEGROWTH = 0 ),( NAME = N 'FT_Demo_v4.ndf' , FILENAME = N'C:\FT\PRI\SE1-SP2-DG4-v4' , SIZE = 417GB , FILEGROWTH = 0 ), ( NAME = N 'FT_Demo_v6.ndf' , FILENAME = N'C:\FT\PRI\SE2-SP1-DG6-v6' , SIZE = 417GB , FILEGROWTH = 0 ),( NAME = N 'FT_Demo_v7.ndf' , FILENAME = N'C:\FT\PRI\SE2-SP1-DG7-v7' , SIZE = 417GB , FILEGROWTH = 0 ),( NAME = N 'FT_Demo_v8.ndf' , FILENAME = N'C:\FT\PRI\SE2-SP2-DG8-v8' , SIZE = 417GB , FILEGROWTH = 0 ),( NAME = N 'FT_Demo_v9.ndf' , FILENAME = N'C:\FT\PRI\SE2-SP2-DG9-v9' , SIZE = 417GB , FILEGROWTH = 0 ), ( NAME = N 'FT_Demo_v11.ndf' , FILENAME = N'C:\FT\PRI\SE3-SP1-DG11-v11' , SIZE = 417GB
, FILEGROWTH = 0 ),( NAME = N 'FT_Demo_v12.ndf' , FILENAME = N'C:\FT\PRI\SE3-SP1-DG12-v12' , SIZE = 417GB
, FILEGROWTH = 0 ),( NAME = N 'FT_Demo_v13.ndf' , FILENAME = N'C:\FT\PRI\SE3-SP2-DG13-v13' , SIZE = 417GB
, FILEGROWTH = 0 ),( NAME = N 'FT_Demo_v14.ndf' , FILENAME = N'C:\FT\PRI\SE3-SP2-DG14-v14' , SIZE = 417GB
, FILEGROWTH = 0 ),
54
LOG ON( NAME = N 'FT_LOG_v5.ldf' , FILENAME = N 'C:\FT\LOG\SE1-SP2-DG5-v5' , SIZE = 100GB , MAXSIZE = 500GB , FILEGROWTH = 50 )GO
/*****************Configure recommended settings***********************/ALTER DATABASE FT_Demo SET AUTO_CREATE_STATISTICS ONGO
ALTER DATABASE FT_Demo SET AUTO_UPDATE_STATISTICS ONGO
ALTER DATABASE FT_Demo SET AUTO_UPDATE_STATISTICS_ASYNC ON GO
ALTER DATABASE FT_Demo SET RECOVERY SIMPLE GO
sp_configure 'show advanced options', 1go
reconfigure with overridego
/********Make sure all tables go on our filegroup and not the Primary filegroup****/ALTER DATABASE FT_DemoMODIFY FILEGROUP FT_DemoDEFAULTGO
테스트 테이블 만들기다음은 CREATE TABLE 문의 예입니다.
CREATE TABLE lineitem ( l_orderkey bigint not null, l_partkey integer not null, l_suppkey integer not null, l_linenumber integer not null, l_quantity float not null, l_extendedprice float not null, l_discount float not null, l_tax float not null, l_returnflag char(1) not null, l_linestatus char(1) not null, l_shipdate datetime not null, l_commitdate datetime not null, l_receiptdate datetime not null, l_shipinstruct char(25) not null, l_shipmode char(10) not null, l_comment varchar(132) not null )ON FT_DemoGO
CREATE CLUSTERED INDEX cidx_lineitem ON lineitem(l_shipdate ASC)
55
WITH( SORT_IN_TEMPDB = ON , DATA_COMPRESSION = PAGE )ON FT_DemoGO
BCR 측정에 대한 데이터 로드이 문서의 앞부분에서 설명한 대로 Fast Track 데이터 웨어하우스 시스템은 데이터베이스 파일의 조각화에 영향을 받습니다. 이 문서에서 설명한 방법 중 하나를 사용하여 데이터를 로드합니다. FTDW 테스트에서는 방법 2 에서 설명한 클러스터형 인덱스 로드 방법을 사용했습니다. TPC-H datagen 도구에서 -s100 옵션을 사용하고 파일을 8 개 부분으로 생성하며 –S 및 –C 옵션을 사용하여 lineitem 테이블 데이터를 70GB 의 크기로 만들었습니다.
가능한 경우 최소 로깅을 사용하도록 모든 로드 작업 중에 추적 플래그 610 이 설정되었습니다.
BULK INSERT 를 사용하여 단일 클러스터형 인덱스 준비 테이블에 이 데이터를 병렬로 삽입했고 최소 로깅을 사용했습니다. 사용 가능한 메모리를 과도하게 채우지 않는 블록 크기를 선택하여 디스크로 확산되지 않도록 했습니다. 준비 테이블에서 페이지 잠금 및 잠금 에스컬레이션을 사용하지 않도록 설정하여 이 단계에서 성능을 높였습니다.
마지막 삽입은 MAXDOP 1(TABLOCK 힌트 사용)을 사용하여 동일한 대상 테이블에 정렬 없이 수행되었습니다.
BCR 측정에 대한 쿼리 실행SQL Server Profiler 도구를 사용하여 쿼리 벤치 마크 관련 정보를 기록합니다. SQL Server Profiler 는 논리적 읽기, CPU, 지속 시간, 데이터베이스 이름, 스키마 이름, SQL 문, 실제 쿼리 계획을 기록하도록 설정해야 합니다. 또는 통계 세션 매개 변수 SET STATISTICS IO ON 및 SET STATISTICS TIME ON을 사용할 수 있습니다.
다음은 참조 시스템에서 구한 BCR 과 몇 가지 예제 쿼리(TPC-H 벤치마크의 쿼리 기반)입니다. 이 예는 특정 시스템에서 얻을 수 있는 성능 지표가 아닙니다. BCR 값은 시스템, 스키마 크기, 데이터 형식, 쿼리 구조 및 통계에 대해 고유하며 많은 변수 중 몇 개에 이름을 지정합니다.
쿼리 복잡성 MAXDOP 4 에서 코어당 BCR(페이지 압축)
단순 201MB/s보통 83MB/s복잡 56MB/s표 7: 벤치 마크의 예
단순
SELECT sum(l_extendedprice * l_discount) as revenueFROM
56
lineitemWHERE l_discount between 0.04 - 0.01 and 0.04 + 0.01 and l_quantity < 25OPTION (maxdop 4)
보통
SELECT l_returnflag, l_linestatus, sum(l_quantity) as sum_qty, sum(l_extendedprice) as sum_base_price, sum(l_extendedprice*(1-l_discount)) as sum_disc_price, sum(l_extendedprice*(1-l_discount)*(1+l_tax)) as sum_charge, avg(l_quantity) as avg_qty, avg(l_extendedprice) as avg_price, avg(l_discount) as avg_disc, count_big(*) as count_orderFROM lineitemWHERE l_shipdate <= dateadd(dd, -90, '1998-12-01')GROUP BY l_returnflag, l_linestatusORDER BY l_returnflag, l_linestatusOPTION (maxdop 4)
복잡
SELECT 100.00 * sum(case when p_type like 'PROMO%' then l_extendedprice*(1-l_discount) else 0
end) / sum(l_extendedprice * (1 - l_discount)) as promo_revenueFROM lineitem, partWHERE l_partkey = p_partkey and l_shipdate >= '1995-09-01' and l_shipdate < dateadd(mm, 1, '1995-09-01')
57
OPTION (maxdop 4)
쿼리 사용률에 영향을 주는 요인MCR(최대 CPU 사용률) 또는 BCR(벤치마크 사용률)을 달성하지 못하는 쿼리도 있습니다. 쿼리 사용률에 영향을 주는 요인에는 여러 가지가 있습니다. 사용률을 구하는 데 사용하는 작업보다 간단한 쿼리는 사용률이 더 높고 작업이 복잡할수록 사용률이 낮습니다. 다음은 복잡성과 사용률에 영향을 줄 수 있는 여러 요인의 예입니다.
쿼리 복잡성: 예를 들어 계산 및 집계 수 측면에서 쿼리가 CPU 를 많이 사용할수록 사용률은 더 낮습니다.
정렬 복잡성: 명시적인 order by 작업이나 group by 작업의 정렬은 더 많은 CPU 작업을 생성하므로 사용률이 감소합니다. 디스크로 확장되는 쿼리 등으로 인한 tempdb 에 대한 추가 쓰기는 사용률에 부정적인 영향을 줍니다.
쿼리 계획 복잡성: 각 데이터 단위는 긴 작업 파이프라인을 통해 처리되기 때문에 쿼리 계획이 더 복잡할수록 단계와 연산자가 많아지고 CPU 사용률은 낮아집니다.
압축: 사용률은 기본적으로 CPU 바인딩된 쿼리에 대해 측정되기 때문에 압축하면 실제로 데이터 사용량이 줄어들고 압축을 해제하면 CPU 주기를 사용합니다. 그러나 작업에서 CPU 를 많이 사용하지 않는 경우 일반적으로 압축과 관련된 CPU 오버헤드가 추가되더라도 처리량이 향상되는 것이 더 유용합니다. 압축된 데이터와 압축되지 않은 데이터에 대한 사용률을 비교할 때는 압축비를 고려해야 합니다. 또 다른 방법은 초당 행 수 관점에서 사용률을 고려하는 것입니다.
데이터 사용률: 검사 중 데이터 삭제(예: 쿼리 예측 및 선택 사용)는 매우 효율적인 프로세스입니다. 쿼리에서 테이블의 데이터를 모두 사용하는 경우 단위 데이터 처리량당 더 많은 데이터가 처리되므로 사용률이 낮아집니다.
58