mikkriТеперь бизнес хочет иметь доступ к данным в агрегированом виде, например, отобразить список заказов конкретного клиента удовлетворящих определенному критерию. В текущей реализации с довольно большим количеством индексов запрос может занимать 10-20 секунд. Но иногда оптимизатор Оракла решает сделать full table scan, который занимает порядка 20-30 минут минимум. Пользователь, разумеется, открывает приложение еще и еще и запускает тот же запрос. В результате имеем проблемы с OLTP из-за "неправильных" OLAP запросов.

Какие идеи "приходили в голову":

1) установить Oracle RAC и просто задавить проблему индексами и серверами
2) реплицировать БД онлайн в другую БД (уверен, задержку до 1 минуты мы сможем "продать" бизнесу, но не больше). В качестве другой БД:
а) Oracle
b) Sybase IQ
3) использовать TimesTen, который бы загрузил все "актуальные" данные в память с минимальной задержкой.
4) использовать Data Grids

С точки зрения реализации 1 и 2 выглядят как самые адекватные с точки зрения количества изменений в коде и возможности добиться результата.

Было б интересно услышать ваши соображения и, может быть, узнать об альтернативных вариантах.

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

Конечно, это всего лишь предположения о том, что моно проверить перед рассмотрением решений предложенных в в перечне. Тем более что они никада не помешают.

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


Репликация связана все же с распределенными БД: применение ее для повышения производительности может выглядеть без дополнительных сведений как применение не по назначению. Реальный кластер как бы задумывался для горизонтального масштабирования. Это как бы ближе. Но все же луче быть уверенными, что другте средства Оракла использованы на 100 процентов.