Основные причины, из-за которых может быть испорчена база данных InterBase: 1. Изменение метаданных в тот момент, когда к базе данных подключены другие пользователи. Изменение метаданных производится, например, во время патча базы при переходе к новым версиям программ. 2. Подключение пользователей к базе данных во время её восстановления из страховой копии операцией Restore. 3. Подключение к одной базе данных с помощью различных строк подключения. Например, если один пользователь подключается по пути c:im\database\search4.gdb, а другой - c:\im\database\search4.gdb, то InterBase начинает думать, что это разные базы данных, что приводит к разрушению БД. 4. Копирование базы данных средствами ОС при работающем сервере InterBase приводит к получению испорченной копии базы данных даже если в этот момент к исходной базе данных нет активных подключений. Если же в момент копирования какой-либо процесс попытается получить эксклюзивных доступ к базе данных (например, процесс страхового копирования), то будет разрушена не только копия, но и исходная база данных! В связи с этим рекомендуется делать копии БД только средствами самого InterBase (с помощью операции Backup/Restore). 5. Превышение максимально допустимого размера файла базы данных (4Gb для Windows и 2Gb для Unix) приводит к полному разрушению базы данных, поэтому необходимо отслеживать размер файла БД и своевременно добавлять к базе новые файлы командой ALTER DATABASE ADD FILE... 6. Отключение режима Forced writes. При включенном режиме Forced writes InterBase записывает на диск изменения в базе данных специальными порциями, сохраняющими файлы БД в стабильном состоянии. Отключение этого режима приводит к тому, что InterBase начинает кэшировать изменения БД в памяти и производит их запись на диск с точки зрения увеличения производительности, но при этом увеличивается риск повреждения базы данных. Рекомендуется ВСЕГДА включать режим Forced writes. В InterBase 6 это делается в утилите IBConsole (команды Login->Database|Connect->Database|Properties-> General->Forsed writes=Enabled) для каждой базы данных в отдельности. В поставляемых НПП Интермех базах данных режим Forced writes включен. 7. Сбои в аппаратной части. Если выйдет из строя диск, на котором находится файл базы данных, то база данных будет потеряна. Лучший способ избежать этого - использовать соответствующий RAID-массив жестких дисков для хранения базы данных. Это позволяет также повысить скорость обработки запросов к БД. Конечно, нельзя забывать и о регулярном страховом копировании базы данных. Также следует позаботиться об обеспечении сервера источником бесперебойного питания (UPS), т.к. неожиданное выключение питания сервера приводит к аварийному завершению работы InterBase со всеми вытекающими отсюда последствиями (см. п. 9). Сбои памяти сервера также могут приводить к записи в базу неверных данных, поэтому рекомендуется использовать в серверах качественные модули памяти с коррекцией ошибок. 8. Различные версии сервера и клиента InterBase. Данная ситуация непосредственно не может привести к разрушению базы данных, но она может вызывать аварийное завершение сервера InterBase (см. п. 9), что в свою очередь может привести к ошибкам в базе данных. Например, комбинация InterBase 6 Client + InterBase 5.6 Server + BDE 5.2 приводит к аварийному завершению сервера InterBase при выполнении параметризованного запроса с датами. 9. Аварийное завершение сервера InterBase. Если это произошло в момент записи данных на диск, то база данных может быть повреждена. Это наиболее вероятно в случае, если выключен режим Forced writes. Причем данное событие может остаться сперва незамеченным, поскольку InterBase Guardian автоматически рестартует сервер InterBase после его аварийного завершения, но соответствующая информация об ошибке всё же будет сохранена в файл interbase.log. 10. Большое количество генераторов в базе данных. Вообще говоря, InterBase не накладывает ограничения на количество генераторов в базе данных, но он содержит ошибку, которая не позволяет создавать в одной БД более чем 110 - 1000 генераторов (их максимальное количество зависит от размера страницы (page size) конкретной базы данных). Точнее говоря, создавать генераторы можно в любом количестве, но результатом будет разрушение базы данных. Данная ошибка обнаружена на всех версиях InterBase вплоть до 6.5. Увеличение размера страницы БД позволяет снизить риск появления данной ошибки. Для увеличения размера страницы необходимо сделать страховую копию базы данных операцией Backup, а затем восстановить базу операцией Restore, указав при этом размер страницы 8192. 11. Слишком большое количество транзакций в базе данных. InterBase не позволяет выполнить более 131000000*размер_страницы_БД (в килобайтах) транзакций в базе данных. Избежать данной ошибки можно с помощью регулярной (хотя бы раз в квартал) операции Backup/Restore для каждой базы данных. 12. Открытие базы данных InterBase 4 (On Disk Structure v.8) сервером InterBase 6.0 Open Edition. Данная операция не вызовет явного сообщения об ошибке, но при этом база данных будет повреждена. В любом случае при обновлении InterBase на новую версию рекомендуется сначала сделать Backup всех баз данных в старом InterBase, а затем их восстановление (Restore) - в новой версии. 13. Использование сервера InterBase 5.5. В данной версии InterBase присутствуют ошибки, в результате которых операция автоматической очистки мусора в базе (sweep) приводит к разрушению базы данных. Примечание. Ошибки 3, 5 и 10 исправлены в InterBase 7.1, а также во всех версиях Yaffil и Firebird. Выводы. При работе с СУБД InterBase следует более внимательно относиться к проблеме страхового копирования базы данных. Эту операцию следует делать ежедневно и только средствами самого InterBase (gbak.exe или IBConsole) или специализированными утилитами (например, GBAK Scheduler). При этом необходимо обеспечить наличие нескольких страховых копий базы данных и регулярно контролировать процесс страхового копирования, т.к. InterBase не может сделать страховую копию повреждённой базы данных, в результате чего можно оказаться и без базы данных, и без её страховой копии.