Тормозит первое чтение

[Frattello]

В базу прилетают данные пачками примерно по 100 записей, раз примерно в 15 минут. Чтение из таблицы как правило редкое, может произойти намного позже (неделю и более спустя).
Проблема в том, что такое первое чтение может стопорнуться в определенном месте и оооочень надолго, вплоть до часов. Причем это происходит в достаточно случайных местах, я не смог обнаружить какой либо закономерности касательно скажем перезагрузки сервера. Несколько раз в этих таблицах даже обнаруживались ошибки (shecksum error и вроде бы wrong metadata или как то так, уже забыл).
Прикладу, которая складирует данные, я проверял мельком, вроде бы не должно быть ситуаций когда она оставляет незакоммиченные транзакции с записями, делали и закидывание по 1000 записей-коммит и по одной, все равно проблема остается. Хотя поскольку писал не я, на 100% исключить такую ситуацию не могу.
Свип отключен, бэкап-откат делается в среднем раз в месяц. Структура таблицы приведена ниже. У кого какие мнение, что это такое и как с этим бороться?

[hvlad]

gstat -h, gstat -r кто-нибудь когда-нибудь делал ?

[hvlad]

Я правильно понимаю, что вопрос был задан просто так, лишь бы задать, и ответ не интересует автора ?

[Frattello]

Я правильно понимаю, что вопрос был задан просто так, лишь бы задать, и ответ не интересует автора ?

Аааа, кажется я понял. Ты наверное имел ввиду "для более точного понимания ситуации хотелось бы иметь результаты выполнения следующих команд..."

• Database header page information:
  Flags 0
  Checksum 12345
  Generation 24430768
  Page size 8192
  ODS version 11.2
  Oldest transaction 10619
  Oldest active 17730476
  Oldest snapshot 17729632
  Next transaction 24267226
  Bumped transaction 1
  Sequence number 0
  Next attachment ID 163536
  Implementation ID 26
  Shadow count 0
  Page buffers 0
  Next header page 0
  Database dialect 3
  Creation date Jun 2, 2015 22:05:19
  Attributes force write
  
  Variable header data:
  Sweep interval: 0
  *END*
  
  TTS3_DATA (150)
  Primary pointer page: 209, Index root page: 210
  Average record length: 91.30, total records: 6558192
  Average version length: 9.11, total versions: 672804, max versions: 111
  Data pages: 109295, data page slots: 136707, average fill: 82%
  Fill distribution:
  0 - 19% = 471
  20 - 39% = 1054
  40 - 59% = 674
  60 - 79% = 51
  80 - 99% = 107045
  
  Index RDB$PRIMARY67 (0)
  Depth: 3, leaf buckets: 7624, nodes: 6558192
  Average data length: 3.20, total dup: 0, max dup: 0
  Fill distribution:
  0 - 19% = 55
  20 - 39% = 0
  40 - 59% = 409
  60 - 79% = 15
  80 - 99% = 7145
  
  TTS4_DATA (143)
  Primary pointer page: 195, Index root page: 196
  Average record length: 91.47, total records: 10812202
  Average version length: 9.29, total versions: 1050166, max versions: 108
  Data pages: 181617, data page slots: 225555, average fill: 81%
  Fill distribution:
  0 - 19% = 2304
  20 - 39% = 900
  40 - 59% = 985
  60 - 79% = 650
  80 - 99% = 176778
  
  Index RDB$PRIMARY96 (0)
  Depth: 3, leaf buckets: 11730, nodes: 10812202
  Average data length: 2.60, total dup: 0, max dup: 0
  Fill distribution:
  0 - 19% = 54
  20 - 39% = 1
  40 - 59% = 643
  60 - 79% = 8
  80 - 99% = 11024

Надеюсь кто нибудь сможет что нибудь хорошее посоветовать.

P.S. Может ли помочь создание дополнительного индекса только по полю LOCALTIME? Полезно ли будет добавить в программу, записывающую данные, еще и чтение после записи?

[kdv]

Oldest active 17730476
Next transaction 24267226
ну чего вы фигней маетесь? У вас активная транзакция блокирует сборку мусора уже 10 ДНЕЙ. 10 дней торчит приложение, подключенное к БД с активной транзакцией.

[kdv]

про версионость что-нибудь вообще читали? про сборку мусора? Про транзакции?
По-моему, вообще нет. На сайте масса информации. можете начать отсюда
http://www.ibase.ru/devinfo/mga.htm
http://www.ibase.ru/devinfo/garbage.htm
http://www.ibase.ru/devinfo/summary.htm

если у вас firebird 2.1 и выше, найти проблемное приложение с долгим коннектом и транзакцией можете найти выполнив
select * from mon$attachments
select * from mon$transactions

[Frattello]

про версионость что-нибудь вообще читали? про сборку мусора? Про транзакции?
По-моему, вообще нет. На сайте масса информации. можете начать отсюда
http://www.ibase.ru/devinfo/mga.htm
http://www.ibase.ru/devinfo/garbage.htm
http://www.ibase.ru/devinfo/summary.htm

если у вас firebird 2.1 и выше, найти проблемное приложение с долгим коннектом и транзакцией можете найти выполнив
select * from mon$attachments
select * from mon$transactions

Я же написал, что свип отключен. Я читал и про версионность и про сборку мусора и про транзакции. Вопрос в том, почему проблема не возникает ни с одной другой таблицей?

[kdv]

просто поразительно.
"- вы ничего не понимаете в версионности
- я же написал, что свип отключен"

ну отключен свип, и что? Вы не знаете, что такое свип
http://www.ibase.ru/devinfo/sweep.htm

А проблема у вас вот в чем
- длинная транзакция приводит к накоплению версий, что само по себе со временем ухудшает производительность.
- как только эта транзакция завершается, внезапно, версии из "нужных" превращаются в "мусорные, ненужные". И первый же запрос к данным с накопленными версиями начинает собирать мусор. А мусора у вас накапливается просто дофига. Потому и
"Проблема в том, что такое первое чтение может стопорнуться в определенном месте и оооочень надолго, вплоть до часов."

Если бы вы действительно понимали про версионность и сборку мусора и про транзакции, вы бы
- проверили свое приложение на предмет длинных транзакций
- посмотрели бы IBAnalyst-ом, где и сколько версий накапливается (хотя это и так видно в поцитированной вами статистике).
- сделали бы выводы, исправили приложение