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

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

  1. Как давно были созданы мои последние резервные копии?
  2. Имеются ли резервные копии всех моих баз данных (требующих восстановления)?
  3. Соответствует ли частота снятия резервных копий моим требованиям и стандартам?
  4. Придерживаюсь ли я корректной процедуры резервного копирования в контексте режима восстановления своей базы данных SQL?

На все эти вопросы я могу ответить с помощью одного запроса.

Запрос для определения времени выполнения резервных копий

Метаданные, касающиеся резервных копий, хранятся в системной базе данных SQL Server msdb. Всего существует четыре основных системных представления; для данного запроса нам понадобится два из них.

  • msdb.dbo.backupset. Это представление содержит основные метаданные по предыстории снятия резервных копий, включая сведения о времени формирования соответствующей резервной копии, имени выполнявшего эту операцию сотрудника, о типе резервной копии, ее размере и о том, подвергались ли данные сжатию; регистрационный номер транзакции в журнале, позволяющий воссоздавать цепочку резервирования для обеспечения порядка восстановления и многие другие данные.
  • msdb.dbo.backupmediafamily. Данное представление содержит сведения о месте расположения резервных файлов, созданных в процессе резервного копирования.

Кроме того, я использую хранящееся в главной базе данных системное представление sys.databases, которое позволяет идентифицировать режим восстановления базы данных (обеспечивает ли этот режим регистрацию транзакций, дающую возможность восстановления базы на определенный момент?). Наряду с этим мне нужно использовать соединение LEFT JOIN между представлением sys.databases и представлениями предыстории резервного копирования, чтобы идентифицировать базы данных, существующие в соответствующем экземпляре SQL Server, но не снабженные списками последних мероприятий по резервному копированиию, то есть базы данных с риском потери содержащихся в них сведений.

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

Во главе запроса размещается обобщенное табличное выражение. Оно, в сущности, формирует виртуализованное результирующее множество, которое может быть повторно использовано на протяжении оставшейся части сценария. Это выражение включает в себя всю информацию, касающуюся имени базы данных и режима восстановления из представления sys.databases, и объединяет эти результаты с данными dbo.backupset, чтобы представить тип резервной копии и дату ее формирования с помощью имеющихся метаданных по резервной копии, хранящихся в msdb. Для упорядочения результатов по датам формирования резервных копий от последних до самых первых и переустановления этого значения для каждого сочетания имени базы данных и типа резервной копии я...

Это не вся статья. Полная версия доступна только подписчикам журнала. Пожалуйста, авторизуйтесь либо оформите подписку.
Купить номер с этой статьей в PDF