Вопрос:Наш продукт использует SQL Server для хранения данных. Время от времени мы выпускаем новую версию нашего продукта, который включает в себя обновленный сценарий для запуска в базе данных. В процессе тестирования последней версии сценария обновления на репрезентативной тестовой базе данных, размер файла журнала транзакций превысил 40 ГБ. Мы бы хотели предотвратить такой стремительный рост журнала. Какие у нас есть варианты? Мы не можем отказаться от использования модели полного восстановления для восстановления после сбоев.
Ответ: Во-первых, это замечательно, что вы проводите тестирование на репрезентативных клиентских данных. Много раз я видел, как поставщики многоуровневых приложений тестировали такого рода сценарии лишь на небольших наборах данных, после чего клиенты неизбежно сталкивались с массой проблем. Я отвечу на ваш вопрос так, будто вы пользователь. Так вы сможете взглянуть на проблему глазами своих клиентов.
Вы говорите, что вам нужно придерживаться модели полного восстановления. Это означает, вы уже используете резервные копии журнала транзакций и в общем случае у вас нет проблем с неконтролируемым ростом журнала транзакций. Это хорошо, поскольку использование резервных копий журнала транзакций - единственная процедура, позволяющая очищать журнал после фиксации транзакций. (Подробные сведения об этом см. в статье technet.microsoft.com/magazine/2009.02.logging, в которой объясняется работа журнала транзакций и различное влияние моделей восстановления на его поведение.)
С другой стороны, частота, с которой выполняется резервное копирование журнала транзакций, является фактором, определяющим, как быстро очищается журнал транзакций и ограничивается его размер. Например, если задание регулярного резервного копирования журнала транзакций выполняется каждые полчаса, файл журнала транзакций должен быть достаточными для хранения наибольшего возможного количества транзакций, созданных за эти полчаса, иначе его размер будет увеличиваться.
Если ваш сценарий обновления запускается каждый час при том, что журнал транзакций увеличивается за полчаса до 20 ГБ, то файлы журнала транзакций должны быть размером в 20 ГБ. Но это все равно слишком много, так что придется выполнять резервное копирование журнала транзакций чаще. Это позволит чаще очищать журнал транзакций и не допускать его неконтролируемого увеличения. У нас была аналогичная ситуация у клиента, и в конечном итоге пришлось выполнять резервное копирование журнала транзакций ежеминутно в течение нескольких часов, пока аналогичный сценарий обслуживал большую базу данных.
Нужно иметь в виду один нюанс:эти "лишние" резервные копии журналов транзакций являются частью цепочки резервных копий журнала и необходимы для восстановления в случае сбоя. Позаботьтесь, чтобы у всех у них были осмысленные имена и чтобы ни один из них не удалялся.
Надо учесть другое обстоятельство: каков размер самой крупной транзакции, происходящей во время вашего процесса обновления? Журнал транзакций может быть очищен только от записей зафиксированных транзакций (мы немного упрощаем, подробнее см. в данной). Это означает, что занимающая длительное время транзакция не позволяет очистить журнал, хотя резервное копирование журнала транзакций все это время работает.
Если сценарий обновления содержит транзакцию, занимающую 15 ГБ в журнале транзакций, размер последнего должен быть не менее 15 ГБ, чтобы "уместить" всю эту транзакцию. Если это так, то неважно, как часто выполняется резервное копирование журнала транзакций, - журнал транзакций не будет очищаться. Единственным выходом в этом случае является разбиение большой транзакции на несколько мелких, если это возможно.
Резюме: размер журнала транзакций, необходимого для работы сценария обновления, зависит от частоты резервного копирования журнала транзакций и размера самой крупной транзакции.
Парадокс конфигурации
Вопрос: Мы устанавливаем новые хранилища с непосредственным подключением на одном из наших серверов баз данных и хотим знать все доступные нам возможности, чтобы создать максимально правильную конфигурацию. Не могли бы вы рассказать, какие варианты конфигурации возможны, когда дело касается использования SQL Server?
Ответ: Есть множество вариантов настройки и параметров конфигурации хранилища, поэтому я предпочитаю, чтобы управлением хранением занимался выделенный администратор. Есть параметры конфигурации, о которых администратор SQL Server должен обязательно знать и позаботиться о правильной их настройке.
Первое - уровень RAID. Каждый уровень RAID - это компромисс между производительностью и избыточностью. Например, самой дешевой конфигурацией RAID, обеспечивающей какую-никакую избыточность, является RAID-5. Но эта конфигурация обеспечивает защиту от отказа только одного из дисков (если только не использовать RAID-6 или конфигурацию дисками горячей замены) и характеризуется невысокой производительностью в режимах с преобладанием операций записи при определенном количестве дисков в массиве.
RAID-10 обеспечивает высокую избыточность, но это решение дороже. Общий объем массива составляет не больше половины суммарного размера входящих в его состав дисков. В TechNet есть хорошая статья о различных уровнях RAID - это "белая книга" "Physical Database Storage Design".
Другое важное обстоятельство - размер блоков чередования в RAID, размер блоков NTFS (размер кластера) и выравнивание разделов на диске. Если эти параметры задать неверно, возможно значительное снижение производительности. Наиболее важно выравнивание разделов на диске на дисковых томах, созданных с помощью Windows Server 2003. При этом используется выравнивание по умолчанию размером 31,5 КБ, что отличается от общепринятого размера блока данных RAID равного 64 КБ (или кратного этой величине). Таким образом, в каждой операции ввода/вывода должно выполняться чтение или запись двух блоков RAID. Ясно, что это сильно снижает производительность.
В Windows Server 2008 выравнивание по умолчанию составляет 1 МБ. На томах, которые созданы в Windows Server 2003 и на которых ОС обновлена до Windows Server 2008, выравнивание не меняется и производительность не улучшается. Проблема решается только переформатированием тома, но часто выигрыш в производительности стоит того.
Подробное обсуждение этих вопросов действительно выходит за рамки данной статьи, но более подробная информация (и ссылки для дальнейшего чтения) вы найдете в моем блоге "Are your disk partition offsets, RAID stripe sizes and NTFS allocation units set correctly?"
При развертывании любого нового хранилища данных настоятельно рекомендуется проведение нагрузочных испытаний и испытаний на производительность до перевода хранилища в производственную среду. Нагрузочные испытания позволяют предотвратить ошибки конфигурации, которые могут привести к потере данных или простоям. Проверка производительности поможет проверить, обеспечивает ли новое хранилище требуемую производительность ввода / вывода в условиях нормальной рабочей нагрузки. Microsoft предлагает для этого бесплатные инструменты, о которых можно узнать больше в "белой книге" "Pre-Deployment I/O Best Practices".
Свет мой, зеркальце…
Вопрос: Мне не совсем понятна роль следящего сервера при настройке зеркального отображения базы данных. Насколько мощным он должен быть? Зависит ли это от количества баз данных, отказоустойчивость которых он обеспечивает? Имеет ли значение, в котором из центров обработки данных размещается следящий сервер? Я хочу быть уверенным в максимальной доступности зеркальных баз данных.
Ответ: Непонимание роли следящего сервера в системе зеркального отображения базы данных встречается очень часто. Следящий сервер в конфигурации синхронной зеркальной базы данных существует исключительно для облегчения автоматического перехода в случае отказа основного сервера.
Основной сервер непрерывно пересылает записи журнала транзакций на зеркальный, но никогда - на следящий сервер. Основной, зеркальный и следящий серверы проверяют связь друг с другом ежесекундно - это происходит в рамках автоматического механизма обнаружения отказов. Потеряв по какой-либо причине связь с основным сервером, зеркальный сервер не может инициировать автоматический переход, если не получит подтверждения от следящего сервера о том, что тот тоже не может связаться с основным сервером. "Согласие" этих двух серверов формирует кворум, и инициируется автоматический переход на зеркальный сервер. Если следящий сервер отсутствует, кворум невозможен, а значит, невозможен и автоматический переход.
Таким образом, следящий сервер существует исключительно для кворума. Он не инициирует переход на другой ресурс и не хранит зеркальные базы данных. Обычно кворум существует между основным и зеркальным серверами.
Поскольку следящий сервер не обрабатывает и не хранит данные, он не должен быть мощным. На этом сервере можно установить любую версию SQL Server, даже SQL Server Express Edition. Также нет ограничений на число сеансов зеркального отображения баз данных, в которых конкретный экземпляр SQL Server может выступать в качестве следящего сервера.
Следящий сервер лучше размещать в отдельном от основного или зеркального серверов центре обработки данных. Однако у большинства компаний нет трех центров обработки данных, поэтому вопрос размещения следящего сервера, сводится к выбору:вместе с зеркальным или с основным сервером.
Когда есть только два центра данных, следящий сервер должен всегда находиться с основным сервером. Причина связана с формированием кворума. Если следящий и зеркальный серверы размещаются вместе, и сетевое соединение с основным сервером нарушается, возникает кворум между следящим и зеркальным сервером, что инициирует переход.
В отсутствие кворума вполне "здоровый" основной сервер может перейти в автономный режим. В этом случае предполагается, что на зеркале начнется переход. Для предотвращения подобной ситуации основной и следящий сервер размещают вместе, чтобы сохранить их кворум в случае отказа сети. Основная база данных остается доступной.
Следящий сервер совершенно не обязателен, но без него нет возможности автоматического перехода на другой ресурс и, следовательно, получения максимальной доступности при зеркальном отображении базы данных. В остальном зеркальное отображение баз данных работает, как обычно. Если следящий сервер настроен, но по какой-то причине становится недоступным, потери функциональности зеркального отображения не возникает - пропадает только возможность автоматического перехода.