Причины разрушения баз данных Interbase

Основные причины, из-за которых может быть испорчена база данных InterBase с нашими комментариями. Рекомендуем так же почитать статью Что НЕ надо делатьhttp://www.ibase.ru/devinfo/dontdoit.htm (хотя большая часть из статьи предназначена для разработчиков):

[ul]
1.Изменение метаданных в тот момент, когда к базе данных подключены другие пользователи.

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

Как избежать - выдерните сетевой шнур во время такой операции, или измените имя файла базы данных ( самое простое - расширение).
Начиная с версии 2.9.0.0 все наши клиентские приложения подключаются к базе данных через конфигуратор. За соединениями сделанными лично вами (например через Server Manager ) следите сами.
[/ul]

[ul]
2.Подключение пользователей к базе данных во время её восстановления операцией Restore.

Как избежать -  Восстанавливайте базу данных всегда с новым именем и никогда не замещайте ее.
[/ul]

[ul]
3. Подключение к одной базе данных разными путями.

Начиная с версии 2.9.0.0 подключение ведется через конфигуратор, так что это управляется с одного места и контролируетя администратором БД.

[/ul]

[ul]
4. Копирование базы данных Копирование базы данных средствами ОС при работающем сервере InterBase может привести к получению испорченной копии базы данных.

Одна из самых часто встречающихся проблем. Чтобы ее избежать остановите службу Interbase Server либо копируйте делая Backup/Restore

Как избежать -  Остановите службу Interbase Server. (примечание - надо сначала остановить службу  Interbase Guardian только тогда вы сможете остановить сам InterBase Server)
[/ul]

[ul]
5. Превышение максимально допустимого размера файла Превышение максимально допустимого размера файла базы данных (4Gb для Windows и 2Gb
для Unix) приводит к полному разрушению базы данных, поэтому необходимо отслеживать
размер файла БД и своевременно добавлять к базе новые файлы командой
ALTER DATABASE ADD FILE...

Как избежать - Ну это уже на администраторе БД. Следите за размером базы, не увлекайтесь блобами сильно (эскизы). Подробности в документации к Interbase.
[/ul]

[ul]
6. Отключение режима Forced writes. Реализация Interbase для Windows по умолчанию не использует кэширование записи(используется т.н. write-through cache). Каждая операция записи в КЭШ тут же передается системе в/в для записи на диск. Правда, иногда система в/в сама может иметь КЭШ записи, но чаще такого нет.
Рекомендуется ВСЕГДА включать режим Forced writes ( должна стоять галочка в "Enable Forced Writes" в свойствах базы данных в программе Interbase Server Manager)
Если вы отключите этот режим, то скорость обновления данных заметно возрастет,  однако надежность БД падает.

Как избежать - включите режим Forced writes ( по умолчанию включен).
[/ul]

[ul]
7. Большое количество генераторов в базе данных. Количество генераторов зависит от размера страницы БД ( и к сожалению никак не контролируется Interbase). В основном эта проблема лежит на разработчиках.

Как избежать - при восстановлении указывайте размер страницы 4096 (рекомендуемый нами) или выше.[/ul]

[ul]
8. Слишком большое количество транзакций в базе данных. InterBase не позволяет выполнить
более 131000000*размер_страницы_БД (в килобайтах)  транзакций в базе данных.

Как избежать - Делайте регулярно Backup/Restore базы данных.
[/ul]

[ul]
9. Использование сервера InterBase 5.5. В данной версии InterBase присутствуют ошибки, поэтому рекомендуется заменить ее на 5.6 или использовать более новые версии. Список поддерживаемых баз данных в документации на ТКС.

Как избежать - не используйте Interbase 5.5
[/ul]

[ul]
10. Аварийное завершение сервера InterBase. Если это произошло в момент записи данных на диск, то база данных может быть повреждена. Это наиболее вероятно в случае, если выключен
режим Forced writes. Это конечно же характерно для всех программ (не только Interbase), просто на Interbase данное событие может остаться незамеченным, поскольку InterBase Guardian автоматически рестартует сервер InterBase после его аварийного завершения, но соответствующая информация об ошибке будет сохранена в файл interbase.log.

Как избежать - сложно сказать что либо определенное. Зависит от конкретной ситуации, следить за логом и разбираться в каждом конкретном случае. Забота администратора БД.
[/ul]

Выводы. При работе с СУБД InterBase следует более внимательно относиться к проблеме резервного копирования базы данных. Эту операцию следует проводить как можно чаще  и только средствами самого InterBase (gbak.exe) или специализированными утилитами (например GBAK Scheduler). 
Отнестись как можно более серьезно к процедуре обновления БД ( и исправления ошибок)  и выполнить все предписанные инструкции. 
Подсоединяться к базе данных только через наши программы или через утилиты Interbase.

Для администраторов БД рекомендуется ознакомиться со статьей Как починить базу данных Interbase http://www.ibase.ru/devinfo/db_repair.htm