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

[kosty]

Ситуация примерно такая. Есть железяка средней мощности под НТ. На ней [Oracle] с миллионами записей. там выполняются определенные вычисления и генерится [report]. Вычислений дофига и один [report] получается за 12 часов - два в сутки. Что маловато. Потому ставится еще одна точно такая железяка и там выполняется еще два [reports] в сутки. Что тоже маловато. В итоге получилось шесть одинаковых машин и, соответственно, 12 [reports] в сутки.

Сейчас возникла определенная потребность запихать все в одну машину.

Вопрос - а как? Даже если взять супер-пупер многопроцессорный монстр, то вытянет ли он 12 [reports] в сутки? Или повесить на этого монстра сразу 6 ДБ (я, честно скажу, больше двух под НТ не видел, под [UNIX] - три), то что на это скажет [OS]? И как они (ДБ) будут перформ? Слабоват я в этом. Т.е нужно 12 [reports] в сутки на одной машине. А как?

ПС. Оптимизация вычислительных процессов сейчас не рассматривается.

Спасибо.

[camel]

Ситуация примерно такая. Есть железяка средней мощности под НТ. На ней [Oracle] с миллионами записей. там выполняются определенные вычисления и генерится [report]. Вычислений дофига и один [report] получается за 12 часов - два в сутки. Что маловато. Потому ставится еще одна точно такая железяка и там выполняется еще два [reports] в сутки. Что тоже маловато. В итоге получилось шесть одинаковых машин и, соответственно, 12 [reports] в сутки.

Сейчас возникла определенная потребность запихать все в одну машину.

Вопрос - а как? Даже если взять супер-пупер многопроцессорный монстр, то вытянет ли он 12 [reports] в сутки? Или повесить на этого монстра сразу 6 ДБ (я, честно скажу, больше двух под НТ не видел, под [UNIX] - три), то что на это скажет [OS]? И как они (ДБ) будут перформ? Слабоват я в этом. Т.е нужно 12 [reports] в сутки на одной машине. А как?

ПС. Оптимизация вычислительных процессов сейчас не рассматривается.

Спасибо.

если на 6 машинах одни и те же данные и запускаются только репорты, т.е. нет оперативной обработки транзакций, то конечно лучше базу перенести на один мощный сервер, лучше под UNIX. Чтобы не получилось медленнее, чем было, сервер естественно должен быть производительный - не обязательно супер пупер, но по крайней мере раз в 8 мощнее, чем отдельные серверы, на которых это сейчас работает. т.е. 8 процессорный должен вроде бы подойти
можно и несколько баз запустить на таком сервере, хоть 12, но не вижу смысла - скорости это не прибавит

[kosty]

если на 6 машинах одни и те же данные и запускаются только репорты, т.е. нет оперативной обработки транзакций, то конечно лучше базу перенести на один мощный сервер, лучше под UNIX. Чтобы не получилось медленнее, чем было, сервер естественно должен быть производительный - не обязательно супер пупер, но по крайней мере раз в 8 мощнее, чем отдельные серверы, на которых это сейчас работает. т.е. 8 процессорный должен вроде бы подойти
можно и несколько баз запустить на таком сервере, хоть 12, но не вижу смысла - скорости это не прибавит

А можно немного подробнее, пожалуйста?

Шесть одинаковых серверов под NT с Oracle. Xeon 2.4GHz, 512K, 2x146GB.

Процесс примерно такой. Raw data - 100-150 млн записей. На основании спецификасии отбирается до 1млн записей в working table. С отобранной датой выполняются статистические вычисления, результаты - в final table. Из final data рисуются репорты. Потом вся working/final data выкидывается, и - все заново с новой спецификацией.

Вопрос тот же. Можно ли это все сделать на одной машине без потери производительности. Какая примерно это должна быть машина? Windows или UNIX? 1 ДБ или шесть? Как шесть уживутся вместе. Если одна, как исполнять: по одному в очередь или параллельно? И т.д.

Спасибо.

[chepackav]

А оптимизировать что-нибудь в базе пробовали? Индексы там всякие построить и прочее .... а то против table scans никакое железо не поможет.

[kosty]

А оптимизировать что-нибудь в базе пробовали?

Да, конечно. Ясно, что нельзя сделать идеально, но на данном этапе считается, что лучше не можем. Да лучше-то и не нужно. Нужно одну машину вместо шести.

[Mark]

А оптимизировать что-нибудь в базе пробовали?

Да, конечно. Ясно, что нельзя сделать идеально, но на данном этапе считается, что лучше не можем. Да лучше-то и не нужно. Нужно одну машину вместо шести.

Насчет оптимизации Вас не просто так спрашивают, потому как Ваше узкое место именно в ней, а то что вы поставите например одну RISC (Sun/IBM/HP)машину с 8/10/20 процессорами и дисковой стойкой EMC вам конечно поможет - но не так сильно как оптимизация. А про затраты на эту железяку я уж не говорю. Это вам не интеловые боксы с Зеонами.

[Ctrl-C]

Насчет оптимизации Вас не просто так спрашивают, потому как Ваше узкое место именно в ней

Присоединяюсь.

[kosty]

Насчет оптимизации Вас не просто так спрашивают, потому как Ваше узкое место именно в ней

Присоединяюсь.

Оптимизировали, скока хватило мозгов. Об этом можно спорить, но задача другая. Все нормально работает, все устраивает. Но, нужно (если можно) в одной коробке. Физически.

Это внутрикорпоративные финансовые взаиморасчеты. У нас в division нет своей бухгалтерии, потомы мы отчсляем копейку на бухгалтеров и т.д. За техподдержку и обслуживание одного сервера корпорация берет 15К/год. Шесть коробок - 90К. Я думаю, как сделать одну коробку. Я косты катаю. Пытаюсь.

