проблема заключается в следующем:
имеется база данных (IB5.6) через которую идет обмен между приложениями написанными на BCB5 и использующие стандартные компоненты для работы с InterBase. Одно приложение записывает данные (UPDATE), другое – считывает их оттуда (SELECT). База прирастает примерно на 1Мб в сутки. Когда база достигает размера 36Мб, база перестает открываться при этом выдается ошибка «internal gds software consistency check (cannot find tip page (165))». База была открыта с помощью IBSurgeon Viewer 1.0.1, который показал, что большую часть базы занимают «Transaction inventory page», и число страниц – около 66 миллионов.
Вопрос: как предотвратить рост базы?
рост базы данных
написать нормальную работу с транзакциями в приложении. в 5.6 есть баг с ограничением на число транзакций в 131 миллион при размере страницы 1К. Этот баг исправлен только в IB 6.0 и выше.
то есть путей несколько
1. пересмотреть работу с транзакциями в приложении
2. увеличить размер страницы (до 4-8К). это увеличит лимит транзакций до очередной ошибки.
3. регулярно делать backup/restore, тогда tip "сбрасывается" и все транзакции начинаются по новой, с нуля.
переход на другую версию IB/FB я здесь не упоминаю потому, что если вы не вылечите ЭТО, то скорее всего переход на версию без этого бага приведет к тому, что вы "забъете" на минимальное администрирование БД совсем и через некоторое время получите какие-нибудь более серьезные проблемы или катастрофическое ухудшение производительности.
можно скинуть мне или сюда результат gstat db.gdb -h
?
p.s. кстати, число страниц 66 миллионов при размере базы 36 мег никак не может быть. т.к. минимальный размер страницы БД - 1К. Предлагаю поделить размер базы на 1К и посчитать число таких страниц в ней
то есть путей несколько
1. пересмотреть работу с транзакциями в приложении
2. увеличить размер страницы (до 4-8К). это увеличит лимит транзакций до очередной ошибки.
3. регулярно делать backup/restore, тогда tip "сбрасывается" и все транзакции начинаются по новой, с нуля.
переход на другую версию IB/FB я здесь не упоминаю потому, что если вы не вылечите ЭТО, то скорее всего переход на версию без этого бага приведет к тому, что вы "забъете" на минимальное администрирование БД совсем и через некоторое время получите какие-нибудь более серьезные проблемы или катастрофическое ухудшение производительности.
можно скинуть мне или сюда результат gstat db.gdb -h
?
p.s. кстати, число страниц 66 миллионов при размере базы 36 мег никак не может быть. т.к. минимальный размер страницы БД - 1К. Предлагаю поделить размер базы на 1К и посчитать число таких страниц в ней
вижу число транзакций:
Database "control.GDB"
Database header page information:
Flags 0
Checksum 12345
Generation 131596310
Page size 1024
ODS version 9.1
Oldest transaction 131596236
Oldest active 131596288
Oldest snapshot 131596288
Next transaction 131596304
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Creation date Feb 18, 2004 16:42:31
Attributes force write
Variable header data:
*END*
Database "control.GDB"
Database header page information:
Flags 0
Checksum 12345
Generation 131596310
Page size 1024
ODS version 9.1
Oldest transaction 131596236
Oldest active 131596288
Oldest snapshot 131596288
Next transaction 131596304
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Creation date Feb 18, 2004 16:42:31
Attributes force write
Variable header data:
*END*
что и требовалось доказать (про 131 миллион). я засунул статистику в IBAnalyst - ~352 тысячи транзакций в день.
База "брошенная", то есть при такой активности за год никто не озаботился b/r сделать.
"починить" ситуацию можно открыв эту БД в 6.0, сделать backup, затем restore, затем опять backup gbak-ом от 5.6, и ресторить этот бэкап уже на сервере 5.6. Но - с размером страницы 4К.
и я бы еще советовал сохранить базу. очень бы хотелось увидеть полную статистику, полученную как gstat db.gdb -a -r. только для этого придется оригинальную базу (ее копию, и только ПОТОМ!!!) подсунуть например FB 1.5.
База "брошенная", то есть при такой активности за год никто не озаботился b/r сделать.
"починить" ситуацию можно открыв эту БД в 6.0, сделать backup, затем restore, затем опять backup gbak-ом от 5.6, и ресторить этот бэкап уже на сервере 5.6. Но - с размером страницы 4К.
и я бы еще советовал сохранить базу. очень бы хотелось увидеть полную статистику, полученную как gstat db.gdb -a -r. только для этого придется оригинальную базу (ее копию, и только ПОТОМ!!!) подсунуть например FB 1.5.
да, еще. при условии 2-х рабочих мест и 8-часового рабочего дня каждое раб. место шарашит по 366 транзакций в минуту. то есть по ~6 транзакций в секунду. не круто?
даже если предположить работу 24 часа в сутки, все равно получается по 2 транзакции в секунду. для двух рабочих мест это слишком круто.
У нас на web-системе при 10 тысячах одновременных пользователей в сутки доходило до 250 тысяч транзакций.
даже если предположить работу 24 часа в сутки, все равно получается по 2 транзакции в секунду. для двух рабочих мест это слишком круто.
У нас на web-системе при 10 тысячах одновременных пользователей в сутки доходило до 250 тысяч транзакций.
А одно из них - верняк показания какого-то датчика напрямки в базу пишет и коммитит в темпе вальсаkdv писал(а):да, еще. при условии 2-х рабочих мест и 8-часового рабочего дня каждое раб. место шарашит по 366 транзакций в минуту. то есть по ~6 транзакций в секунду. не круто?
даже если предположить работу 24 часа в сутки, все равно получается по 2 транзакции в секунду. для двух рабочих мест это слишком круто.
именно такMerlin писал(а):А одно из них - верняк показания какого-то датчика напрямки в базу пишет и коммитит в темпе вальсаkdv писал(а):да, еще. при условии 2-х рабочих мест и 8-часового рабочего дня каждое раб. место шарашит по 366 транзакций в минуту. то есть по ~6 транзакций в секунду. не круто?
даже если предположить работу 24 часа в сутки, все равно получается по 2 транзакции в секунду. для двух рабочих мест это слишком круто.