(Возврат на основную страницу)

Содержание номера за Сентябрь 2009 год

SQL Server
для администраторов

Сентябрь 2009
№ 9 (39)

Брэд МакГи

SQL Server 2008: сборщик данных о производительности

Роб Гаррисон

Изучаем фильтруемые индексы в версии SQL Server 2008

Робин Пейдж

Средства проверки допустимости данных SQL Server

Санджай Мишра, Майк Рутраф

Как повысить производительность резервного копирования со сжатием в версии SQL Server 2008. Часть 3

Эндрю Келли

Знакомство с Virtual File Stats. Часть 1

SQL Server 2008: сборщик данных о производительности

Теперь с помощью сборщика Performance Data Collector, который входит в состав SQL Server 2008, можно обеспечить централизованное хранение данных о производительности нескольких экземпляров SQL Server. Накоплением этих данных на каждом сервере занимается комплект сбора (collection set); накопленные данные хранятся в общедоступном хранилище данных (management data warehouse, MDW). На основе этих данных можно формировать отчеты: стандартные или пользовательские, подготовленные с помощью служб Reporting Services. Об остальном рассказывает Брэд МакГи (Brad McGehee).

В совершенном мире в состав SQL Server входило бы одно инструментальное средство, которое обеспечивало бы не только автоматический сбор всех важных данных, необходимых администраторам БД для идентификации и исправления проблем производительности. По традиции в состав SQL Server входит множество инструментальных средств, которые помогают администраторам БД идентифицировать и устранить проблемы производительности. К таким средствам относятся профайлер (Profiler), системный монитор (System Monitor), помощник по настройке ядра СУБД (Database Engine Tuning Advisor), среда Management Studio, динамические административные представления (DMVs), команды языка T­SQL и т. д. Некоторые из этих инструментов обеспечивают возможность протоколирования в журнале выполняемых действий в хронологическом порядке, а некоторые — нет. И даже если используемое вами инструментальное средство позволяет вести журнал, получение и анализ данных такого журнала — это все­таки трудный процесс. Другие инструментальные средства, например представления мониторинга (DMV), вообще не позволяют вести какого­либо рода протоколирование, если только вы не запрограммируете собственное решение для ведения журнала. Такое смешение различных инструментов и методов сбора данных затрудняет для администраторов БД выявление и исправление множества разнообразных проблем производительности.

В совершенном мире в состав SQL Server входило бы одно инструментальное средство, которое обеспечивало бы не только автоматический сбор всех важных данных, необходимых администраторам БД для идентификации и исправления проблем производительности, но также позволяло бы хранить эти данные централизованно в едином формате. Кроме того, такой инструмент предоставлял бы развитые средства для создания отчетов, которые обеспечили бы легкую интерпретацию собранных данных администраторами БД и, следовательно, возможность найти соответствующее решение проблемы.

Хотя в версии SQL Server 2008 нет идеального средства сбора и анализа данных о производительности, в этой версии представлена новая возможность, которая называется «сборщик данных о производительности» (Performance Data Collector), и это — первый шаг в правильном направлении на пути к такому идеальному инструменту.

В двух словах, назначение сборщика данных о производительности — это помощь администраторам БД, которая заключается в следующем:

•   Обеспечение центрального репозитория данных: один из компонентов сборщика — это так называемое хранилище данных (Management Data Warehouse, MDW). Это хранилище используется для централизованного хранения в одном месте всех собранных данных. В хранилище могут храниться данные, полученные для одного или для нескольких экземпляров SQL Server. Хотя основная задача хранилища MDW в версии SQL Server 2008 — это хранение данных, имеющих отношение к производительности, предполагается, что в последующих версиях SQL Server там будут храниться практически все данные, которые вы захотите собрать для экземпляра SQL Server, например данные расширенных событий (Extended Events), данные аудита и другие сведения. Хранилище MDW — это компонент с наращиваемыми возможностями, поэтому, если вы способны решить такую задачу, можете хранить в MDW свои собственные данные.

•   Сбор данных о производительности выбранного экземпляра SQL Server: тогда как хранилище MDW используется для хранения данных о производительности, собственно сбор данных осуществляют так называемые комплекты сбора (Data Collection Sets). В составе SQL Server 2008 поставляются три стандартных комплекта сбора данных: один обеспечивает сбор информации об использовании дисковой подсистемы (Disk Usage information); другой — сбор статистики запросов (Query Statistics), а третий — сбор разнообразных данных об активности сервера (Server Activities). Согласно утверждению фирмы Microsoft, эти три комплекта собирают самые основные данные, которые необходимы для идентификации и решения наиболее распространенных проблем производительности SQL Server. Если вы считаете, что собранных таким образом данных недостаточно, можете создать собственные пользовательские комплекты сбора.

