Вопрос к DBA или спецу по Oracle?

[hren]

Я согласен с комментариями Tengiz'a. Хочу добавить только, что Oracle на многопроцессорной машине ведет себя существенно не так, как на однопроцессорной и на малом количестве ЦПУ и требует существенно других настроек. Как совершенно верно замечено, Вам следует начать с профилирования существующего приложения и проанализировать последствия перевода системы на параллельную генерацию отчетов.Сейчас, насколько я понял, они генерируются на каждой базе строго последовательно. Установка одного экземпляра СУБД на мощный сервер с хорошим storage поможет в случае, если значительное время расходуется на длинные чтения и/или если высока загрузка ЦПУ при низком уровне latch и enqueue waits. Первое мне кажется маловероятным, поскольку выборки у Вас не экстремально велики и должны хорошо кэшироваться при качественной настройке экземпляра. Или за время между генерациями отчета меняется значительный очень процент записей? Второе более вреоятно, но проблема может возникнуть при переходе к параллельной обработке без изменения архитектуры приложения. Я неоднократно наблюдал, как на многопроцессорных машинах начинается лавинообразное сильно нелинейное с ростом загрузки нарастание wait time за счет contention за системные ресурсы при достижении определенного уровня параллелизма. Ваша архитектура выглядит с этой точки зрения несколько подозрительно - переписывание в рабочие и финальные таблицы может быть источником конфликтов при параллельной обработке. Так что возможна ситуация, когда при переносе на одну машину Вам может оказаться выгоднее использовать несколько параллельно работающих экземпляров. Учитывайте, что такая конфигурация потребует суммарно больше оперативной памяти, чем один экземпляр под той же нагрузкой.

[verzlo]

Мои предложения:

1) 6 ДБА выгнать, так как это нужно быть глюпым совсем, чтобы в 21 веке до сих пор по 12 часов отчёты считать.

Я участвовал в проектах, где счётные финансовые задачи оптимизировались с двух недель до 40 минут, с итоговым переносом с восьмипроцессорного кластера на однопроцессорную Ультру. Архитектура процесса у вас хромает.

Соглашусь на 100% с предыдушими предложениями.. Очень часто, особенно когла речь идет о больших объемах данных, задачи которые могут работать за 5-10-15-20 минут работают по 12-24-36 и более часов, если что-то неправильно сконфигурировано в базе данных, или не оптимизирован SQL (на том же хардваре).
Последний личный пример: DW, 2.5 Tb data overall. After 9i migration the job was running 20 hours, abd before in 8i it was taken only 25 minutes to complete. Feel the difference. Оказалось, что вместо индекс сканов, Оракл все равно preffer fullt table scans, even if the statistics was analysed and hints was used to use spesific indexes. Вылечилось просто, изменением одного-единственного параметра в init.ora - OPTIMIZER_INDEX_COST_ADJ . Это я к тому что мож и не надо ничего покупать и вместо 6 серверов вам надо мож только 1.
В принципе ваше стремление решить все проблемы за счет покупки более мощного хардваре в коре не верны с оптимизационной точки зрения...
Если ваш ДБА не в состоянии ничего проанализировать -
Выпросите денег на Oracle консалтинг на 1-2 дня (можно не Обязательно native Oracle - но обязательно по рекомендации от людей, которые с ними имели дело). Они вам если не решат все проблемы ,то уж точно смогут проанализировать все и дать рекомендации, что улучшить и куда копать...

Если хотите сами разобраться, то установите Oracle statspack - (он бесплатный ), run the jobs to get the stats snapshots while runing your jobs/reports. Потом на основании этих snapshots you can generate statspack report и уже по нему можно определить, чего там у вас не так...
Также совет - исходя из вашего описания задачи, подход с выборкой миллиона записей, создания временных таблиц с ними, и потом удаления их очень decrease database performance overall, и желательно избегать таких операций и заменять их другими решениями.
Я не знаю по какому критерию отбираются данные, как часто они обновляются в основной базе, но помоему если правильно составлены индексы (если этого не достаточно, то можно доплнительно можно использовать partitionning), проводится регулярный сбор статистики по таблицам, то все дожно быть очень оперативно. Кстати если у вас проводятся какие-то вычисления, то вы можете сделать или function-based indexes или materialized views уже с этими вычислениями и на них наложить индексы...

[Dmitry67]

Если Вы оптимизировали сами то стоит просто взять ОЧЕНЬ ДОРОГОГО специалиста по Oracle на неделю
Вы съэкономите много денег
Возможно вообще ничего покупать не придется