Статья
09/28/2010

Подготовка к аварийному восстановлению

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

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

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

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

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

Модели восстановления SQL Server

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

Базовые сведения о моделях восстановления см. в разделе Обзор моделей восстановления.

Управление носителем резервной копии

Рекомендуется включить в план восстановления возможности управления носителем резервной копии, такие как следующие:

план наблюдения и управления за хранением и утилизацией резервных наборов данных;
расписание перезаписи носителя резервной копии;
в многосерверной среде — решение о централизованном или распределенном резервном копировании;
средства наблюдения за ресурсом носителя;
процедура для минимизации последствий при утере резервного набора данных или носителя резервной копии (например потеря магнитной ленты);
решение о хранении резервных наборов данных вне офиса и анализ того, как это повлияет на время восстановления.

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

Выполнение сценария базовой функциональности

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

Сценарий базовой функциональности всегда зависит от конкретного приложения и может иметь различные формы. Например, для системы поддержки принятия решений или системы формирования отчетов таким сценарием могут оказаться всего несколько запросов на формирование ключевых отчетов. Для системы оперативной обработки транзакций (OLTP) этот сценарий может выполнять пакетные хранимые процедуры, которые вызывают инструкции INSERT, UPDATE и DELETE. Например, сценарием базовой функциональности может быть SQL-файл, который посылает серверу пакетные инструкции SQL с помощью программы sqlcmd. Другим примером является использование BAT-файла, содержащего команды bcp и sqlcmd.

Проверка степени готовности к аварийным ситуациям

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

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

Храните системные журналы в безопасном месте. Ведите учет всех устанавливаемых пакетов обновления Microsoft Windows и SQL Server. Ведите учет используемых сетевых библиотек и режима безопасности. Кроме того, если SQL Server использует смешанный режим проверки подлинности (режимы проверки подлинности SQL Server и Windows), запишите пароль sa в безопасном месте. Дополнительные сведения см. в разделе Защита и обеспечение безопасности (компонент Database Engine).

Важно!
Проверка подлинности Windows намного надежнее, чем проверка подлинности SQL Server. При возможности используйте проверку подлинности Windows.

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

Аудит и предотвращение потенциально катастрофических ошибок, вызываемых действиями пользователей

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

Триггеры языка определения данных (DDL).

Триггеры DDL могут создаваться для аудита или регулирования определенных изменений в схеме базы данных. Триггеры DDL вызывают хранимые процедуры в ответ на ряд инструкций языка DDL. Эти инструкции в основном начинаются ключевыми словами CREATE, ALTER и DROP. Областью действия триггера DDL является либо конкретная база данных, либо весь экземпляр сервера. Дополнительные сведения см. в разделе Основные сведения о триггерах DDL.

Уведомления о событиях.

Уведомления о событиях выполняются в ответ на разнообразные инструкции языка определения данных (DDL) Transact-SQL и на события SQL Trace. Уведомления отправляют сведения об этих событиях службе компонента Service Broker.

Уведомления о событиях могут быть запрограммированы для многих одинаковых событий, зафиксированных SQL Trace. Но, в отличие от создания трассировок, уведомления о событиях могут быть использованы для выполнения действий в ответ на события внутри экземпляра SQL Server. Поскольку уведомления о событиях выполняются асинхронно, эти действия не потребляют ресурсы, определенные немедленной транзакцией. Дополнительные сведения см. в разделе Уведомления о событиях (компонент Database Engine).

Примечание
Не все DDL-события можно использовать в триггерах DDL. Некоторые события предназначены только для асинхронных инструкций, не входящих в транзакции. Например, в триггере DDL невозможно использовать событие CREATE DATABASE. Для таких событий следует применять уведомления о событиях.

Не все DDL-события можно использовать в триггерах DDL. Некоторые события предназначены только для асинхронных инструкций, не входящих в транзакции. Например, в триггере DDL невозможно использовать событие CREATE DATABASE. Для таких событий следует применять уведомления о событиях.

Агент SQL Server.

Агент — это служба Microsoft Windows, выполняющая запланированные административные задачи, которые называются заданиями. Агент SQL Server использует SQL Server для хранения сведений о заданиях. Помимо прочего, агент SQL Server может выполнять задание в ответ на определенное событие, например в ответ на ошибку с указанной степенью серьезности или номером сообщения.

Основные сведения об агенте SQL Server см. в разделе Автоматизация задач администрирования (агент SQL Server). Сведения об использовании агента SQL Server для событий см. в разделе Наблюдение и обработка событий.

SQL Trace.

SQL Trace предоставляет системные хранимые процедуры Transact-SQL для создания трассировок выбранных пользователем классов событий в экземпляре SQL Server Database Engine. Эти системные хранимые процедуры можно использовать для создания трассировок вручную в рамках пользовательских приложений. Дополнительные сведения см. в разделе Знакомство с SQL Trace.

Примечание
Приложение SQL Server Profiler — это графический пользовательский интерфейс для SQL Trace, с помощью которого можно наблюдать за экземпляром компонента Database Engine или службой Analysis Services. Дополнительные сведения см. в разделе Работа с приложением SQL Server Profiler.

Приложение SQL Server Profiler — это графический пользовательский интерфейс для SQL Trace, с помощью которого можно наблюдать за экземпляром компонента Database Engine или службой Analysis Services. Дополнительные сведения см. в разделе Работа с приложением SQL Server Profiler.