Всем доброго
пытаюсь переделать схему базы, и вот, что беспокоит...
сейчас база с областями I типа. Переходим на II. После проведенного анализа было принято решение выделить одну таблицу в отдельную облать, и вот, что получается:
dbanalys по исходной базе(по интересующей таблице):
PUB.jl 23265867 3.9G 87 318 181 23272221 1.0 1.0
текстовый дамп таблицы весит 4.75 GB.
воспользовавшись всем известным трудом ‘Best Practices’ for Records-Per- Block Settings взял RPB для области 32.
сделал загрузку, и в итоге, размер файла на диске для этой области(в которой только одна таблица jl) получился 5.81Gb. Индексы не в этой области!
ээээ.... беспокоит такое большое расхождение с текстовым дампом. почти в 1Gb. Неужели столько служебной информации? Или может я все-таки не достаточно глубоко изучил 'известный труд' ?
Размер области
Re: Размер области
Средний размер записи - 181 байт. С RPB 32 в блоках в среднем будет заполнено 5792 байт из 8192, т.е. 2400 байт останется свободным - при том что по умолчанию Progress резервировал бы всего 300 байт (toss limit). Область получилась в 1.41 (=8192/5792) раз больше чем могла бы быть.
Здесь подошел бы RPB 64. Записи не сильно различаются по размеру - от 87 до 318 байт. В старой области число фрагментированных записей было крайне незначительным: 6354 из 23265867 записей. Значит много свободного места резервировать в каждом блоке не нужно, значения по умолчанию вполне хватит.
Здесь подошел бы RPB 64. Записи не сильно различаются по размеру - от 87 до 318 байт. В старой области число фрагментированных записей было крайне незначительным: 6354 из 23265867 записей. Значит много свободного места резервировать в каждом блоке не нужно, значения по умолчанию вполне хватит.
Re: Размер области
Спасибо, помогло. Поставил RPB64.
PUB.jl 23265867 4.0G 87 327 185 23265867 1.0 1.0
Правильно-ли я понимаю?: ссылаясь на ваши вычисления, при RPB64, вероятность того, что записи будут дефрагментированны между блоками гараздо больше, чем при RPB32, так как в среднем в блоке должно быть 11584 байт из 8192.
Даже наверно вопрос такой: что происходит, когда блок подходит к заполнению и новая запись полностью не влазит в блок? Она полностью идет в следующий, или разбивается между двумя? И в случае 'разбиения', что получается лучше: читать 1 блок с диска для извлечения записи, но иметь в этом блоке относительно много пустоты, или-же более часто читать по 2 блока для извлечения какой нибуть одной записи?
Может есть где почитать на эту тему?
Заранее спасибо.
PUB.jl 23265867 4.0G 87 327 185 23265867 1.0 1.0
Правильно-ли я понимаю?: ссылаясь на ваши вычисления, при RPB64, вероятность того, что записи будут дефрагментированны между блоками гараздо больше, чем при RPB32, так как в среднем в блоке должно быть 11584 байт из 8192.
Даже наверно вопрос такой: что происходит, когда блок подходит к заполнению и новая запись полностью не влазит в блок? Она полностью идет в следующий, или разбивается между двумя? И в случае 'разбиения', что получается лучше: читать 1 блок с диска для извлечения записи, но иметь в этом блоке относительно много пустоты, или-же более часто читать по 2 блока для извлечения какой нибуть одной записи?
Может есть где почитать на эту тему?
Заранее спасибо.