Упаковка таблиц Interbase

← →
AlexPul (2003-09-19 17:21) [0]

Возникала ли у кого-то проблема со значительным увеличением размера файла базы после интенсивной работы с ней, хотя данных в ней не так-то уж и много. Как с этой проблемой бороться? (способы, алгоритмы, ссылки и инете)

← →
stud (2003-09-19 17:22) [1]

bukup / restore

← →
Val (2003-09-19 17:44) [2]

а ссылочка все та же... :)

← →
AlexPul (2003-09-19 17:47) [3]

>stud
bukup / restore не сжимает а создает backup базы

← →
Val (2003-09-19 17:51) [4]

>AlexPul (19.09.03 17:47) [3]
сначала читаем литературу, потом спорим.

← →
kaif (2003-09-19 19:15) [5]

Кстати, то, что база быстро растет, не есть ненормально.
Нужно так разрабатывать базу, чтобы быстро не росла. Я добивался уменьшения этого эффекта, тщательно изучая, что я делаю, и экспериментируя с транзакциями, особенно при массовых update-ах. Например, после такого update-а я делаю select count(*) в отдельной транзакции.
На сегодня база после 3-х месяцев работы без backup/restore имеет размер 14 Mb. Если сделать backup/restore ее размер сокращается до 12 Mb. Таким образом, "излишек" составляет не более 20%. В сети с базой работают 3-5 юзеров и каждый день в нее вносятся какие-то данные плюс перепроводятся какие-то документы в таблице проводок.
Если база быстро росла на стадии разработки, это еще ничего (возможно, приходилось делать массовые перекачки данных и т.п.) Однако потом следует сделать backup/restore и смотреть ее в реальной работе (у юзеров). Если база быстро растет - нужно понять, почему.

← →
Sergey_Masloff (2003-09-19 19:28) [6]

kaif © (19.09.03 19:15) [5]
Все что ты говоришь верно, но зачем эта экономия? При современных HDD что 12 Мб что 120 что 1200 - одна фигня. Скажу более - селект каунт в отдельной транзакции при базе размером побольше выльется в серьезные тормоза. Поэтому на больших базах иногда имеет смысл отказаться вообще от автоматической сборки мусора а мусор убирать только плановыми бакуп-ресторами. На базе в 12 Мб (я не говорю что это мало, может задача такая) ты просто не замечаешь тормозов хотя и выигрыш в месте невелик.

← →
kaif (2003-09-19 19:40) [7]

Sergey_Masloff (19.09.03 19:28) [6]
Все что ты говоришь верно, но зачем эта экономия?
Я замечал, что при увеличении файла (именно файла !) базы падает скорость SQL-запросов. Поэтому если база может занимать 10 Mb, а занимает 60, то все работает медленнее. И если скорость select-ов критична, а скорость update-ов - нет, то имеет смысл следить за этими вещами.
Я не спорю, что при больших базах возможна иная политика.
Однако, что касается select count(*), то все равно эта задержка произойдет у любого другого пользователя который после массового update-а попробует сделать свой select. Мне кажется, что лучше, если "нагрузка" ляжет на того, кто предпринял больщой update, чем на того, кто решил взглянуть на простой отчет. Так как последний может решить, что программа зависла и удалить ее из списка задач. А это неверное решение.
Автор ветки говорит о "значительном" увеличении размера
хотя данных в ней не так-то уж и много
поэтому я и решил высказаться в таком ключе.
Дело в том, что при первых экспериментах с массовыми update-ами, я действительно получал прирост в 5-10 Mb после каждого такого update-а. И я скажу, что скорость SQL-запросов четко зависит от размера базы. По крайней мере при десятках тысяч записей в таблицах она падала чуть ли не пропорционально размеру. На миллионах я не смотрел, не знаю.

← →
WihOut Any ... (2003-09-19 20:15) [8]

оратись к sniknik, он мне часто помогал

← →
Sergey_Masloff (2003-09-19 20:18) [9]

>И я скажу, что скорость SQL-запросов четко зависит от размера >базы. По крайней мере при десятках тысяч записей в таблицах она >падала чуть ли не пропорционально размеру.
Не должно влиять. По крайней мере сколько-нибудь заметным образом. Надо смотреть планы запросов и реальную производительность, может индексы перестроить но не должно так тормозить с ростом файла.
Впрочем на базе у которой при размере 10 Мб после массового update росто почти на 50% я бы работал так же как ты.

Упаковка таблиц Interbase Найти похожие ветки