Администрирование InterBase: обслуживание БД

Утилита командной строки gfix

Эта утилита является одним из основных инструментов администратора БД. Утилита gfix позволяет:

• Выполнять принудительную чистку ( sweep ) базы данных;
• Изменять интервал автоматической чистки;
• Закрывать базу данных для получения монопольного доступа, и затем снова открывать ее;
• Переводить базу в режимы "чтение/запись" или "только чтение";
• Переключаться между синхронным и асинхронным вводом ( Forced Writes );
• Изменять диалект БД;
• Устанавливать размер кэша;
• Отыскивать повисшие транзакции и отменять или подтверждать их;
• Активировать или удалять теневые копии ;
• Производить ремонт поврежденных баз данных.

Синтаксис утилиты очень простой:

gfix [параметры] <база данных>;

Все параметры утилиты приведены в следующей таблице:

Чистка sweep происходит в фоновом режиме и может выполняться параллельно работе пользователей. Этот способ более предпочтителен, чем чистка gbak при восстановлении БД. Утилита gbak не делает полной чистки, так как остаются версии удаленных записей и записей отмененных транзакций. Принудительную чистку можно сделать так:

gfix -sweep c:\databases\first.gdb -user sysdba -pa masterkey

Чистка базы данных происходит автоматически через определенное количество (по умолчанию 20 000) транзакций. Расчет интервала делается из старейшей транзакции, зарегистрированной в области TIP (Инвентарная страница транзакций), и из старейшей активной транзакции. Когда инвентарный номер старейшей активной транзакции окажется больше на указанный интервал, чем инвентарный номер старейшей зарегистрированной в TIP транзакции, произойдет автоматический запуск чистки. Изменить интервал на 10 000, например, можно так:

gfix -h 10000 c:\databases\first.gdb -user sysdba -pa masterkey

Если же вместо 10 000 указать 0, автоматическая чистка для данной БД вообще будет отменена. Как уже говорилось, чистка не требует монопольного доступа к базе данных, однако если БД очень большая, и много пользователей интенсивно с ней работают, чистка может заметно замедлить работу с БД. В этом случае, перед чисткой рекомендуется вначале отключить базу данных.

Отключение базы данных делается командой - shut с одним из трех дополнительных параметров. Чтобы безусловно отключить базу данных через 10 минут, выполните команду:

gfix -sh -force 600 c:\databases\first.gdb -user sysdba -pa masterkey

Однако такой радикальный способ рекомендуется использовать с осторожностью: пользователи, которые на этот момент продолжали работу с БД, потеряют результаты своей работы. Вначале вместо " -force " лучше попробовать более "мягкие" дополнительные параметры " -attach " или " -tran ".

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

gfix -o c:\databases\first.gdb -user sysdba -pa masterkey

Кэш (или буфер) - это оперативная память, выделяемая сервером для работы с базой данных. Операции в оперативной памяти происходят гораздо быстрее, чем если данные постоянно считываются с диска. Размер кэша указывается в страницах БД. Если размер страницы установлен 8192, то кэш в 5000 страниц займет примерно 40 мегабайт ОЗУ. По умолчанию, InterBase использует кэш в 75 страниц. Если сразу много пользователей одновременно обращаются к базе данных, может случиться, что серверу не хватит выделенной оперативной памяти. В этом случае он начнет работать с диском, что замедлит производительность БД. Изменить размер кэша для базы данных на 300 страниц можно так:

gfix -b 300 c:\databases\first.gdb -user sysdba -pa masterkey

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

c:\program files\borland\interbase\ibconfig

Это обычный текстовый файл, в котором все параметры закомментированы (первым символом идет "#"). Нужно снять комментарий, и установить новое значение нужного параметра. То есть, вместо

#DATABASE_CACHE_PAGES           75

указать

DATABASE_CACHE_PAGES           300

Однако более предпочтительным способом для этих целей является утилита gfix, так как она позволяет установить собственный размер кэша для каждой базы данных. Если какой то БД пользуются реже, размер кэша для нее можно оставить по умолчанию, или даже уменьшить.

База данных может работать в одном из двух режимов доступа: только для чтения, или для чтения / записи (по умолчанию). Если вам понадобилось запретить пользователям модифицирование данных, вы можете поменять режим командой:

gfix -mo read_only  c:\databases\first.gdb -user sysdba -pa masterkey

Операции изменения режима занимают время! Не забудьте потом вернуть режим read_write, иначе пользователи не смогут вносить изменения в БД.

Режимы Forced Writes требуют особого пояснения. Forced Writes, или режим синхронного ввода, определяет, как будет происходить работа с БД. При включенном Forced Writes добавление новых записей, удаление старых, появление новых версий записей сразу же физически сохраняется на диске. При отключенном синхронном вводе сервер InterBase возлагает это на операционную систему: физическое сохранение изменений происходит позже - когда переполнится буфер, или когда ОС решит, что компьютер долго простаивает. Отключение Forced Writes следует делать лишь на очень надежных машинах, с обязательным источником бесперебойного питания ( UPS ). Ведь может случиться, что физической записи на диск не происходит целый день, а при сбое системы или отключении питания потеряются результаты всей работы! Отключенный режим немного увеличивает скорость работы с БД, однако данные становятся менее защищенными.

По умолчанию, все БД работают с включенным Forced Writes и отключать этот режим не рекомендуется. Если все же вы не удовлетворены производительностью БД, и при этом стопроцентно уверены в своем серверном ПК, можете попробовать отключить Forced Writes командой:

gfix -w async c:\databases\first.gdb -user sysdba -pa masterkey

Команда

gfix -v c:\databases\first.gdb -user sysdba -pa masterkey

выведет на экран все неназначенные страницы, которые являются мусором. Если на экран ничего не вышло, значит, таких страниц в БД нет.

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

gfix - ac d:\databases\first.shd -user sysdba -pa masterkey

Рекомендации по ремонту поврежденных баз данных

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

1. Прежде всего, отключите от базы всех пользователей, не позволяйте им вносить изменения в БД.
2. Сделайте копию рабочей базы данных средствами файловой системы ( gbak не сможет выполнить резервное копирование с разрушенными данными). Все попытки восстановления делайте с полученной копией, не трогая оригинал.
3. Проведите полную проверку ( gfix -v -full <база данных> <пользователь> <пароль> ). Если выводятся сообщения об ошибках контрольных сумм, можно добавить переключатель - i, чтобы игнорировать эти ошибки.
4. Далее можно попытаться исправить разрушенные данные, помечая их как недоступные:

   gfix -mend -full -ignore <база данных> <пользователь> <пароль>
5. После этого вновь выполните проверку на наличие разрушенных структур, как в № 3, но без - i.
6. Затем попробуйте снова выполнить резервное копирование утилитой gbak, например:

   gbak -b -v -i <база данных> <резервная копия> <пользователь> <пароль>
7. Если это удалось, то все хорошо. Иначе попробуйте сделать еще одно резервное копирование, добавив параметр - g (не собирать мусор). Если разрушения связаны с повисшими limbo -транзакциями, то - limbo.
8. В большинстве случаев, такие меры позволяют сделать нормальную резервную копию. Попробуйте восстановить ее командой

   gbak -create -v <резервная копия> <база данных> <пользователь> <пароль>

Как правило, такой порядок действий позволяет восстановить разрушенную БД. Если же этого не случилось, попробуйте использовать другие переключатели. Например, - inactive у утилиты gbak делает неактивными индексы, и если разрушены именно они, восстановление удастся. Параметр - one_at_a_time будет восстанавливать по одной записи за раз, что позволит восстановить целые таблицы, и пропустить поврежденные.

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