сообщение о поломке индекса
Добавлено: 28 апр 2008, 20:44
Проблема: периодически одна из программ, работающих с базой, выдаёт сообщения вида "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 или включить дополнительный уровень вывода логов?
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 или включить дополнительный уровень вывода логов?