SERG1257,

Вообще-то это нормальная ситуация - объем данных растет операционная база пухнет, - начиная с какого-то момента никакие планы не спасают от тормозов. Для этого и создается хранилище чтобы там держать исторические данные, а в операционной - только небольшой временной промежуток.

Насчет профессиональной репликации - опять-таки, не совсем согласна - зависит от сложности задачи/объема данных, а то ведь и из пушки по воробьям может получиться. На одном из начальных этапов/для задач где не прогнозируется большой рост объемов или нагрузки, работа на триггерах вполне может послужить сносным решением.. Конечно предварительно надо оттестится насколько это повысит нагрузку на операционную базу, ну и vippiзабирать, парсить и скидывать в отчётную БД. - это все конечно на ночь или в моменты сниженной нагрузки накрайняк, - в зависимости от того каковы требования на сроки обновления данных в хранилище.
А потратить деньги на всевозможные ETL-инструменты - это никогда не поздно, - главное чтоб оправдано было.

vippi - а сейчас у вас операционная база и хранилище - это по структуре/объему данных одно и то же или нет?
Если у вас пользователи имеют возможность создавать произвольные запросы, то чтобы это работало прилично вам по любому придется покрывать все индексами по максимуму - только делать это нужно будет в хранилище а не в операционной базе, - ну на то оно и хранилище - здесь мы жертвуем размерами БД и скоростью вставки в обмен на скорость выборки.
Что-то упоминалось про денормализацию... вы собираетесь создавать отдельную структуру хранилища или как?

И, - можете озвучить примерный объем данных операционной базы, объем хранилища и объем прироста дынных в хранилище за день? И прогнозы по росту?

SERG1257 Это не нормальная ситуация, чтобы быть нормальной оно должно поддерживаться авторами софта.
Ну здесь частично согласна, но ведь не все предусматривают. Ну к примеру, классические продажи. Храните вы их в базе за год, два, три... если у вас ко всему прочему еще и успешная компания, через пяток лет база по-любому распухнет. А терять все это никто не хочет, ибо это бесценные данные с точки зрения анализа: что продавали, кому и как. Имея эти данные можно просчитать что, кому и как надо продавать чтобы максимально эффективно было.

SERG1257Далее - имеем тормоза - я предлагаю разобраться чем они вызваны - в какие моменты, какие процедуры и т.д. Без этого любая настройка не имеет смысла.
Я не спорю с тем, что с этого надо начинать, но рано или поздно наступает момент, когда это перестает спасать. Ну все, - все попадает в индексы, статистика обновлена, запросы оптимальны и т.д. и т.п. ну объективно - а посчитать отчет - 6 часов.

SERG1257самописная репликация - склад граблей со стороны пользователей приложения.
А вы думаете, если писать перенос используя профессиональный ETL инструмент граблей будет меньше? И там и там люди пишут. Согласитесь, это зависит от кривизны рук пишущего.

SERG1257AnyaNartova вам по любому придется покрывать все индексами по максимумуЩаз. Начинать надо опять от пользователей от статистики запросов, и требований бизнеса. Пользователи не выдают совсем произвольных запросов, а для типичных надо протоптать дорожку, выбрать идеальный план, убедится что он используется. Плохо если приложение выдает динамический запрос прямо к базе, тогда ой.
А что такое ad-hoc запросы, - вы не слышали? Это собственно оно самое и есть - динамический запрос прямо к базе.
Собственно, это первый шаг на пути к реальной аналитике, и случается он, когда простых статических отчетов уже нехватает. Дальше идет уже продвинутая аналитика и прогнозирование.
Эти динамические запросы, - убийство для большинства баз, - вот и придумали обходные маневры: OLAP-решения, где все аггрегаты посчитаны заранее; чисто железячные и супер-дорогие с MPP-архитектурой типа Terradata; базы с хранением данных по колонкам типа Sybase IQ, и т.п.

SERG1257подобные мелочи делают вопрос постороения отчетов в OLTP системе неоднозначным.
Вот! Вот это как раз и есть камень преткновения. Я полностью согласна с тем, что в OLTP нельзя гонять ad hoc, в том числе и по описанным вами причинам. Такие вещи возможны только в хранилищах, - где данные и структура подготовлены специальным образом и очищены. К примеру - null в правильно построенном хранилище должен отсутствовать как класс.

Ладно, давайте и правда закроем тему, а то мы уже далеко удалились от ТС.