Опубликован: 07.05.2010 | Доступ: свободный | Студентов: 2866 / 291 | Оценка: 4.49 / 4.19 | Длительность: 25:58:00
Лекция 26:

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

< Лекция 25 || Лекция 26: 123 || Лекция 27 >

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

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

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

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

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

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

Таблица 26.3 . Параметры утилиты gfix
Параметр Описание
-ac[tivate] <теневая копия> Параметр предназначен для активации теневой копии. <Теневая копия> - адрес и имя файла теневой копии (или первого из файлов).
-at[tach] n Дополнительный параметр к - shut. Предназначен для запрета новых соединений с БД. n указывает количество секунд, через которое произойдет отключение БД. Отключение отменится, если к этому времени еще останутся активные соединения.
-b[uffers] n Устанавливает новый размер кэша (буфера) БД в страницах. n - количество страниц. По умолчанию, кэш = 75 страниц.
-ca[che] n Параметр зарезервирован для будущих версий и не используется.
-c[ommit] {ID| all} Завершает подтверждением зависшую транзакцию с идентификатором ID, или все зависшие транзакции ( all )
-force n Дополнительный параметр к - shut. Предназначен для принудительного закрытия базы данных. n указывает количество секунд, через которое произойдет закрытие. Если остались активные пользователи, они отключатся, последние результаты их работы будут потеряны. Такое средство нужно применять с осторожностью, как последнюю возможность.
-f[ull] Используется вместе с - v для проверки структур записей и таблиц; освобождает неназначенные фрагменты записей.
-h[ousekeeping] n Изменяет интервал транзакций для автоматической чистки sweep (по умолчанию 20 000). n устанавливает новый интервал. Если n=0, автоматическая чистка запрещена.
-i[gnore] Игнорировать ошибки контрольных сумм при проверке или чистке.
-k[ill] <база данных> Удаляет все неиспользуемые теневые копии базы данных.
-l[ist] Показывает ID всех зависших транзакций. Также показывает, что произойдет при наличии зависших limbo -транзакций и использования опции - t.
-m[end] Помечает разрушенные записи как неиспользуемые.
-mo[de] {read_write | read_only} Устанавливает режим БД. Может быть read_write (чтение-запись, по умолчанию), или read_only (только чтение).
-n[o_update] Используется вместе с - v для проверки разрушенных или неразмещенных структур. Если таковые есть, они отобразятся в сообщении, но не будут исправлены.
-o[nline] Открывает закрытую после - shut базу данных.
-pa[ssword] <пароль> Пароль пользователя SYSDBA или владельца базы данных для работы с gfix.
-p[rompt] Используется вместе с - l. Выводит подсказки при восстановлении транзакций.
-r[ollback] {ID | all} Завершает откатом зависшую транзакцию с идентификатором ID, или все зависшие транзакции ( all )
- sweep Запускает принудительную чистку БД.
-s[ql_dialect] n Изменяет диалект базы данных. n может быть 1 или 3.
-sh[ut] Закрывает базу данных. Используется с одним из дополнительных параметров - attach, - force или - tran.
-t[wo_phase] {ID | all} Автоматическое двухфазное восстановление limbo транзакции с номером ID, или всех транзакций ( all ).
-tr[an] n Дополнительный параметр к - shut. Предназначен для запрета запуска новых транзакций. n указывает количество секунд, через которое произойдет отключение БД. Отключение отменится, если к этому времени еще останутся активные транзакции.
-use {full | reserve} Включает 100% заполнение страниц БД ( full ) или 80% заполнение по умолчанию ( reserve ). 100%-е заполнение имеет смысл для баз только для чтения.
-user <имя пользователя> Имя администратора или владельца базы данных для работы с gfix.
-v[alidate] Определяет и показывает неназначенные страницы БД. То есть, созданные, но не назначенные для каких либо структур данных.
-w[rite] {sync | async} Переключает режимы синхронной / асинхронной записи Forced Writes.
-z Выводит версию InterBase и утилиты 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 будет восстанавливать по одной записи за раз, что позволит восстановить целые таблицы, и пропустить поврежденные.

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

< Лекция 25 || Лекция 26: 123 || Лекция 27 >
Евгений Медведев
Евгений Медведев

В лекции №2 вставляю модуль данных. При попытке заменить name на  fDM выдает ошибку: "The project already contains a form or module named fDM!". Что делать? 

Анна Зеленина
Анна Зеленина

При вводе типов успешно сохраняется только 1я строчка. При попытке ввести второй тип вылезает сообщение об ошибке "project mymenu.exe raised exception class EOleException with message 'Microsoft Драйвер ODBC Paradox В операции должен использоваться обновляемый запрос'. 

Артем Хмелев
Артем Хмелев
Россия, 5
Андрей Хорольский
Андрей Хорольский
Украина, Покровск