[camel]

если на 6 машинах одни и те же данные и запускаются только репорты, т.е. нет оперативной обработки транзакций, то конечно лучше базу перенести на один мощный сервер, лучше под UNIX. Чтобы не получилось медленнее, чем было, сервер естественно должен быть производительный - не обязательно супер пупер, но по крайней мере раз в 8 мощнее, чем отдельные серверы, на которых это сейчас работает. т.е. 8 процессорный должен вроде бы подойти
можно и несколько баз запустить на таком сервере, хоть 12, но не вижу смысла - скорости это не прибавит

А можно немного подробнее, пожалуйста?

Шесть одинаковых серверов под NT с Oracle. Xeon 2.4GHz, 512K, 2x146GB.

Процесс примерно такой. Raw data - 100-150 млн записей. На основании спецификасии отбирается до 1млн записей в working table. С отобранной датой выполняются статистические вычисления, результаты - в final table. Из final data рисуются репорты. Потом вся working/final data выкидывается, и - все заново с новой спецификацией.

Вопрос тот же. Можно ли это все сделать на одной машине без потери производительности. Какая примерно это должна быть машина? Windows или UNIX? 1 ДБ или шесть? Как шесть уживутся вместе. Если одна, как исполнять: по одному в очередь или параллельно? И т.д.

Спасибо.

ок, немного подробнее:

Можно ли это все сделать на одной машине без потери производительности? конечно, можно (и нужно)

Какая примерно это должна быть машина? примерно 4-8 процессоров, память 4G, диски соответствующие, чтобы база поместилась и хотя бы последний бакап.

Windows или UNIX? лучше Unix, но Windows тоже можно

1 ДБ или шесть? лучше 1.

Как шесть уживутся вместе? прекрасно уживутся, если достаточно памяти, но не вижу в этом смысла - см. выше

Если одна, как исполнять: по одному в очередь или параллельно? конечно, параллельно - иначе зачем 8 процессоров?

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

[kosty]

ок, немного подробнее:

Спасибо-приспасибо. Я попозже еще спрошу, можно?

[camel]

Насчет оптимизации Вас не просто так спрашивают, потому как Ваше узкое место именно в ней

Присоединяюсь.

Оптимизировали, скока хватило мозгов. Об этом можно спорить, но задача другая. Все нормально работает, все устраивает. Но, нужно (если можно) в одной коробке. Физически.

Это внутрикорпоративные финансовые взаиморасчеты. У нас в division нет своей бухгалтерии, потомы мы отчсляем копейку на бухгалтеров и т.д. За техподдержку и обслуживание одного сервера корпорация берет 15К/год. Шесть коробок - 90К. Я думаю, как сделать одну коробку. Я косты катаю. Пытаюсь.

шесть баз администрировать тоже дороже выйдет, чем одну; да еще процедуры загрузки и синхронизации данных приходится наверное запускать в 6-кратном количестве; кстати, а ДБА у вас бесплатный, что ли? или его вообще нет?
это тоже аргументы в пользу одной базы на одном сервере

[kosty]

шесть баз администрировать тоже дороже выйдет, чем одну; да еще процедуры загрузки и синхронизации данных приходится наверное запускать в 6-кратном количестве; кстати, а ДБА у вас бесплатный, что ли? или его вообще нет?
это тоже аргументы в пользу одной базы на одном сервере

Не, DBA не бесплатный - корпоративный. Но ведь у меня сейчас и так 6 DB. И запускаем по 6 раз. Но если 6 DB на одной машине вдруг оказалось бы лучше, то дороже не станет. Хотя одна, конечно же, выглядит привлекательнее, если только хуже не станет.

[tengiz]

...Но ведь у меня сейчас и так 6 DB. И запускаем по 6 раз. Но если 6 DB на одной машине вдруг оказалось бы лучше, то дороже не станет. Хотя одна, конечно же, выглядит привлекательнее, если только хуже не станет.

Если даже оставить в стороне попытки оптимизировать 12-часовую процедуру вычисления отчёта, то анализ узкого места в системе всё равно нужно сделать. Иначе непонятно, что конкретно в этой одной системе должно быть в 6 раз больше/мощнее/производительнее, чтобы результирующее время подготовки отчётов было не хуже. Например, если все 6 исходных систем 99% времени из этих 12 часов проводят в IO, то для новой системы скорее всего будет достаточно шестикратного запаса по количеству физических дисков + соответствующей пропускной способности шины ввода/вывода + разумеется некоторого дополнительного количество памяти. Если затык с CPU - то это совсем другая история. Поэтому так или иначе, но разобраться и найти узкое место придётся. Но как только такой анализ будет добросовестно произведён, есть очень хороший шанс, что будет ясно, где можно будет оптимизировать собственно исходную задачу. Возможно, удастся вместо 12 часов ужать отчёты в 1 час - и тогда вообще ничего нового покупать не будет нужно вовсе .

[Дед Мороз]

1. Полностью согласен с Тенгизом.



2. Сколько длится каждый из этапов
В частности: сколько времени занимает выборка (только выборка!)
1 млн. записей из 150 млн ?
сколько стат. вычисления ?
сколько запись в final table ?

На каждом из этих этапов, что является bottleneck ?
Это я к тому, что оптимизировать и (самое главное), может на разных этапах bottleneck разный ?
Тогда можно запускать репорты через 2-4-6 часов, и пока один мучает диск, другой будет съедать процессор ....
(ессно, так в 6 раз не улучшишь, но в 2 - может быть )

[NightFlier]

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

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

2) Переносите базу на Мейнфрейм, там у вас любой вычислительной мощности хватит.

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

[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 на неделю
Вы съэкономите много денег
Возможно вообще ничего покупать не придется