data page slots существенно больше Data pages
data page slots существенно больше Data pages
Растёт база данных. Насколько я понимаю, страницы некоторых таблиц не освобождаются:
FDB_DATA (142)
Primary pointer page: 373, Index root page: 374
Average record length: 27.60, total records: 15180676
Average version length: 0.00, total versions: 0, max versions: 0
Data pages: 186024, data page slots: 489560, average fill: 90%
FDB_LOG (133)
Primary pointer page: 355, Index root page: 356
Average record length: 65.78, total records: 72632
Average version length: 0.00, total versions: 0, max versions: 0
Data pages: 1574, data page slots: 4405, average fill: 94%
FDB_RECORDS (137)
Primary pointer page: 363, Index root page: 364
Average record length: 31.92, total records: 1690923
Average version length: 0.00, total versions: 0, max versions: 0
Data pages: 27109, data page slots: 47511, average fill: 76%
Статистика транзакций выглядит порядочно:
Database header page information:
Flags 0
Checksum 12345
Generation 4783504
Page size 4096
ODS version 11.1
Oldest transaction 4783492
Oldest active 4783493
Oldest snapshot 4783493
Next transaction 4783494
Bumped transaction 1
Sequence number 0
Next attachment ID 92
Implementation ID 16
Shadow count 0
Page buffers 256
Next header page 0
Database dialect 3
Creation date Jul 25, 2015 21:01:53
Attributes no reserve
Variable header data:
Sweep interval: 20000
Думаю, на транзакции пенять нет оснований.
Таблицы простые - блобов и триггеров нет. Апдейты не делаются, только инсерты и делете.
Было подозрение на "Неактуальные данные" из http://www.ibase.ru/devinfo/garbage.htm т.к. логи, например, действительно может никто не смотреть.
Но select count(*) и запуск sweep не помогает.
К базе подключаются с параметрами read_committed rec_version nowait.
Транзакции подтверждаются CommitRetaining (не знаю, почему).
С базой работает единственная длл-ка на Делфи 7 через стандартные компоненты InterBase.
Инсерт и делете делаются из хранимых процедур, которые содержат только эти операторы. Из кода вызывается процедура,
затем делается CommitRetaining единственной активной транзакции.
Приложение, пишущее и стирающее записи не отключается от базы по несколько недель. Есть другие приложения, которые через эту же
длл-ку читают таблицы. Некоторые тоже могут оставаться подключенными продолжительное время (днями/неделями).
Добавление записей происходит ежеминутно, удаление - раз в неделю.
Куда копать? Есть рекомендации?
FDB_DATA (142)
Primary pointer page: 373, Index root page: 374
Average record length: 27.60, total records: 15180676
Average version length: 0.00, total versions: 0, max versions: 0
Data pages: 186024, data page slots: 489560, average fill: 90%
FDB_LOG (133)
Primary pointer page: 355, Index root page: 356
Average record length: 65.78, total records: 72632
Average version length: 0.00, total versions: 0, max versions: 0
Data pages: 1574, data page slots: 4405, average fill: 94%
FDB_RECORDS (137)
Primary pointer page: 363, Index root page: 364
Average record length: 31.92, total records: 1690923
Average version length: 0.00, total versions: 0, max versions: 0
Data pages: 27109, data page slots: 47511, average fill: 76%
Статистика транзакций выглядит порядочно:
Database header page information:
Flags 0
Checksum 12345
Generation 4783504
Page size 4096
ODS version 11.1
Oldest transaction 4783492
Oldest active 4783493
Oldest snapshot 4783493
Next transaction 4783494
Bumped transaction 1
Sequence number 0
Next attachment ID 92
Implementation ID 16
Shadow count 0
Page buffers 256
Next header page 0
Database dialect 3
Creation date Jul 25, 2015 21:01:53
Attributes no reserve
Variable header data:
Sweep interval: 20000
Думаю, на транзакции пенять нет оснований.
Таблицы простые - блобов и триггеров нет. Апдейты не делаются, только инсерты и делете.
Было подозрение на "Неактуальные данные" из http://www.ibase.ru/devinfo/garbage.htm т.к. логи, например, действительно может никто не смотреть.
Но select count(*) и запуск sweep не помогает.
К базе подключаются с параметрами read_committed rec_version nowait.
Транзакции подтверждаются CommitRetaining (не знаю, почему).
С базой работает единственная длл-ка на Делфи 7 через стандартные компоненты InterBase.
Инсерт и делете делаются из хранимых процедур, которые содержат только эти операторы. Из кода вызывается процедура,
затем делается CommitRetaining единственной активной транзакции.
Приложение, пишущее и стирающее записи не отключается от базы по несколько недель. Есть другие приложения, которые через эту же
длл-ку читают таблицы. Некоторые тоже могут оставаться подключенными продолжительное время (днями/неделями).
Добавление записей происходит ежеминутно, удаление - раз в неделю.
Куда копать? Есть рекомендации?
Re: data page slots существенно больше Data pages
То, что есть незанятые слоты, говорит лишь о том, что были массовые удаления из таблицы.
Эти слоты
а) есть не просят
б) будут повторно использованы при вставках данных
Т.е. волноваться не о чем.
PS Если всё же сильно напрягает (не знаю почему) - бекап\рестор это уберёт.
До следующей массовой чистки, есс-но
Эти слоты
а) есть не просят
б) будут повторно использованы при вставках данных
Т.е. волноваться не о чем.
PS Если всё же сильно напрягает (не знаю почему) - бекап\рестор это уберёт.
До следующей массовой чистки, есс-но
Re: data page slots существенно больше Data pages
не растут только те БД, где ничего не вставляется, не обновляется, и не удаляется.
Впрочем, по Average fill на уровне 90% - все нормально.
Ради интереса можете взять IBTM, запустить, и через недельку посмотреть на графики (или прислать полученные *.tmd нам). Тогда будет ясно, есть проблемы с активными транзакциями, или нет.
http://www.ib-aid.com/download/ibtm_trial.zip
не очень понятно, зачем вы это привели. я бы понял, если бы написали read read_committed ....К базе подключаются с параметрами read_committed rec_version nowait
вот тут караул. про вред Retaining на ibase.ru написано в нескольких статьях. "Одна транзакция на приложение", да еще в retaining - самый худший вариант, который можно придумать (при многопользовательской работе. в однопользовательском - сойдет).затем делается CommitRetaining единственной активной транзакции.
то есть, приложение постоянно плодит версии, увеличивается количество занятых страниц, потом, через недели приложение отключается, версии превращаются в мусор, убираются авто-свипом, и остается туча незаполненных страниц.Приложение, пишущее и стирающее записи не отключается от базы по несколько недель.
Впрочем, по Average fill на уровне 90% - все нормально.
Ради интереса можете взять IBTM, запустить, и через недельку посмотреть на графики (или прислать полученные *.tmd нам). Тогда будет ясно, есть проблемы с активными транзакциями, или нет.
http://www.ib-aid.com/download/ibtm_trial.zip
Re: data page slots существенно больше Data pages
Спасибо всем за участие.
Пекап/рестор напрягает пользователей. Просят от него избавится.
Я предполагал, что если количество добавляемых записей будет равно количеству удаляемых, то размер базы застабилизируется на каком-то уровне. Не похоже, что это происходит.
Параметры компонента транзакции привёл для полноты картины, чтобы было проще определить источник проблемы. Я не понял, там что-то не так?
Я предполагал, что достаточно сделать коммит после делете, чтобы страницы превратились в мусор и были использованы повторно. Для чего нужно отключаться от базы? Почему место удалённых записей после подтверждения не может использоваться повторно в том же сеансе? Другие приложения не держат эти записи, насколько я понимаю.
О вреде Retaining прочитаю.
Следующий сеанс связи с этим "луноходом" будет примерно через неделю. Надеюсь, к тому времени определить источник проблемы. Установка дополнительного софта и сбор статистики - крайний случай, если теоретически решить проблему не удастся.
Итак, основные подозреваемые сейчас - "активные транзакции", так? Т.е. есть некая транзакция, которая держит записи и мешает им удалятся?
BTW. Галка "Сообщать мне о получении ответа" стоит, а уведомления в почту не приходят.
Пекап/рестор напрягает пользователей. Просят от него избавится.
Я предполагал, что если количество добавляемых записей будет равно количеству удаляемых, то размер базы застабилизируется на каком-то уровне. Не похоже, что это происходит.
Параметры компонента транзакции привёл для полноты картины, чтобы было проще определить источник проблемы. Я не понял, там что-то не так?
Я предполагал, что достаточно сделать коммит после делете, чтобы страницы превратились в мусор и были использованы повторно. Для чего нужно отключаться от базы? Почему место удалённых записей после подтверждения не может использоваться повторно в том же сеансе? Другие приложения не держат эти записи, насколько я понимаю.
О вреде Retaining прочитаю.
Следующий сеанс связи с этим "луноходом" будет примерно через неделю. Надеюсь, к тому времени определить источник проблемы. Установка дополнительного софта и сбор статистики - крайний случай, если теоретически решить проблему не удастся.
Итак, основные подозреваемые сейчас - "активные транзакции", так? Т.е. есть некая транзакция, которая держит записи и мешает им удалятся?
BTW. Галка "Сообщать мне о получении ответа" стоит, а уведомления в почту не приходят.
Re: data page slots существенно больше Data pages
И ещё. Правильно ли я понял, что количество слотов не уменьшится до рестора, а при добавлении записей будет расти количество страниц. И пока оно меньше количества слотов, то размер файла базы расти не должен?
Re: data page slots существенно больше Data pages
от commitretaining надо избавляться.Я не понял, там что-то не так?
коммит или commitretaining? конкурирующие транзакции при этом есть? Я не вижу смысла цитировать тут статьи по транзакциям и версионности с ibase.ru.Я предполагал, что достаточно сделать коммит после делете, чтобы страницы превратились в мусор и были использованы повторно. Для чего нужно отключаться от базы?
интересно, почему крайний. gstat -r вы же каким-то образом запустили. Я тогда не понимаю, зачем, если вас все устраивает. Ну растет база, смиритесь. У одной конторы, которая статистику недавно прислала, база выросла на 50 гигабайт за полгода. Так что все относительно.Установка дополнительного софта и сбор статистики - крайний случай
это проверяется установкой ibtm.Т.е. есть некая транзакция, которая держит записи и мешает им удалятся?
Re: data page slots существенно больше Data pages
Совершенно не правильно.AndreyB писал(а):И ещё. Правильно ли я понял, что количество слотов не уменьшится до рестора, а при добавлении записей будет расти количество страниц. И пока оно меньше количества слотов, то размер файла базы расти не должен?
Слоты - это не есть страницы данных. Это ячейки массива, в котором записаны номера страниц с данными.
Кол-во слотов - размер массива. Массив может быть уменьшен, если последние ячейки освобождаются.
Размер БД не связан явным образом с соотношением слоты\страницы данных. Ибо кроме данных таблиц,
в БД есть ещё много всяких других данных.