Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ - Хелен Борри

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

Синтаксис

Используйте следующий синтаксис DROP SHADOW:

DROP SHADOW номер-набора-теневой-копии;

Номер набора теневой копии является обязательным аргументом команды DROP SHADOW. Для отыскания этого номера используйте в isql команду SHOW DATABASE, будучи подключенным к этой базе данных.

В следующем примере удаляются все файлы, связанные с набором оперативной копии за номером 25:

DROP SHADOW 25;

Использование gfix-переключателя -kill

Служебная утилита командной строки gfix (см. главу 39) имеет переключатель -kill, который внутренне вызывает команду DROP SHADOW, чтобы удалить теневую копию и сделать ее недоступной. После выполнения этой команды можно будет продолжить создание новых теневых копий.

Например, для удаления недоступной теневой копии нашей базы данных employee в POSIX наберите:

[[email protected] bin]# ./gfix -kill ../examples/employee.gdb -user SYSDBA

-password masterkey

В Win32 наберите:

C:Program FilesFirebirdbin> gfix -kill ..examplesemployee.gdb

-user SYSDBA -password masterkey

"Гигиена" базы данных

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

Фоновая сборка мусора

Для ограничения такого разрастания Firebird постоянно выполняет сборку мусора (garbage collection) на фоне активности базы данных.

Фоновая сборка мусора ничего не делает с устаревшими версиями записей, которые относятся к незавершенным транзакциям - они не будут обработаны в процессе обычных служебных действий. Для полной санации базы данных Firebird может выполнять чистку базы данных (database sweeping).

Чистка базы данных

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

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

Ручная чистка может быть инициирована из служебной программы командной строки gfix. Подробности см. в главе 39. Некоторые другие инструменты обеспечивают графический интерфейс для инициирования ручной чистки.

Интервал очистки

Сервер Firebird поддерживает инвентаризацию транзакций. Самая старая из транзакций, которые помечены в инвентарном списке как завершенные по rollback, называется "старейшей заинтересованной" (Oldest Interesting Transaction, OIT, или Oldest transaction), и обозначает начальную точку для интервала очистки. Если интервал очистки больше нуля, Firebird запускает полную чистку базы данных, когда разница между OIT и транзакцией Oldest snaphsot превышает порог, установленный для интервала очистки.

Инструкции см. в главе 39.

Сборка мусора в процессе резервного копирования

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

! ! !

ВНИМАНИЕ! Резервное копирование не является заменой чистки. Когда резервное копирование выполняет полную сборку мусора в базе данных, оно не очищает учетные записи транзакций, как это делает чистка. Эффекты от чистки - или от игнорирования ее выполнения - обсуждаются в нескольких разделах главы 25.

. ! .

Информацию о преимуществах резервного копирования и восстановления см. в главе 38.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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