Справочник по хранилищу данных Fast Track для SQL Server 2012

Справочник по хранилищу данных Fast Track для SQL Server 2012
Техническая статья по 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 года
Область применения: SQL Server 2012
Сводка. В этой статье определена эталонная модель конфигурации (известная как
хранилище данных Fast Track), в которой используется подход с балансированием
ресурсов к реализации архитектуры системы баз данных SQL Server на основе
симметричной мультипроцессорной обработки (SMP). Данная модель доказала свою
производительность и масштабируемость для рабочих нагрузок хранилищ данных.
Назначение эталонной архитектуры хранилища данных Fast Track состоит в достижении
эффективного балансирования ресурсов между возможностями обработки данных SQL
Server и достигнутой пропускной способностью компонентов оборудования.
Авторские права
Документ предоставляется «как есть». Сведения и мнения, содержащиеся в этом документе,
включая URL-адреса, а также ссылки на другие веб-сайты, могут изменяться без предварительного
уведомления. Вы принимаете на себя риск, связанный с использованием данного документа.
Этот документ не предоставляет пользователям права интеллектуальной собственности на какиелибо продукты Майкрософт. Разрешается копирование и использование документа в справочных
целях, для внутреннего использования.
© Корпорация Майкрософт (Microsoft Corporation), 2012. Все права защищены.
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
Качественные атрибуты рабочей нагрузки хранилищ данных ......................................................... 13
Выбор эталонной конфигурации FTDW................................................................................................... 15
Вариант 1. Базовая оценка ................................................................................................................... 15
Шаг 1. Оценка варианта использования, предложенного клиентом ............................................... 15
Шаг 2. Выбор опубликованной эталонной архитектуры FTDW..................................................... 17
Вариант 2. Общая оценка ..................................................................................................................... 17
Общие сведения о процессе ............................................................................................................ 17
Шаг 1. Оценка варианта использования для клиента .................................................................... 18
Шаг 2. Определение показателей оценки ...................................................................................... 18
Шаг 3. Выбор эталонной архитектуры хранилища данных Fast Track .......................................... 19
Вариант 3. Эталонные архитектуры, определяемые пользователем .............................................. 19
Шаг 1. Определение рабочей нагрузки........................................................................................... 20
Шаг 2. Определение тестов для архитектуры компонентов ......................................................... 20
Окончательный выбор FTRA................................................................................................................. 21
Стандартная конфигурация FTDW ........................................................................................................... 22
Архитектура компонентов оборудования .......................................................................................... 22
Требования к компонентам и конфигурация ................................................................................. 22
3
Конфигурация приложения .................................................................................................................. 25
Windows Server 2008 R2 .................................................................................................................... 25
SQL Server 2012 Enterprise ................................................................................................................ 25
Система хранения данных ................................................................................................................ 27
Рекомендации по SQL Server для FTDW .................................................................................................. 32
Архитектура данных .............................................................................................................................. 32
Структура таблицы ............................................................................................................................ 32
Секционирование таблиц ................................................................................................................. 34
Индексирование................................................................................................................................ 34
Индексы columnstore, оптимизированные для памяти xVelocity ................................................. 34
Статистика базы данных ................................................................................................................... 37
Сжатие ................................................................................................................................................ 37
Управление фрагментацией данных ................................................................................................... 38
Фрагментация файловой системы ................................................................................................... 38
Несколько файловых групп .............................................................................................................. 41
Загрузка данных .................................................................................................................................... 41
Добавочные загрузки........................................................................................................................ 42
Перенос данных ................................................................................................................................ 44
Тестирование и проверка ......................................................................................................................... 47
Выполнение базовой проверки FTDW ................................................................................................ 48
Базовая проверка с помощью SQLIO ............................................................................................... 48
Проведение эталонного тестирования базы данных Fast Track ....................................................... 52
Вычисление MCR ............................................................................................................................... 53
Вычисление BCR ................................................................................................................................ 54
Опубликованные эталонные архитектуры FTDW ................................................................................... 57
Заключение ................................................................................................................................................ 57
Приложение............................................................................................................................................... 59
Средство изменения размера системы FTDW .................................................................................... 59
Проверка определяемой пользователем архитектуры FTRA............................................................ 59
Синтетическое тестирование ввода-вывода .................................................................................. 59
Создание тестовых файлов с помощью SQLIO ................................................................................ 59
4
Проверка рабочей нагрузки ................................................................................................................. 62
Измерение MCR для сервера (необязательно) .............................................................................. 62
Измерение показателя BCR для конкретной рабочей нагрузки ................................................... 63
Факторы, влияющие на норму потребления запроса .................................................................... 67
5
Журнал изменений FTDW
В следующей таблице представлен список наиболее значительных изменений или
обновлений в определенных как версии выпусках справочника по хранилищу данных
Fast Track.
Описание
Версия
Новые
возможности для
4.0
SQL Server 2012
Новые
возможности для
4.0
SQL Server 2012
Новые
возможности для
4.0
SQL Server 2012
Новые
возможности для
4.0
SQL Server 2012
Новые
возможности для
4.0
SQL Server 2012
Новые
возможности для
4.0
SQL Server 2012
Новые
возможности для
4.0
SQL Server 2012
Таблица 1. Журнал изменений
Примечание
Ссылки на другие документы
с рекомендациями по
SQL Server
Местоположение
Тестирование и проверка
Внимание!
Требования к памяти
ОЗУ
Индексы columnstore,
оптимизированные для
памяти xVelocity
Индексы columnstore
Хранилище на SSD-дисках
SSD-диски
Проверка и индексы
columnstore
Проверка
Проверка базового плана
ввода-вывода
SQLIO
Важно!
Введение
Настоящий документ определяет архитектуру компонентов и методологию для
программы хранилища данных SQL Server Fast Track (FTDW). Таким образом проводится
проверка минимальных требований к архитектуре системы баз данных Microsoft SQL
Server, включая готовое программное обеспечение и оборудование. Это необходимо для
достижения и поддержания базового уровня производительности при разных рабочих
нагрузках хранилища данных.
Аудитория
Целевая аудитория этого документа включает планировщиков ИТ-служб, архитекторов,
администраторов баз данных и пользователей бизнес-аналитики, которые заинтересованы
в выборе стандартных проверенных системных архитектур для рабочих нагрузок SQL Server,
соответствующих требованиям к FTDW.
6
Хранилище данных Fast Track
Разработки в области хранилища данных SQL Server Fast Track привели к созданию
базовой методологии и подготовке конкретных примеров развертывания
сбалансированной конфигурации оборудования и базы данных для рабочей нагрузки
хранилища данных. Дополнительные сведения см. в разделе Рабочая нагрузка FTDW
этого документа.
Баланс — это показатель правильности выбора основных системных компонентов SQL
Server: хранилища, сервера, сети хранилища, базы данных и операционной системы.
Каждый из этих компонентов настраивается для достижения оптимальной конфигурации.
Задача состоит том, чтобы на выходе сложился оптимальный баланс между
возможностями обработки данных SQL Server и ресурсами аппаратных компонентов.
В идеале в применяемой конфигурации должен быть необходимый минимум оборудования
системы, удовлетворяющий требованиям к хранению данных и производительности для
рабочей нагрузки хранилища данных.
Fast Track
Брендом SQL Server Fast Track обозначается конфигурация компонентов оборудования,
которая соответствует принципам эталонной архитектуры FTDW (FTRA). Каждая
архитектура FTRA определяется рабочей нагрузкой и основным набором рекомендаций
по конфигурации, проверке и базе данных. Ниже перечислены основные принципы
программы Fast Track.



Тестирование с учетом рабочей нагрузки. Конструкция и конфигурация системы
определяются реальными рабочими нагрузками по обработке параллельных
запросов.
Подробные и выверенные спецификации аппаратных компонентов.
Достижение баланса в архитектуре компонентов между возможностями базы
данных и основными аппаратными ресурсами.
Ценовое предложение
В основе ценового предложения FTDW лежат следующие принципы:



7
Предопределенный баланс между основными компонентами системы.
Это позволяет свести к минимуму риск чрезмерных затрат на ресурсы ЦП или
памяти, которые никогда не будут применяться на практике.
Прогнозируемая производительность готовых решений. Конфигурации
Fast Track опираются на мощности, которые уже соответствуют возможностям
приложения SQL Server для выбранного сервера и рабочей нагрузки.
Сосредоточение на рабочей нагрузке. В отличие от подхода к созданию
конфигурации базы данных универсального размера, подход на основе FTDW
предназначен исключительно для применения вместе с хранилищем данных.
Методология
Целостная архитектура компонентов
Эталонная архитектура SQL Server FTDW предоставляет применимую на практике
платформу для балансировки сложных связей между основными компонентами
архитектуры системы баз данных. Эта архитектура компонентов, известная под общим
названием стек, показана на рис. 1.
Рис. 1. Пример архитектуры компонентов базы данных Fast Track
Каждый компонент стека представляет собой ссылку на последовательность операций,
необходимых для обработки данных в SQL Server. Стек оценивается как интегрированная
система, что дает возможность определять реальную пропускную способность каждого
компонента. Это позволяет добиться того, чтобы отдельные компоненты предоставляли
достаточную пропускную способность, которая соответствовала бы возможностям
приложения SQL Server для предписанного стека.
Способ оптимизации рабочей нагрузки
Разные рабочие нагрузки приложения базы данных могут потребовать очень различной
архитектуры компонентов для достижения оптимального баланса ресурсов. Классическим
примером этого является контраст между рабочими нагрузками оперативной обработки
транзакций (OLTP) с малыми запросами на основе поиска и рабочими нагрузками
хранилищ аналитических данных с интенсивным применением просмотра и крупными
запросами. В вариантах с использованием OLTP широко применяется индексация для
обеспечения выборки с небольшой задержкой малого количества строк из наборов
данных, которые часто имеют небольшой объем архивных данных. При операциях
с базой данных такого типа происходит интенсивное движение головок диска и образуются
классические шаблоны просмотра в операциях ввода-вывода с произвольным доступом.
В вариантах аналитического характера, таких как хранилища данных, могут встречаться
гораздо более крупные запросы к данным, поэтому существенный выигрыш достигается
при увеличении пропускной способности последовательных просмотров диска.
8
Применение сбалансированного стека компонентов положительно сказывается при всех
вариантах использования, даже с противоположными требованиями. Что касается
современных жестких дисков SAS, то в среднем для каждого диска показатели обмена
данными при произвольном доступе могут оказаться в 10 раз ниже по сравнению
с последовательным доступом (при том же оборудовании). Применительно к рабочим
нагрузкам хранилища данных Fast Track основное внимание уделяется достижению
неизменно высоких показателей обмена данными (измеряемых в МБ/с) в отличие от
более традиционного подхода, сосредоточенного на количестве операций в секунду
(измеряемого в IOPS).
Проблема, вызванная существенным различием рабочих нагрузок, решается путем
четкого определения атрибутов рабочих нагрузок клиентом. Рабочие нагрузки SQL Server
Fast Track определяются списком качественных атрибутов, которые однозначно описывают
общий вариант использования приложения базы данных. Кроме того, каждая рабочая
нагрузка представлена количественными мерами, включая стандартные эталонные
запросы. Эталонное тестирование с учетом рабочей нагрузки используется для проверки
конфигурации базы данных, соблюдения требований и рекомендаций по компонентам
оборудования.
Проверенные эталонные конфигурации SQL Server Fast Track
Все опубликованные эталонные архитектуры Fast Track проверены на соответствие
принципам и рекомендациям, приведенным в этом справочнике. Примеры этого процесса
можно найти в следующих разделах настоящего документа.
Сводка
В центре внимания спецификации SQL Server FTDW, описанной в этом справочнике,
находятся рабочая нагрузка и балансировка компонентов. Этот подход основан на
признании того факта, что во многих вариантах использования базы данных
провизионирование по принципу «один размер для всех» может оказаться неэффективным
и дорогостоящим. Бизнес-требования все ужесточаются, а объемы данных постоянно
растут, поэтому должно быть найдено более реалистичное решение. В настоящем
документе даны предписания по эталонным архитектурам, тестированию аппаратных
и программных компонентов и четко выверенным рабочим нагрузкам, т. е. представлен
практический подход к достижению сбалансированных архитектур компонентов.
Рабочая нагрузка FTDW
Шаблоны рабочей нагрузки хранилища данных
Типичные проблемы хранилищ данных, требующих доступа к большим объемам данных.
Хранилища данных должны поддерживать широкий диапазон запросов от разнообразной
аудитории (например, финансисты, маркетологи, эксплуатационщики и научноисследовательские группы).
9
В целях преодоления ограничений традиционных систем хранилищ данных организации
прибегают к использованию таких сложившихся методов оптимизации реляционной
СУБД, как построение индексов, предварительное агрегирование данных, а также
ограничение доступа к более низким уровням данных. С этими подходами связаны такие
издержки на обслуживание, что часто не хватает даже самых продолжительных окон,
выделенных на пакетную обработку. Технология хранилищ данных становится все
более зрелой, а круг их пользователей постоянно растет, поэтому поддержка средств
оптимизации, в которых учитывается вариант использования, неизменно усложняется,
особенно если сами данные или исправления данных поступают с запозданием.
Обычно для решения этой задачи просто устанавливают новые диски; приходится
видеть, что относительно небольшое хранилище данных поддерживается сотнями дисков
в попытке преодолевать ограничения производительности ввода-вывода, связанные
с тем, что инфраструктура ввода-вывода, основанная на поиске, отображается на
рабочую нагрузку, которая основана на просмотре. Это часто наблюдается в средах
с большими общими сетями хранения данных (SAN), которые по традиции оптимизируются
для поиска. Применение многих эталонных шаблонов и методов организации вводавывода в хранилищах данных способствует увеличению количества операций вводавывода с произвольным доступом. Это приводит к увеличению задержек диска
и уменьшению общей пропускной способности подсистемы хранилища при рабочих
нагрузках хранилища данных, в которых в основном применяется просмотр.
В хранилище данных Fast Track применяется другой способ оптимизации для рабочих
нагрузок хранилища данных. Файлы и конфигурация базы данных подготавливаются
с учетом эффективного просмотра диска (а не поиска), поэтому производительность
отдельных дисков может стать намного выше. В результате повышения
производительности отдельных дисков сокращается количество дисков, необходимых
для обеспечения достаточной пропускной способности ввода-вывода для удовлетворения
способности SQL Server обрабатывать данные по конкретной рабочей нагрузке.
Кроме того, можно избежать использования некоторых методов оптимизации на
основе индексов, применяемых для улучшения поиска на диске.
Оценка рабочей нагрузки
При анализе рабочих нагрузок для систем на основе FTDW важно учитывать, насколько
они соответствуют рекомендациям и системным конфигурациям, представленным
в настоящем документе. Некоторые требования к хранилищу данных, предъявляемые
клиентом, а также такие требования, как репликация базы данных, могут оказаться не
соответствующими для всех систем, спроектированных согласно архитектуре FTDW.
Основные, начальные условия для оценки рабочей нагрузки такого типа представлены
ниже.
10
Интенсивное применение просмотра
В составе рабочей нагрузки хранилища данных часто встречаются запросы, требующие
просмотра большого количества строк. По этой причине производительность просмотра
диска приобретает все больший приоритет в отличие от транзакционных рабочих
нагрузок, для которых решающим является время поиска на диске. Эталонная архитектура
FTDW предусматривает оптимизацию аппаратных компонентов и программных компонентов
базы данных с учетом производительности в качестве основного приоритета. Это приводит
к повышению эффективности последовательного чтения диска и соответствующему
увеличению пропускной способности операций ввода-вывода на диске.
Отсутствие изменчивых данных
Данные после записи изменяются редко. Необходимо внимательно отслеживать такие
операции DML, как обновления SQL, которые выводят страницы, связанные с одной и той
же таблицей базы данных, из непрерывного выравнивания. Рабочие нагрузки, которые
обычно создают такую изменчивость, могут оказаться не совсем подходящими для FTDW.
Если обнаруживается изменчивость, необходимо периодически проводить обслуживание
для уменьшения фрагментации.
Сокращение количества индексов
Добавление некластеризованных индексов обычно приводит к повышению
производительности поиска одной или нескольких записей. Если некластеризованные
индексы применяются к таблицам, в которых происходит выборка большого количества
строк, то в связи с увеличением количества операций произвольного поиска на диске
общая производительность системы может снизиться. Кроме того, к увеличению
издержек организации хранения и обработки данных может привести необходимость
обслуживания индексов, что влечет за собой возрастание риска несоблюдения
соглашения об уровне обслуживания (SLA) и уменьшения способности проводить
загрузку данных в отведенных для этого окнах.
С другой стороны, показатели обмена данными при последовательном просмотре могут
быть намного выше (в 10 и более раз) по сравнению с показателями при произвольном
доступе. Система, в которой использование произвольного поиска сведено к минимуму
и предусмотрены вторичные индексы, обычно характеризуется более высокими средними
показателями ввода-вывода. Это означает, что ресурсы ввода-вывода хранилища
используются более рационально, а производительность крупных запросов, основанных
на просмотре, становится выше.
Для оптимизации базы данных методология FTDW предписывает применять методы,
соответствующие характеристикам целевой рабочей нагрузки. Кластеризованные
индексы и секционирование по диапазонам представляют собой примеры структур
данных, поддерживающих эффективный дисковый ввод-вывод на основе просмотра,
и мы рекомендуем их в качестве основного средства оптимизации с учетом архитектуры
данных для среды FTDW.
11
Секционирование с выравниванием
Общей характерной особенностью рабочих нагрузок FTDW является способность
использовать секционирование SQL Server. Секционирование позволяет упростить
управление жизненным циклом данных и со временем свести фрагментацию данных к
минимуму. Кроме того, шаблоны запросов для больших просмотров позволяют
воспользоваться уточнением секций диапазона и значительно уменьшить размер
просмотров таблиц без опасения создать фрагментацию или снизить производительность
дискового ввода-вывода.
Дополнительные замечания
При оценке рабочей нагрузки базы данных необходимо рассматривать следующие
дополнительные вопросы:



