Расухание базы данных
Модератор: kdv
Расухание базы данных
При добавлении данных (порядка 500кБ.) в базу данных в одной транзакции (степень изоляции READ COMMITED, параллельных транзакций нет) наблюдается очень сильное распухание базы данных.
Версия сервера Firebird 1.5.3
Подскажите пожалуйста на что мне стоит обратить внимание чтобы решить эту проблему.
Версия сервера Firebird 1.5.3
Подскажите пожалуйста на что мне стоит обратить внимание чтобы решить эту проблему.
Я знаю, что такое выделение нового куска.
Когда говорю сильно, значит сильно.
Теперь подробнее:
1. Пустая база из скрипта ~300кБ.
2. Добавляем ~2МБ информации (две транзакции)
3. Размер базы после добавления <90МБ
4. Делаем бэкап/рэсторе: размер базы ~4МБ
Если добавлять еще, то и дальше пухнет. До гигабайта правда не дошло.
Когда говорю сильно, значит сильно.
Теперь подробнее:
1. Пустая база из скрипта ~300кБ.
2. Добавляем ~2МБ информации (две транзакции)
3. Размер базы после добавления <90МБ
4. Делаем бэкап/рэсторе: размер базы ~4МБ
Если добавлять еще, то и дальше пухнет. До гигабайта правда не дошло.
Вот статистика:
В базу данных занесение происходит в основном в BLOB поля.
Вставка происходит в представление. В триггере замещения
происходит обработка: вставляемая в BLOB поле информация обрабатывается UDF функцией на входе которой BLOB, на выходе тоже BLOB. Обработанное функцией значение, собственно, и помещается в таблицу.
Код: Выделить всё
Database header page information:
Flags 0
Checksum 12345
Generation 155
Page size 1024
ODS version 10.1
Oldest transaction 143
Oldest active 144
Oldest snapshot 144
Next transaction 154
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date May 3, 2007 10:10:37
Attributes force write
Variable header data:
*END*
Вставка происходит в представление. В триггере замещения
происходит обработка: вставляемая в BLOB поле информация обрабатывается UDF функцией на входе которой BLOB, на выходе тоже BLOB. Обработанное функцией значение, собственно, и помещается в таблицу.
Я понимаю, что вместо помощи проще всего высказать своё недоверие, нозвездеж 100%, не побоюсь этого слова.Цитата:
2. Добавляем ~2МБ информации (две транзакции)
3. Размер базы после добавления <90МБ
или в базе какие-нибудь триггеры, которые порождают из 2 мб входящих данных эти самые 90 мегабайт.
еще раз скажу:
1. В базе есть, безусловно, триггеры, но объема они не порождают.
2. Я уже писал, что после бэкапа и рэсторе размер базы уменьшается более чем на порядок.
3. Ниже приведена статистика базы данных текущий размер которой составляет 125288 К, после занесения ~5M
4. В базе происходит обработка вставляемой информации при помощи UDF.
5. Данные вставлялись в 2-е транзакции.
6. Сейчас размер Page size = 8192, как советовал hvlad
7. Проверить на Firebird 2 в настоящее время не представляется возможным.
Вот очередная статистика:
Код: Выделить всё
Database header page information:
Flags 0
Checksum 12345
Generation 847
Page size 8192
ODS version 10.1
Oldest transaction 137
Oldest active 842
Oldest snapshot 812
Next transaction 846
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date May 3, 2007 21:20:20
Attributes force write
Variable header data:
*END*
Database file sequence:
Database log page information:
Creation date
Log flags: 2
No write ahead log
Next log page: 0
Variable log data:
Control Point 1:
File name:
Partition offset: 0 Seqno: 0 Offset: 0
Control Point 2:
File name:
Partition offset: 0 Seqno: 0 Offset: 0
Current File:
File name:
Partition offset: 0 Seqno: 0 Offset: 0
*END*
Analyzing database pages ...
ANSWER_TB (128)
Primary pointer page: 139, Index root page: 140
Average record length: 28.96, total records: 500
Average version length: 0.00, total versions: 0, max versions: 0
Data pages: 136, data page slots: 308, average fill: 87%
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 16
60 - 79% = 5
80 - 99% = 115
Index FK_ANSWER_TB_TASK_TB (1)
Depth: 1, leaf buckets: 1, nodes: 914
Average data length: 0.00, total dup: 730, max dup: 4
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 0
60 - 79% = 1
80 - 99% = 0
Index PK_ANSWER_TB (0)
Depth: 2, leaf buckets: 2, nodes: 914
Average data length: 2.00, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 0
20 - 39% = 1
40 - 59% = 1
60 - 79% = 0
80 - 99% = 0
DISCIPLINE (129)
Primary pointer page: 141, Index root page: 142
Average record length: 25.00, total records: 2
Average version length: 0.00, total versions: 0, max versions: 0
Data pages: 1, data page slots: 1, average fill: 1%
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0
Index PK_DISCIPLINE (0)
Depth: 1, leaf buckets: 1, nodes: 2
Average data length: 1.00, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0
EVENTS_LOG (130)
Primary pointer page: 144, Index root page: 145
Average record length: 0.00, total records: 0
Average version length: 0.00, total versions: 0, max versions: 0
Data pages: 0, data page slots: 0, average fill: 0%
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0
PRN_TEMPLATES (131)
Primary pointer page: 146, Index root page: 147
Average record length: 25.50, total records: 2
Average version length: 0.00, total versions: 0, max versions: 0
Data pages: 1, data page slots: 1, average fill: 1%
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0
SECTION (132)
Primary pointer page: 148, Index root page: 149
Average record length: 30.00, total records: 4
Average version length: 29.00, total versions: 2, max versions: 2
Data pages: 1, data page slots: 1, average fill: 3%
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0
Index FK_SECTION_DISCIPLINE (1)
Depth: 1, leaf buckets: 1, nodes: 5
Average data length: 0.00, total dup: 3, max dup: 2
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0
Index PK_SECTION (0)
Depth: 1, leaf buckets: 1, nodes: 4
Average data length: 4.00, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0
TASK_TB (133)
Primary pointer page: 150, Index root page: 151
Average record length: 27.89, total records: 100
Average version length: 0.00, total versions: 0, max versions: 0
Data pages: 57, data page slots: 57, average fill: 70%
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 15
60 - 79% = 30
80 - 99% = 12
Index D_TASK_TB (2)
Depth: 1, leaf buckets: 1, nodes: 100
Average data length: 1.00, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0
Index FK_TASK_TB_SECTION (1)
Depth: 1, leaf buckets: 1, nodes: 100
Average data length: 0.00, total dup: 98, max dup: 49
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0
Index PK_TASK_TB (0)
Depth: 1, leaf buckets: 1, nodes: 100
Average data length: 1.00, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0
USED_TEST_COD (134)
Primary pointer page: 153, Index root page: 154
Average record length: 0.00, total records: 0
Average version length: 0.00, total versions: 0, max versions: 0
Data pages: 0, data page slots: 0, average fill: 0%
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0
Index FK_USED_TEST_COD (1)
Depth: 1, leaf buckets: 1, nodes: 0
Average data length: 0.00, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0
Index PK_USED_TEST_COD (0)
Depth: 1, leaf buckets: 1, nodes: 0
Average data length: 0.00, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0
5 мегабайт это 90 мегабайт? Возьми IBAnalyst и посмотри свою статистику. 5 мб - это копейки. особенно для базы с размером страницы 8к. При таком размере страницы пустая база будет ~2мб.Я понимаю, что вместо помощи проще всего высказать своё недоверие, но
у тебя в двух таблицах, ANSWER_TB 308 страниц и TASK_TB 57 страниц. Это чистых 3 мегабайта данных (при размере страницы 8к). Мог бы и сам умножить. С учетом остальных таблиц и индексов, и блобов, вполне может набежать 5 мегабайт.
Я вообще удивляюсь, в чем вопрос. 5 мегабайт - это так много? Да еще с учетом упаковки данных?
можно и не проверять. размер базы будет примерно одинаковым в пределах килобайт на ЛЮБОЙ версии IB/FB.7. Проверить на Firebird 2 в настоящее время не представляется возможным.
1. Я умножать умею, и статистику выложил по просьбе.
5 мегабайт это 90 мегабайт? Возьми IBAnalyst и посмотри свою статистику. 5 мб - это копейки. особенно для базы с размером страницы 8к. При таком размере страницы пустая база будет ~2мб.
у тебя в двух таблицах, ANSWER_TB 308 страниц и TASK_TB 57 страниц. Это чистых 3 мегабайта данных (при размере страницы 8к). Мог бы и сам умножить. С учетом остальных таблиц и индексов, и блобов, вполне может набежать 5 мегабайт.
Я вообще удивляюсь, в чем вопрос. 5 мегабайт - это так много? Да еще с учетом упаковки данных?
2. 5 мегабайт это не много. Еще раз: я говорю не об объёме реальных данных, коих действительно около 5 мегабайт, а о размере файла базы данных, который занимает после вставки 125 Мегабайт.
125 - 5 = 120. Меня интересует откуда у меня берется 120 мегабайт "воздуха". Собственно по каким причинам это может быть.
Блобы уровня выше 0 в статистике не отражаются. Предлагаю взять любую УДФ, показывающую р-р блоба, и посчитать р-р имеющихся блобов
Далее :
Далее :
Каковы размеры входных блобов, выходных блобов и есть ли промежуточные блобы ?вставляемая в BLOB поле информация обрабатывается UDF функцией на входе которой BLOB, на выходе тоже BLOB. Обработанное функцией значение, собственно, и помещается в таблицу
Да, OST похоже застрял и мусор не собирается - а это может препятствовать повторному использованию места.WildSery писал(а):Он утверждает, что "набежало" 125 Мб. Ставлю на место из-под мусора.kdv писал(а):С учетом остальных таблиц и индексов, и блобов, вполне может набежать 5 мегабайт.
Хотя мусорных версий записей в статистике почти нет, но настораживает явное не соответствие кол-ва версий в таблице ANSWER_TB (500) и кол-ва ключей в индексах (914).
Возможно и временные блобы так же где-то болтаются.
Имеет смысл проверить это на 2.0, т.к. там учёт блобов более качественный