Ivan Kosyakov — FastTrack DW

FastTrack Data Warehouse
Особая благодарность
Алексею Халяко из SQLCAT
Иван Косяков
Technology Architect, MTC Moscow
i-ivanko@microsoft.com
Что такое FastTrack Data Warehouse?
 Метод построения эффективной по затратам, сбалансированной
системы для загрузки, типично для хранилищ данных
 Эталонные аппаратные конфигурации разработаны с
поставщиками оборудования
 Рекомендации размещения, загрузки и управления данными
Используется только для реляционных хранилищ –
не для SSAS, IS, RS
Темы
 Сбалансированная архитектура, как подход к
построению DW
 Примеры справочных архитектур FastTrack DW
 Оптимизация хранилищ, загрузки и поддержка
 Примеры внедрений
 Выводы
SQL Server
Windows Server OS
Storage Interconnect
Архитектура компонентов FastTrack DW
Storage
Processor
Disk Array
Host Storage Adaptor
Server
Storage Enclosure
CPU Feed Rate
FC
HBA
SQL Server
Read Ahead Rate
A
B
A
B
HBA Port Rate
DISK
A
B
STORAGE
CONTROLLER
CACHE
FC
HBA
FC SWITCH
CACHE
SQL SERVER
WINDOWS
CPU CORES
SERVER
Потенциальные узкие места в системе
DISK
A
LUN
A
B
DISK
DISK
B
LUN
Switch Port Rate
SP Port Rate
LUN Read Rate
Disk Feed Rate
Сбалансированная архитектура
Компонент
Сбалансирован для …
CPU
Максимальное потребление данных из кэша для
определенных наборов запросов (на следующих
слайдах)
Controller (Service
Пропускной канал для поставки данных ядрам CPU
(базируется на наборе запросов)
Processor)
HBA
(Host Bus Adapter)
Агрегирует потоки данных, поставляемые контроллером
Switch
Выровнен с пропускной способностью HBA и
оптимизирован для последовательного ввода-вывода
Disks
Агрегирует потоки данных с контроллера /емкость
хранилища
Cбалансированная система





Построить систему, состоящую из сервера и хранилища, в которых
пропускная способность ввода-вывода может достаточно загрузить SQL
Relational DW
Избегайте разделения хранилища с другими серверами
Избегайте избыточного инвестирования в диски
 Обращайте внимание на производительность scan операций, а не IOPS
Располагайте данные так, чтобы максимально использовать сканирование
диапазонов
Минимизировать фрагментацию данных
Характеристики нагрузок хранилищ данных
 Интенсивные
сканирования
 Hash Joins
 Агрегации
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(*) AS COUNT_ORDER
FROM
LINEITEM
GROUP
BY
L_RETURNFLAG,
L_LINESTATUS
ORDER
BY
L_RETURNFLAG,
L_LINESTATUS
Проверка системы
 Для подтверждения корректной настройки
 Фазы тестирования:
 Синтетические тесты ввода-вывода
 Проверка системы хранения, сети, операционной системы
 SQLIO для генерации операций ввода-вывода
 Perfmon – для мониторинга
 Тестирование SQL Server
 Проверка производительности стека SQL Server
 Maximum Consumption Rate (MCR) – данные из памяти для
обработки запроса процессором
 Benchmark Consumption Rate (BCR) – данные с диска для
обработки типичной нагрузки процессором
 Финальный шаг процесса внедрения
Демонстрация
тестирования ввода-вывода
Сбалансированная система - CPU
 Определить объем потребления данных на ядро процессора для
набора запросов


Пример: Предположим TPC-H запрос 2 – типичная загрузка для
системы
Выполнить запрос на тестовом сервере с данными полностью
загруженными в кэш
 Запрос выполняется параллельно с MAXDOP 4
 Убедиться в загрузке 100% CPU на 4 ядрах
 Засечь время выполнения и определить количество прочитанных
