сообщение о поломке индекса

[nof8]

Проблема: периодически одна из программ, работающих с базой, выдаёт сообщения вида "database file appears corrupt", "wrong page type;page 1575126 is
of wrong type (expected 7, found 0)".
Excpected - всегда страницы типа 7 (насколько я понимаю, индекс), found - разные.

Т.е. как бы индекс ломается при большой нагрузке.

Роль программы - самодельная репликация, сохранение записанных в базе логов изменений, генерируемых с помощью триггеров, плюс пометка их как сохранённых для исключения повторного сохранения.

Когда нагрузка была небольшая (скажем, 100 000 транзакций в день), такие сообщения были редки (пару раз в неделю) - мы их даже не замечали., поскольку никак не сказывалось на работе (скрипт репликации просто повторно запускал программу после того, как она завершила работу).
Сейчас такое бывает несколько раз в день.

Да и это не было бы проблемой, если бы не замедление работы с базой в разы у других программ, совпадающее по времени с появлением этой ошибки.
Странный факт - в логах самого сервера сообщений об этой ошибке нет, но isc_interprete(), вызываемый из программы репликации, выдаёт именно два указанных в начале сообщения. Права записи в firebird.log у сервера есть, и другие ошибки там иногда возникают (одни разрывы коннектов, но ничего, вязанного с повреждениями базы)

Теперь самое интересное. Во-первых, ошибок при бэкапе/ресторе нет, хотя бэкап/ресторе делаем каждую ночь. Т.е. действительно падают только страницы индекса. Это наводит меня на мысль, что проблема не в железе (ведь не может же быть, чтобы на протяжении полугода работы портились исключительно индексы, но не данные?).
Во-вторых, есть помогающий избавиться от тормозов и на некоторое время от этих ошибок способ - остановить работу всех клиентов, при монопольном доступе к базе данных удалить и создать заново PK по основной таблице с логами репликации.

Код программы, которая выдаёт сообщение об ошибке, внимательно изучался - непохоже, чтобы выдавалась неправильная ошибка (ну, человеческий фактор, конечно, исключать нельзя - может, программер всё-таки ошибся, если никто ничего дельного не скажет - будем снова смотреть).


База данных в 30Гб, Firebird 2.1 CS под gentoo Linux 2.6.20 x86_64 2xDual Core AMD, 8Gb памяти, 4xSCSI винта.
Под Firebird 2.0.1 была такая же проблема (собственно, перешли на 2.1 в надежде излечить).

Проверяли - в свап не залезает совсем (кэш стоит по 128 страниц на клиента, клиентов около 60).

Много читающих, много пишущих. Около 300 000 транзакций в день.
Каждую ночь backup/restore. Пробовали и отключать sweep совсем в течение дня, и ставить в 20000 - проблема проявляется и в том, и в другом случае.

На всякий случай ещё вот ситуация под конец дня:
Database header page information:
Flags 0
Checksum 12345
Generation 284347
Page size 16384
ODS version 11.1
Oldest transaction 250831
Oldest active 250832
Oldest snapshot 245613
Next transaction 273505
Bumped transaction 1
Sequence number 0
Next attachment ID 10832
Implementation ID 24
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Apr 28, 2008 2:02:07
Attributes

Variable header data:
Sweep interval: 20000
*END*

И ещё доп. инфа:
Mutex wait: 5.6%
Hash slots: 2039, Hash lengths (min/avg/max): 0/ 1/ 7


Собственно, теперь вопросы:
1) Может ли быть такое, что баг есть, но в firebird.log ничего не попадает?
2) Какие действия уважаемые знатоки посоветуют предпринять для дальнейшей локализации ошибки? Может, откомпилировать как-нибудь firebird с debug_info или включить дополнительный уровень вывода логов?

[nof8]

Попробовали под Windows 2003 Enterprise Server + FB2.1 Classic, то же самое.

[hvlad]

Собственно, теперь вопросы:
1) Может ли быть такое, что баг есть, но в firebird.log ничего не попадает?
2) Какие действия уважаемые знатоки посоветуют предпринять для дальнейшей локализации ошибки? Может, откомпилировать как-нибудь firebird с debug_info или включить дополнительный уровень вывода логов?

1. Увы, да, может быть
2. Пытаться создать воспроизводимый пример и зарегистрировать его в трекере

[nof8]

Попробовали под Gentoo Linux 2.6.20 с FB 1.5 Classic - то же самое.

[Merlin]

Попробовали под Gentoo Linux 2.6.20 с FB 1.5 Classic - то же самое.

В трекере есть заметки про ломку индексов, и даже несколько месяцев назад hvlad очередную проблему фиксил. В принципе я мог бы напрячься и её вспомнить, но всё равно не вспомню в какой версии пофикшено. Так что лучше почитать трекер самому и поискать у себя в коде похожие проблемные участки.

[dimitr]

оно в 2.1 и фиксилось, насколько я помню...

[nof8]

Попробовали самый свежий на момент 9 октября 2008 снэпшот Firebird2.1.1 из CVS, бранч B2_1_Release.

Gentoo Linux 2.6.20 x86_64, 2xDual Core AMD Opteron.

То же самое. Индексы ломаются.

К тому же ещё на два бага в этом CVS-снапшоте наткнулись (или это у нас руки кривые?). Почему-то localhost ресолвится в какой-то левый ip-адрес и ещё появился в firebird.log следующий баг:
internal gds software consistency check (page in use during flush (210), file: cch.cpp line:
4057)

Но думаю, к основной проблеме, поломке индексов, отношения это не имеет.