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

Содержание номера за январь 2008 год

Использование виртуальных или физических экземпляров SQL Server

Виртуализация – одна из наиболее быстро развивающихся технологий в мире ИТ индустрии. Основной мотивацией этого роста является возможность абстрагировать сервер от железа, что позволяет вам запускать несколько виртуальных машин на единственном сервере и легко переносить виртуальные машины с сервера на сервер вместе с их гостевой ОС. Многие организации используют эту технологию для решения задач консолидации. Но виртуализация — не единственный способ консолидации серверов. Начиная с версии 2000, SQL Server поддерживает работу нескольких экземпляров СУБД на одном сервере. Подобная функциональность уникальна среди серверных продуктов Microsoft.

Использование экземпляров по сути дела позволяет вам исполнять несколько процессоров баз данных на одном физическом сервере. Так, SQL Server 2005 Enterprise Edition поддерживает до 50 экземпляров. Интернет­провайдеры и другие организации, обеспечивающие хостинг, часто используют несколько экземпляров sql server для того, чтобы различные клиенты работали со своими базами данных, не требуя выделенного сервера. Итак, как можно сравнивать множество экземпляров и виртуализацию?

Во­первых, и во многих случаях это основной аргумент, это производительность. По совершенно объективным причинам виртуальные среды не в состоянии обеспечить такой же уровень производительности, как физическая машина, так как виртуальная среда вносит собственные накладные расходы, отбирающие скорость. По большинству оценок виртуальная среда вносит от 10 до 15 процентов накладных расходов. При работе в консолидированной среде эти накладные расходы будут даже больше, так как на сервере работает несколько виртуальных машин. С другой стороны, экземпляры, исполняющиеся на физической машине помимо собственно полезной нагрузки не вносят никаких (дополнительных. ­— Прим. ред.) возмущений.

Виртуализация и серверные экземпляры сходны с точки зрения администрирования, но использование нескольких экземпляров дает следующие преимущества. Так как у нас только одна инсталляция операционной системы и серверов, его проще обновлять при выходе заплаток и сервисных пакетов (но и падает, если что не так, все сразу.— Прим. ред.). При использовании виртуальной среды, каждую виртуальную машину приходится патчить отдельно (но использование undo дисков делает эту операцию практически безопасной.— Прим. ред.) В любом случае управление выполняется средствами Enterprise Manager или SQL Server Management Studio.

С точки зрения развертывания и восстановления виртуальная среда намного удобнее. Вы можете создать образы, которые можно развернуть на сервере за несколько минут (если бы только не активация, которая висит как жернов на шее. — Прим. ред.). Кроме того, виртуальный образ можно сохранять в резервной копии или передавать на удаленную площадку, где, при возникновении катастрофического сбоя основного сервера, он может быть поднят в течение минут или даже секунд.

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

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

Анализ производительности SQL Server без гадания*

Мое время здесь, приятель

В предыдущей статье в разделе «Эй, куда подевалось мое время?» я рассказал о методе, в основе которого лежит использование событий ожидания (wait events) сервера SQL Server, позволяющее измерить время отклика и выявить самые узкие места в SQL Server­приложениях.

Мониторинг событий ожидания может стать очень мощной методикой диагностирования. Он, например, способен указать, кто именно осуществил данную монопольную блокировку (LATCH_EX) и почему. Даже простое наблюдение за последовательностью событий ожидания может оказаться интересным и привести к открытиям. В этой статье я демонстрирую ряд более содержательных и немного более сложных, примеров того, куда может уходить время и где его искать. Мы исследуем временные задержки, причиной которых являются конструкции языка SQL и система планирования операционной системы Windows, а также рассмотрим совместное использование ресурсов планировщика как при выполнении стандартных, так и параллельных запросов.

Замечание Если вам необходимы некоторые дополнительные сведения и начальная подготовка по теме анализа производительности на основе событий ожидания, обратитесь, пожалуйста, к моей предыдущей публикации и к ссылкам, приведенным в конце той статьи. В частности, два бывших члена команды SQL Server Customer Advisory фирмы Microsoft, Том Дэвидсон (Tom Davidson) и Герт Дрэперс (Gert Drapers), представляют эту тему и публикуют соответствующие статьи, начиная с 2003 года. В целях проведения исследований я по­прежнему содержу в исправности свои собственные внешние хранимые процедуры на сайте www.sqlinternals.com: советую вам поэкспериментировать с ними и изучить, как в действительно­сти происходит выполнение SQL­предложений, как работают лежащие в основе этого механизмы.

