Проверка и ремонт

Проверка и ремонт

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

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

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

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

Когда проверять достоверность и зачем

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

* ошибки "corrupt database" или "consistency check";

* резервное копирование, которое закончилось ненормально;

* отказ или изменение напряжения электропитания при отсутствии источника бесперебойного питания (UPS) или при предположении об отказе UPS;

* предполагаемые или сообщенные системой ошибки жесткого диска, сети или памяти;

* теневая копия заменяет собой базу данных после разрушения диска;

* база данных была перенесена с другой платформы или системы хранения;

* ожидаемое несанкционированное обращение к сети или базе данных со стороны внешних атак.

Подробности использования gfix для выполнения проверки базы данных см. в главе 39.

Что делать с разрушенной базой данных

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

В приложении 4 содержится подробное описание процедур починки разрушенной базы данных.

Как разрушить базу данных Firebird

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

Модификация системных таблиц

Firebird хранит и ведет все свои метаданные и ваши определенные пользователем объекты в... базе данных Firebird! Более точно он хранит их в отношениях (таблицах) прямо в самой базе данных. Идентификаторы системных таблиц, их столбцов и некоторых других типов системных объектов начинаются с символов "RDB$".

Поскольку это обычные объекты базы данных, их можно запрашивать и манипулировать ими как определенными пользователем объектами. Однако то, что вы можете., не означает, что вы должны.

Нельзя настоятельно рекомендовать, чтобы вы использовали только операторы DDL - непрямые операции SQL над системными таблицами - всякий раз, когда вам нужно изменять или удалять метаданные. Отложите всякие "прямые изменения", пока ваши умения в SQL и ваши знания сервера Firebird не станут более полными. Потерпевшая аварию база данных не является ни предметом приятного созерцания, ни легкой в починке.

Отмена принудительной записи для Firebird 1.0.x в Windows

Firebird по умолчанию устанавливается с возможностью принудительной записи (forced writes, синхронной записью). Измененные и новые данные записываются на диск немедленно после завершения операции (post).

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

Сервер платформ Win32 не сохраняет на диск кэш сервера Firebird 1.0.x, пока не будет закрыт сервис Firebird. Не говоря уже о сбое в питании, может много чего плохо- го произойти с сервером Windows. Если он зависнет, система ввода/вывода прекратит работу, и работа вашего пользователя будет потеряна в процессе перезагрузки.

Серьезное предупреждение: не отключайте принудительную запись на сервере Windows, если вы не используете Firebird 1.5 и выше.

Firebird 1.5 по умолчанию сбрасывает кэш на диск каждые 5 секунд или каждые 100 операций записи- что произойдет быстрее. Эта частота может быть изменена В firebird.conf корректировкой одного или двух параметров MaxUnflushedWrites и MaxUnflushedWriteTime.

Windows 95 не поддерживает асинхронную запись на диск.

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

Восстановление резервной копии в работающую базу данных

Один из режимов восстановления в утилите gbak (gbak -r[estore]) позволяет восстанавливать файл резервной копии поверх существующей базы данных - база данных перезаписывается. В этом режиме возможно восстановление без предупреждения о том, что пользователи соединены с базой данных. Разрушение базы данных является практически гарантированным результатом.

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

Чтобы сделать это практически, рекомендуется восстанавливать базу на резервное дисковое пространство, используя gbak -с[reate]. Прежде чем сделать восстановленную базу данных активной, проверьте ее в резервной области, используя isql или ваш предпочитаемый инструмент администратора.

Разрешение пользователям соединяться с базой данных в процессе ее восстановления

Если вашей организации нравится жить на острие ножа, используйте переключатель -restore и позвольте пользователям соединяться с базой данных и выполнять изменения. Процесс восстановления создает базу данных с нуля, и как только будут созданы таблицы, ваши пользователи смогут (по крайней мере, потенциально, или если они все SYSDBA) обращаться к ним с операциями DML, в то время как ссылочная целостность и другие ограничения находятся еще только на подходе. В лучшем случае они получат исключения и кучу неподтвержденных транзакций в частично сконструированной базе данных. В худшем, они полностью уничтожат целостность данных.

Копирование файлов базы данных, в то время как с ней соединены пользователи

Используйте любую утилиту копирования или архивирования файловой системы (DOS copy, xcopy, tar, gzip, WinZip, WinRAR и т.д.) для копирования файлов базы данных, в то время как с ней соединены любые пользователи (включая SYSDBA). Копия будет поврежденной, но еще хуже, система блокировки и/или кэширования этих программ может привести к потере данных и, возможно, к разрушению исходного файла.