12
Реализация стратегии оптимизации базы данных с уменьшенным количеством
индексов и управление ей являются основным требованием с точки зрения
рабочих нагрузок FTDW.
Предполагается, что в хранилище данных должна сохраняться лишь минимальная
фрагментации данных. Из этого следуют такие выводы.
o Фрагментацию такого типа, которая вызывает основную озабоченность,
можно измерять с учетом размера фрагментов. Фрагмент представляет
собой непрерывные распределения страниц базы данных по 8 KБ.
o При развертывании сервера путем добавления хранилища требуется,
чтобы все таблицы, от которых зависит производительность, были заново
заполнены в том виде, который соответствует рекомендациям этого
документа.
o Реализация таких изменчивых структур данных, как таблицы с регулярно
выполняемыми операциями обновления на уровне строки, может
потребовать частого обслуживания (такого как дефрагментация или
перестроение индекса) для уменьшения фрагментации.
o Причиной фрагментации часто становится загрузка таблиц с кластерными
индексами с помощью пакетов идентификаторов кластерных ключей,
которые перекрывают существующие диапазоны. За этим необходимо
тщательно следить и устранять в соответствии с рекомендациями,
приведенными в настоящем справочнике.
Различные пользователи могут применять технологию хранилищ данных
по-разному. Необходимо внимательно оценивать требования клиента к атрибутам
рабочей нагрузки FTDW.
Качественные атрибуты рабочей нагрузки хранилищ данных
Рабочую нагрузку FTDW можно определять с помощью свойств следующих предметных
областей, относящихся к эксплуатации базы данных:




Пользовательские требования и модель доступа
Модель данных
Архитектура данных
Оптимизация баз данных
В следующей таблице представлены атрибуты рабочей нагрузки хранилища данных,
проводится сравнение рабочей нагрузки OLTP и хранилища оперативных данных (ODS).
Атрибут
Описание
примера
использования
13
Сходство рабочих нагрузок.
Хранилище данных
 Преобладание операций
чтения (90-10 %)
 Обновления обычно
определяются требованиями
к качеству данных
 Крупномасштабные массовые
вставки
 Общий параллелизм запросов
от среднего до низкого;
пиковое значение количества
одновременных запросов
находится в диапазоне от
10 до 30
 Пропускная способность
параллельных запросов
определяется потребностями
в анализе и подготовке отчетов
 Просмотры в больших
диапазонах или агрегирование
 Сложные запросы (применение
фильтров, соединений,
группирования, агрегирования)
OLTP/ODS
 Сбалансированное
соотношение операций
чтения и обновления
(60-40 %)
 Пропускная способность
параллельных запросов
характеризуется
эксплуатационными
потребностями
 Вставки и обновления
с высокой степенью
детализации
 Высокая пропускная
способность транзакций
(например, 10с K/сек)
 Общая поддержка
параллельно работающих
пользователей от средней до
высокой; пиковое количество
одновременных запросов
находится в диапазоне от
50 до 100, а иногда и больше
 Как правило, очень короткие
транзакции (например,
отдельные операции
поиска минимального
количества строк)
Атрибут
Сходство рабочих нагрузок.
Хранилище данных
OLTP/ODS
Модель данных
 Централизованная модель
 Рабочая модель данных
хранилища данных с высокой
с высокой нормализацией
степенью нормализации
 Частая денормализация для
 Денормализация для
поддержки принятия
поддержки требований к
решений; высокая степень
отчетности, часто
параллелизма, дискретные
формируемой с помощью
операции поиска с небольшой
приложений бизнес-аналитики,
задержкой
таких как службы SQL Server
 Хранение данных
Analysis Services
с предысторией применяется
 Размерные структуры данных,
в ограниченных масштабах
хранимые в базе данных,
 Извлечение
с аналитическими запросами,
денормализованных моделей
которые характеризуются
данных из других исходных
относительно низким
систем для поддержки
параллелизмом и большим
принятия решений по
объемом
конкретным событиям
 Частое применение
просмотров в большом
диапазоне
 Варианты использования
с произвольными
аналитическими запросами
Архитектура
 Частое использование
 Минимальное использование
данных
табличных структур кучи
табличных структур кучи
 Большие секционированные
 Табличные структуры
таблицы с кластеризованными
кластеризованного индекса,
индексами, поддерживающие
которые поддерживают
просмотр в ограниченном
детализированный поиск
диапазоне
записей (от 1 до нескольких
строк в расчете на запрос)
 Очень крупные таблицы
фактов (например, от сотен
 Меньшие таблицы фактов
гигабайтов до нескольких
(например, менее 100 ГБ)
терабайтов)
 Относительно небольшие
 Очень большие объемы
размеры данных (например,
данных (например, от сотен
несколько терабайтов)
терабайтов до петабайтов)
Оптимизация
 Минимальное использование
 Интенсивное использование
баз данных
вторичных индексов
оптимизации вторичных
(о чем ранее говорилось как
индексов
о сокращении количества
индексов)
 Частое применение
секционирования
Таблица 2. Атрибуты рабочей нагрузки хранилища данных
14
Выбор эталонной конфигурации FTDW
Предусмотрены три общих подхода к использованию методологии FTDW, описанной
в настоящем документе. Из них первые два относятся к использованию опубликованных,
соответствующих спецификаций эталонных архитектур Fast Track для технологии
хранилищ данных. Эти подходы обеспечивают выбор предварительно разработанных
систем, опубликованных в рамках программы FTDW. В третьем подходе основная
методология Fast Track рассматривается как рекомендация по созданию системы
хранения данных, определяемой пользователем. Этот последний подход требует
детализированного профилирования рабочей нагрузки и заблаговременного эталонного
тестирования системы перед покупкой или развертыванием. Он требует высокого уровня
технических знаний в таких областях, как сервер предприятия, конфигурация системы
хранения данных и оптимизация базы данных SQL Server.
Вариант 1. Базовая оценка
В этом сценарии клиент уже наметил для себя эталонную конфигурацию FTDW или
применяет альтернативные методы определения требований к серверу и ЦП. Если
выбран этот вариант, то нет необходимости выполнять полную оценку платформы
(т. е. проверку концепции).
Шаг 1. Оценка варианта использования, предложенного клиентом
Эталонные конфигурации хранилища данных Fast Track не представляют собой
конфигурации программного обеспечения и оборудования, при которых размер должен
быть универсальным. Скорее, они настраиваются с учетом характеристик рабочей
нагрузки хранилища данных. Первый шаг выбора конфигурации состоит в определении
этих характеристик; следует начинать с проверки основных требований клиента и
закономерностей использования.
Рабочая нагрузка
Из определений рабочей нагрузки FTDW следуют два основных направления оценки
варианта использования. Первым из них является набор базовых принципов, которые
определяют основные элементы рабочей нагрузки в их связи с производительностью
SQL Server. Соблюдение этих принципов следует тщательно оценивать применительно к
данному варианту использования, поскольку конфликты могут указывать на то,
что целевая рабочая нагрузка не подходит для эталонной архитектуры FTDW.
Вторым компонентом определения рабочей нагрузки является общее описание целевого
варианта использования. Он представляет собой удобное общее описание варианта
использования в дополнение к обоснованному выбору направления оценки
приемлемости рабочей нагрузки.
15
Оценка рабочей нагрузки
В следующем списке представлен основной процесс оценки рабочей нагрузки для клиента.
Это качественная оценка и должна рассматриваться как рекомендация для следующего:
1. Определение целевых требований к рабочей нагрузке. Сравнение и сопоставление
с атрибутами рабочей нагрузки FTDW. Дополнительные сведения см. в разделе
Рабочая нагрузка FTDW настоящего документа.
2. Оценка рекомендаций по FTDW. Необходимо дать объективную оценку
сложившейся практике управления базами данных, определения архитектуры
данных и оптимизации системы с учетом намеченного варианта использования
и эксплуатационной среды.
Принятие решения
Цель этой оценки рабочей нагрузки состоит в обеспечении принятия полностью
информированного решения при выборе проверенной эталонной архитектуры FTDW.
На практике в большинстве сценариев применения хранилищ данных обнаруживается
сочетание согласованных и конфликтующих атрибутов, относящихся к рабочей нагрузке
FTDW. Ниже перечислены наиболее важные атрибуты рабочей нагрузки, существенным
образом связанные с эталонными конфигурациями Fast Track; основные применяемые
клиентом варианты использования, которые непосредственно конфликтуют с любым
из этих атрибутов, должны тщательно оцениваться, поскольку именно они могут стать
причиной того, что методология станет недопустимой для рассматриваемого варианта.
Рабочая нагрузка
Следующие атрибуты рабочей нагрузки являются высокоприоритетными.



Наиболее важные рабочие нагрузки характеризуются применением шаблонов
доступа к данным с преобладанием просмотров (иначе говоря, эти рабочие
нагрузки подходят для данных с последовательным размещением). Как правило,
выполнение отдельных запросов требует чтения от десятков тысяч до миллионов
строк (или больше).
Больший объем данных и меньшая степень параллелизма по сравнению
с обычными рабочими нагрузками OLTP.
Низкая изменчивость данных. Операции DML с частыми обновлениями или
удалениями должны ограничиваться небольшой частью общего объема
хранилища данных.
Управление базами данных
К этому относятся администрирование базы данных, архитектура данных (модель данных
и структуры таблиц) и применение средств интеграции данных:


16
Секционированная архитектура данных с уменьшенным количеством индексов.
Тщательный контроль над фрагментацией базы данных с применением
подходящих стратегий загрузки и ETL, а также периодического обслуживания.

Прогнозируемые требования к росту данных. Системы FTDW предварительно
подготавливаются для полностью сбалансированных ресурсов. Для расширения
хранилища требуется миграция данных.
Шаг 2. Выбор опубликованной эталонной архитектуры FTDW
Клиент, осуществляя простую оценку на основе своего бюджета или опыта, уже может
иметь в виду определенный сервер. Возможно также, что клиент уже хорошо изучил
характеристики рабочей нагрузки или существующую систему, на которой основан анализ
требований к пропускной способности. Так или иначе, при базовой оценке FTDW полная
оценка платформы не выполняется. Вместо этого выбирается соответствующая
спецификации конфигурация FTDW, которая согласуется с оцениваемыми требованиями
конкретного клиента.
Вариант 2. Общая оценка
Эталонные архитектуры, соответствующие Fast Track, описывают конфигурации
аппаратных компонентов в сочетании с определенными рабочими нагрузками для
клиента. Следующая методология предоставляет упрощенный подход к выбору
архитектуры компонентов базы данных, которая гарантирует лучший баланс готовых
решений между требованиями в варианте использования, производительностью
и масштабируемостью. Для такого подхода необходимо основательное знание
архитектуры систем баз данных и развертывания хранилищ данных. К этому процессу
обычно привлекаются участники инициативы Fast Track и технические специалисты по
продажам Майкрософт.
Общие сведения о процессе
Следующая последовательность операций представляет собой описание процесса
полной оценки FTDW:
1. Оценка атрибутов рабочей нагрузки Fast Track с учетом целевого сценария
использования.
2. Выявление требований к серверу или к пропускной способности в варианте
использования для клиента. До начала процесса оценки необходимо выбрать
опубликованную эталонную конфигурацию FTDW.
3. Определение запроса, представительного с точки зрения требований клиента
к рабочей нагрузке.
4. Вычисление исходной нормы потребления (BCR) в SQL Server для запроса.
5. Вычисление необходимой информационной емкости средств пользователя (UDC).
6. Сравнение показателей BCR и UDC с опубликованными показателями
максимальной нормы потребления (MCR) ЦП и емкости для соответствующих
эталонных архитектур Fast Track.
Ниже последовательно приведены отдельные элементы операций полной оценки.
17
Шаг 1. Оценка варианта использования для клиента
Оценка рабочей нагрузки
Эта операция совпадает с таковой для варианта 1. Базовая оценка.
Выбор оборудования для оценки FTDW
До начала полной оценки системы необходимо выбрать и развернуть опубликованную
эталонную конфигурацию FTDW для проверки. Можно выбрать один из нескольких методов
определения подходящей эталонной конфигурации. Ниже приведены типичные подходы.




Бюджет. Клиент выбирает для покупки систему с наивысшей информационной
емкостью или с наивысшей производительностью, исходя из своих бюджетных
возможностей.
Производительность. Клиент выбирает для покупки систему с наивысшей
производительностью из всех имеющихся.
Внутренний анализ. Решение принимается на основе анализа рабочей нагрузки,
выполненного клиентом на имеющемся оборудовании.
Анализ нерегламентированных запросов. Средство изменения размера FTDW
предоставляет основополагающий подход к вычислению требований к системе
FTDW на основе базовых предположений о рабочей нагрузке целевой базы
данных. Это средство с электронными таблицами можно загрузить по адресу
http://download.microsoft.com/download/D/F/A/DFAAD98F-0F1B-4F8B-988F22C3F94B08E0/Fast%20Track%20Core%20Calculator%20v1.2.xlsx.
Шаг 2. Определение показателей оценки
Для полной оценки FTDW важны следующие три показателя, которые составляют
основные критерии принятия решений по оценке оборудования.
 Максимальная норма потребления (MCR) ресурсов ядра ЦП
 Исходная норма потребления (BCR)
 Требуемая информационная емкость средств пользователя (UDC)
