Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2007.01.07;
Скачать: [xml.tar.bz2];

Вниз

Размер базы *.gdb   Найти похожие ветки 

 
alex_sz   (2006-10-20 22:37) [0]

Приветствую всех! Есть база *.gdb. В одном из полей хранится фотка в формате bmp. Таких фоток пару тысяч. Средний размер 250 кб. Размер базы около 700 мб. Делаю коверт всех фоток в базе в jpg. Получаю размер фото от 5 до 15 кб. Размер базы увеличился почти в два раза. Замена фоток происходит с помощью update. Почему так раздулась база?


 
Desdechado ©   (2006-10-20 22:59) [1]

потому как IB сам решает, когда ему использовать освободившееся место в файле, а когда новое загребать
видимо, фрагментация места не позволила ему использовать старое место в большиннстве случаев
о формате и механизмех управления местом читать ibase.ru


 
PEAKTOP ©   (2006-10-21 10:20) [2]

Потому, что IB пометил все старые записи как удаленные и добавил новые.
Поэтому у тебя база сейчас "старые записи"(МБ)+"новые"(МБ).
backup/restore тебе поможет.


 
Zacho ©   (2006-10-21 10:51) [3]

PEAKTOP ©   (21.10.06 10:20) [2]
backup/restore тебе поможет


Небольшое дополнение:

Да, b/r возможно уменьшит размер БД, но прежде автору вопроса следут подумать - а надо ли ему это ?
Сейчас в БД есть неиспользуемые страницы, которые будут использованы при последующих вставках/модификациях данных. Кстати, насколько помню, после ресторе в новой БД всё равно будет 50% чистых страниц (если не использовать ключ -use_all_space)
Если же "ужать" БД до минимума, то при последующих вставках/модификациях данных сервер должен будет увеличивать размер файла БД, что существенно более затратно, чем использование свободного места в уже существующем файле.
Вобщем, выбирай - оставить как есть, или "сжать" БД и, возможно, получить тормоза в дальнейшей работе.

PEAKTOP ©   (21.10.06 10:20) [2]
Поэтому у тебя база сейчас "старые записи"(МБ)+"новые"(МБ).


Необязательно именно так. Сервер вообще-то использует место, освободившееся в результате удаления записей.


 
PEAKTOP ©   (2006-10-21 12:35) [4]

> (если не использовать ключ -use_all_space)
Мне что-то казалось, что ключ USE_ALL_SPACE необходим, когда делаешь ресторе поверх старой базы. Тогда происходит "дефрагментация страниц", но размер файла все равно остается тем же, просто в конце - пустые страницы


 
Desdechado ©   (2006-10-21 19:12) [5]

> после ресторе в новой БД всё равно будет 50% чистых страниц
AFAIR, меньше
Причем дело не в страницах, а в месте на страницах. Ведь блоб может быть больше одной страницы, а может и несколько блобов на одну страницу вместиться.

> Сервер вообще-то использует место, освободившееся в результате удаления записей.
Если при создании БД (или потом явно) выставлен SWEEP_INTERVAL > 0 (по умолчанию он >0). Или gfix прогонялся с параметром sweep. В остальных случаях это место остается навечно занятым мусором...

> казалось, что ключ USE_ALL_SPACE необходим, когда делаешь ресторе поверх старой базы.
Этот ключ большей частью нужен для read-only баз, особенно на компашках.


 
Romkin ©   (2006-10-21 21:59) [6]


> Мне что-то казалось, что ключ USE_ALL_SPACE необходим, когда
> делаешь ресторе поверх старой базы.

Из серии "слышал звон". А описание прочитать? Этот ключ использует пространство страницы под имеющиеся данные на 100%, тогда как обычно - на 80, для версий.

> Если при создании БД (или потом явно) выставлен SWEEP_INTERVAL
> > 0 (по умолчанию он >0). Или gfix прогонялся с параметром
> sweep. В остальных случаях это место остается навечно занятым
> мусором...

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


 
Romkin ©   (2006-10-21 22:04) [7]

http://www.ibase.ru/devinfo/sweep.htm


 
Desdechado ©   (2006-10-22 16:13) [8]

2 Romkin ©
Да, подзабыл я немного. При чтении действительно старые версии читаемых записей в утиль списываются.



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2007.01.07;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.47 MB
Время: 0.01 c
15-1166435828
AntiUser
2006-12-18 12:57
2007.01.07
Индийские опсосы подверглись хакерской атаке


2-1166260979
VitV
2006-12-16 12:22
2007.01.07
Использование DLL созданных в Дэлфи в VC


15-1166426041
data
2006-12-18 10:14
2007.01.07
Еще одна спортивная ветка)


2-1166521831
Slimer
2006-12-19 12:50
2007.01.07
Печать таблицы с неопределенными столбцами


1-1163765000
laronov
2006-11-17 15:03
2007.01.07
выделение в ComboBox





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский