gfix -w async d:\data\accounts.fdb
Firebird инсталлируется в Windows NT/2000/XP и Linux с включенным режимом Forced Writes. В очень надежной среде с надежной поддержкой бесперебойного питания (UPS) администратор базы данных может отключить Forced Writes для сокращения операций ввода/вывода и улучшения производительности. Когда отключается Forced Writes в менее надежных средах, база данных становится чувствительной к потере данных и даже к их разрушению в случае неуправляемого отключения.
Forced Writes неприменимо в Windows 95. В серверах Windows 98 и ME вы никогда не должны отключать Forced Writes.
Операционные системы Windows менее надежны, чем другие системы в отношении записи на диск кэша. Это проявляется в том, что приложения не могут явно запросить систему Windows записать кэш на диск, система может отложить все выводы на диск до того момента, как файл базы данных будет закрыт.
* Firebird 1.0.x: если Forced Writes не задается для сервера Windows, работающего 24/7 (24 часа, 7 дней в неделю), то запись на диск может никогда не произойти.
* Firebird 1.5: были добавлены новые установки конфигурации для записи буферов кэша на диск в Windows. См. параметры MaxUnfiushedwrites и MaxUnflushedWriteTime (firebird.COnf) В главе 36.
Windows ME вместе с XP Ноте и Professional Edition имеет возможность, называемую системным восстановлением, которая вызывает копирование самой файловой системы в файлы с некоторыми суффиксами каждый раз, как происходят операции ввода/вывода. Системное восстановление не является заменой Forced Writes[156].
Вам следует знать, что база данных Firebird, которая начала свою жизнь в InterBase 6.x (коммерческом или с открытыми текстами), создана с отключенным режимом Forced Writes по умолчанию.
Запрос версии сервера Firebird
Переключатель -z (без параметров) показывает версию gfix и сервера Firebird, инсталлированного на сервере.
Вот синтаксис:
gfix -z
Проверка и починка данных
В повседневных операциях в базе данных иногда происходят события, создающие некоторые проблемы для структуры базы данных.
* Ненормальное завершение сервера. Ненормальное завершение не влияет на целостность базы данных. Однако если Firebird уже назначил страницу данных для неподтвержденных изменений, запрошенных клиентом, эта страница становится бесхозной, "осиротевшей". Поскольку такие страницы являются вполне безобидными, они лишь занимают дисковое пространство, которое должно быть возвращено в свободное пространство. Проверка может отыскать и освободить это пространство.
* Ошибки записи операционной системы или оборудования. Ошибки записи обычно создают проблемы для целостности базы данных. Они могут привести к разрушению или потере структур данных, таких как страницы базы данных и индексы. В худшем случае такие разрушения структур данных могут сделать подтвержденные данные нечитаемыми. Иногда проверка может помочь найти такие разрушенные фрагменты и удалить их.
Когда проверять базу данных
Вы должны проверять базу данных:
* всякий раз при неуспешном копировании базы данных;
* всякий раз, когда приложение получает сообщение об ошибке "разрушена база данных";
* периодически в качестве регулярной процедуры для отслеживания разрушения структур данных или нераспределенного пространства;
* каждый раз, когда вы подозреваете, что данные разрушены.
Утилита командной строки gbak может быть использована вместе с gfix для выполнения последовательной проверки и починки данных.
Выполнение проверки базы данных
Пров базы данных требует исключительного доступа к базе данных. Без исключительного доступа вы получите сообщение об ошибке:
OBJECT имя-базы-данных IS IN OSE
Для проверки базы данных просто введите команду:
gfix -v
Проверка будет молча отыскивать и освобождать неназначенные страницы или нераспределенные структуры, которые она найдет. Она будет сообщать о любых разрушенных структурах, но не будет пытаться их исправлять. Для получения протокола об ошибках gfix, но без попыток освобождения пространства введите переключатель -n[o_update]:
gfix -v -n
Вы можете заставить проверку игнорировать ошибки контрольных сумм, добавив переключатель -i [gnore]:
gfix -v -i
! ! !
ПРИМЕЧАНИЕ. Даже если вы сможете восстановить исправленную базу данных, которая сообщала об ошибках контрольных сумм, объем потерянных данных трудно будет определить. Если это вас беспокоит, вы можете восстановить вашу базу данных с более ранней копии.
. ! .
Восстановление разрушенной базы данных
Если вы подозреваете, что ваша база данных разрушена, важно точно придерживаться последовательности шагов восстановления, чтобы избежать дальнейших разрушений. Подробное описание рекомендуемой процедуры восстановления см. в приложении 4[157].
Восстановление транзакций
Утилита gfix предоставляет инструменты для восстановления зависших транзакций 2РС - транзакций с несколькими базами данных после потери соединения с одной из них.
Двухфазное подтверждение
Транзакция, которая используется в нескольких базах данных Firebird, подтверждается в два этапа, или в две фазы. Такое двухфазное подтверждение гарантирует, что если транзакция не может завершить изменения во всех используемых базах данных, она не будет изменять ни одну из них.
На первой фазе двухфазного подтверждения Firebird подготавливает субтранзакцию для каждой базы данных, вовлеченной в операции транзакции, и записывает соответствующие изменения в каждую базу данных.
На второй фазе, следуя точно в том же порядке, что и при их подготовке и записи, Firebird отмечает каждую подтранзакцию как подтвержденную.
Зависшие (limbo) транзакции- это подтранзакции, которые остались неразрешенными, если возникли какие-то проблемы в соединениях с одной или более базами данных в процессе выполнения второй фазы двухфазного подтверждения, например, ошибки сети или отключение питания. Сервер не может сказать, должны ли зависшие транзакции подтверждаться или следует выполнить их откат.
Следовательно, некоторые записи в базе данных могут оказаться недоступными, пока явно не будут выполнены те действия по разрешению зависших транзакций, с которыми они связаны.
Восстановление транзакции
При использовании gfix, вы имеете множество режимов для получения информации и для разрешения зависших транзакций после ошибок двухфазного подтверждения. Процесс идентификации зависших транзакций и их подтверждение либо откат называется восстановлением транзакций.
Вы можете попытаться восстановить сразу все зависшие транзакции или вы можете выполнять восстановление транзакции за транзакцией, используя идентификатор каждой индивидуальной транзакции.
Для получения списка всех зависших транзакций с индикацией, что произойдет с каждой, если было запрошено автоматическое двухфазное восстановление, используйте переключатель -l[ist]:
gfix -l база-данных
Используйте переключатель -p[rompt] вместе с -l[ist] для получения от gfix списка зависших транзакций одну за другой и выдачи вам запроса на выполняемое действие:
COMMIT или ROLLBACK:
gfix -l -р база-данных
156
Суффикс .gdb включен в filelist.xml, в список файлов, к которым применяется системное восстановление, располагающихся в каталоге Windows/System. К сожалению, из списка типы файлов не могут быть удалены. Это действует на базы данных Firebird, имеющие расширение gdb - системное восстановление приводит к замедлению начального соединения с подобными базами данных, и бывает, что это приводит к разрушению данных (подтвержденные
157
Информацию по ремонту баз данных можно найти здесь: http://www.ibase.ru/dbrepair.htrn и http://www.ibase.ru/devinfo/db_repair.htm. - Прим. науч. ред.