•   Предоставление отчетов о производительности: от данных, которые находятся в хранилище, не очень много толку, если до них нельзя добраться. Версия SQL Server 2008 включает три стандартных отчета: сводка по использованию дискового пространства (Disk Usage Summary), журнал статистики запросов (Query Statistics History) и журнал активности сервера (Server Activity History). Каждый из этих отчетов позволяет проанализировать историю деятельности одного экземпляра SQL Server, по одному за раз. Кроме того, каждый отчет позволяет получить более полное представление о том, что происходит на сервере, с помощью детализирующей информации, содержащейся в подотчетах. Если вы считаете, что стандартные отчеты не обеспечивают полной картины, или вы хотите получить отчет, сформированный на основе данных, накопленных пользовательским сбором, или вам необходимо создать отчеты, которые включают информацию о нескольких экземплярах SQL Server, в таком случае у вас есть возможность создать пользовательские отчеты, воспользовавшись для этого средой SQL Server Business Intelligence Development Studio или любым из разнообразных инструментальных средств служб Reporting Services.

Сборщик данных о производительности полностью поддерживается в выпусках Enterprise SQL Server 2008 и Standard SQL Server 2008. Как готовое решение («прямо из коробки»), сборщик работает только с экземплярами SQL Server 2008 и не является обратно совместимым с предыдущими версиями SQL Server. (Если сделать скрипт на текущие сборщики — по правой клавише мыши выбрать команду Script data collection as…, то код создания сборщика можно модифицировать для совместимости с SQL 2000 и 2005. — Прим. ред.)

Изучаем фильтруемые индексы в версии SQL Server 2008

Введение

Одна из наиболее интересных возможностей, реализованных в версии SQL Server 2008, — это фильтруемые индексы. Давайте начнем с краткого пояснения, а затем углубимся в подробности и рассмотрим результаты.

Фильтруемый индекс — это просто индекс с условием WHERE. Например, если есть таблица, где в 90% записей дата имеет значение NULL, и необходима возможность, позволяющая найти записи, в которых это значение не является NULL, фильтруемый индекс будет содержать только те 10% записей, в которых значение даты отвечает такому условию.

Фильтруемые индексы могут принести большую пользу с точки зрения экономии места, экономии затрат на обслуживание индексов и ускорения выполнения запросов. Однако важно понимать, при каких условиях применение фильтруемых индексов обеспечит более быстрое выполнение запросов.

Средства проверки допустимости данных SQL Server

Если бы вы были абсолютно уверены в том, что при вставке или обновлении в таблицу попадают допустимые данные, тогда вам не понадобились бы ограничения. Даже при наличии полностью «укомплектованного» логического интерфейса хранимых процедур, вам все-таки не обойтись в разработке без ограничений, поскольку как раз то, что невозможно, по-видимому, всегда и случается. Однако в реальном мире, и особенно в таком, где есть программисты, которые используют «динамический SQL» (Dynamic SQL) или ввод данных в таблицы в реальном времени и так далее, ограничения — это важнейшее средство защиты, обеспечивающее целостность ваших данных.

Есть несколько различных способов, позволяющих определить ограничения и предусмотреть проверку данных, и цель этого практического занятия — пройтись по списку и просто обратить внимание на особенности, которые могли бы принести практическую пользу.

Правила, значения по умолчанию, индексы и триггеры используются в следующих целях:

•    для обеспечения целостности данных. Например, столбец должен иметь данные в каждой строке, но это не должны быть значения null.

•    для проверки или подтверждения допустимости данных. Допустимы ли данные? Например, допустим ли адрес электронной почты. Обычно для этого используются триггеры или правила.

•    для обеспечения уникальности данных. В выбранных столбцах никакие две строки в таблице не должны иметь одинаковые значения, не являющиеся null­значениями. Для этого применяются уникальные индексы.

•    для обеспечения ссылочной целостности. При вставке данных в столбец таблицы, в столбце другой таблицы или в другом столбце в этой же таблице уже должны присутствовать соответствующие данные.