#страниц
 (Set Statistics IO on; Set Statistics Time on)
 Расчет нагрузки на ядро = (# Logical Reads * 8K)/(CPU Time)
Можно сделать еще корректнее
 В принципе, запросы, которые выполняют
достаточно сложные вычисления,
форматирование, объединения измерений –
потребляют больше CPU
 Сложные запросы будут «медленней» потреблять
мощность ядер, чем простые
 Измерить потребление данных на ядро для
разных запросов и вычислить «средний вес»
 Стандартный подход при расчете вычислительной
емкости системы
Или давайте это сделаем мы…
 Мы протестировали набор TPCH запросов,
которые соответствуют «типовой» загрузке для
Data Warehouse
 Сделали вывод, что SQL Sever 2008 на нынешней
x64 ядерной платформе потребляет ~200 MB/Sec
на ядро в среднем для такого типа загрузки
 Использовали эти выводы как базу для
опубликованной «эталонной» архитектуры
 Однако, Ваша нагрузка может отличаться!
 Для точного выбора архитектуры и объемов используйте
свои измерения
Примеры загрузки CPU
Пример 1:
Характеристики запроса: Сканирование одного кластерного индекса, hash
match, агрегации по 8 столбцам
Statistics IO: logical reads 3361015, physical reads 0, Readahead reads 0
Statistics Time: CPU time = 144690 ms
Нагрузка на ядро: (3361015 * 8K) / (144690) = 185 MB/s per core
Пример 2:
Характеристики запроса: 3 объединения таблиц, одна агрегация,
множественные hash joins, агрегация по одному столбцу
Statistics IO:
logical reads (total all tables) 2078006, physical reads 0, Readahead reads 0
Statistics Time: CPU time = 121167 ms
Нагрузка на ядро: (2078006 * 8K) / (121167) = 137 MB/s per core
Quad Core AMD
Opteron 2384 (Shanghai)
Fast Track калькулятор
 Определив типы запросов к системе
используйте калькулятор:
User Variable Input
Anticipated total number of users expected on
the system
Estimated percent of actual query concurrency
Fast Track DW CPU max core consumption rate
(MCR) in MB/s of page compressed data per core
Estimated compression ratio (default = 2.5:1)
Estimated drive serial throughput speed in
compressed MB/s
Number of data drives in single storage array
Usable capacity per drive
Space Reserved for TempDB
Adjust for
workload mix
3.000 us e rs
1% concurre ncy
200 MB/s
2,5 :1
Estimated %
Estimated % of data found in
workload
SQL Server
cache
Estimated Query
Desired Query
Data
Estimated Disk
Response Time
Scan Volume
Scan volume MB
(seconds)
MB
(Uncompressed)
(under load)
(Uncompressed)
Si mpl e
70%
10%
8.000
25
7.200
Ave ra ge
20%
0%
75.000
180
75.000
Compl e x
10%
0%
450.000
1.200
450.000
100%
100 MB/s
8 dri ve s
272 GB
26%
Calculations and Results
% of core
consumption
rate achieved
Simple
Average
Complex
100%
50%
25%
Expected per
CPU core
consumption
rate (MB/s)
200
100
50
Calculated
Single Query
Scan Volume in
MB
(compressed)
2.880
30.000
180.000
Calculated
Target
Concurrent
Queries
Estimated
Target
Queries per
Hour
Required IO
Throughput in
MB/s
Estimated
Estimated Single
Number of
Query Run Time
Cores Required
(seconds)
21
6
3
3.024
120
9
2.419
1.000
450
12,10
10,00
9,00
30
3.153
3.869
32,00
0,5
9,4
112,5
Сбалансированная система - хранилище
 Количество ядер CPU и пропускная способность
загрузки помогут определить количество
контроллеров и «корзин» для представления
суммарной нагрузки
 # контроллеров определит минимальное
количество дисков для предоставления пропускной
способности сканирования
 Определить требуемую емкость / # дисков исходя
из ожидаемого объема дискового пространства

Оставить достаточно пространства для TempDB или особенно
большим таблицам в системе (для административных задач)
Сбалансированная система - IO
 Используем для начала
2-x четырех ядерных
сервера
 Убедиться, что скорость
потребления данных на
ядро может быть
предоставлена всеми
компонентами в стеке
ввода-вывода
Максимальная теоретическая пропускная
способность IO стека оптимизированного для 8
ядерной Fast Track архитектуры ( предполагая
200 MB/s на ядро)
CPU Socket
(4 Core)
CPU Socket
(4 Core)
Сбалансированная система –
хранилище (2) Наблюдаемая пропускная способность
 Теоретические
максимумы - всегда
только теоретические
 Тесты для получения
реальных параметров
могут быть
необходимы
на 8 ядерной системе Fast Track при
выполнении SQLIO
CPU Socket
(4 Core)
CPU Socket
(4 Core)
Сбалансированная система – масштабирование
Storage Processor
Fiber
Switch
CPU
Socket
(4 Core)
CPU
Socket
(4 Core)
CPU
Socket
(4 Core)
CPU
Socket
(4 Core)
Storage Processor
CPU
Socket
(4 Core)
CPU
Socket
(4 Core)
Storage Processor
CPU
Socket
(4 Core)
CPU
Socket
(4 Core)
Storage Processor
Storage Enclosure
Storage Processor
RAID-1
RAID-1
RAID-1
RAID-1
RAID-1
Storage Enclosure
Storage Processor
RAID-1
RAID-1
RAID-1
RAID-1
RAID-1
Storage Enclosure
Storage Processor
Storage Processor
HBA
Storage Processor
Storage Processor
HBA
HBA
Storage Processor
Storage Processor
Storage Processor
Storage Processor
RAID-1
RAID-1
RAID-1
Storage Enclosure
RAID-1
RAID-1
RAID-1
RAID-1
RAID-1
RAID-1
RAID-1
RAID-1
RAID-1
RAID-1
Storage Enclosure
HBA
HBA
RAID-1
RAID-1
Storage Enclosure
HBA
HBA
RAID-1
RAID-1
RAID-1
RAID-1
RAID-1
Storage Enclosure
HBA
Server
RAID-1
RAID-1
RAID-1
RAID-1
RAID-1
Storage Processor
Storage Processor
RAID-1
RAID-1
RAID-1
RAID-1
RAID-1
Storage Enclosure
Темы
 Предпосылки
 Сбалансированная архитектура, как подход к
построению DW
 Примеры справочных архитектур FastTrack DW
 Оптимизация хранилищ, загрузки и поддержка
 Примеры внедрений
 Выводы
Оптимизация схемы хранилища для
интенсивных сканирований
 Конфигурация LUN’ов базируется на
RAID10

Предоставляет оптимальный уровень
доступа к дискам
 «Размазывание» данных по дискам
происходит на уровне файлов SQL
Server (разбиение на файлы в
файловой группе)
 Наблюдаемая производительность
одной RAID пары >= 130 MB/s
S
P
A
S
P
B
RAID GP01
RAID GP02
01
03
02
LUN1
LUN3
LUN2
LUN4
04
RAID GP04
05
07
06
LUN7
LUN6
LUN8
09
10
LUN0
(Logs)
RAID GP03
LUN5
RAID GP05
08
HS
Влияние схемы хранилища на SQL Server
Stage
DB
Permanant_DB
LUN 1
LUN 2
LUN16
LUN 3
Permanent FG
Permanent_1.ndf
Permanent_2.ndf
Permanent_16.ndf
Permanent_3.ndf
Stage FG
Stage_1.ndf
Stage_2.ndf
Stage_3.ndf
Stage_16.ndf
Temp
DB
Local Drive 1
TempDB.mdf (25GB)
TempDB_02.ndf (25GB)
TempDB_03ndf (25GB)
TempDB_16.ndf (25GB)
Log LUN 1
Permanent DB Log
Stage DB Log
Секционирование таблиц
Table January: Partitioned by day, all days in one File Group
January_static
01.01.2011 02.01.2011 …
January_1.ndf
January_2.ndf
January_3.ndf
January_4.ndf
…
January_N.ndf
FG_January
February_Static
30.01.2011 31.01.2011
01.02.2011 02.02.2011 …
LUN1
LUN_N
27.02.2011 28.02.2011
February_1.ndf
February_2.ndf
February_3.ndf
February_4.ndf
…
February_N.ndf
FG_February
Обзор фрагментации
 Логическая фрагментация


Величина, показывающая степень несоответствия порядка размещения
физических страниц логическому ключу(по всем файлам)
sys.dm_db_index_physical_stats: Logical_Fragmentation
B-tree
Page
Фрагментация
B-tree
Page
B-tree
Page
Листовые
страницы
1:31
1:32
1:54
1:33
1:34
1:35
1:53
1:36
Логический порядок индекса
1:37
1:38
1:39
1:40
1:41
1:42
1:80
1:60
Обзор фрагментации
 Фрагментация экстентов
 Величина, показывающая на сколько размещение
экстентов является упорядоченным (по всем файлам)
 sys.dm_db_index_physical_stats:
Avg_Fragment_Size_in_Pages, Fragment_Count
Idx 1
Idx 1
Idx 2
Idx 2
Idx 1
Idx 1
Idx 1
Idx 1
Экстенты внутри файла данных
Idx 1
Idx 2
Idx 1
Idx 1
Idx 1
Idx 1
Idx 1
Idx 1
Как оптимизировать сканирование
 SQL Server выполняет большое количество асинхронных read-ahead
запросов выполняя сканирование
 Пытается выполнить столько операций I/O, чтобы поддерживать CPU
“занятым”
 Размер I/O зависит от «продолжительности» фрагмента в файле данных

Размер I/O может быть в диапазоне от 8K до 512K
 Средний размер read-ahead запроса может быть выяснен с помощью

avg_fragment_size_in_pages в составе sys.dm_index_physical_stats

Значения >= 64 страниц означает, что размер I/O’s близок к 512K
Read-Ahead операции в действии
 Кластерный индекс: упорядоченный ключ
1.
2.
3.
Каждый следующий запрошенный диапазон страниц
определяется при поиске в B-дереве следующего диапазона
ключей
Страницы в диапазоне отсортированы
I/O запрос выполняется для каждого непрерывающегося
диапазона страниц (до 64 страниц в запросе)
 Heap: порядок размещения
 Сканируются GAM страницы, чтобы определить следующий
диапазон страниц
1. I/O запрос выполняется для каждого непрерывающегося
диапазона страниц (до 64 страниц в запросе)
Read-Ahead операции в действии
Определение следующего диапазона страниц для
запроса, основываясь на упорядоченном ключе
(пример: ключи A-B)
B-tree
Page
1
B-tree
Page
B-tree
Page
Физический порядок страниц
2
A
1:31
B
1:32
B
1:33
B
1:34
B
1:35
C
1:36
D
1:37
B
1:38
B
1:39
C
1:40
D
1:41
A
1:42
A
1:43
Группирование в физическом порядке
A
1:31
B
1:32
B
1:38
B
1:39
A
1:42
A
1:43
B
1:33
A
1:44
B
1:34
A
1:45
B
1:35
A
1:46
3
3. Выполнение I/O
запросов для каждого
непрерывного куска
Disk
A
1:44
A
1:45
A
1:46
Приемы для увеличения
эффективности сканирования







Параметры запуска:
 -E – экстенты до 2 Мбайт
 -T1117 – равномерный рост всех файлов в файловой группе
Минимизировать использование некластерных индексов на таблице фактов
Использовать техники загрузки данных, позволяющих избегать фрагментацию
 Загрузка в порядке сортировки кластерного индекса (допустим, по дате)
если это возможно
Создавать индекс всегда с MAXDOP 1, SORT_IN_TEMPDB
Изолировать «активные» таблицы в другие файловые группы
Изолировать стейджинговые таблицы в отдельные файловые группы или базы
Периодические административные операции
«Обычный» тип загрузки приводит к
фрагментации
 Bulk Insert в кластерный индекс со «средним» размером пакета
 Каждый пакет отсортирован независимо
 Пересекающиеся пакеты приводят к «расщеплениям» страниц
1:31
1:36
1:32
1:32
1:33
1:37
1:34
1:33
1:35
1:36
1:37
1:38
1:39
1:40
1:38
1:34
Порядок сортировки по ключу
1:39
1:35
1:40
Альтернативные пути загрузки
 Использование heap
 Полезно, если запрос сканирует всю секцию
 или…использование BATCHSIZE = 0
 Допустимо. Если параллелизм при загрузке не требуется
 или…загрузка в два приема
1. Загрузка в стейджинговую таблицу (heap)
2. INSERT-SELECT из стейджинговой таблицы в целевую с CI
В результате таблица не фрагментирована
В шаге 1 можно использовать параллелизм, что критично при
загрузке больших объемов данных
Двух шаговая загрузка – варианты
 Вариант A: высокий параллелизм при загрузке архивных данных

Обычно в секционированную таблицу

Использование временных таблиц (heap), секционированных по тому
же принципу, что и целевая таблица

Использование множественных потоков при загрузке во временную
таблицу с «умеренным» размером пакетов batchsize (SSIS, Bulk Insert, и
т.д.)

INSERT-SELECT в раздельные секции целевой таблицы (параллелизм)
 Использование ALTER TABLE SET (LOCK_ESCALATION = AUTO)
 Внимание: если памяти не хватает, то TempDB будет перегружена
операциями сортировки sorting
Двух шаговая загрузка –
варианты
 Вариант B: избегаем нагрузку на TempDB во время
загрузки данных



Использовать стейджинговые таблицы, которые используют индексы,
аналогичные целевой таблице
Загрузка в стейджиговые таблицы с «умеренным» размером пакетов:
batchsize (< 1M rows)
Финальный INSERT-SELECT в целевую таблицу будет сортированным!
 Однако мы платим журналированием вставки в стейджинговую таблицу

Внимание: ограниченный параллелизм при «накладке» диапазонов
вставки
Другие рекомендации по избеганию фрагментации
 НЕ использовать Autogrow для файловых групп

Заранее назначать размер файловой группе, исходя из ожиданий
использования базы

Если нужно, то производить операцию «вручную» добавляя сразу
большие «куски»
 «Активные таблицы» - в отдельную файловую группу

Таблицы, которые часто перестраиваются, или куда данные
добавляются маленькими порциями
 Если архивные данные загружаются параллельно, можно подумать о
разделении файловых групп для разделения секций, к ним
привязанных и избежать фрагментации экстентов
Иногда фрагментации не избежать
 Если «дозаливки» пересекаются с уже
существующими диапазонами данных в
кластерном индексе – расщеплений страниц
не избежать
 Периодические административные действия
могут помочь уменьшит/избежать
фрагментации
 Секционирование по историческому ключу
(date key) может помочь уменьшить объем
административных задач
Администрирование
 Использовать
ALTER INDEX … REBUILD …
… WITH (MAXDOP = 1, SORT_IN_TEMPDB)




Один поток -- избегаем создания фрагментации экстентов
Можно ограничиться перестроением «актуальной» секции
Избегайте использовать ALTER INDEX … REORGANIZE
Страницы будут упорядочены на физическом уровне, однако
может отразиться серьезной фрагментацией экстентов
Управление «долгосрочной»
фрагментацией
 Иногда проще «начать с начала» :
 Создать новую файловую группу, чтобы перенести данные. Удалить
старую группу
 Создать пустую копию таблицы в новой файловой группе
 С совпадающими ключами секционирования и кластеризации
 INSERT-SELECT из старой таблицы в новую
 Создать вторичные индексы
 Удалить оригинальную таблицу и переименовать новую
 Все шаги могут выполняться онлайн
Стратегии индексирования
 Если большинство операций (запросов)
характеризуются сканированием диапазонов –
нужен ли нам кластерный индекс?


Ключ секционирования не обязательно должен быть кластерным
Меньше проблем при параллельной заливке данных
 Какая нагрузка возлагается на некластерные
индексы?


Возможные блокировки при заливке данных
Неактуальная статистика может привести к неэффективным CI или
RID Lookup
 Необходим «облегченный! Вариант индексирования
Секционирование для доступности
INSERT /
UPDATE
•
Исторические и актуальные данные
находятся в разных таблицах, в
разных файловых группах
2010-08
2010-01 to 2010-07
ALTER VIEW +
SWITCH
MSCFactCDR
(View)
2009
2008
2007
SELECT ...
FROM
MSCFactCDR
Пример 1: Страховая компания--
массивная загрузка за ограниченное время
 Задача: Загрузить и дополнить данные объемом в 50
GB за менее, чем 1 час
 Выполнимо только при высоком параллелизме
загрузки
 Используется секционирование таблицы
 Секционирование по ключу “customer”
 Кластерный индекс по дате!
 # секций = # ядер
 Параллельная загрузка во временные таблицы
 Разделение файловых групп (группа – секция) не допускают
пересечения загрузок
Архитектура
MSA2000 DAE
Pri_A
Pri_B
Pri_C
Primary Storage
8 Drives
(4 RAID1 Pairs)
Pri_D
Log
Logs
2 Drives
(1 RAID1 Pair)
Hot
Spare
Hot
Spare
Spares
2 Drives
Результат
Существующее решение
SQL Server
Fast Track DW
51:31 total time
Сравнение
R SQL Server 6x
faster
4:36:08 total time
1:50.01 total time
R SQL Server 2.5x
faster
3:03 avg query time
0:15 avg query time
R SQL Server 12x
(using 9 benchmark queries) (using 9 benchmark queries)
faster
Loading –
Subject Area 1
Loading –
Subject Area 2
Время запроса–
Subject Area 1
5:10:21 total time
Время запроса –
Subject Area 2
56:44 avg query time
8:09 avg query time
R SQL Server 7x
(using 4 benchmark queries) (using 4 benchmark queries)
faster
Цена за TB (8TB) – Cal :
Цена за TB (16TB) – Cal:
$22K / TB
$13K / TB
Пример 2: Телеком– изначальная
загрузка данных
 Загрузка 400 GB в «новый» кластерный индекс на
8-ядерном сервере в течении 7часов
 Целевая таблица- 8 секций поделенных по
историческим диапазонам
 3-шаговая загрузка, использующая
секционирование



Load, Index, Switch
Все шаги используют параллелизм
Минимальное журналирование
Европейский Телеком
Описание
 Реляционная часть разработана на :
 HP DL785 G6 с 8 x 6 ядрами AMD
 196GB RAM
 EMC SAN с 12 x EMC AX4, где каждый 20 x 450 GB дисков.
 Общая ёмкость примерно 38 TB без сжатия и 76 TB при
консервативной оценке сжатия в 50%
 Windows Server 2008 R2 Enterprise Edition
 SQL Server 2008 R2 Enterprise Edition
Производительность
Оценка производительности была произведена с помощью:
 SQLIO
 SQL Server обрабатывал актуальные данные
Результаты:
 SQLIO показал общую пропускную способность системы в 9,6GB/sec,
что является теоретическим максимумом.
 SQL Server производил сканирование таблиц со скоростью в 8,8 до
9.0GB/sec.
 SQLIO показал комбинированную скорость записи в 4,7 до 5.1 GB/sec
 SQL Server произвел запись 1 TB за менее, чем 20 минут при
использовании параллельных пакетов SSIS.
 SQL Server показал скорость создания резервной копии в более, чем
3 GB/sec.
“Почти FastTrack”
 Многие клиенты следуют рекомендациям
FastTrack без точного следования описанной
архитектуре:
 НЕ использовать разделяемое хранилище данных
 Инвестировать в большее количество «полок» и HBA для
обеспечения соответствующей пропускной способности
 Повысить эффективность операций сканирования используя
техники загрузки данных
Fast Track «подобная» система
Table Scan
Current Disk Queue Length = ~ 670
(достаточное время отклика,
учитывая объем и глубину
outstanding I/O)
•
Storage – MSA60
–
Disk Read Bytes / sec = ~ 4 GB/s
–
Read-ahead pages/sec is почти на
том же уровне, что и pages/sec.
•
5 x HP SAS P800 controllers with 512MB
cache.
Каждый конроллер подключен MSA60
«полке»
LUN Configuration
–
–
–
24 Data LUNs, One RAID1 Pair per LUN
1 Log LUN
50 spindles total
Avg.Disk Bytes/Read = ~ 500 KB
А если нагрузка включает много Random
IO?
 Принципы FastTrack позволят получить приемлемую
скорость для операций сканирования.
 Особенно учитывая количество контроллеров и HBAs
Однако
 Возможно придется дополнительно инвестировать в
большее количество дисков для обеспечения
поддержки высокого уровня random IO в секунду
 100+ дисков – не редкость
Рекомендация
 Изучите «FastTrack Methodology and Reference
Architectures for Data Warehouse»
http://www.microsoft.com/sqlserver/2008/en/us/
fasttrack.aspx
Дополнительные ресурсы:
 Data Loading Performance Guide
http://msdn.microsoft.com/en-us/library/dd425070.aspx
 SQLCAT Top 10 DW Best Practices
http://go.microsoft.com/fwlink/?LinkId=141862
Questions?