Восстановление базы данных после жесткого сбоя

SELECT ID, COUNT(*) FROM TABLE

GROUP BY ID

HAVING (COUNT(*)) > 1

где id - столбец, по которому есть не создаваемый  уникальный индекс. После этого можно  активировать индексы, которые не были восстановлены.

5. Повреждения таблиц

Нормальная база данных - это не набор отдельных таблиц. Таблицы  между собой могут быть достаточно сильно взаимосвязаны, вплоть до циклических  ссылок. Поэтому даже один и тот  же тип и объем повреждения  может иметь разные последствия, в зависимости от того, с какой таблицей это произошло. Типичный пример: таблица CLIENTS - справочная, а ORDERS - оперативная. Если пропадет часть записей из ORDERS, то после починки БД будет нормально функционировать. Если же будет повреждена CLIENTS, то после починки в ORDERS будут записи, ссылающиеся на несуществующих клиентов. Таким образом БД вроде бы будет отремонтирована, но логическая целостность данных будет нарушена. Бороться с этой ситуацией никак невозможно, разве что чаще делая backup (поскольку справочники меняются реже, чем оперативные данные). Подобная ситуация (с повреждением master-таблицы) может возникнуть даже в том случае, если все записи пакета master-detail вставляются в одной транзакции, а Forced Write выключен (off) - страницы с записями detail могут быть записаны на диск операционной системой из кэша раньше, чем соответствующие им записи таблицы master. Это не приводит к "невосстановимому backup", но после restore придется или добавлять недостающие master-записи, или удалять "осиротевшие" detail-записи (в зависимости от сложности триггеров, обрабатывающих вставку в master или удаление в detail. Возможно, такие триггеры на время ремонта данных нужно будет отключить).

Также, в подобной ситуации, при restore отремонтированной базы данных могут оказаться неактивными индексы по Foreign Key соответствующих связей master-detail. Активировать их можно после упомянутых вставок или удалений master/detail, путем установки rdb$indices.rdb$index_inactive в 0.

7. Стихийные и техногенные  бедствия

Шторм, землетрясение, воры, пожар, прорыв водопровода — всё это приводит к потере всех носителей данных, расположенных на определённой территории. Данная причина потери данных бывает очень редко, но она имеет место.

Единственный способ защиты от стихийных  бедствий — держать часть резервных копий в другом помещении.

8. Вредоносные программы

В эту категорию входит случайно занесённое ПО, которое намеренно  портит информацию — (вирусы, черви, «троянские кони»). Иногда факт заражения обнаруживается, когда немалая часть информации искажена или уничтожена.

Решением этой проблемы будет:

• установка антивирусных программ на рабочие станции. Простейшие антивирусные меры — отключение автозагрузки, изоляция локальной сети от Интернета, и т. д.;
• обеспечение централизованного обновления: первая копия антивируса получает обновления прямо из Интернета, а другие копии настроены на папку, куда первая загружает обновления; также можно настроить прокси-сервер таким образом, чтобы обновления кешировались (это всё меры для уменьшения трафика);
• иметь копии в таком месте, до которого вирус не доберётся — выделенный сервер или съёмные носители;

Если копирование идёт на сервер: обеспечить защиту сервера от вирусов (либо установить антивирус, либо использовать ОС, для которой вероятность заражения мала). Хранить версии достаточной давности, чтобы существовала копия, не контактировавшая с заражённым компьютером.

Если копирование идёт на съёмные  носители: часть носителей хранить (без дописывания на них) достаточно долго, чтобы существовала копия, не контактировавшая с заражённым компьютером.

9. Человеческий фактор

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

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

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

Хранить версии достаточной давности, чтобы при обнаружении испорченных данных файл можно было восстановить.

Перед переустановкой ОС следует обязательно  копировать всё содержимое раздела, на которой будет установлена  ОС, на сервер, на другой раздел или  на CD / DVD.

Оперативно обновлять ПО, которое заподозрено в потере данных.

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

Заключение

Процесс восстановления данных - важнейшая операция в SQL Server. Восстановить данные не так сложно, как представлялось раньше, особенно с помощью графического интерфейса утилиты Enterprise Manager. Затруднение вызывает только восстановление поврежденной базы данных master.

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

Резервное копирование необходимо для возможности быстрого и недорогого восстановления информации в случае поломки рабочей копии базы по какой-либо причине.

Список литературы

1. Ковязин А.Н., Востриков С.М. "Мир Interbase", М.: Кудиц-Образ, 2002г.
2. Крис Касперски «Восстановление данных. Практическое руководство» Спб.: БХВ-Петербург, 2007г.
3. Леонов Василий. «Восстановление данных». М.: Эксмо, 2009 г.
4. Михеев Ростислав «MS SQL Server 2008 для администраторов». Спб.: БХВ-Петербург, 2007г.
5. Уильям Р. Станек «Microsoft SQL Server 2008. Справочник администратора». М.: Русская Редакция, 2008 г.