Обзор основных причин повреждения базы данных

Обзор основных причин повреждения базы данных

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

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

Основными причинами повреждения баз данных являются:

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

* Дефекты и неисправности серверного компьютера, особенно дисков, дисковых контроллеров, оперативной памяти компьютера и кеш-памяти RAID-контроллеров.

* Некорректное соединение с многопользовательской базой данных одного или более пользователей. При соединении по протоколу TCP/IP путь к базе данных должен указываться servername:drive:/path/databasename (для серверов на платформе Unix servernameVpath/databasename), по протоколу NetBEUI \servernamedrivepathdatabasename. Даже при соединении с базой с того же компьютера, на котором находится база и работает сервер, следует пользоваться точно такой же строкой, заменяя servername на localhost. Нельзя использовать mapped drive в строке соединения. При нарушении любого из этих правил сервер считает, что он работает с разными базами, и повреждение базы данных гарантировано.

* Файловое копирование или другой файловый доступ к базе данных при запущенном сервере. Выполнение команды shutdown или отключение пользователей обычным порядком не является гарантией того, что сервер ничего не делает с базой; если sweep interval не установлен в 0, может выполняться sweep. Кроме того, после отключения последнего пользователя сервер выполняет уборку "мусора" Обычно на это уходит 1-2 мин. но. если перед этим выполнялось много операций delete или update, процесс может затянуться.

* Использование нестабильных серверов InterBase 5.1-5.5. Компания Borland официально признала наличие в этих серверах серьёзных ошибок и выкладывала на своём сайте для бесплатного скачивания покупателями серверов 5.1 - 5.5 стабильный upgrade 5.6 убранный только после выпуска сертифицированного InterBase 6.

* Превышение ограничения на размер файла базы. Для большинства существующих на момент написания этих строк серверов Unix-платформы это 2 Гбайт, для Windows NT/2000 - 4 Гбайт, но рекомендовано ориентироваться также на 2 Гбайт. При приближении размера базы к граничному значению должен быть создан дополнительный файл.

* Исчерпывание свободного дискового пространства во время работы с базой.

* Для Borland InterBase-серверов версий меньше 6.0.1.6 превышение ограничения на количество генераторов, по сообщению Borland InterBase R&D, определяемое следующим образом (см. таблицу 4.9).

Табл 4.9. Критическое количество генераторов в InterBase ранних версий

Версия

Размер страницы, байт

1024

2К

4К

Pre-V6

248

504

1016

V6

124

257

508

* Для всех серверов Borland InterBase превышение допчсжмого количества транзакций без выполнения backup/restore. Узнать количество транзакций, произошедших в базе чанных с момента последнего создания (или restore), можно с помощью вызова утилиты gstat с ключом —h, параметр NEXT TRANSACTION ID будет искомым числом транзакций. По сообщению Ann W. Harrison, критическое количество транзакций зависит от размера страницы и имеет следующие значения (см. таблицу 4.10).

Табл 4.10. Критическое количество транзакций в серверах Borland InterBase

Размер страницы базы данных, байт

Критическое число транзакций

1024

131 596287

2048

265814016

4096

534 249 472

8192

1 071 120 384

Перечисленные выше ограничения серверов Borland InterBase не распространяются на сервера Firebird за исключением самых ранних версий 0.x, существование которых стало уже историей. Если вы используете окончательный) версии (релиз) Firebird 1.0 или InterBase 6.5, то вам не следует беспокоиться о пп. 5, 6, 8 и 9, а надо сосредоточить свои усилия на остальных причинах. Сейчас мы подробно рассмотрим наиболее частые из них.

Отключение питания

При отключении питания на компьютере-сервере все процессы обработки данных прерываются в самых неожиданных и (согласно закону Мерфи) опасных местах. В результате информация в базе данных может исказиться или вовсе пропасть Самый простой случай, когда в результате отключения питания все неподтвержденные данные из пользовательских программ-клиентов пропали. После восстановления питания сервер просматривает данные, видит незавершенные транзакции не привязанные ни к одному из "живых" клиентов, и откатывает все изменения, проведенные в рамках этих "погибших" транзакций. Собственно, такое поведение является нормальным и изначально предполагаемым разработчиками InterBase. Однако отключение питания не всегда сопровождается лишь такими незначительными потерями. Если сервер в момент отключения питания производил расширение базы данных, то велик риск получить "потерянные" страницы в файле базы данных (orphan pages), т. е. такие страницы, которые физически распределены и зарегистрированы на страницах учета страниц (PIP), но запись данных на которые невозможна. Подробнее о потерянных страницах см. ниже главу "Структура базы данных InterBase". Бороться с потерянными страницам в файле-базы данных умеет только инструмент починки и модификации gfix, который мы подробнее рассмотрим ниже. Собственно, потерянные страницы приводят только к излишнему расходу дискового пространства и как таковые не служат причиной потери или порчи данных. Но потеря питания приводит и к более серьезным повреждениям.

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