Forced writes - палка о двух концах
Чтобы влиять на эту ситуацию, в InterBase 6 предусмотрена настройка режима записи данных на диск. Эта настройка называется foreed writes (FW) и имеет два значения - ON (synchronous) и OFF (asynchronous). Значения forced writes определяют, каким образом InterBase взаимодействует с диском. Если установлено значение forced writes on, то включается режим синхронной записи на диск, когда подтвержденные данные записываются на диск сразу после команды commit, причем сервер ждет завершения записи и лишь потом продолжает работу. В случае режима forced writes off InterBase не торопится записывать данные на диск после команды подтверждения транзакции (commit), а делегирует эту задачу параллельному потоку, в то время как основной поток продолжает обработку данных, не дожидаясь конца записи на диск.
Режим синхронной записи на диск (FW ON) является более безопасным и приводит к минимизации возможной потери данных, однако следствием его применения является некоторая потеря производительности. Режим асинхронной записи (FW OFF) увеличивает производительность, однако значительно возрастает риск потери большого количества данных.
Для получения максимально возможной производительности обычно устанавливают режим FW OFF, в результате чего при сбое питания теряется гораздо большее количество данных, чем при синхронном режиме записи на диск. При установке режима записи следует хорошенько взвесить, насколько увеличение производительности важнее возможности потерять несколько часов работы при неожиданном сбое питания.
Часто сами пользователи грешат неджентльменским отношением к InterBase. В небольших организациях, где экономят на любых мелочах, зачастую на компьютер-сервер, на котором установлен сервер СУБД, также ставят другие серверные (и не только серверные) программы. И в случае их "зависания", недолго думая, нажимают на Reset, что повторяется несколько раз на дню. Хотя InterBase является необычайно устойчивым к таким действиям по сравнению с другими СУБД и позволяет начать работу с базой данных сразу после аварийной перезагрузки, однако такое обращение не проходит бесследно. В результате аварийных перезагрузок накапливаются потерянные страницы, теряются связи между страницами данных. Это может продолжаться довольно долго, однако развязка рано или поздно наступит. Когда "битые страницы" появятся среди страниц учета страниц (PIP) или затронут страницы генераторов или, еще хуже, испортится заголовочная страница базы данных, то база данных может просто больше не открыться и превратиться в большой кусок разрозненных данных, из которого нельзя извлечь ни байта полезной информации.
