data page slots существенно больше Data pages

Запросы, планы, оптимизация запросов, ...

Модераторы: kdv, CyberMax

Ответить
AndreyB
Сообщения: 3
Зарегистрирован: 18 сен 2015, 18:01

data page slots существенно больше Data pages

Сообщение AndreyB » 22 сен 2015, 12:22

Растёт база данных. Насколько я понимаю, страницы некоторых таблиц не освобождаются:

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 единственной активной транзакции.

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


Куда копать? Есть рекомендации?

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48
Контактная информация:

Re: data page slots существенно больше Data pages

Сообщение hvlad » 22 сен 2015, 13:14

То, что есть незанятые слоты, говорит лишь о том, что были массовые удаления из таблицы.
Эти слоты
а) есть не просят
б) будут повторно использованы при вставках данных

Т.е. волноваться не о чем.

PS Если всё же сильно напрягает (не знаю почему) - бекап\рестор это уберёт.
До следующей массовой чистки, есс-но :)

kdv
Forum Admin
Сообщения: 6575
Зарегистрирован: 25 окт 2004, 18:07
Контактная информация:

Re: data page slots существенно больше Data pages

Сообщение kdv » 22 сен 2015, 20:10

не растут только те БД, где ничего не вставляется, не обновляется, и не удаляется.
К базе подключаются с параметрами read_committed rec_version nowait
не очень понятно, зачем вы это привели. я бы понял, если бы написали read read_committed ....
затем делается CommitRetaining единственной активной транзакции.
вот тут караул. про вред Retaining на ibase.ru написано в нескольких статьях. "Одна транзакция на приложение", да еще в retaining - самый худший вариант, который можно придумать (при многопользовательской работе. в однопользовательском - сойдет).
Приложение, пишущее и стирающее записи не отключается от базы по несколько недель.
то есть, приложение постоянно плодит версии, увеличивается количество занятых страниц, потом, через недели приложение отключается, версии превращаются в мусор, убираются авто-свипом, и остается туча незаполненных страниц.
Впрочем, по Average fill на уровне 90% - все нормально.

Ради интереса можете взять IBTM, запустить, и через недельку посмотреть на графики (или прислать полученные *.tmd нам). Тогда будет ясно, есть проблемы с активными транзакциями, или нет.
http://www.ib-aid.com/download/ibtm_trial.zip

AndreyB
Сообщения: 3
Зарегистрирован: 18 сен 2015, 18:01

Re: data page slots существенно больше Data pages

Сообщение AndreyB » 23 сен 2015, 17:07

Спасибо всем за участие.

Пекап/рестор напрягает пользователей. Просят от него избавится.

Я предполагал, что если количество добавляемых записей будет равно количеству удаляемых, то размер базы застабилизируется на каком-то уровне. Не похоже, что это происходит.

Параметры компонента транзакции привёл для полноты картины, чтобы было проще определить источник проблемы. Я не понял, там что-то не так?

Я предполагал, что достаточно сделать коммит после делете, чтобы страницы превратились в мусор и были использованы повторно. Для чего нужно отключаться от базы? Почему место удалённых записей после подтверждения не может использоваться повторно в том же сеансе? Другие приложения не держат эти записи, насколько я понимаю.

О вреде Retaining прочитаю.

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

Итак, основные подозреваемые сейчас - "активные транзакции", так? Т.е. есть некая транзакция, которая держит записи и мешает им удалятся?

BTW. Галка "Сообщать мне о получении ответа" стоит, а уведомления в почту не приходят.

AndreyB
Сообщения: 3
Зарегистрирован: 18 сен 2015, 18:01

Re: data page slots существенно больше Data pages

Сообщение AndreyB » 23 сен 2015, 18:44

И ещё. Правильно ли я понял, что количество слотов не уменьшится до рестора, а при добавлении записей будет расти количество страниц. И пока оно меньше количества слотов, то размер файла базы расти не должен?

kdv
Forum Admin
Сообщения: 6575
Зарегистрирован: 25 окт 2004, 18:07
Контактная информация:

Re: data page slots существенно больше Data pages

Сообщение kdv » 24 сен 2015, 12:00

Я не понял, там что-то не так?
от commitretaining надо избавляться.
Я предполагал, что достаточно сделать коммит после делете, чтобы страницы превратились в мусор и были использованы повторно. Для чего нужно отключаться от базы?
коммит или commitretaining? конкурирующие транзакции при этом есть? Я не вижу смысла цитировать тут статьи по транзакциям и версионности с ibase.ru.
Установка дополнительного софта и сбор статистики - крайний случай
интересно, почему крайний. gstat -r вы же каким-то образом запустили. Я тогда не понимаю, зачем, если вас все устраивает. Ну растет база, смиритесь. У одной конторы, которая статистику недавно прислала, база выросла на 50 гигабайт за полгода. Так что все относительно.
Т.е. есть некая транзакция, которая держит записи и мешает им удалятся?
это проверяется установкой ibtm.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48
Контактная информация:

Re: data page slots существенно больше Data pages

Сообщение hvlad » 24 сен 2015, 12:49

AndreyB писал(а):И ещё. Правильно ли я понял, что количество слотов не уменьшится до рестора, а при добавлении записей будет расти количество страниц. И пока оно меньше количества слотов, то размер файла базы расти не должен?
Совершенно не правильно.
Слоты - это не есть страницы данных. Это ячейки массива, в котором записаны номера страниц с данными.
Кол-во слотов - размер массива. Массив может быть уменьшен, если последние ячейки освобождаются.
Размер БД не связан явным образом с соотношением слоты\страницы данных. Ибо кроме данных таблиц,
в БД есть ещё много всяких других данных.

Ответить

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 3 гостя