Дополнительные сведения о вычислении этих показателей см. в разделе Тестирование
и проверка настоящего документа.
MCR
Этот показатель измеряет максимальную скорость обработки данных в SQL Server
для стандартного запроса и набора данных в конкретном сочетании сервера и ЦП.
Эта скорость задается в расчете на ядро и измеряется как просмотр на основе запроса
из кэша памяти. MCR служит отправной точкой для разработки системы Fast Track. Этот
показатель представляет оценку максимальной необходимой пропускной способности
ввода-вывода для сервера, ЦП и рабочей нагрузки. Показатель MCR применяется
в качестве начального руководства при проектировании, поскольку он требует лишь
минимального объема локального хранилища и простейшей схемы базы данных для
оценки потенциальной пропускной способности для данного ЦП. Важно подчеркнуть,
что MCR используется как отправная точка проектирования системы; этот
показатель не может служить мерой производительности системы.
18
BCR
Показатель BCR измеряется с помощью набора запросов, который рассматривается как
определяющий для рабочей нагрузки FTDW. BCR вычисляется на основе суммарной
пропускной способности чтения с диска и из кэша, а не только из кэша, как при
вычислении MCR. BCR позволяет приспособить инфраструктуру к варианту
использования для конкретного клиента, поскольку измеряется по набору запросов,
соответствующих характеру рабочей нагрузки для клиента. С другой стороны, если
проверка FTRA выполняется участником, то набор тестовых запросов используется
для получения гарантий того, что системы спроектированы для напряженных рабочих
нагрузок. В конечном итоге BCR является реальным мерилом возможности обработки
данных с использованием многочисленных запросов при одновременно применяемых
рабочих нагрузках по отношению к значительным объемам данных.
Информационная емкость пользовательских средств обработки данных
Этот показатель представляет предсказуемую информационную емкость базы данных
для SQL Server. При определении информационной емкости пользовательских средств
обработки данных Fast Track учитывается сжатие базы данных после загрузки. Этот
показатель представляет оценку объема несжатых файлов или потоков пользовательских
данных, которые могут быть загружены в систему Fast Track. Стандартным
коэффициентом сжатия, используемым для FTDW, является 3,5:1.
Следует учитывать, что для любого расширения хранилища за пределы первоначального
развертывания может потребоваться миграция данных, которая по существу приводит
к чередованию существующих данных с местонахождениями новых файлов базы данных.
Поэтому при выборе подходящей эталонной архитектуры очень важно учитывать
ожидаемый рост базы данных и средний вероятный срок жизни системы.
Шаг 3. Выбор эталонной архитектуры хранилища данных Fast Track
Показатель BCR после его вычисления можно сравнить с опубликованными
показателями MCR и информационной емкостью, которые предоставляются участниками
инициативы Fast Track для каждой опубликованной FTRA. Дополнительные сведения
об участниках нашей инициативы см. в разделе Хранилище данных Fast Track
(http://www.microsoft.com/sqlserver/en/us/solutions-technologies/data-warehousing/fasttrack.aspx).
Показатель BCR можно использовать в качестве общей отправной точки для оценки
результатов тестирования или проверки системы по опубликованным конфигурациям.
Начиная со значения показателя BCR, клиент может выбрать вариант Fast Track, который
в наибольшей степени соответствует результатам тестирования.
Вариант 3. Эталонные архитектуры, определяемые пользователем
В этом подходе используется методология FTDW в целях приспособления системы для
конкретной рабочей нагрузки или набора оборудования. Такой подход требует полного
понимания как работы SQL Server, так и компонентов оборудования, на котором он
работает. Следующие шаги представляют общий подход к разработке пользовательской
эталонной архитектуры, которая соответствует принципам FTDW.
19
Шаг 1. Определение рабочей нагрузки
Для выбора конфигураций FTDW решающее значение имеет наличие основных сведений
о конкретном варианте использования целевой базы данных. Это в равной степени
относится к любому пользовательскому приложению в справочнике, представленном
в настоящем документе. В качестве справочной модели включения оценки рабочей
нагрузки в проект архитектуры компонентов можно использовать рекомендации по
архитектурам FTRA, особенно в части рабочих нагрузок.
Шаг 2. Определение тестов для архитектуры компонентов
Ниже описана исходная платформа разработки эталонной архитектуры для стандартной
рабочей нагрузки.
1. Определение максимальной нормы потребления (MCR) ЦП для выбранного
сервера и ЦП. Для вычисления MCR используется метод, описанный в разделе
Тестирование и проверка настоящего документа. Можно также использовать
опубликованные показатели MCR для конфигураций FTDW. Вообще говоря, ЦП из
одного и того же семейства имеют одинаковые нормы потребления ресурсов ядра
ЦП для базы данных SQL Server.
2. Использование значения MCR для оценки требований к хранилищу и к сети
хранилища, а также для создания исходного проекта системы.
3. Подготовка системы тестирования на основе начального проекта системы.
В идеальном случае тем самым будет определена полная конфигурация.
4. Определение исходной нормы потребления (BCR). Определение запроса или
(в идеальном случае) набора репрезентивных запросов на основе оценки
рабочей нагрузки. При этом должны использоваться методики, описанные
в разделе Измерение BCR для рабочей нагрузки настоящего документа.
5. Корректировка проекта системы на основе полученных результатов.
6. Определение окончательной конфигурации сервера и хранилища.
Шаг 3. Проверка системы
Цель тестирования системы состоит в проверке конфигурации системы и пропускной
способности компонентов оборудования с конфигурацией, определенной в шаге 2.
Дополнительные сведения об этом процессе см. в разделе Проверка FTRA,
определяемой пользователем настоящего документа. Для проверки системы выполните
следующие действия.
1. Оценка пропускной способности компонента в соответствии с установленными
требованиями к производительности. Тем самым гарантируется соответствие
реальной пропускной способности системы ожиданиям.
2. Проверка пропускной способности системы путем перестроения с учетом
окончательной конфигурации и выполнения заключительных тестов. Как правило,
конечное значение BCR должно достигать или превышать 80 процентов от MCR
системы.
20
Окончательный выбор FTRA
В следующей таблице представлены сведения о трех вариантах выбора FTRA.
Вариант
Базовая оценка
Преимущества
 Очень быстрая
установка и подготовка
системы к работе
(от нескольких дней до
нескольких недель)
 Уменьшение до
минимума стоимости
проектирования и оценки
 Более низкие
требования к подготовке
в части инфраструктуры
Полная оценка
 Стандартная эталонная
архитектура,
приспособленная
к ожидаемой рабочей
нагрузке
 Возможность
сокращения затрат
на оборудование
 Большая уверенность
в правильности решения
Определяемая
 Возможность повторного
пользователем
использования
эталонная архитектура
существующего
оборудования
 Возможность
применения новейшего
оборудования
 Высокая степень
приспособления
системы к конкретному
варианту использования
Таблица 3. Сравнение различных вариантов оценки
21
Недостатки
 Вероятность слишком
точного определения
хранилища или
недостаточно точного
определения ЦП





Дополнительные
затраты усилий и
времени на оценку
(от нескольких недель
до нескольких месяцев)
Необходимость
подробного изучения
целевой рабочей
нагрузки
Затраты времени
на осуществление
процесса, достигающие
нескольких месяцев
Потребность
в значительном объеме
знаний в области
инфраструктуры
Потребность
в значительном объеме
знаний по SQL Server
Стандартная конфигурация FTDW
Архитектура компонентов оборудования
Текущая эталонная архитектура FTDW основана на применении выделенной
конфигурации хранилища. На данный момент опубликованы варианты на основе
коммутируемой системы SAN, непосредственно подключенных дисков SAS, SAS-RBOD
и iSCSI. Требуемая пропускная способность дискового ввода-вывода достигается за счет
использования независимых, выделенных устройств хранения с собственными ЦП.
Каждый поставщик Fast Track публикует дополнительные сведения и данные
о конфигурации. На рис. 2 показаны стандартные блоки на уровне компонентов,
из которых состоит хранилище SAN на основе эталонной архитектуры FTDW.
Рис. 2. Пример конфигурации хранилища для сервера с 2 сокетами и 12 ядрами
Требования к компонентам и конфигурация
Память сервера
Общий объем ОЗУ. Выделение памяти для архитектур FTRA основано на результатах
тестирования, проведенного с целью достижения баланса между максимальной
логической пропускной способностью (общего количества страниц, считанных с диска и из
буфера с течением времени) и использованием ЦП. В табл. 4 приведены рекомендации
по выделению памяти для эталонных архитектур на основе SQL Server 2012.
Приведенные максимальные значения объемов памяти не являются жестко заданными
пределами, а представляют собой средние значения для успешно проверенных систем.
22
Размер сервера
Минимальный объем
Максимальный объем
памяти
памяти
1 сокет
64 ГБ
128 ГБ
2 сокета
128 ГБ
256 ГБ
4 сокета
256 ГБ
512 ГБ
8 сокетов
512 ГБ
768 ГБ
Таблица 4. Рекомендации по выделению памяти для SQL Server 2012
При оценке требований к памяти системы важно также учитывать следующие
соображения.




Запрос из кэша. Рабочие нагрузки, характеризующиеся тем, что большая
процентная доля запросов обслуживается из кэша, могут в целом выигрывать от
увеличения объема распределения памяти по мере возрастания рабочей нагрузки.
Хэш-соединения и сортировки. Запросы, основанные на крупномасштабных
хэш-соединениях или на выполнении крупномасштабных операций сортировки,
выигрывают от увеличения объема физической памяти. При меньшем объеме
памяти выполнение этих операций требует страничного обмена на диске
и интенсивного использования tempdb, в результате чего на жестких дисках
сервера чаще применяются операции ввода-вывода с произвольным доступом.
Операции загрузки. Применение массовых вставок также может привести к
появлению операций сортировки, в которых используется tempdb, если для их
осуществления не хватает доступной памяти.
Индекс columnstore, оптимизированный для памяти xVelocity. Рабочие
нагрузки, в которых часто применяются планы запросов с индексами columnstore,
обрабатываются более эффективно при использовании пулов памяти при больших
значениях в диапазонах, перечисленных в табл. 4.
SAN на основе Fibre Channel
HBA — SAN. Все компоненты HBA и сети SAN в определенной степени различаются
в зависимости от изготовителя и модели. Кроме того, пропускная способность хранилища
как отдельного устройства может зависеть от конфигурации SAN и характеристик шины
PCIe. Данная рекомендация является общей и согласуется с тестированием, проводимым
во время разработки эталонной архитектуры FTDW.
Если применяется секционирование по зонам, то в зонах должны быть представлены
только порты, используемые для системы Fast Track. Подробные сведения о топологии
и конфигурации сети FC приведены в технических руководствах по конфигурации,
представленных каждым участником инициативы Fast Track, и относятся к конкретным,
опубликованным архитектурам FTRA.
Multipath I/O (MPIO). Должна быть выполнена настройка MPIO. Каждый том,
размещенный в выделенных дисковых массивах хранения данных, должен иметь по
меньшей мере один активный путь.
23
В конфигурациях Fast Track по умолчанию должна применяться политика циклического
перебора с подмножествами, но в эталонных архитектурах участников применяется
редко, поскольку группы технических специалистов участников инициативы FTDW
определили более оптимальные конфигурации. Модули устройства или документы
конкретных участников часто предписывают различные параметры, и с ними необходимо
ознакомиться перед настройкой.
Хранилище данных
Локальный диск. Для установки Windows Server и SQL Server должен быть выделен по
меньшей мере массив RAID1 с 2 дисками. На диске необходимо выделить достаточно
места для выполнения требований к виртуальной памяти и подкачке. Как правило,
свободное место на диске должно быть больше 250 ГБ или в 1,5 раза превышать объем
ОЗУ системы. Конфигурация остальных дисков зависит от варианта использования
и предпочтений клиента.
Логическая файловая система. В Windows предпочтительным является подключение
к путям папок с точками подключения не имен дисков, а LUN, поскольку во многих
системах Fast Track количество томов очень велико.
Может также оказаться полезным определение того, какие назначения дисков
в операционной системе Windows представляют те или иные LUN (тома), группы дисков
RAID и точки подключения Windows Server в устройствах хранилищ. При подключении
LUN к папкам Windows можно применять определенную схему именования для точек
подключения и томов. Дополнительные сведения о схемах именования устройств см.
в техническом руководстве по конфигурации участника инициативы Fast Track.
Для осуществления рекомендуемой схемы именования томов можно использовать
средства, предоставляемые конкретным поставщиком. Если подходящего средства нет,
можно последовательно предоставлять операционной системе Windows доступ к одному
диску за другим из дисковых массивов хранения данных, присваивая при этом имена
дисков для достижения правильной физически-логической топологии.
Физическая файловая система. Дополнительные сведения и подробные инструкции
см. в разделе Настройка приложения настоящего документа.
Конфигурация устройства хранилища. Для всех параметров устройства хранилища
остаются заданными значения по умолчанию, если не указано иное в технической
документации участника инициативы Fast Track. Спецификации FTDW для конфигурации
файловой системы требуют, чтобы устройства хранилищ допускали применение
определенной конфигурации для групп RAID и назначений LUN. Это необходимо
учитывать при любой замене оборудования в эталонной конфигурации FTDW или при
оценке определяемого пользователем оборудования.
24
Конфигурация приложения
Windows Server 2008 R2
Если не указано иное, то для операционной системы Windows Server 2008 R2 Enterprise
следует использовать параметры по умолчанию. Убедитесь в том, что применен не
только последний пакет обновления, но и все другие важные обновления. Для многих
эталонных архитектур требуется функция Multipath I/O. Дополнительные сведения
о подробном задании конфигурации MPIO для конкретной эталонной архитектуры см.
в техническом руководстве по конфигурации участника инициативы Fast Track. Проверьте,
чтобы ОС Windows Server 2008 R2 была установлена в роли сервера приложений для
обеспечения правильной установки платформы .NET и параметров по умолчанию.
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. Дополнительные
сведения об этих и других флагах трассировки см. в статье базы знаний Майкрософт
920093 (http://support.microsoft.com/kb/920093).
Примечание. В настоящее время SQL Server 2012 не поддерживает использование
параметра -T834, если в базе данных используются индексы columnstore. Если
планируется использование индексов columnstore, то не следует задавать этот флаг
трассировки.
25
Максимальное использование памяти в SQL
Для SQL Server 2012 не следует распределять больше 92 процентов общего объема
ОЗУ сервера. Если сервер должен совместно использоваться другими приложениями,
то следует откорректировать соответствующим образом объем ОЗУ, оставшийся
доступным для операционной системы. Эта настройка контролируется параметром max
server memory. Дополнительные сведения о параметрах памяти для утвержденных
эталонных архитектур см. в документации участника инициативы FTDW.
Регулятор ресурсов
Рабочие нагрузки хранилищ данных обычно содержат сложные запросы, работающие
с большими объемами данных. Эти запросы могут требовать больших объемов памяти
и подкачки, если объем памяти ограничен. Это вызывает определенные последствия
с точки зрения управления ресурсами. В SQL Server 2012 можно применять технологию
регулятора ресурсов для управления использованием ресурсов.
При использовании для SQL Server параметров по умолчанию регулятор ресурсов
предоставляет вплоть до 25 процентов ресурсов памяти для каждого сеанса. Это
означает, что в худшем случае три запроса, достаточно трудоемкие, чтобы израсходовать
по меньшей мере 25 процентов доступной памяти, заблокируют любой другой запрос,
требующий большого объема памяти. В этой ситуации любые дополнительные запросы,
требующие большого объема памяти для выполнения, будут поставлены в очередь до
момента появления доступных ресурсов.
Регулятор ресурсов можно использовать для уменьшения максимального объема памяти,
рассчитанного на запрос. Но в результате параллельные запросы, которые в противном
случае потребляли бы большие объемы памяти, вместо этого используют tempdb, что
приводит к увеличению объема ввода-вывода с произвольным доступом и тем самым
к снижению общей пропускной способности. Хотя для многих рабочих нагрузок хранилища
данных может оказаться благоприятным ограничение объема системных ресурсов, доступных
в отдельном сеансе, в этом следует убедиться путем измерения с анализом параллельных
рабочих нагрузок от запросов. Дополнительные сведения об использовании регулятора
ресурсов см. в разделе Управление рабочими нагрузками SQL Server с помощью
регулятора ресурсов (http://msdn.microsoft.com/ru-ru/library/bb933866.aspx).
Необходимо также обращаться к руководствам и рекомендациям по решениям Fast Track
конкретных поставщиков. В частности, более крупные решения Fast Track с 4 и 8 сокетами
могут опираться на конкретные параметры регулятора ресурсов при достижении
оптимальной производительности.
26
В конечном итоге существует компромисс между смягчением ограничений, что обеспечивает
повышение производительности отдельных запросов, и введением более строгих
ограничений, гарантирующих достижение определенного количества запросов,
которые могут выполняться параллельно.
Дополнительные сведения о рекомендациях и общих сценариях для регулятора
ресурсов см. в техническом документе Использование регулятора ресурсов
(http://msdn.microsoft.com/ru-ru/library/ee151608.aspx).
Система хранения данных
Для эталонных архитектур FTDW, в которых система хранения данных базы данныхисточника располагается на жестких дисках (HDD), важно контролировать фрагментацию,
вызывающую снижение производительности системы с течением времени. По этой
причине должна быть подробно задана конфигурация системы хранения данных
и файловой системы.
Компоненты системы хранения данных
На рис. 3 показаны три основных уровня настройки конфигурации хранилища для
интегрированного стека базы данных. При этом должен учитываться вариант эталонной
архитектуры, поскольку конкретная топология в значительной степени зависит от участника
инициативы Fast Track. Типичный стек базы данных содержит следующие элементы:



27
Физический дисковый массив; на рис. 3 показан стандартный подход, в котором на
4 физических дисках определен массив RAID 1+0. В эталонных архитектурах для
SQL Server 2008 R2 и SQL Server 2012 некоторых участников используются также
RAID 5 и RAID 6.
Назначение томов (LUN) операционной системы.
Базы данных: пользовательская, системная временная, системная для журнала.
Рис. 3. Пример всеобъемлющей архитектуры хранилища для системы FTDW, основанной
на применении трех устройств хранилищ, в которой один LUN (диск) применяется для
каждой дисковой группы.
Подробные сведения о конфигурации хранилища
Для каждого устройства хранилища выполните следующие действия.
1. Создание дисковой группы по 4 диска в каждой с использованием RAID 1+0
(RAID 10). Точное количество дисковых групп в расчете на устройство хранилища
зависит от поставщика. Дополнительные сведения см. в документации
поставщика. Вообще говоря, количество дисковых групп составляет 2 в массиве
RAID10
и 1 в массиве RAID1 применительно к устройствам с большим формфактором
(LFF)
и 5 дисковых групп в массиве RAID10 для устройств с малым формфактором
(SFF).
28
Общее количество томов, используемых в качестве места расположения
файловых групп для первичных данных, не должно превышать 32. Если общее
количество LUN системы хранения данных превышает указанное пороговое
значение, могут использоваться более крупные дисковые группы для уменьшения
количества LUN и вместе с тем сохранения той же пропускной способности вводавывода. Например, можно использовать дисковую группу из 8 дисков в массиве
RAID 10 с 1 LUN вместо дисковой группы из 4 дисков в массиве RAID 10 с 1 LUN.
При увеличении дисковой группы происходит некоторое снижение пропускной
способности и эффективности. Это зависит от технологии хранения данных.
2. Все дисковые группы, кроме одной, должны быть выделены для первичных
пользовательских данных (PRI). В SQL Server термин «место хранения первичных
пользовательских данных» является синонимом для термина «файловая группа
базы данных».
Во всех архитектурах FTRA предусмотрено использование либо одного, либо двух
LUN для каждой дисковой группы PRI. Дополнительные сведения см. в руководстве
поставщика по выбранной эталонной архитектуре. Эти LUN используются для
хранения файлов базы данных SQL Server (файлов MDF и NDF).
3. Проверьте, чтобы назначения процессора в основном хранилище для каждого
дискового тома, выделенного первичным данным в устройстве хранилища, были
сбалансированы равномерно. Например, в устройстве хранилища с четырьмя
дисковыми томами, распределенными для первичных данных, два тома будут
назначены процессору хранилища A и еще два — процессору хранилища B.
4. Создание одного LUN на оставшейся дисковой группе для размещения журналов
транзакций базы данных. В некоторых более крупных конфигурациях Fast Track
размещения журналов ограничивается только первыми несколькими устройствами
хранилищ в системе. В этом случае дополнительные дисковые группы
используются для промежуточного хранения вне базы данных или остаются
незаполненными для снижения затрат.
Для каждой базы данных выполните следующие действия.
1. Создание по меньшей мере одной файловой группы, содержащей по одному
файлу данных для каждого PRI LUN. Обязательно задайте для всех файлов
одинаковый размер. Если необходимо использовать несколько файловых групп
в одной базе данных для разделения объектов (в качестве примера можно указать
промежуточную базу данных для поддержки загрузки), следует включить все PRI
LUN в качестве мест хранения для каждой файловой группы.
2. Если файлы данных создаются для каждой файловой группы, их необходимо
предварительно распределять с учетом максимального ожидаемого размера,
причем размер должен быть достаточным для хранения ожидаемых объектов.
3. Отключение параметра автоувеличения для файлов данных и увеличение
вручную всех файлов данных после приближения к текущему пределу размера.
29
4. Дополнительные сведения о рекомендациях для пользовательских баз данных
и файловых групп см. в разделе Управление фрагментацией данных настоящего
документа.
Для tempdb выполните следующие действия.
1. Предварительное распределение пространства, а затем добавление по одному
файлу данных на каждый LUN. Необходимо обеспечить, чтобы все файлы имели
одинаковый размер.
2. Назначение временных файлов журнала на один из LUN, выделенных для файлов
журнала.
3. Включение автоувеличения; в общем случае для рабочих нагрузок хранилища
данных подходит использование большего шага приращения. Приемлемое
начальное значение эквивалентно 10 процентам от исходного размера файла.
4. Руководствуйтесь стандартными рекомендациями по SQL Server для базы данных
и требованиями по изменению размеров tempdb. На этапе миграции данных
или во время первоначальной загрузки данных в хранилище данных может
потребоваться распределить больше места. Дополнительные сведения см.
в разделе Планирование загрузки базы данных tempdb
(http://msdn.microsoft.com/ru-ru/library/ms345368.aspx), входящем в состав
электронной документации по SQL Server.
Применительно к журналу транзакций выполните следующие действия.
1. Создание по одному файлу журнала транзакций для каждой базы данных
на одном из LUN, назначенных для пространства журнала транзакций.
Распределение файлов журнала для разных баз данных по доступным LUN или
использование нескольких файлов журнала для увеличения размера журнала по
мере необходимости.
2. Включение параметра автоувеличения для файлов журнала.
3. Убедитесь, что информационная емкость журнала соответствует требованиям,
представленным в табл. 5. Приемлемы некоторые изменения в зависимости от
характеристик проекта конкретной системы.
ОЗУ системы (ГБ)
Емкость,
классифицированная
по FT (терабайты)
<= 96
<=10
<= 128
>10
<=40
Таблица 5. Рекомендации по размещению журнала
30
Рекомендуемое
минимальное
распределение журнала
Зеркалированное
свободное
пространство (ГБ)
300 ГБ X 1 том
300 ГБ x 2 тома
или
600 ГБ x 1 том
См. существующие рекомендации по размещению журнала транзакций SQL Server
и управлению им.
Хранилище на SSD-дисках
Эталонная архитектура FTDW, в которой используется хранилище на SSD-дисках для
первичных (PRI) данных, имеет много преимуществ, включая упрощенное управление,
более низкие издержки на эксплуатацию и прогнозируемую поддержку базы данных.
Упрощенное управление. Хранилище на SSD-дисках не требует управления
фрагментацией. Тем не менее должен использоваться параметр запуска -E для SQL
Server, но дальнейшая оптимизация или управление размещением страниц не требуется.
Благодаря этому упрощению долгосрочное управление средами FTDW значительно
облегчается. Кроме того, могут использоваться более крупные дисковые группы
и меньшие значения количества томов на LUN без отрицательных последствий для
производительности. Это изменение значительно упрощает создание и обслуживание
файловой группы.
Эластичность ввода-вывода. Хранилище на SSD-дисках испытывает минимальное
снижение производительности при высокой степени параллелизма или фрагментации
страниц. Кроме того, увеличение доли рабочей нагрузки с произвольным чтением
(поиском) не оказывает отрицательного влияния на шаблоны ввода-вывода с большими
запросами (просмотрами).
Прогнозируемое обслуживание. Для многих вариантов хранилищ на SSD-дисках
предусмотрена выполняемая с меньшей частотой программная поддержка мониторинга
срока существования записанных данных применительно к труднопредсказуемым
физическим сбоям.
Более низкая стоимость эксплуатации. Стоимость хранилища на SSD-дисках
по прейскуранту выше, но оно обеспечивает более эффективный баланс между
пропускной способностью ввода-вывода и емкостью в расчете на единицу оборудования.
Эффективные скорости ввода-вывода при рабочей нагрузке FTDW для жесткого диска
SAS 10k с объемом 300 ГБ составляют в среднем 50 МБ/с. SSD-диск Enterprise MLC
с объемом 600 ГБ позволяет достичь скорости от 150 до 200 МБ/с. Кроме того, хранилище
на SSD-дисках требует значительно меньших затрат энергии, вырабатывает меньше
тепла и часто допускает применение решений с более высокой плотностью.
Конфигурация хранилища на SSD-дисках
Если для томов PRI используется хранилище на SSD-дисках, то можно внести следующие
корректировки в стандартные рекомендации по конфигурации хранилища FTDW.

31
Если требуется зеркальное отображение, можно использовать RAID1+0 или
RAID5. RAID5 обеспечивает большую информационную емкость без снижения
производительности для рабочих нагрузок FTDW на SSD-дисках.



Количество LUN и томов можно уменьшить вплоть до одного тома PRI в расчете
на один блок хранилища. В некоторых случаях удобнее задавать количество томов
PRI, кратное числу ядер ЦП. Минимальное количество томов PRI равно двум.
Журнал транзакций также можно поместить на SSD-диск, но рабочие нагрузки
FTDW обычно не зависят от производительности обработки журнала. Можно
уменьшить затраты, поместив журнал на обычный жесткий диск. То же справедливо
в отношении локального хранилища для установки Windows Server и SQL Server.
Рекомендации по управлению фрагментацией страниц и параллельной загрузке
кластерного индекса можно не рассматривать, поскольку логическая фрагментация
базы данных не влияет на производительность ввода-вывода SSD-диска.
Рекомендации по SQL Server для FTDW
Рекомендации по рабочим нагрузкам Fast Track проверяются и документируются в двух
случаях. Первый случай возникает, если условия применения Fast Track существенно
отличаются от тех, что прописаны в установленных рекомендациях по SQL Server. Второй
случай обнаруживается в тех сценариях, когда рекомендации отсутствуют или доступ
к ним ограничен. Приведенные здесь рекомендации не следует рассматривать как
исчерпывающие, поскольку уже сейчас наработан богатый набор документации по
развертыванию базы данных SQL Server. По многим вопросам, касающимся развертывания
FTDW, следует обращаться к технической документации по SQL Server и к рекомендациям.
Важно! В настоящем руководстве приведено несколько ссылок на документацию по SQL
Server 2008 R2. Мы считаем, что большая часть этого руководства все еще сохраняет
ценность для SQL Server 2012, поэтому необходимо обращаться к обновленным версиям
этих документов после их выпуска. Как только станут доступными обновленные ссылки,
они будут приведены в следующих версиях этого справочника.
Архитектура данных
Структура таблицы
От типа таблицы, используемой для хранения данных в базе данных, в значительной
степени зависит производительность последовательного доступа. Очень важно учесть
это при проектировании физической схемы, чтобы в планах запросов в максимально
возможной степени применялся последовательный ввод-вывод.
Выбор типа таблицы сводится к определению того, как будет происходить доступ
к данным таблицы большую часть времени. Для определения того, какой тип таблицы
должен быть выбран с учетом характеристик данных, можно использовать следующие
сведения.
Таблицы кучи
Таблицы-кучи обеспечивают чисто последовательный ввод-вывод для просмотров
таблицы и в целом обладают более низкими издержками в отношении фрагментации
таблицы. Они по сути таковы, что не допускают применения оптимизированных
32
просмотров в диапазоне (с прямым доступом) в отличие от таблиц с кластеризованным
индексом. В диапазоне просматривается вся таблица-куча (или соответствующая секция
диапазона, если применяется секционирование).
При просмотре таблиц-куч максимальная пропускная способность достигается
применительно к 32 файлам, поэтому использование таблиц-куч для больших таблиц
фактов в системах со значительным количеством LUN (больше 32) или ядер (больше 16)
может потребовать применения регулятора ресурсов, ограничений DOP или изменений
в стандартном размещении файлов базы данных Fast Track.
Таблицы-кучи в наибольшей степени подходят в следующих условиях.



Большинство высокоприоритетных запросов к таблице ссылок содержат
предикаты, которые ссылаются на многие разрозненные столбцы, или не имеют
предикатов столбцов.
В запросах обычно выполняются большие просмотры, а не просмотры
в ограниченном диапазоне, как в таблицах, применяемых исключительно для
заполнения кубов служб Analysis Services. (В этих случаях таблица-куча должна
быть секционирована с такой же степенью детализации, что и заполняемый куб
служб Analysis Services.)
Требования к рабочей нагрузке запроса выполняются без дополнительных
издержек на управление индексом или первостепенную значимость имеет
производительность загрузки, ведь таблицы-кучи обеспечивают самую быструю
загрузку.
Таблицы с кластеризованными индексами
В среде хранилища данных кластеризованный индекс наиболее эффективен, если ключ
определен на столбце, заданном в соответствии с диапазоном (например, диапазоном
дат), который часто используется в ограничениях для соответствующей рабочей нагрузки
запросов. В этом случае индекс может использоваться для существенного сокращения и
оптимизации объема просматриваемых данных.
Таблицы с кластеризованным индексом в наибольшей степени подходят в следующих
случаях.

33
В таблице имеются столбцы, заданные в соответствии с диапазоном, которые
используются в ограничениях запросов для большинства сценариев
высокоприоритетной рабочей нагрузки запросов по отношению к таблице.
Что касается конфигураций FTDW, то секционированный столбец даты также
должен представлять собой ключ кластеризованного индекса.
Примечание. В некоторых случаях для таблицы с кластеризованным индексом
может оказаться более выгодным выбор ключа кластеризованного индекса,
не представляющего собой столбец секционирования по дате. Но велика
вероятность возникновения в связи с этим фрагментации, если не происходит
загрузка полных секций, поскольку новые данные, перекрывающие существующие
диапазоны ключей кластеризованного индекса, вызывают разбиения страниц.

В запросах к таблице обычно применяется детализированный поиск или поиск
с ограничением по диапазону, а не просмотр всей таблицы или нескольких
больших диапазонов.
Секционирование таблиц
Секционирование таблиц может оказаться важным средством управления фрагментацией
в базах данных FTDW. Например, секционирование может использоваться для обновления
или удаления больших блоков пользовательских данных с учетом диапазона из таблицы
без обращения к другим частям таблицы. С другой стороны, построчное удаление
с помощью кластеризованного индекса может привести к значительной фрагментации
экстентов. После устаревания данных в новых секциях и снижения частоты операций
DML для представленного в них диапазона обычно выполняется перестроение этих секций.
Секция становится стабильной по отношению к операциям DML и характеризуется
минимальной фрагментацией экстентов.
Кроме того, большие таблицы, которые используются в основном для заполнения кубов
служб SQL Server Analysis Services, можно создавать как секционированные таблицы-кучи
с таким условием, что секционирование таблицы соответствует секционированию куба.
При доступе к большой таблице осуществляется просмотр только соответствующих
секций таблицы. (Секции, которые поддерживаются в режиме ROLAP службы Analysis
Services, могут иметь лучшую структуру для использования в качестве кластеризованных
индексов.)
Дополнительные сведения о секционировании таблиц см. в техническом документе
Стратегии секционированных таблиц и индексов при использовании SQL Server 2008
(http://msdn.microsoft.com/ru-ru/library/dd578580(v=SQL.100).aspx).
Индексирование
При создании индексов FTDW необходимо учитывать следующие рекомендации.




Использование кластеризованного индекса для диапазонов дат или общих
ограничений.
По возможности использование индекса columnstore. В следующем разделе
приведены рекомендации по работе с индексами columnstore в средах FTDW.
Ограничение использования некластеризованных индексов для тех ситуаций,
в которых требуется детализированный поиск, а секционирование таблиц не
обеспечивает достаточной производительности. По возможности использование
индекса columnstore в качестве альтернативы для некластеризованного индекса.
Некластеризованные, покрывающие индексы могут оказаться значимыми для
некоторых рабочих нагрузок хранилища данных. Решение по их применению
необходимо оценивать с учетом конкретного случая и проводить сравнение
с индексами columnstore.
Индексы columnstore, оптимизированные для памяти xVelocity
В SQL Server 2012 предусмотрено новое средство ускорения запросов к хранилищам
данных на основе технологии доступа к столбцам: индексы columnstore. Применение этих
34
новых индексов в сочетании с усовершенствованными средствами обработки запросов
способствует повышению производительности выполнения широкого круга аналитических
запросов к хранилищу данных.
Индексы columnstore с оптимизацией памяти xVelocity являются «чистыми» (а не
гибридными) индексами такого типа, поскольку в них все данные для включенных
столбцов хранятся на отдельных страницах. Применение индексов columnstore
способствует повышению производительности ввода-вывода при просмотре и улучшению
показателей попадания в буферный кэш. Кроме того, они хорошо укладываются
в методологию проектирования FTDW.
Рекомендации
Объекты индекса columnstore размещаются вместе с таблицами и создаются аналогично
объектам некластеризованных индексов. Из этого следует необходимость дополнительного
увеличения информационной емкости хранилища. Не требуется создавать индексы
columnstore в отдельных файловых группах при условии, что не предполагаются частые
изменения в таблице, для которой создан индекс. Если индексы columnstore поддерживаются
в отдельных файловых группах, это позволяет легче справляться с фрагментацией
страниц в течение времени в средах, характеризующихся значительной изменчивостью.
Создание индексов columnstore для нормализованных моделей данных
Применение нормализованных моделей данных (т. е. 3NF) становится причиной частого
выполнения соединений между двумя или несколькими большими таблицами (фактов).
В настоящее время соединения этого типа не являются наиболее подходящими для
обработки индексов columnstore, поэтому могут показывать снижение производительности
по сравнению с планами запросов на основе индексов, отличных от columnstore.
Избежать возникновения этой проблемы при использовании нормализованных моделей
данных можно с помощью следующих подходов:




35
Использование указаний на уровне запроса для блокирования обработки индекса
columnstore.
Использование предложения
OPTION(IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX).
Перезапись запросов. Дополнительные сведения см. в ресурсах, перечисленных
в разделе Общие рекомендации по использованию индекса columnstore
настоящего документа.
Попытка изъять общие ключи соединения с одной из таблиц, участвующих
в соединениях SQL с признаками снижения производительности, из планов
запросов с индексами, отличными от columnstore. Изъятие ключа соединения
из индекса columnstore в одной из таблиц может привести к тому, что указанный
индекс не будет использоваться для запросов, в которых соединение выполняется
по изъятому столбцу. Этот подход может оказаться полезным в таких средах,
где параметры уровня запроса неприменимы. Следует учитывать, что изъятие
столбца из индекса columnstore не гарантирует получения лучшего плана запроса
и может отрицательно повлиять на другие запросы, в которых применение индекса
columnstore способствует повышению производительности. Если принято решение
использовать этот параметр, необходимо выбирать столбец из меньшей среди
рассматриваемых таблиц, поскольку при этом уменьшается отрицательное влияние
на производительность других запросов. Следует учитывать, что объявленные
(в DDL) первичные ключи должны быть включены в индекс columnstore, а это
ограничивает перечень доступных столбцов соединения. Даже в случае исключения
столбца первичного ключа из определения индекса columnstore все столбцы
первичного ключа автоматически добавляются к индексу columnstore при его создании.
Безусловно, нормализованные модели данных не являются полностью оптимизированными
для индексов columnstore в текущей версии, но важно отметить, что тестирование
FTDW основано на модифицированной версии теста TPC-H, представляющего собой
нормализованную модель. Измерения все равно показывают значительное улучшение
для параллельных рабочих нагрузок, характеризующихся применением планов запросов
и с индексами columnstore, и с индексами, отличными от columnstore, включая
номинальную пропускную способность FTDW, при которой в некоторых случаях общая
производительность обработки рабочей нагрузки почти удваивается.
Создание индексов columnstore для многомерных моделей данных
Необходимо соблюдать стандартные рекомендации по индексам columnstore для
многомерных моделей, таких как схема типа «звезда». Это можно рассматривать как
лучший вариант развития событий для обработки индекса columnstore.
Управление памятью для индексов columnstore
В архитектурах FTRA, проверенных для SQL Server 2012, обычно задается больший
общий объем ОЗУ системы по сравнению с аналогичными конфигурациями для SQL
Server 2008 R2. Основной причиной этого является то, что обработка рабочих нагрузок,
улучшенных для индекса columnstore, выполняется эффективнее при помощи более
крупных пулов памяти. Следует всегда использовать регулятор ресурсов в целях задания
максимального объема памяти для каждого сеанса в средах FTDW, в которых намечено
использовать преимущества индексов columnstore. Параметры регулятора ресурсов,
позволяющие достичь производительности, классифицированной по FT,
документированы в утвержденных FTRA, и эти значения можно рассматривать как
отправную точку для рабочих нагрузок клиента. В идеальном случае каждый параметр
должен быть проверен и настроен специально для рабочей нагрузки клиента после
установки системы.
Для настройки регулятора ресурсов SQL Server в соответствии с этими рекомендациями
применяется следующая команда SQL. В этом случае максимальный объем памяти для
каждого сеанса составляет 19 процентов.
ALTER RESOURCE GOVERNOR RECONFIGURE;
ALTER WORKLOAD GROUP [default] WITH(request_max_memory_grant_percent=19);
Общие рекомендации по использованию индекса columnstore, оптимизированного
для памяти xVelocity
В справочнике по FTDW рассматриваются только рекомендации, касающиеся Fast Track.
Дополнительные сведения об индексах columnstore см. в разделах Руководство по
настройке SQL Server 2012 CSI (http://social.technet.microsoft.com/wiki/contents/articles/sqlserver-columnstore-performance-tuning.aspx) и Часто задаваемые вопросы по SQL Server
36
2012 CSI (http://social.technet.microsoft.com/wiki/contents/articles/sql-server-columnstoreindex-faq.aspx).
Статистика базы данных
Принятие решения о том, когда осуществлять сбор статистики и как часто ее обновлять,
не зависит от каких-либо отдельных факторов. Как правило, решать проблемы со
статистикой базы данных приходится в двух случаях: при наличии свободного перерыва
на профилактическое техобслуживание и при общем снижении производительности
системы.
Дополнительные сведения см. в разделе Статистика для SQL Server 2008
(http://msdn.microsoft.com/ru-ru/library/dd535534.aspx).
Рекомендации
Рекомендуется следующий подход к сбору статистики базы данных.




Использование параметров AUTO CREATE и AUTO UPDATE (в синхронном или
асинхронном режиме) для статистики (речь идет о системных параметрах по
умолчанию в SQL Server). При использовании этого метода необходимость
выполнять сбор статистики вручную сводится к минимуму.
Если сбор статистики должен осуществляться вручную, то в идеальном случае
это следует делать для всех столбцов таблицы. Если нет возможности собирать
статистику по всем столбцам, то необходимо по крайней мере выполнять это
действие на всех столбцах, которые используются в предложении WHERE или
HAVING и в соединениях с ключами. Создание индекса приводит к построению
статистики для ключа индекса, что снимает необходимость заниматься этим
специально.
Для многих сценариев соединения очень важно иметь составную статистику (для
нескольких столбцов). В отсутствии составной статистики применение соединений
таблиц фактов и измерений, в которых участвуют составные ключи соединения,
может привести к созданию неоптимальных планов оптимизации с вложенными
циклами. Применение автоматически формируемой статистики не приводит
к созданию, обновлению или замене составной статистики.
Статистика, которая охватывает ключи с возрастающими значениями (такие как даты
в таблице фактов), должна обновляться вручную после каждой операции добавочной
загрузки. Во всех остальных случаях статистику можно обновлять менее часто.
Если окажется, что применение параметра AUTO_UPDATE_STATISTICS не
позволяет добиться удовлетворительных результатов, следует осуществлять сбор
статистики по расписанию.
Сжатие
Конфигурации FTDW разработаны с учетом сжатия страниц. Рекомендуется использовать
сжатие страниц во всех таблицах фактов. Сжатие малых таблиц измерений (размеры
которых не превышают миллион строк) необязательно. При более крупных таблицах
измерений часто рекомендуется использовать сжатие страниц. Так или иначе,
37
необходимость сжатия таблиц измерений следует оценивать для каждого варианта
использования. Сжатие строк — это дополнительная возможность, позволяющая
добиться приемлемых коэффициентов сжатия для данных некоторых типов.
Сжатие страниц в SQL Server приводит к уменьшению места, занимаемого данными
в таблицах, индексах и секциях. Это приводит к уменьшению объема физического
пространства, необходимого для хранения пользовательских таблиц, что позволяет
помещать больше данных в буферный пул (памяти) SQL Server. Одним из преимуществ
этого становится уменьшение количества запросов ввода-вывода, обслуживаемых из
физической памяти.
Величина сжатия, которая фактически может быть достигнута, зависит от хранимых
данных и от частоты появления повторяющихся полей данных в самих данных. Если
данные имеют в основном случайный характер, то преимущества сжатия весьма
ограниченны. Даже в самом благоприятном случае сжатие приводит к увеличению
потребности в ресурсах ЦП на сжатие и распаковку данных, но также способствует
уменьшению потребности в физическом дисковом пространстве и в большинстве
обстоятельств приводит к сокращению времени формирования ответа на запрос,
поскольку запросы ввода-вывода обслуживаются из буфера памяти. Как правило, сжатие
страниц приводит к достижению коэффициента сжатия (отношения исходного размера
и размера в сжатом виде) от 2 до 7:1, причем типичной консервативной оценкой
является 3:1. Полученные результаты зависят от характеристик конкретных данных.
Управление фрагментацией данных
Фрагментация может происходить на нескольких уровнях, и на каждом из них необходимо
ею управлять, чтобы ввод-вывод продолжал оставаться последовательным. Основное
назначение системы FTDW состоит в поддержании данных по мере возможности
в последовательно упорядоченном виде и ограничении при этом фрагментации на
всех уровнях. Если целенаправленно и последовательно не бороться с фрагментацией,
то общая производительность системы снижается.
Периодическая дефрагментация необходима, но частоту достаточно длительных
процедур дефрагментации можно снизить путем следующих рекомендаций.
Фрагментация файловой системы
В файловой системе NTFS дисковые блоки, относящиеся к каждому из файлов базы
данных, должны непрерывно следовать друг за другом на пластинах физического диска.
На этом уровне фрагментацию можно предотвратить, предварительно распределяя
пространство для файлов до предполагаемого максимального размера после их создания.
Следует избегать применения средств дефрагментации файловой системы NTFS.
Эти средства предназначены для работы на уровне операционной системы, и в них
не учитываются внутренние структуры файлов данных SQL Server.
38
Фрагментация экстентов
В 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 [размер в ГБ]
FROM sys.dm_db_index_physical_stats (DB_ID() --NULL = все базы данных
, OBJECT_ID('$(TABLENAME)')
,1
, 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;
39
В следующей таблице представлены общие рекомендации по интерпретации значений
среднего размера фрагмента.
Средний размер
фрагмента
>400
Состояние
Действие
Идеальный
Это идеальное значение, и его поддержание
для некоторых структур данных может оказаться
затруднительным.
300-399
Зеленый
Таблица обеспечивает высокую производительность
операций ввода-вывода и не требует обслуживания
для устранения логической фрагментации.
150-299
Желтый
Логическая фрагментация, влияющая на
эффективность ввода-вывода, наиболее вероятна.
Рекомендуется обслуживание для уменьшения
количества фрагментов.
10-149
Красный
Существенная логическая фрагментация Выполнение
больших запросов ввода-вывода по отношению
к данной структуре будет приводить к существенным
движениям головок диска и уменьшению общей
производительности ввода-вывода системы.
<10
Красный
Наличие столь низких значений среднего размера
фрагмента обычно указывает, что параметр запуска
-E SQL Server не задан или не распознан при запуске.
Таблица 6. Значения среднего размера фрагмента
Наконец, важно отметить, результаты определения среднего размера фрагмента не
следует оценивать для таблиц или секций с размерами меньше 500 МБ. В малых
структурах данных обычно слишком невелико общее количество страниц для достижения
действительно заметной фрагментации. Кроме того, запросы к данным в этих малых
структурах данных обычно невелики и не оказывают существенного влияния на общую
эффективность ввода-вывода системы. Наилучших результатов чаще всего можно
добиться только при обслуживании самых крупных, наиболее часто используемых таблиц
в среде хранилища данных.
Фрагментация индекса
Индекс может иметь другой физический (страница) и логический (индекс) порядок.
Для устранения фрагментации такого типа не следует использовать команду ALTER
INDEX REORGANIZE, поскольку это может привести к потере преимуществ больших
размещений данных. Проблема может быть устранена путем перестроения индекса или
использования инструкции INSERT...SELECT для вставки данных в новую копию индекса
(последний способ универсален и позволяет отказаться от других методов). При любом
процессе ALTER INDEX REBUILD необходимо указывать SORT_IN_TEMPDB=TRUE для
предотвращения фрагментации целевой файловой группы. Значение MAXDOP, равное 1,
является идеальным, но может привести к значительному снижению скоростей загрузки.
В некоторых случаях может быть задано такое высокое значение MAXDOP, как 8.
Дополнительные сведения см. в разделе Загрузка данных настоящего документа.
40
Несколько файловых групп
Могут создаваться отдельные файловые группы для сведения к минимуму логической
фрагментации в вариантах использования изменчивых данных наподобие следующих:




Таблицы или индексы, которые часто удаляются и создаются (оставляя пропуски
в схеме хранения, заполняемые другими объектами).
Индексы, без которых нельзя обойтись, но поддержка которых приводит
к значительной фрагментации из-за разбиения страниц, например в вариантах,
в которых часто загружаются дополнительные данные, приводящие главным
образом к перекрытию существующих диапазонов ключей кластеризованного
индекса.
Меньшие таблицы (такие как таблицы измерений), которые загружаются в виде
относительно небольших дополнительных порций, могут быть помещены
в изменчивую файловую группу для предотвращения чередования строк
этих таблиц со строками в больших транзакциях или в таблицах фактов.
Промежуточные базы данных, из которых данные вставляются в конечную
целевую таблицу.
Другие таблицы можно поместить в файловую группу, характеризующуюся отсутствием
изменчивости. Кроме того, в отдельные файловые группы можно помещать очень
большие таблицы фактов.
Загрузка данных
Архитектура компонентов Fast Track сбалансирована для обеспечения более высоких
средних скоростей просмотра, которые достигаются при последовательном доступе к
диску. Для поддержки этих скоростей просмотра необходимо следить за тем, чтобы
сохранялась непрерывная компоновка данных в файловой системе SQL Server.
В настоящем разделе рассматриваются два метода высокого уровня: добавочная
загрузка и миграция данных. Это руководство относится к технологии хранилищ данных
Fast Track, но его назначение этим не исчерпывается.
Дополнительные сведения о массовой загрузке SQL Server см. в разделе Руководство по
обеспечению производительности загрузки данных (http://msdn.microsoft.com/ru-ru/
library/dd425070.aspx).
Еще одним полезным ресурсом являются рекомендации по загрузке данных Fast Track 3.0.
Эту презентацию PowerPoint Майкрософт можно найти на портале SQL Server Fast Track
DW (http://msdn.microsoft.com/ru-ru/library/dd425070.aspx). Этот документ, первоначально
разработанный на основе SQL Server 2008 R2, остается применимым для SQL Server 2012.
41
Добавочные загрузки
В этом разделе рассматриваются обычные сценарии повседневной загрузки в среде
хранилища данных. В настоящем разделе описываются сценарии загрузки с одним или
несколькими из следующих атрибутов:



Малый размер относительно доступной памяти системы
Для операций сортировки при загрузке достаточно лишь имеющейся памяти
Малый размер по сравнению с общим количеством строк в целевом объекте
загрузки
При загрузке таблицы-кучи или таблицы с кластеризованным индексом необходимо
учитывать следующие рекомендации.
Процесс загрузки таблицы-кучи
Массовые вставки для таблиц-куч могут быть реализованы как последовательный или
параллельный процесс. Используйте следующие рекомендации.


Для перемещения данных в целевую таблицу-кучу следует использовать
инструкцию BULK INSERT с параметром TABLOCK. Если итоговая постоянная
таблица секционирована, должен использоваться параметр BATCHSIZE,
поскольку загрузка в секционированную таблицу вызывает выполнение сортировки
в tempdb.
Для повышения производительности загрузки по времени при импорте больших
наборов данных следует выполнять несколько операций массовой вставки
одновременно для обеспечения параллелизма этого массового процесса.
Процесс загрузки таблицы с кластеризованным индексом
Для загрузки таблиц с кластеризованным индексом с минимальной фрагментацией
таблицы можно использовать следующие два основных подхода.
Вариант 1
Использование инструкции BULK INSERT для загрузки данных непосредственно
в целевую таблицу. Для достижения наилучшей производительности полный набор
загружаемых данных должен допускать сортировку в памяти. Все загруженные данные
должны обрабатываться с помощью одной операции фиксации при использовании
значения BATCHSIZE, равного 0. При таком значении параметра исключается
чередование данных из нескольких пакетов и появление разбиений страниц.
Если выбран этот параметр, то загрузка должна происходить в однопоточном режиме.
42
Вариант 2
Создание промежуточной таблицы, которая совпадает по структуре (включая
секционирование) с целевой таблицей.


Выполнение последовательной или многопоточной массовой вставки в пустую
промежуточную таблицу с кластеризованным индексом при задании ненулевых
значений размера пакета, чтобы не приходилось выполнять операции сортировки
в tempdb. Наилучшая производительность достигается при определенном
уровне параллелизма. Цель этого шага состоит в достижении приемлемой
производительности, поэтому не столь важно, если параллельные или
одновременные операции вставки приведут к разбиению страниц и возникновению
логической фрагментации.
Вставка из промежуточной таблицы в целевую таблицу с кластеризованным
индексом с помощью одной инструкции INSERT...SELECT со значением MAXDOP,
равным 1. При значении 1 параметра MAXDOP гарантируется минимальная
фрагментация экстентов, но производительность часто снижается. Для повышения
производительности загрузки можно использовать значения параметра MAXDOP
вплоть до 8, но по мере увеличения параллелизма обнаруживается более
значительная фрагментация экстентов. В этих условиях следует искать
эффективный баланс для каждого конкретного случая.
Вариант 3
В этом варианте требуется использование двух файловых групп, а также двух или
нескольких таблиц. При этом подходе требуется таблица с секционированным
кластерным индексом, который максимально подходит для таблиц, в которых
обнаруживаются высокие уровни логической фрагментации в секциях, созданных
в самую последнюю очередь, в отличие от более старых секций, в которых активность
изменений невелика или отсутствует. Общая цель состоит в том, чтобы изменяемые
секции были помещены в выделенную файловую группу с последующим устареванием
или «отправкой» этих секций в статическую файловую группу после того, как они
перестанут получать новые записи или изменения в существующих записях.


43
Создание двух файловых групп в соответствии с рекомендациями по FTDW.
Одна из них должна быть предназначена для изменчивых секций, а вторая —
для статических секций. Как изменчивая секция рассматривается такая секция,
в которой больше 10 процентов строк изменяются во времени. Как статическая
секция рассматривается секция, не являющаяся изменчивой.
Создание секционированной таблицы с первичным кластерным индексом
в статической файловой группе.



Создание таблицы, соответствующей одному из следующих двух общих подходов.
o Единственная таблица-куча с ограничением, зеркальным по отношению
к схеме секционирования первичной таблицы. Это ограничение должно
представлять изменчивый диапазон первичного набора данных и может
распространяться на один или несколько диапазонов секционирования
схемы главной таблицы. Такой подход наиболее удобен, если основным
критерием принятия решения является производительность начальной
загрузки, поскольку загрузка в таблицу-кучу обычно происходит более
эффективно по сравнению с таблицей с кластеризованным индексом.
o Единственная таблица с кластеризованным индексом, схема
секционирования которой согласована с секцией главной таблицы. Это
позволяет выполнять операции вставки с низкой степенью параллелизации
(DOP) в главной таблице по мере устаревания изменчивых секций. После
того как секции становятся устаревшими в результате вставок в главную
таблицу, происходит их удаление и добавление новых диапазонов.
Создание представления, в котором объединяются обе таблицы. Тем самым
сочетание двух таблиц с точки зрения пользователя предстает как единый объект.
После того как изменчивые диапазоны данных становятся статическими с точки
зрения изменения данных, вступает в действие соответствующий процесс
устаревания, такой как переключение.
o Если используется таблица-куча с ограничением, то данные перемещаются
по диапазонам секций в статическую файловую группу посредством вставки
в промежуточную таблицу. Использование инструкции CREATE INDEX
и переключения секций для перемещения данных в первичную таблицу.
Дополнительные сведения об операции этого типа для конфигураций FTDW
см. в разделе Перенос данных настоящего документа.
o Если используется секционированный кластеризованный индекс,
необходимо применять значение DOP, меньшее или равное 8. После этого
выполняется инструкция INSERT, ограниченная по диапазону секций,
для вставки непосредственно в главную таблицу. Для предотвращения
фрагментации может потребоваться уменьшить значение DOP до 1
в зависимости от общей степени параллелизма в системе.
Перенос данных
В этом разделе рассматриваются сценарии одноразовой или не очень частой загрузки
в среде хранилища данных. Такие ситуации могут возникать во время переноса на другую
платформу или в ходе загрузки тестовых данных для проверки системы. В настоящем
разделе приведены сценарии загрузки с одним или несколькими следующими
атрибутами:


44
Операции загрузки, которые требуют объема памяти, превышающего доступный
объем в системе
Операции загрузки с высокой степенью параллелизма и большим объемом
данных, выполнение которых вызывает нехватку свободной памяти
Процесс загрузки таблицы-кучи
Необходимо следовать приведенным ранее указаниям по осуществлению добавочной
загрузки.
Процесс загрузки таблицы с кластеризованным индексом
Предусмотрено несколько общих подходов до загрузки таблиц с кластеризованными
индексами с минимальной фрагментацией таблиц.
Вариант 1
Использование инструкции BULK INSERT для загрузки данных непосредственно
в целевую таблицу с кластеризованным индексом. Операции сортировки и общий размер
фиксации должны соответствовать объему памяти для достижения максимальной
производительности. Необходимо следить за тем, чтобы в отдельных пакетах
загружаемых данных не было перекрывающихся диапазонов ключей индекса.
Вариант 2
Выполнение последовательной или многопоточной массовой вставки в пустую
промежуточную таблицу с кластеризованным индексом, имеющую идентичную структуру.
Использование не слишком больших и ненулевых размеров пакетов для выполнения
сортировки в памяти. После этого необходимо вставить данные в пустую таблицу
с кластеризованным индексом с помощью одной инструкции INSERT...SELECT со
значением MAXDOP, равным 1.
Вариант 3
Использование многопоточных операций массовой вставки в секцию, согласующуюся
с промежуточной таблицей-кучей, с применением не слишком больших ненулевых
размеров пакетов для выполнения сортировки в памяти. Затем применяется ряд
последовательных или параллельных инструкций INSERT...SELECT, охватывающих
каждый диапазон секционирования для вставки данных в таблицу с кластеризованным
индексом.
Вариант 4
Использование операций переключения секций в многошаговом процессе, который
обычно обеспечивает наилучшие результаты операций загрузки большого объема
данных. В этом подходе общий процесс становится более сложным, и он разработан
для демонстрации подхода, оптимального с точки зрения чистой производительности
загрузки. Основная цель этого подхода состоит в обеспечении параллельной записи на
всех этапах вставки для обработки кластеризованного индекса без появления логической
фрагментации. Это достигается с применением промежуточных таблиц во многих
файловых группах до окончательной вставки данных в целевую таблицу.
1. Определение схемы секционирования для окончательно полученной целевой
таблицы с кластеризованным индексом.
2. Создание промежуточной файловой группы.
3. Создание распакованной несекционированной «базовой» промежуточной
таблицы-кучи в промежуточной файловой группе.
45
4. Массовая вставка данных в базовую промежуточную таблицу с применением
параметра WITH TABLOCK. Если можно использовать несколько исходных файлов,
то применение многочисленных параллельных операций массового копирования
становится наиболее эффективным подходом. Количество параллельных
операций загрузки, позволяющее достичь максимальной пропускной способности,
зависит от ресурсов сервера (ЦП и памяти) и объема загружаемых данных.
5. Определение числа поддерживаемых первичных файловых групп. Это числовое
значение должно быть кратным общему количеству секций в целевой таблице. Это
число также представляет общее количество операций INSERT и CREATE INDEX,
которые должны выполняться одновременно в последующих шагах. Например,
если в таблице 24 секции, а сервер имеет восемь ядер, то следует применять базу
данных с восемью первичными файловыми группами. Эта конфигурация позволит
выполнять в последующих шагах восемь параллельных операций вставки,
по одной для каждой из восьми первичных файловых групп и ядер ЦП. В этом
случае каждая файловая группа будет содержать по три диапазона секций данных.
6. Создание первичных файловых групп в таком количестве, которое определено ранее.
7. Создание одной промежуточной таблицы-кучи в каждой первичной файловой
группе для каждого диапазона секций без сжатия. Создание в промежуточной
таблице ограничения, согласуемого с соответствующим диапазоном секционирования
целевой таблицы. Согласно приведенному выше примеру в этом шаге должны быть
созданы по три промежуточные таблицы на каждую первичную файловую группу.
8. Создание целевой секционированной таблицы с кластерным индексом со сжатием
страниц. Эта таблица должна быть секционирована по всем первичным файловым
группам. Секции должны быть согласованы с диапазонами ограничений
промежуточной таблицы-кучи.
9. Выполнение по одной инструкции выборки или вставки (SELECT или INSERT) из
базовой промежуточной таблицы в таблицы промежуточных файловых групп для
каждой первичной файловой группы. Это необходимо выполнять параллельно.
Необходимо следить за тем, чтобы предикат для инструкции INSERT или SELECT
был согласован с соответствующими диапазонами секций. Ни в коем случае не
следует выполнять одновременно больше одной инструкции SELECT или INSERT
для каждой файловой группы.
10. Выполнение по одной команде CLUSTERED INDEX CREATE со сжатием страниц
в расчете на каждую файловую группу для вновь заполненных промежуточных
таблиц. Это можно выполнять параллельно, но со значением DOP, которое не
должно превышать 8. Ни в коем случае не следует выполнять одновременно
больше одной операции создания индекса в расчете на файловую группу. При
выполнении операции CREATE INDEX каждый раз следует использовать параметр
SORT_IN_TEMPDB для предотвращения фрагментации первичных файловых
групп. Оптимальное количество одновременных операций создания индекса
зависит от размера сервера, объема памяти и самих данных. Вообще говоря,
необходимо стремиться к большему использованию ЦП для всех ядер, но не
выходя за рамки допустимой нагрузки (общее использование 85–90 процентов).
11. Выполнение последовательных операций переключения секций из промежуточных
таблиц в целевую таблицу. Это можно также выполнять после завершения каждой
промежуточной операции CREATE INDEX.
46
Тестирование и проверка
В настоящем разделе приведено общее описание процессов, используемых для
проектирования и оценки эталонных архитектур SQL Server FTDW. Эта информация
предоставлена с целью поддержки определяемых пользователем или заказных
эталонных архитектур, основанных на методологии FTDW. По вопросам тестирования,
устранения неполадок или проверки опубликованных и предварительно одобренных
участниками эталонных архитектур обращайтесь к участнику инициативы, которому
принадлежит публикация (HP, Dell, EMC, IBM, Cisco и др.).
Процесс проверки FTDW можно разбить на две категории, описанные ниже.
Проверка базового оборудования
Цель проверки оборудования состоит в определении реальных, а не номинальных
показателей производительности для основных компонентов оборудования в эталонной
архитектуре Fast Track. Этот процесс позволяет определить фактические базовые
характеристики производительности основных компонентов оборудования в стеке
базы данных.
Проверка базы данных Fast Track
Определение характеристик производительности SQL Server при рабочей нагрузке
FTDW позволяет проводить сопоставление с предположениями о производительности,
подготовленными в процессе оценки базового оборудования. Вообще говоря, показатели
пропускной способности рабочей нагрузки базы данных должны показывать по меньшей
мере 80 процентов от базовых показателей для проверенных эталонных архитектур
Fast Track. Показатели производительности, вычисленные в этом процессе, становятся
основой для опубликованных значений производительности FTDW и базируются на
параллельных рабочих нагрузках запросов SQL, выполняемых с помощью средства
проверки Fast Track с контрольной точкой.
Контрольная точка — это программное инструментально средство Майкрософт,
распространяемое по участникам разработки оборудования Fast Track, и представляет
собой единственную инфраструктуру, посредством которой происходит проверка
и утверждение корпорацией Майкрософт официально принятой эталонной архитектуры
Fast Track. В этом средстве создается экземпляр эталонной схемы базы данных
и применяются многочисленные параллельные рабочие нагрузки запросов,
предназначенные для выявления узких мест и определения основных показателей
производительности системы.
Проверка Fast Track с применением индексов columnstore, оптимизированных
в памяти xVelocity
В SQL Server 2012 реализована технология индексов columnstore в качестве одного
из вариантов некластеризованной индексации для существующих таблиц. Планы
оптимизации индекса columnstore могут использоваться или не использоваться
в отдельных запросах в зависимости от структуры запроса. Это означает, что становится
невозможно прогнозировать сочетание традиционных средств, основанных на строках,
и новых средств, основанных на столбцах, в планах запросов для среды FTDW в тот или
иной момент времени.
47
По этим причинам проектирование и проверка системы FTDW для SQL Server 2012
основаны на оценке эталонных тестов с индексами, отличными от columnstore. Системы
FTDW предназначены для эффективной эксплуатации в любой конкретной период
времени, в который не достигнута оптимизация по столбцам. Если активны планы
запросов с индексом columnstore, часто достигается существенное повышение
производительности, и это повышение можно рассматривать как дополнение
к возможностям основного проекта системы.
В эталонных архитектурах, проверенных участниками инициативы Fast Track для
SQL Server 2012, опубликованы дополнительные показатели логической пропускной
способности для эталонных тестов, улучшенных с использованием индекса columnstore,
и эти числовые данные можно применять для прогнозирования положительного влияния
на производительность запросов, на которое могут рассчитывать клиенты при параллельной
рабочей нагрузке запросов. Эти цифры основаны на тех же эталонных тестах FTDW
и схемах, используемых для всех проверок системы.
Выполнение базовой проверки FTDW
Базовая проверка осуществляется на уровне операционной системы с помощью
такого средства, как SQLIO. На этом этапе не выполняется тестирование приложений
SQL Server и все тесты представляют собой синтетические сценарии с наилучшими
вариантами развития событий. Задача состоит в проверке того, что конфигурация
оборудования и операционной системы выбрана точно и обеспечивает достижения
ожидаемых результатов, основанных на эталонных тестах при проектировании
и разработке.
Монитор производительности и стабильности системы Windows Server (известный также
как системный монитор) может использоваться для отслеживания, регистрации
и составления отчетов о производительности ввода-вывода. Для проверки пропускной
способности ввода-вывода можно использовать такое средство, как SQLIO. Дополнительные
сведения об инструменте SQLIO, включая инструкции и местонахождения загрузок, см.
в техническом документе SQLCAT Рекомендации по предварительному развертыванию
ввода-вывода (http://sqlcat.com/sqlcat/b/whitepapers/archive/2007/11/21/predeployment-i-obest-practices.aspx).
Для создания базовых эталонных тестов оборудования используются следующие
компоненты и процессы проверки.
Базовая проверка с помощью SQLIO
Применение средства SQLIO описано более полно в статье с рекомендациями.
Как правило, тесты чтения принимают следующую форму:
sqlio –kR –fSequential -s30 -o120 -b512 d:\iobw.tst –t1
В этом случае R указывает на тест чтения; 30 — это продолжительность теста в секундах;
120 — количество отправленных запросов; 512 — размер блоков сделанных запросов
в килобайтах; d:\iobw.tst — местонахождение тестового файла; 1 — количество потоков.
48
Для тестирования в сценариях с агрегированной пропускной способностью необходимо
выполнять параллельно несколько тестов SQLIO. Следует использовать по одному
экземпляру SQLIO для каждой точки подключения исходных данных (дискового тома).
Распараллеливания экземпляров SQLIO можно достичь с помощью Windows PowerShell
или других методов поддержки скриптов. Что касается эталонных архитектур FTDW,
проверенных участниками, то скрипты для базовой проверки ввода-вывода можно
получить непосредственно от участника.
В статье с рекомендациями по предварительному развертыванию также описано,
как отслеживать выполняемые тесты с помощью системного монитора. Регистрация
и сохранение результатов тестов позволяет получить основу для последующего анализа
производительности и устранения проблем.
Шаг 1. Проверка пропускной способности ввода-вывода
Первый шаг в проверке конфигурации FTDW состоит в определении максимально
достижимой агрегированной пропускной способности между сетью ввода-вывода
хранилища и сервером. Для этого необходимо исключить диск как узкое место
и сосредоточиться на компонентах, отличных от диска (таких как HBA, инфраструктура
коммутации и контроллеры массива). Для выполнения этой задачи с помощью SQLIO
применяются следующие действия.
1. Создание по одному небольшому файлу данных в расчете на каждый LUN для
использования в качестве файлов базы данных. Эти файлы должны иметь такие
размеры, чтобы все файлы данных поместились в кэш чтения на контроллерах
массива (например, по 50 МБ на каждый файл).
2. Использование SQLIO для выдачи запросов последовательного чтения к каждому
файлу одновременно с использованием больших размеров блоков ввода-вывода
(512 КБ) и по меньшей мере двух потоков чтения на каждый файл. Следует
обязательно вычислять агрегированное значение для необработанных операций
чтения. Например, 2 потока чтения с 50 необработанными запросами составят
всего 100 необработанных запросов в расчете на целевой LUN.
3. Следует начать с относительно низкого значения для необработанных операций
ввода-вывода (-o) и повторять тесты, увеличивая это значение до тех пор,
пока агрегированная пропускная способность не перестанет увеличиваться.
Назначение этого теста состоит в достижении агрегированной пропускной способности,
которая является приемлемой в сравнении с теоретическими пределами для
компонентов в пути между сервером и хранилищем. Этот тест проверяет пропускную
способность между сервером и процессорами хранилища SAN. Речь идет о путях Fibre
Channel с самостоятельным выбором маршрутов.
49
Шаг 2. Проверка пропускной способности LUN/том
Этот тест аналогичен предыдущему. Но используются большие файлы для исключения
потенциальных преимуществ применения кэша массива из кэша контроллера. Эти
тестовые файлы должны быть достаточно велики, чтобы имитировать размер файла
целевой базы данных в расчете на каждый том, например по 25 ГБ на том. Аналогичные
параметры должны использоваться для SQLIO, как описано в шаге 1.
Должны выдаваться команды последовательного чтения больших блоков (512 КБ)
к тестовым файлам на каждом томе. Рекомендуется использовать по одному потоку
на каждый файл с глубиной необработанных запросов примерно от 4 до 16 (начинать
с меньшего и увеличивать, пока не будет достигнута максимальная пропускная
способность). Вначале необходимо проверить каждый том отдельно, а затем проверить
одновременно два тома. Пропускная способность дисковой группы зависит от поставщика
хранилища и конфигурации, но всегда можно провести сравнение со скоростью чтения
для одного жесткого диска. Например, дисковая группа RAID1+0 с 4 дисками позволяет
достичь пиковой скорости чтения, превышающей примерно в четыре раза скорость
чтения с одного жесткого диска для базового шаблона чтения этого типа.
Производительность RAID 1 или 1+0 зависит от модели хранилища, поскольку некоторые
поставщики применяют технологию зеркалированного чтения, при которой операции
ввода-вывода обслуживаются с обеих сторон зеркалированной пары во время
выполнения запросов на непрерывное чтение.
Шаг 3. Проверка агрегированной пропускной способности
В этом тесте последовательные операции чтения должны выполняться на всех доступных
томах данных одновременно по отношению к тем же файлам, которые использовались
в шаге 2. Средство SQLIO должно эксплуатироваться при использовании по два потока
на каждый тестовый файл с размером ввода-вывода 512 КБ и оптимальным количеством
необработанных операций ввода-вывода, определенным в предыдущем тесте.
Результаты этого теста показывают максимальную агрегированную пропускную способность,
достижимую при чтении данных с физических дисков.
Данные считываются из больших файлов данных, как в предыдущем тесте,
одновременно с каждого тома.
Для сбалансированных систем FTDW агрегированные показатели производительности
чтения с диска должны находиться в пределах от 80 до 90 процентов от агрегированной
пропускной способности операций ввода-вывода в хранилище.
50
Оценки компонентов
На следующей диаграмме показаны результаты синтетического эталонного теста,
совместимые со значениями, представленными в аналогичных эталонных архитектурах
Fast Track.
Рис. 4. Пример показывает пропускную способность, достигнутую в синтетическом
эталонном тесте, для сервера с 2 сокетами и 12 ядрами, оборудованного тремя
двухпортовыми картами HBA на 8 Гбит/с, с первичным томом данных на 12 RAID1+0
с 4 дисками
Сводка
Базовое эталонное тестирование оборудования позволяет проверить фактическую
пропускную способность основных компонентов оборудования в стеке базы данных.
Это осуществляется с помощью синтетических тестов для наилучшего варианта,
выполняемых с помощью средства, подобного SQLIO.
51
Проведение эталонного тестирования базы данных Fast Track
На этом этапе вычисления показателей FTRA измеряется производительность SQL
Server для рабочей нагрузки FTDW в терминах двух основных показателей. Первый
показатель, максимальная норма потребления (MCR) ЦП, является мерилом пиковой
пропускной способности обработки ввода-вывода. Второй показатель, исходная норма
потребления (BCR), служит мерой фактической пропускной способности ввода-вывода
для запроса или рабочей нагрузки на основе запросов.
Определение показателя MCR
Вычисление MCR позволяет получить значение пропускной способности ввода-вывода
в расчете на каждое ядро в мегабайтах или гигабайтах в секунду. Это значение измеряется
путем выполнения стандартного, предназначенного только для чтения, неоптизированного
запроса из буферного кэша и измерения времени выполнения по отношению к объему
данных в мегабайтах или гигабайтах. Показатель MCR измеряется при выполнении из
кэша, поэтому представляет собой пиковую неоптизированную скорость просмотра,
достижимую с помощью SQL Server для оцениваемой системы. По этой причине MCR
представляет собой базовую пиковую скорость, применяемую в целях начального
проектирования. Этот показатель не предназначен для указания на средние или
ожидаемые результаты для реальной рабочей нагрузки. Проверенные архитектуры FTDW
имеют агрегированные результаты базовой пропускной способности ввода-вывода,
составляющие не менее 100 процентов от показателя MCR, который определен для сервера.
Эту мысль можно выразить иным образом, что MCR представляет наилучшую возможную
скорость обработки в SQL Server для приемлемой рабочей нагрузки в худшем случае.
Показатель MCR можно также использовать как справочную шкалу при сравнении
с другими опубликованными и проверенными эталонными архитектурами FTDW для
SQL Server 2012.
Подведем итог.




52
MCR определенно не представляет фактические результаты, относящиеся
к рабочей нагрузке для клиента.
MCR позволяет определить базовое значение максимальной скорости обработки
данных для SQL Server и для одного запроса, связанного с рабочей нагрузкой
Fast Track.
MCR зависит от ЦП и сервера. Вообще говоря, скорости, связанные с конкретным
ЦП, не подвержены существенным изменениям в зависимости от сервера
и архитектуры системной платы, но конечное значение MCR следует фактически
определять путем тестирования.
Оценку пропускной способности MCR можно использовать в качестве значения,
сравниваемого с показателями существующих, опубликованных эталонных
архитектур FTDW. Это может помочь при выборе оборудования перед проверкой
компонентов и приложений.
Вычисление MCR
Базовая норма потребления (MCR) ЦП для приложения SQL Server устанавливается
путем выполнения стандартного SQL-запроса, определенного для программы FTDW.
Этот запрос спроектирован как относительно простое представление типичного запроса
для данного типа рабочей нагрузки (в рассматриваемом случае хранилища данных)
и выполняется из буферного кэша. Результирующее значение зависит от ЦП и сервера,
на котором выполняется запрос. Для вычисления MCR используется следующий метод:
1. Создание ссылочного набора данных, основанного на таблице lineitem TPC-H или
на аналогичном наборе данных. Таблица должна иметь размер, позволяющий
полностью кэшировать ее в буферном пуле SQL Server, но вместе с тем обеспечивать
как минимум секундное время выполнения для представленного здесь запроса.
2. Для FTDW используется следующий запрос: SELECT sum([целочисленное поле])
FROM [таблица] WHERE [подходящее ограничение по объему данных] GROUP
BY [столбец].
3. Среда должна:
o обеспечивать применение значений параметров регулятора ресурсов по
умолчанию;
o обеспечивать выполнение запроса из буферного кэша. Однократное
выполнение запроса должно привести к размещению страниц в буфере,
а при последующих вызовах чтение должно происходить полностью из
буфера. Необходимо проверить, чтобы в выходных данных статистики
запросов не были показаны операции физического чтения;
o задавать значения параметров STATISTICS IO и STATISTICS TIME, равных
ON, для вывода результатов.
4. Многократное выполнение запроса при MAXDOP = 4.
5. Регистрация количества логических операций чтения и времени ЦП из вывода
статистических данных для каждого выполнения запроса.
6. Вычисление MCR в МБ/с с помощью формулы:
( [логические операции чтения] / [время ЦП в секундах] ) * 8 КБ / 1024
7. Как минимум при пяти выполнениях запроса должен обнаруживаться
согласованный диапазон значений (+/- 5 %). Наличие значительных выбросов
(+/- 20 % или более) может указывать на проблемы настройки конфигурации.
Среднее из не менее чем 5 вычисленных результатов соответствует показателю
MCR для FTDW.
На основе вычисления MCR можно построить диаграмму пропускной способности
архитектуры компонентов. Применительно к оценке MCR системы пропускная
способность компонента определяется на основе пропускной способности, измеренной
поставщиком. Эта диаграмма может оказаться полезной при проектировании системы,
выборе и анализе узких мест. Пример такой диаграммы показан на рис. 5.
53
Рис. 5. Пример определения максимальной нормы потребления (MCR) ЦП и номинальной
пропускной способности компонентов для сервера с 2 сокетами и 12 ядрами с ЦП Intel
Westmere
Дополнительные сведения об измерении MCR см. в разделе Тестирование рабочей
нагрузки в приложении.
Вычисление BCR
Значение исходной нормы потребления (BCR) для приложения SQL Server устанавливается
путем выполнения при соответствующем уровне параллелизма базового набора
SQL-запросов, характерных для рабочей нагрузки хранилища данных. Количество
используемых запросов и степень распараллеливания полностью зависят от
предполагаемого варианта использования. Рабочая нагрузка запроса должна
обслуживаться с диска, а не из буферного пула SQL Server, как это происходит при
измерении MCR. Результирующее значение зависит от ЦП, сервера и применяемой
к нему рабочей нагрузки. В разделе приложения Тестирование рабочей нагрузки приведен
более подробный пример создания эталонного теста для рабочей нагрузки BCR.
54
Для вычисления BCR используется следующий метод:
1. Создание ссылочного набора данных, который содержит по меньшей мере одну
таблицу. Эта таблица должна иметь достаточно большой размер, чтобы не
происходило ее полного кэширования ни в кэше буферного пула SQL Server,
ни в кэше массива SAN. Если предоставленные клиентом данные отсутствуют,
можно использовать синтетический набор данных. Необходимо аппроксимировать
ожидаемые характеристики данных для целевого случая использования.
2. Базовая форма запроса для FTDW является следующей: SELECT
sum([целочисленное поле]) FROM [таблица] WHERE [подходящее ограничение по
объему данных] GROUP BY [столбец]. Его можно использовать в качестве отправной
точки для проектирования рабочей нагрузки запроса, если отсутствуют запросы,
подготовленные клиентом. Еще одним широко используемым тестом для запросов
является TPC-H, который может служить в качестве эталонного набора запросов.
3. Что касается тестирования FTDW клиентом, то всегда желательно выбирать
запросы, представительные с точки зрения целевой рабочей нагрузки.
Запросы должны быть распланированы по нескольким параллельным сеансам,
представляющим пиковую зарегистрированную или проектируемую активность
для среды клиента. При выборе запроса можно учитывать следующие критерии.
 Представление усредненных требований к целевой рабочей нагрузке. Это
может потребовать увеличения или уменьшения сложности базовой формы
запроса, добавления соединений или исключения большего или меньшего
объема данных с применением проекций и ограничений.
 Запрос не должен приводить к записи данных в tempdb при условии, что эта
особенность не является существенной частью целевой рабочей нагрузки.
 Запрос должен возвращать минимальное количество строк. Для управления
этим можно использовать параметр SET ROWCOUNT. Следует использовать
значение ROWCOUNT больше 100 (для тестирования Fast Track стандартным
является значение 105). В качестве альтернативы можно использовать
агрегирование для уменьшения количества записей, возвращаемых из
крупных неограниченных операций просмотра.
4. Среда должна:
 обеспечивать установку значений по умолчанию согласно параметрам
регулятора ресурсов;
 обеспечивать очистку кэшей перед выполнением запроса с использованием
команды DBCC dropcleanbuffers;
 задавать значения параметров STATISTICS IO и STATISTICS TIME, равных
ON, для вывода результатов.
5. Многократное выполнение запроса или рабочей нагрузки, начиная со значения
MAXDOP, равного 8. После каждого выполнения запроса необходимо увеличивать
параметр MAXDOP для запроса, а между прогонами очищать кэши.
 Регистрация количества логических операций чтения и времени ЦП из
вывода статистических данных.
 Вычисление значения BCR в МБ/с с помощью формулы:
( [логические операции чтения] / [время ЦП в секундах] ) * 8 КБ / 1024
 Это позволяет определить диапазон значений BCR. Если используется
несколько запросов, то для определения BCR необходимо найти
взвешенное среднее.
55
Результаты определения BCR
На рис. 6 показаны результаты тестирования рабочей нагрузки SQL Server, которые
согласуются с результатами, представленными для аналогичных эталонных архитектур
хранилища данных Fast Track.
Рис. 6. Пример определения пропускной способности с помощью синтетического теста на
сервере с 2 сокетами и 12 ядрами, оборудованном тремя двухпортовыми картами HBA на
8 Гбит/с, с первичным LUN данных на 12 RAID1+0 с 4 дисками
56
Интерпретация показателя BCR
Если значение BCR, полученное для среднего запроса, намного меньше стандартного
значения MCR, определенного в тесте для рассматриваемой FTRA, то, скорее всего,
имеет место ограничение, связанное с ресурсами ЦП. В ответ на это можно рассмотреть
возможность уменьшения пропускной способности хранилища, например, путем
сокращения количества массивов, введения большего количества дисков в расчете на
массив или увеличения размеров дисков; эти шаги способствуют уменьшению стоимости
инфраструктуры хранилища до сбалансированного уровня. В качестве альтернативы
можно рассмотреть использование сервера с большим количеством сокетов или
применение ЦП с более высокой производительностью, что позволит воспользоваться
преимуществом «излишней» пропускной способности ввода-вывода хранилища. Так или
иначе, задача состоит в том, чтобы сбалансировать возможности обработки базы данных
с пропускной способностью ввода-вывода хранилища.
Соответственно, если BCR больше MCR, то может потребоваться большая
пропускная способность ввода-вывода для обработки рабочей нагрузки запросов
в сбалансированной форме.
Опубликованные эталонные архитектуры FTDW
Подробные спецификации оборудования в эталонной архитектуре предоставляются
каждым участником инициативы создания хранилищ данных Fast Track. Дополнительные
сведения, включая ссылки на каждого участника, см. в разделе Технология хранилищ
данных Fast Track (http://www.microsoft.com/sqlserver/en/us/solutions-technologies/datawarehousing/fast-track.aspx).
Информационная емкость FTDW оценивается по предполагаемому объему несжатых
файлов пользовательских данных, которые можно загрузить в базу данных. Этот
показатель именуется информационной емкостью пользовательских данных (UDC).
В этом вычислении предполагается, что для всех таблиц включена функция сжатия
страниц и все тома с данными зеркалированы. Используется средний коэффициент
сжатия 3,5:1. Перед вычислением UDC дополнительно к распределению вплоть до
30 процентов информационной емкости в несжатом виде распределяется для
tempdb. Следует учитывать, что для больших конфигураций с большей суммарной
информационной емкостью это соотношение уменьшается вплоть до 20 процентов.
Дополнительные сведения об изменении размера tempdb см. в разделе Планирование
загрузки базы данных tempdb (http://msdn.microsoft.com/ru-ru/library/ms345368.aspx).
Заключение
Хранилище данных SQL Server Fast Track предоставляет образцы и инструменты,
позволяющие перейти от проектирования хранилища данных к его развертыванию.
В настоящем документе рассматриваются методология, параметры конфигурации,
рекомендации, эталонные конфигурации, а также методы тестирования и проверки для
хранилищ данных Fast Track.
57
Дополнительные сведения см. в следующих разделах:
Веб-сайт SQL Server
Веб-сайт SQL Server Fast Track
Технический центр SQL Server
Источники в Интернете по SQL Server
10 лучших рекомендаций по построению крупномасштабных реляционных хранилищ
данных (группа разработчиков SQLCAT)
Как включить параметр «Блокировка страниц в памяти» (Windows)
Настройка параметров для SQL Server 2005 и SQL Server 2008 для
высокопроизводительных рабочих нагрузок
Как настроить сервер SQL Server на использование программной архитектуры NUMA
Инициализация файлов базы данных
Как просмотреть или изменить модель восстановления базы данных (среда SQL Server
Management Studio)
Наблюдение за использованием памяти
Устранение неполадок в сети хранения данных (SAN)
Установка и настройка MPIO
Технический документ по основам ввода-вывода в SQL Server 2000
Сжатие данных. Стратегия, планирование загрузки и рекомендации
Помогла ли вам эта статья? Оставьте свой отзыв. Оцените материал по шкале
от 1 (плохо) до 5 (отлично) и обоснуйте свою оценку. Например:

Вы высоко оценили этот документ из-за наличия подходящих примеров, четких
снимков экрана, ясного изложения или по какой-либо другой причине?
 Вы низко оценили степень полезности этого документа из-за плохих примеров,
нечетких снимков экрана и неясного изложения?
Ваш отзыв поможет нам повысить качество выпускаемых нами технических документов.
Отправить отзыв
58
Приложение
Средство изменения размера системы FTDW
Средство изменения размера системы FTDW — это калькулятор с электронными
таблицами, который оказывает помощь в процессе вычисления требований клиента
к рабочей нагрузке с точки зрения пропускной способности системы FTDW. Это средство
можно использовать в случае отсутствия платформы тестирования или в качестве
отправной точки при оценке требований клиента. Это средство можно найти в разделе
Технология хранилищ данных Fast Track (http://www.microsoft.com/sqlserver/en/us/solutionstechnologies/data-warehousing/fast-track.aspx). Кроме того, некоторые поставщики
участников инициативы разработали собственные согласованные средства изменения
размера Fast Track. Их можно найти на веб-сайте участника.
Проверка определяемой пользователем архитектуры FTRA
Синтетическое тестирование ввода-вывода
SQLIO — это средство, доступное для загрузки с сайта Майкрософт, которое позволяет
проверять подсистему ввода-вывода независимо от SQL Server.
Создание тестовых файлов с помощью SQLIO
При запуске SQLIO формируется соответствующий тестовый файл, если таковой еще
не существует. Для создания файла определенного размера используется параметр -F.
Например, можно воспользоваться файлом параметров (param.txt), содержащим
следующее:
C:\stor\pri\1\iobw.tst 1 0x0 50
Запуск SQLIO с параметром -F приводит к созданию файла с размером 50 МБ при первом
выполнении.
Eq sqlio -kW -s60 -fsequential -o1 -b64 -LS -Fparam.txt
Если файлы велики, этот процесс может занять некоторое время. Необходимо создать
по одному файлу на каждом диске данных, где должны размещаться данные SQL Server
и файлы tempdb. Этого можно достичь, вводя дополнительные строки в файл параметров,
что приведет к последовательному созданию требуемых файлов. Чтобы создавать
файлы параллельно, необходимо подготовить несколько файлов параметров, а затем
запустить одновременно несколько сеансов SQLIO.
59
Проверка пропускной способности хранилища (из кэша)
Использование небольшого тестового файла с продолжительностью чтения в несколько
минут гарантирует полное размещение файла в кэше массива. На рис. 7 приведены
значения показателя скорость логического чтения с диска в байт/с для дисков
в примере системы Fast Track при различных количествах необработанных запросов
и размерах блоков. Прогон тестов должен осуществляться по меньшей мере в течение
нескольких минут для достижения согласованной производительности. На рисунке
показано, что для достижения оптимальной производительности требуется, чтобы
очередь необработанных запросов составляла по меньшей мере 4 запроса в расчете на
файл. Каждый отдельный диск должен вносить свой вклад в общее значение пропускной
способности.
Рис. 7. Показатель «скорость логического чтения с диска в байт/с»
Проверка пропускной способности тома в расчете на каждый LUN (при чтении с диска)
Эти тесты позволяют убедиться в том, что все дисковые тома, предоставленные
с помощью дисковых массивов в распоряжение операционной системы Windows,
способны внести свой вклад в общую агрегированную пропускную способность путем
последовательного чтения из каждого тома. Можно обнаружить, что показатели
некоторых LUN свидетельствуют о большем быстродействии по сравнению с другими
LUN. В этом нет ничего необычного, однако, если различие превышает 15 процентов,
необходимо дополнительно изучить эту ситуацию.
60
Рис. 8. Проверка пропускной способности тома и пары RAID в расчете на каждый LUN
Необходимо выполнять тесты одновременно по отношению к одному или нескольким
томам, которые относятся к одной и той же дисковой группе. На следующем рисунке
показаны результаты тестов, проведенных по отношению к группам из 8 дисков.
Рис. 9. Проверка LUN, в которых совместно используются дисковые группы
61
Проверка агрегированной пропускной способности (при чтении с диска)
Следующий тест демонстрирует эффект постепенного наращивания пропускной
способности ввода-вывода путем добавления по одному тому в состав тестируемых
томов через регулярные интервалы. Поскольку каждый тест выполняется в течение
определенного отрезка времени, можно наглядно видеть изменения показателей.
Наблюдаемая картина всегда должна быть одинаковой. После первого этапа пиковая
агрегированная пропускная способность чтения с диска должна приближаться к значению
от 80 до 90 процентов пропускной способности, обнаруживаемой при чтении из кэша. На
графике показаны результаты теста при обработке блоков разных размеров: 512 и 64 КБ.
Рис. 10. Агрегированная пропускная способность при различных размерах блоков
Проверка рабочей нагрузки
Измерение MCR для сервера (необязательно)
Показатель MCR предназначен для оценки максимальной пропускной способности одного
ядра ЦП, применяемого для эксплуатации SQL Server, в отсутствии проблем, связанных
с появлением узких мест ввода-вывода. Показатель MCR вычисляется для каждого ядра.
Чтобы читатель мог провести эти вычисления для собственного сервера, ниже приведено
более подробное описание метода вычисления MCR.
1. Создание ссылочного набора данных на основе таблицы lineitem TPC-H или
аналогичного набора данных. Таблица должна иметь размер, который позволяет
полностью кэшировать ее в буферном пуле SQL Server, но вместе с тем требует
времени выполнения не менее 2 секунд для каждого приведенного ниже запроса.
2. Для FTDW используется следующий запрос: SELECT sum([целочисленное поле])
FROM [таблица] WHERE [подходящее ограничение по объему данных] GROUP
BY [столбец].
62
3. Среда должна:
 обеспечивать задание значений по умолчанию для регулятора ресурсов;
 обеспечивать выполнение запроса из буферного кэша. При однократном
выполнении запроса происходит лишь размещение страниц в буфере, а при
последующих выполнениях чтение должно полностью осуществляться из
буфера. Необходимо проверить, чтобы в выходных данных статистики
запросов не были показаны операции физического чтения;
 задавать значения параметров STATISTICS IO и STATISTICS TIME, равных
ON, для вывода результатов.
4. Многократное выполнение запроса при MAXDOP = 4.
 Регистрация количества логических операций чтения и времени ЦП по
выходным статистическим данным для каждого выполнения запроса.
 Вычисление показателя MCR в МБ/с с помощью формулы:
( [логические операции чтения] / [время ЦП в секундах] ) * 8 КБ / 1024
 В течение не меньше пяти выполнений запросов должен обнаруживаться
согласованный диапазон значений (+/- 5 %). Наличие значительных
выбросов (+/- 20 % или более) может указывать на проблемы настройки
конфигурации. Среднее из не менее чем 5 вычисленных результатов
соответствует показателю MCR для FTDW.
Измерение показателя BCR для конкретной рабочей нагрузки
Измерение BCR аналогично измерению MCR, за исключением того, что данные
поступают с диска, а не из кэша. Запрос и набор данных для измерения BCR должны
представлять рабочую нагрузку целевого хранилища данных.
Один из подходов к определению BCR состоит в применении простого запроса, запроса
средней сложности и действительно сложного запроса в составе рабочей нагрузки.
Сложными считаются запросы, которые предъявляют больше требований к ресурсам ЦП.
Простой запрос должен быть аналогичным с точки зрения MCR и выполнять аналогичный
объем работы, чтобы можно было применять его результаты при сравнении
показателей MCR.
Создание базы данных
Ниже приведен пример инструкции CREATE DATABASE для системы FTDW с 8 ядрами
и 16 LUN с данными.
CREATE DATABASE FT_Demo ON PRIMARY Filegroup FT_Demo
( NAME = N 'FT_Demo_.mdf' , FILENAME = N'C:\FT\PRI\SE1-SP1-DG1-v1' ,
FILEGROWTH = 0 ),
( NAME = N 'FT_Demo_v1.ndf' , FILENAME = N'C:\FT\PRI\SE1-SP1-DG1-v1'
FILEGROWTH = 0 ),
( NAME = N 'FT_Demo_v2.ndf' , FILENAME = N'C:\FT\PRI\SE1-SP1-DG2-v2'
FILEGROWTH = 0 ),
( NAME = N 'FT_Demo_v3.ndf' , FILENAME = N'C:\FT\PRI\SE1-SP2-DG3-v3'
FILEGROWTH = 0 ),
( NAME = N 'FT_Demo_v4.ndf' , FILENAME = N'C:\FT\PRI\SE1-SP2-DG4-v4'
FILEGROWTH = 0 ),
63
SIZE = 100MB ,
, SIZE = 417GB ,
, SIZE = 417GB ,
, SIZE = 417GB ,
, SIZE = 417GB ,
( NAME = N
FILEGROWTH
( NAME = N
FILEGROWTH
( NAME = N
FILEGROWTH
( NAME = N
FILEGROWTH
(
,
(
,
(
,
(
,
'FT_Demo_v6.ndf'
= 0 ),
'FT_Demo_v7.ndf'
= 0 ),
'FT_Demo_v8.ndf'
= 0 ),
'FT_Demo_v9.ndf'
= 0 ),
, FILENAME = N'C:\FT\PRI\SE2-SP1-DG6-v6' , SIZE = 417GB ,
, FILENAME = N'C:\FT\PRI\SE2-SP1-DG7-v7' , SIZE = 417GB ,
, FILENAME = N'C:\FT\PRI\SE2-SP2-DG8-v8' , SIZE = 417GB ,
, FILENAME = N'C:\FT\PRI\SE2-SP2-DG9-v9' , SIZE = 417GB ,
NAME = N 'FT_Demo_v11.ndf'
FILEGROWTH = 0 ),
NAME = N 'FT_Demo_v12.ndf'
FILEGROWTH = 0 ),
NAME = N 'FT_Demo_v13.ndf'
FILEGROWTH = 0 ),
NAME = N 'FT_Demo_v14.ndf'
FILEGROWTH = 0 ),
, FILENAME = N'C:\FT\PRI\SE3-SP1-DG11-v11' , SIZE = 417GB
, FILENAME = N'C:\FT\PRI\SE3-SP1-DG12-v12' , SIZE = 417GB
, FILENAME = N'C:\FT\PRI\SE3-SP2-DG13-v13' , SIZE = 417GB
, FILENAME = N'C:\FT\PRI\SE3-SP2-DG14-v14' , SIZE = 417GB
LOG ON
( NAME = N 'FT_LOG_v5.ldf' , FILENAME = N 'C:\FT\LOG\SE1-SP2-DG5-v5' , SIZE = 100GB ,
MAXSIZE = 500GB , FILEGROWTH = 50 )
GO
/*****************Настройка рекомендованных параметров***********************/
ALTER DATABASE FT_Demo SET AUTO_CREATE_STATISTICS ON
GO
ALTER DATABASE FT_Demo SET AUTO_UPDATE_STATISTICS ON
GO
ALTER DATABASE FT_Demo SET AUTO_UPDATE_STATISTICS_ASYNC ON
GO
ALTER DATABASE FT_Demo SET RECOVERY SIMPLE
GO
sp_configure 'show advanced options', 1
go
reconfigure with override
go
/********Убедиться в том, что все таблицы входят в нашу файловую группу, а не в
первичную файловую группу****/
ALTER DATABASE FT_Demo
MODIFY FILEGROUP FT_Demo
DEFAULT
GO
Создание тестовых таблиц
Пример инструкции 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,
64
l_discount
l_tax
l_returnflag
l_linestatus
l_shipdate
l_commitdate
l_receiptdate
l_shipinstruct
l_shipmode
l_comment
float not null,
float not null,
char(1) not null,
char(1) not null,
datetime not null,
datetime not null,
datetime not null,
char(25) not null,
char(10) not null,
varchar(132) not null
)
ON FT_Demo
GO
CREATE CLUSTERED INDEX cidx_lineitem
ON lineitem(l_shipdate ASC)
WITH( SORT_IN_TEMPDB = ON
, DATA_COMPRESSION = PAGE
)
ON FT_Demo
GO
Загрузка данных для измерения BCR
Как было описано ранее в этом документе, системы хранилища данных Fast Track
чувствительны к фрагментации файлов базы данных. Для загрузки данных необходимо
использовать один из методов, описанных в настоящем документе. При проверке FTDW
использовался метод загрузки с кластеризованным индексом, представленный как
вариант 2. С помощью средства datagen в составе TPC-H создана таблица с данными
lineitem с размером 70 ГБ с помощью параметров -s100, сформирован файл из 8 частей,
и применены параметры -S и -C.
При выполнении всех операций загрузки был задан флаг трассировки 610 для ведения
журнала в минимальном объеме, если это возможно.
С помощью инструкции BULK INSERT осуществлялась параллельная вставка данных
в одну промежуточную таблицу с кластеризованным индексом при ведении журнала
в минимальном объеме; мы выбрали размер блока, который не требует выхода за
пределы доступной памяти и уменьшает объем подкачки на диске. На этой стадии
отключение блокировки страниц и укрупнение блокировки для промежуточной таблицы
способствовало повышению производительности.
Результирующие операции вставки выполнялись в идентичную целевую таблицу со
значением MAXDOP, равным 1 (с использованием указания TABLOCK), а также была
предотвращена сортировка.
65
Выполнение запросов для измерения BCR
Для регистрации информации, относящейся к эталонному тестированию запросов,
необходимо использовать приложение SQL Server Profiler. Приложение SQL Server
Profiler должно быть настроено на регистрацию логических операций чтения, времени ЦП,
продолжительности, имени базы данных, имени схемы, инструкции SQL и фактических
планов запросов. В качестве альтернативы можно использовать параметры сеанса
статистики set statistics io on и set statistics time on.
Ниже приведено несколько примеров запросов (на основе запросов из эталонного теста
TPC-H) и показаны значения BCR, достигнутые в эталонных системах. Следует
учитывать, что этот пример не может указывать на то, какая производительность
достижима в той или иной конкретной системе. Показатели BCR полностью зависят от
системы, размера схемы, типов данных, структуры запроса и статистики, не говоря уже
о многих других переменных.
Сложность запроса
Простые
Средние
Сложные
Таблица 7. Примеры эталонных тестов
BCR в расчете на одно ядро
(страницы со сжатием ) при
MAXDOP, равном 4
201 МБ/с
83 МБ/с
56 МБ/с
Простые
SELECT
sum(l_extendedprice * l_discount) as revenue
FROM
lineitem
WHERE
l_discount between 0.04 - 0.01 and 0.04 + 0.01 and
l_quantity < 25
OPTION (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_order
66
FROM
lineitem
WHERE
l_shipdate <= dateadd(dd, -90, '1998-12-01')
GROUP BY
l_returnflag,
l_linestatus
ORDER BY
l_returnflag,
l_linestatus
OPTION (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_revenue
FROM
lineitem,
part
WHERE
l_partkey = p_partkey
and l_shipdate >= '1995-09-01'
and l_shipdate < dateadd(mm, 1, '1995-09-01')
OPTION (maxdop 4)
Факторы, влияющие на норму потребления запроса
Не во всех запросах достигается максимальная норма потребления (MCR) ЦП или исходная
норма потребления (BCR). На норму потребления для запроса могут повлиять многие
факторы. При более простых запросах по сравнению с рабочей нагрузкой, используемой
для создания нормы потребления, обнаруживаются более высокие нормы потребления,
а при более сложных рабочих нагрузках — более низкие нормы потребления. Указанная
сложность и норма потребления зависят от многих факторов, например следующих:


67
Сложность запроса. Чем больше ресурсов ЦП требуют запрос, например с точки
зрения объема вычислений и количества операций агрегирования, тем ниже норма
потребления.
Сложность сортировки. Операции сортировки, исходя из явного упорядочения по
операциям или группирования по операциям, создают большую рабочую нагрузку
ЦП и уменьшают норму потребления. Дополнительные операции записи в tempdb,
вызванные такими запросами, требующими вывода на диск, отрицательно влияют
на норму потребления.



68
Сложность плана запроса. Чем сложнее план запроса, тем больше в нем шагов
и операторов и тем ниже норма потребления ресурсов ЦП, поскольку каждый блок
данных обрабатывается через более длинный конвейер операций.
Сжатие. Сжатие приводит к уменьшению нормы потребления ресурсов для
данных в реальном выражении, поскольку норма потребления по определению
измеряется количеством запросов, ограничиваемых ресурсами ЦП, а распаковка
требует затрат времени ЦП. Однако если рабочая нагрузка не требует больших
затрат времени ЦП, то преимущества, связанные с повышением пропускной
способности, обычно перевешивают недостатки в виде дополнительного
расходования времени ЦП при сжатии. При сравнении норм потребления для
сжатых и распакованных данных необходимо учитывать коэффициент сжатия.
Еще одно направление анализа этой проблемы состоит в рассмотрении нормы
потребления, исчисляемой количеством строк в секунду.
Использование данных. Процесс исключения данных во время просмотров
(например, с применением в запросах проекций и критериев выбора) является
весьма эффективным. Запросы, в которых используются все данные таблицы,
имеют более низкую норму потребления, поскольку на единицу пропускной
способности для данных обрабатывается больше данных.