Rent_yДобрый день. Столкнулся с такой ситуацией что при загрузке базы при помощи dbimport при размере физического журнала 1 Гб, и 100мб при одинаковой частоте выполнения контрольных точек при меньшем размере журнала база загружается примерно на 25% быстрее.
С трудом верится в такой результат, хотя все относительно.
Если в первом случае утилита работала 20 сек, а во втором 15 сек, то такую погрешность в 5 сек. тоже можно считать в 25% :), но это не основание делать выводы, которые были выше.
Т.о. приведите конкретные цифры, условия сравнения, хотя бы кусочки из лога сообщений в периоды загрузки, чтобы можно было увидеть срабатывания КТ, отсутствие бэкапов и т.п.
И вообще, в чем здесь смысл ? У вас ведь импорт базы не является регламентной работой, под которую надо конфигурировать сервер ?

Rent_yИнтересует можно ли под все пространства выделить место с 2-х, 3-х кратным запасом и забыть про проблемы связанные с нехваткой места - или наличие большого количества неиспользуемых чанков (или одного чанка(под физический журнал например) большого размера при использовании только 10-20% его размера) негативно сказывается на внутренней работе информикса что приводит к падению производительности?
"Вопрос философский" :)
Я часто повторяю - "За все надо платить". Уверен, что и в данном случае это также верно.
При больших размерах нужно дольше искать, держать больших размеров служебные области и т.п.
Насколько "дольше" ? на доли % или на целый % - не знаю.
Опять таки, уменьшение дополнительной работы для админа тоже ведь трудно измерить (геморой он всегда трудно измерим :).
Помню, когда в одной из версий появилась возможность делать чанки более 2ГБ многие админы , задолбанные постоянным разбиением на кусочки, тут же решили посоздавать 100ГБ чанки. Оказалось, в сравнении, плоховато для производительности. Откатились назад, но к размеру 10-15Гб. Вроде лучше стало. Но вряд ли кто то скажет точные цифры ухудшение (а может в некоторых случаях и улучшения) производительности от размера - слишком много косвенных параметров на это влияет.
Я всегда сторонник оптимальности размера того же физжурнала - есть некоторые начальные рекомендации, создали, помониторили, изменили, помониторили и ... не трогаем.