iBase.ru Forum

При добавлении данных (порядка 500кБ.) в базу данных в одной транзакции (степень изоляции READ COMMITED, параллельных транзакций нет) наблюдается очень сильное распухание базы данных.
Версия сервера Firebird 1.5.3
Подскажите пожалуйста на что мне стоит обратить внимание чтобы решить эту проблему.

Сдаётся, никакой проблемы нет, и "сильного распухания" тоже. Наверняка система просто выделила очередной кусок дискового пространства для базы, когда в уже отведённое место перестало влезать.
Или она у тебя на гигабайт сразу "опухла"?

Я знаю, что такое выделение нового куска.
Когда говорю сильно, значит сильно.
Теперь подробнее:
1. Пустая база из скрипта ~300кБ.
2. Добавляем ~2МБ информации (две транзакции)
3. Размер базы после добавления <90МБ
4. Делаем бэкап/рэсторе: размер базы ~4МБ

Если добавлять еще, то и дальше пухнет. До гигабайта правда не дошло.

Дай-ка статистику по БД до и после вставки записей (которая gstat -h). Ну и расскажи, как ты это делаешь?

Вот статистика:

Код: Выделить всё

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 поля.
Вставка происходит в представление. В триггере замещения
происходит обработка: вставляемая в BLOB поле информация обрабатывается UDF функцией на входе которой BLOB, на выходе тоже BLOB. Обработанное функцией значение, собственно, и помещается в таблицу.

Страницу нормального размера сделай. 4К или 8К

Страницу нормального размера сделай. 4К или 8К

Сделал 8К -- результат тотже: база пухнет.

Можно попросить употреблять цифры, а не словами описывать размеры и прочее? Каков теперь размер БД после вставки? На FB 2.0 воспроизводится ситуация?

ivl писал(а):
Страницу нормального размера сделай. 4К или 8К
Сделал 8К -- результат тотже: база пухнет.

gstat -r показывай

2. Добавляем ~2МБ информации (две транзакции)
3. Размер базы после добавления <90МБ

звездеж 100%, не побоюсь этого слова.
или в базе какие-нибудь триггеры, которые порождают из 2 мб входящих данных эти самые 90 мегабайт.

Можно и проще. Эти два мегабайта раз 50 проапдейтить.

Цитата:
2. Добавляем ~2МБ информации (две транзакции)
3. Размер базы после добавления <90МБ
звездеж 100%, не побоюсь этого слова.
или в базе какие-нибудь триггеры, которые порождают из 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

В какой из таблиц блобы ?

BLOB'ы в таблицах ANSWER_TB и TASK_TB.
В них и производится вставка большего объёма информации.

Я понимаю, что вместо помощи проще всего высказать своё недоверие, но

5 мегабайт это 90 мегабайт? Возьми IBAnalyst и посмотри свою статистику. 5 мб - это копейки. особенно для базы с размером страницы 8к. При таком размере страницы пустая база будет ~2мб.

у тебя в двух таблицах, ANSWER_TB 308 страниц и TASK_TB 57 страниц. Это чистых 3 мегабайта данных (при размере страницы 8к). Мог бы и сам умножить. С учетом остальных таблиц и индексов, и блобов, вполне может набежать 5 мегабайт.

Я вообще удивляюсь, в чем вопрос. 5 мегабайт - это так много? Да еще с учетом упаковки данных?

7. Проверить на Firebird 2 в настоящее время не представляется возможным.

можно и не проверять. размер базы будет примерно одинаковым в пределах килобайт на ЛЮБОЙ версии IB/FB.

kdv писал(а):С учетом остальных таблиц и индексов, и блобов, вполне может набежать 5 мегабайт.

Он утверждает, что "набежало" 125 Мб. Ставлю на место из-под мусора.

5 мегабайт это 90 мегабайт? Возьми IBAnalyst и посмотри свою статистику. 5 мб - это копейки. особенно для базы с размером страницы 8к. При таком размере страницы пустая база будет ~2мб.

у тебя в двух таблицах, ANSWER_TB 308 страниц и TASK_TB 57 страниц. Это чистых 3 мегабайта данных (при размере страницы 8к). Мог бы и сам умножить. С учетом остальных таблиц и индексов, и блобов, вполне может набежать 5 мегабайт.

Я вообще удивляюсь, в чем вопрос. 5 мегабайт - это так много? Да еще с учетом упаковки данных?

1. Я умножать умею, и статистику выложил по просьбе.
2. 5 мегабайт это не много. Еще раз: я говорю не об объёме реальных данных, коих действительно около 5 мегабайт, а о размере файла базы данных, который занимает после вставки 125 Мегабайт.
125 - 5 = 120. Меня интересует откуда у меня берется 120 мегабайт "воздуха". Собственно по каким причинам это может быть.

Блобы уровня выше 0 в статистике не отражаются. Предлагаю взять любую УДФ, показывающую р-р блоба, и посчитать р-р имеющихся блобов
Далее :

вставляемая в BLOB поле информация обрабатывается UDF функцией на входе которой BLOB, на выходе тоже BLOB. Обработанное функцией значение, собственно, и помещается в таблицу

Каковы размеры входных блобов, выходных блобов и есть ли промежуточные блобы ?

WildSery писал(а):
kdv писал(а):С учетом остальных таблиц и индексов, и блобов, вполне может набежать 5 мегабайт.
Он утверждает, что "набежало" 125 Мб. Ставлю на место из-под мусора.

Да, OST похоже застрял и мусор не собирается - а это может препятствовать повторному использованию места.
Хотя мусорных версий записей в статистике почти нет, но настораживает явное не соответствие кол-ва версий в таблице ANSWER_TB (500) и кол-ва ключей в индексах (914).
Возможно и временные блобы так же где-то болтаются.

Имеет смысл проверить это на 2.0, т.к. там учёт блобов более качественный

Каковы размеры входных блобов, выходных блобов и есть ли промежуточные блобы ?

Промежуточных блобов нет.
Выходные (хранимые) меньше входных.
Входные колеблются в размере от 150Байт до 2-4Кб.

iBase.ru Forum

Расухание базы данных

Расухание базы данных