Книга: Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil

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

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

К сожалению, всегда существует ненулевая вероятность, что любое информационное хранилище будет повреждено и часть информации из него потеряна. Базы данных не исключение из этого правила. В этой главе мы рассмотрим основные причины, которые чаще всего приводят к повреждениям базы данных 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 ранних версий

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

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

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

Оглавление книги