Я испытываю определенные трудности, говоря об этих средствах, поскольку команда SQL Server поспешила сообщить о своем намерении заменить правила и значения по умолчанию, возможно, определенными в стандарте ANSI доменами. Однако пока этого не произошло, правила и значения по умолчанию — это самый эффективный способ реализовать в базе данных некоторые бизнес­правила. (В соответствии с текстом стандарта ANSI 99, эдомен — именованный пользовательский объект, который может быть определен как альтернатива типу данных во всех случаях, где может использоваться тип. Домен состоит из характеристики типа данных, может иметь значение умолчания и ни одного, одно или больше ограничений. «A domain is a named user­defined object that can be specified as an alternative to a data type,wherever a data type can be specified. A domain consists of a data type, possibly a default option,and zero or more (do­main) constraints.» — Прим. ред.)

Можно было бы возразить, что перечисленные средства не следует использовать, поскольку они подлежат удалению, но факты таковы, что в версии SQL 2005 нет реальной замены для обеспечиваемых ими функциональности и механизмов защиты.

Вы отказались бы от использования ремня безопасности, если бы до вас дошел слух о том, что года через четыре должна появиться более совершенная конструкция?

Как повысить производительность резервного копирования со сжатием в версии SQL Server 2008. Часть 3*

Сжатие резервной копии и сжатие данных

Сжатие данных (Data compression) — это возможность версии SQL Server 2008, которая позволяет сэкономить пространство на диске за счет сжатия страниц данных в базе данных. Чаще всего задают вопрос: «Обеспечивают ли операции создания резервных копий со сжатием дополнительные преимущества, если используются сжатые данные (как с точки зрения коэффициента сжатия, так и производительности операций создания резервной копии)?».

В этом тесте все таблицы и индексы были сжаты в базе данных, а затем была измерена производительность операции создания резервной копии со сжатием. Отдельные тесты выполнялись без сжатия (NONE), со сжатием по типу ROW и со сжатием по типу PAGE применительно ко всем таблицам и индексам.

Некоторые выводы, сделанные по результатам:

•    В результате сжатия резервной копии может быть получена дополнительная экономия дискового пространства даже для тех баз данных, которые содержат таблицы или индексы со сжатием типа ROW или PAGE. Размер сжатой резервной копии и коэффициент ее сжатия зависят от характеристик данных, хранящихся в базе данных, и они могут отличаться от результатов, демонстрируемых в рассматриваемых примерах.

•    Резервное копирование баз данных, использующих сжатие по типу ROW или PAGE, вероятно, потребует меньших временных затрат, поскольку меньший объем базы данных транслируется в меньшее количество операций ввода­вывода.

•    Потребление ресурсов ЦП во время операции резервного копирования для баз данных, использующих сжатие по типу ROW или PAGE, может оказаться выше в результате уменьшения количества операций ввода­вывода, что ведет к увеличению времени, которое ЦП затрачивает на операции сжатия.

Ссылки

•    Доставка журналов (http://technet.microsoft.com/en­us/library/ms187103.aspx)

•    Опция ‘backup compression default’ хранимой процедуры sp_configure (http://technet.microsoft.com/en­us/library/bb677250.aspx)

•    sp_add_log_shipping_primary_database (http://technet.microsoft.com/en­us/library/ms182718.aspx)

•    Сжатие данных (http://technet.microsoft.com/en­us/library/cc280449.aspx)

•    Прозрачное шифрование данных (http://technet.microsoft.com/en­us/library/bb934049.aspx)

*См. Санджай Мишра, Майк Рутраф. Как повысить производительность резервного копирования со сжатием в версии SQL Server 2008. Части 1 и 2 // SQL Server для администраторов. 2007  № 7 и 2009. № 8.

Знакомство с Virtual File Stats. Часть 1

Каждый администратор баз данных (АБД) знает, что существуют определенные аспекты SQL Server и связанного с ним аппаратного обеспечения, которые вам просто необходимо контролировать, если вы хотите измерить общую производительность системы. Однако не каждый в точности представляет, за чем следить, как следить и, самое важное, как истолковывать результаты. В этом более длинном, чем обычно, описании я проведу относительно подробное рассмотрение с целью исследовать один из этих ключевых фрагментов этой проблемы: я воспользуюсь встроенным динамическим административным представлением (DMV) SQL Server 2005, связанным с физическим файловым доступом — sys.dm_io_virtual_file_stats() — а также создам и задействую небольшое количество специализированного кода, который позволит вам легко получать сведения о данных, выводимых этим DMV. Хотя это DMV вы найдете только в SQL Server 2005 или более поздних версиях, оно заменяет схожую функцию SQL Server 2000, именуемую fn_virtualfilestats(). Приемы, код, принципы работы, описанные в этой статье, специфичны для SQL Server 2005, но вы можете без труда применить их к SQL Server 2000 с незначительными изменениями.

(Возврат на основную страницу)