SQL в вопросах и ответах: Резервное копирование и установка

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

Ответ: Во-1-х, это замечательно, что вы проводите тестирование на репрезентативных клиентских данных. Много раз я лицезрел, как поставщики многоуровневых приложений тестировали такового рода сценарии только на маленьких наборах данных, после этого клиенты безизбежно сталкивались с массой заморочек. Я отвечу на ваш вопрос так, как будто вы юзер. Так вы можете посмотреть на делему очами собственных клиентов.

Вы гласите, что вам необходимо придерживаться модели полного восстановления. Это значит, вы уже используете запасные копии журнальчика транзакций и в общем случае у вас нет заморочек с неконтролируемым ростом журнальчика транзакций. Это отлично, так как внедрение запасных копий журнальчика транзакций — единственная процедура, позволяющая очищать журнальчик после фиксации транзакций. (Подробные сведения об этом см. в статье technet.microsoft.com/magazine/2009.02.logging, в какой разъясняется работа журнальчика транзакций и различное воздействие моделей восстановления на его поведение.)

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

Если ваш сценарий обновления запускается каждый час при том, что журнальчик транзакций возрастает за полчаса до 20 ГБ, то файлы журнальчика транзакций должны быть размером в 20 ГБ. Но это все равно очень много, так что придется делать запасное копирование журнальчика транзакций почаще. Это позволит почаще очищать журнальчик транзакций и не допускать его неконтролируемого роста. У нас была подобная ситуация у клиента, и в итоге пришлось делать запасное копирование журнальчика транзакций ежеминутно в течение нескольких часов, пока аналогичный сценарий обслуживал огромную базу данных.

Необходимо подразумевать один аспект:эти «лишние» запасные копии журналов транзакций являются частью цепочки запасных копий журнальчика и нужны для восстановления в случае сбоя. Похлопочите, чтоб у всех у их были осмысленные имена и чтоб ни какой-то из них не удалялся.

Нужно учитывать другое событие: каковой размер самой большой транзакции, происходящей во время вашего процесса обновления? Журнальчик транзакций может быть очищен только от записей зафиксированных транзакций (мы мало упрощаем, подробнее см. в данной). Это значит, что занимающая долгое время транзакция не позволяет очистить журнальчик, хотя запасное копирование журнальчика транзакций все это время работает.

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

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

Феномен конфигурации

Вопрос: Мы устанавливаем новые хранилища с конкретным подключением на одном из наших серверов баз данных и желаем знать все доступные нам способности, чтоб сделать очень правильную конфигурацию. Не могли бы вы поведать, какие варианты конфигурации вероятны, когда дело касается использования SQL Server?

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

1-ое — уровень RAID. Каждый уровень RAID — это компромисс меж производительностью и избыточностью. К примеру, самой дешевенькой конфигурацией RAID, обеспечивающей какую-никакую избыточность, является RAID-5. Но эта конфигурация обеспечивает защиту от отказа только 1-го из дисков (если только не использовать RAID-6 либо конфигурацию дисками жаркой подмены) и характеризуется низкой производительностью в режимах с доминированием операций записи при определенном количестве дисков в массиве.

RAID-10 обеспечивает высшую избыточность, но это решение дороже. Общий объем массива составляет не более половины суммарного размера входящих в его состав дисков. В TechNet есть не плохая статья о разных уровнях RAID — это «белая книга» «Physical Database Storage Design».

Другое принципиальное событие — размер блоков чередования в RAID, размер блоков NTFS (размер кластера) и выравнивание разделов на диске. Если эти характеристики задать ошибочно, может быть существенное понижение производительности. Более принципиально выравнивание разделов на диске на дисковых томах, сделанных при помощи Windows Server 2003. При всем этом употребляется выравнивание по дефлоту размером 31,5 КБ, что отличается от принятого размера блока данных RAID равного 64 КБ (либо кратного данной величине). Таким макаром, в каждой операции ввода/вывода должно производиться чтение либо запись 2-ух блоков 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».

Свет мой, зеркало…

Вопрос: Мне не совершенно понятна роль следящего сервера при настройке зеркального отображения базы данных. Как массивным он должен быть? Зависит ли это от количества баз данных, отказоустойчивость которых он обеспечивает? Имеет ли значение, в каком из центров обработки данных располагается следящий сервер? Я желаю быть уверенным в наибольшей доступности зеркальных баз данных.

Ответ: Недопонимание роли следящего сервера в системе зеркального отображения базы данных встречается очень нередко. Следящий сервер в конфигурации синхронной зеркальной базы данных существует только для облегчения автоматического перехода в случае отказа основного сервера.

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

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

Так как следящий сервер не обрабатывает и не хранит данные, он не должен быть массивным. На этом сервере можно установить всякую версию SQL Server, даже SQL Server Express Edition. Также нет ограничений на число сеансов зеркального отображения баз данных, в каких определенный экземпляр SQL Server может выступать в качестве следящего сервера.

Следящий сервер лучше располагать в отдельном от основного либо зеркального серверов центре обработки данных. Но практически у всех компаний нет 3-х центров обработки данных, потому вопрос размещения следящего сервера, сводится к выбору:вкупе с зеркальным либо с главным сервером.

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

В отсутствие кворума полностью «здоровый» основной сервер может перейти в автономный режим. В данном случае подразумевается, что на зеркале начнется переход. Для предотвращения схожей ситуации основной и следящий сервер располагают совместно, чтоб сохранить их кворум в случае отказа сети. Основная база данных остается доступной.

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

В сеансе зеркального отображения базы данных можно сделать два следящих сервера. Единственный метод дополнительно повысить избыточность роли следящего сервера — расположить экземпляр следящего сервера SQL Server на отказоустойчивом кластере. Подробнее о конфигурациях зеркального отображении базы см.«белую книгу» «Database Mirroring in SQL Server 2005».

Связанные материалы

Перенос, настройка производительности, запасное копирование и зеркалирование баз данных
Распределенные транзакции, счетчики производительности и запасные копии SQL
Согласованность базы данных, временные таблицы и почти все другое

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.