* См. Марио Брудбаккер. SQL Server ждут перемены: исключаем догадки из процесса профилирования производительности // SQL Server для профессионалов. 2007. № 12.

Уровни изоляции в SQL Server 2005

Уровни изоляции вступают в игру, когда вам необходимо выделить ресурс для данной транзакции и «защитить» его от других транзакций. Такая защита осуществляется путем получения блокировок. Какие блокировки необходимы и как их следует устанавливать применительно к транзакции, определяет SQL Server, основываясь на заданном уровне изоляции. Самые низкие уровни изоляции позволяют нескольким пользователям обращаться к ресурсу одновременно (параллельно), но это может послужить причиной возникновения проблем распараллеливания, таких, например, как «грязное» чтение (dirty-reads) и неточные данные (data inaccuracy). Более высокие уровни изоляции исключают проблемы распараллеливания и повышают степень точности данных, но могут приводить к блокированию. Обратите внимание, первые четыре уровня изоляции, описанные ниже, рассматриваются в порядке от самого низкого до самого высокого. Два последующих уровня являются новинками версии SQL Server 2005, и рассматриваются отдельно.

Обработка индексов в оперативном режиме в версии SQL Server 2005

Обработка индексов в оперативном режиме – это новая возможность, представленная в версии SQL Server 2005. В версии SQL Server 2005 DBA-администраторы могут создавать, перестраивать или удалять индексы в оперативном режиме (online). Операции с индексами базовой таблицы можно выполнять параллельно с операциями обновления или запросами. Это было невозможно в предыдущих версиях SQL Server. В прошлом, в версиях SQL Server 2000 или 7.0, операции с индексами (их реорганизация или перестроение) обычно осуществлялись в рамках общего технического обслуживания в то время, когда нагрузка спадала до минимума. Все то время, пока они выполнялись, такие offline-операции индексирования удерживали монопольные блокировки базовой таблицы и связанных с ней индексов. Версия SQL Server 2005 устраняет необходимость использовать монопольные блокировки при выполнении операций с индексами в оперативном режиме. (Это разъясняется в разделе «Как выполняются операции с индексами в оперативном режиме») Возможность обрабатывать индексы в оперативном режиме очень полезна для сред, которые функционируют 24 часа в сутки, семь дней в неделю. Функциональность, обеспечивающая индексацию в оперативном режиме, доступна только в редакции Enterprise Edition версии SQL Server 2005.

Как выполняются операции с индексами в оперативном режиме?

Итак, давайте рассмотрим, каким образом осуществляются операции с индексами в версии SQL Server 2005. При выполнении операций с индексами в оперативном режиме используются несколько различных структур: источник (source), существующие ранее индексы (preexisting indexes), целевые индексы (target) и временные индексы сопоставления (temporary mapping indexes).

Источником называется базовая таблица или данные кластеризованного индекса. Ранее существующие индексы – это некластеризованные индексы, ассоциированные с данной таблицей или кластеризованным индексом. Ранее существующие индексы предоставляются в распоряжение пользователей ради выполнения параллельных DML­операций. Структура «целевой индекс» – это новый индекс, созданный или полученный в результате реорганизации существующего индекса. Временный индекс сопоставления появляется во время создания кластеризованного индекса. Этот некластеризованный индекс создается на том же этапе, что и новый кластеризованный индекс (или куча), и не требует отдельной операции сортировки. Параллельные транзакции также поддерживают временный индекс сопоставления во всех операциях INSERT, UPDATE и DELETE.

Индексную online­операцию можно разбить на три этапа:

•    Подготовка (Preparation);

•    Сборка (Build);

•    Завершение (Final).

Этап сборки является самым продолжительным из всех. Именно на этом этапе осуществляется создание, удаление или реорганизация индексов. Продолжительность этапа сборки зависит от объема данных и быстродействия аппаратуры. На этапе сборки монопольные блокировки не удерживаются, благодаря чему в это время можно выполнять параллельные DML­операции.

Этапы подготовки и завершения длятся недолго. Они не зависят от такого фактора, как объем данных. Во время прохождения этих двух коротких этапов, табличные или индексные данные недоступны для параллельных DML­операций. Теперь давайте рассмотрим эти три этапа подробно.

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