Использование Oracle RAC

[Gandrew]

При заявленной Ораклом поддержки одновременной работы сотни тысяч пользователей - вы уверены, что вам все-таки нужен кластер (хотя вроде и для интернет-серверов и коротких транзакций)? Может дешевле взять спеца по Ораклу и решать проблемы другим способом? Хотя и спектр возможных действий ограничен манипулированием табличными пространствами, распределением ресурсов и оптимизатором, но и это может дать приемлемый результат? Можно рагрузить сервер и за счет распределения БД.

[gavrilyukmg]

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

[prometey]

Оно конечно как бы переезжает и даже работает, только вот будут проблемы с одновременной работой :)) 10 человек может и будут работать, но вот 50 - вряд ли. А о большем количестве даже можно и не говорить (искренне надеюсь что там больше человек, ибо покупать рак для 10-ти человек крайне странно). Будут постоянно вылезать странные ошибки доступа. Да и в текущей архитектуре тормоза, к сожалению, будут дикие. Т.е. если у нас заявлено что рак не поддерживается, значит он не поддерживается (пока что ;)), и вы будете использовать его на свой страх и риск :). И то что он сейчас вроде как на тестах работает, еще не значит что в промышленной эксплуатации он будет работать так же отлажено. Очень странное решение покупать один из элементов системы как СУПЕР НАДЕЖНЫЙ в то время как второй элемент системы в купе с ним будет НЕ СОВСЕМ НАДЕЖНЫМ. Т.е. система из 2-х элементов будет надежна только тогда, когда оба элемента не только по отдельности надежны, но и в купе ;). А сейчас об этом говорить не приходится.

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

[gavrilyukmg]

Все это хорошо. Мы тоже читали документацию, форумы, где люди делились своим опытом. Но руководство форумам и документации не верит, требует доказательств: логов, по которым было бы ясно, где идет потеря производительности и почему, какие то реальные ошибки. А у нас кроме потери производительности по закрытию счетов например с 3 часов на 7-ке до суток на кластерной 8-ке, при том что не формируется логов с ошибками - короче говоря, как мне доказать всю несостоятельность данной идеи, какие протоколы можно получить( может тестирование какое-нибуть) подскажите пожалуйста Стрелочнику очень нелегко

Если можно подробнее

[Gandrew]

Отказоустойчивость я так понял подразумевает если вдруг молния ударит в сервер, тогда его задачу подхватит второй? Т.к. отказостойчивость дисков можно обеспечить другими способами. Да и имея второй сервер можно и по-иному решать задачу - вынесете диски в стойку если процессор умрет переключите стойку на другой сервер - это займет 10 минут. А фирменные серверы умирают крайне редко - чаще летят диски.
А для руководства, верить по вопросам производительности можно только спецу по Ораклу который имеет сертификат самого представительства Оракла и имеющий опыт работы не менее 5-10 лет в данной области. Когда он проведет анализ работоспособности, задач и настройки ваших серверов и вы отвалите ему только за это штук 30000 минимум, тогда такому мнению стоит доверять. Какие-то замеры, логи и т.д. сделанные людьми плохо представляющие внутренние механизмы работы Оракла имеют мало научной ценности. Либо необходимо иметь четкие рекомендации - установите такие-то параметры работы и замерте время выполнения такой-то задачи или запроса.

[gavrilyukmg]

Стала проверять эмпирически: на 7-ке процесс идет 2 часа, на кластере более суток. Сейчас на одной ноде проверяем с трассировкой. А на счет спеца - Ораклом для 8-ки на кластере занимается человек без опыта работы, но очень способный, знающий. Ну и консультации берущий, конечно.

Времени жалко потраченного впустую ужастно (, и самое противное - если не на кластере, то вообще переход на 8-ку будет отменен. Маячит 1с......на 2010 год. На Галактике 7-ке под нас специально писались патчи по зарплате - их нет в 8-й версии, к сожалению.(zar16spec, tab_sv_pr, tab_sv_pr1, zar16fix28 - и это не все еще. Карзюк писал, в частности, и исходников, естественно, нет.)

[prometey]

Можете проверять с трассировкой на раке. Только смысл? Вы мало что сможете изменить. Если по поводу производительности работы не в раке, то могу посоветовать вынести активные журналы повторного выполнения на отдельные физические устройства. Кроме этого, так же разнести по разным физ. устройствам ТП данных и индексов. Если всё же решитесь проанализировать результаты трассировок (не в раке), то по построенным профилям ресурсов вы поймете, что больше всего времени тратится на работу клиентского приложения. На 2-м и 3-м местах обычно маячат log file sync (мы можем уменьшить влияние вынеся акт. журналы на отдельный диск) и одноблочные/многоблочные чтения (в основном будут одноблочные, ибо жестко юзаются индексы). Иногда в верхние ряды вклиниваются события ожидания передачи данных по сети. Это можно пофиксить настройками NET*8. А что касается рака - то тут вы мало что сможете сделать настройками. Ну вот такая пока что архитектура, которая не дружит с раком. По поводу тяжелой участи стрелочника, тут могу посоветовать только гонять тесты на раке, при чем с как можно более большим количеством человек. И еще раз - рассмотрите идею со стендбаем. Она позволит построить отличную отказоустойчивую систему и при этом с меньшими трудозатратами и мучениями с раком :)

[Screw]

Уважаемая Марина!
Из спецпатчей (перенесены также в zar16fix28):
106.8450 - решение проблемы поставляется в компонентах wt.dll.8.10.0.3 и z_wt.res.8.10.0.3
102.66768 - extfunwt.res.8.10.3.0
102.66768 - wt.dll.8.10.0.3
101.35499 - g_zarpl.dll.8.10.0.18

tab_sv_pr* - не из числа официальных. Если я приложил руку к их созданию, то буду рад помочь в восстановлении потерянного кода. Предлагаю продолжить обсуждение вопроса в личной почтовой переписке.

[Gandrew]

Если причина падения производительности в клиентской подсистеме то конечно никакими настройками Оракла это не победить.
В противном случае, если уверены в дисковой подсистеме (и не планируете восстанавливать БД по журналу) попробуйте режим nologing
Для курсоров попробуйте
cursor_sharing = similar
cursor_space_for_time = TRUE
Поиграйтесь оптимизатором (не забудте собрать статистику), например
optimizer_index_caching = 90
optimizer_index_cost_adj = 50
optimizer_mode = FIRST_ROWS

[cruger]

Не знаю, как насчёт конкретно этого алгоритма, но доподлинно известно, что есть системные алгоритмы, которые приводят к тормозам. Повторюсь - поддержка (ака оптимизация) в ближайших планах.

[prometey]

Андрей, можно поинтересоваться, в результате каких исследований и умозаключений был сделан вывод, что в данном случае помогут Ваши рекомендации с настройками указанных параметров? :)

[Gandrew]

Экспериментальным на версии 712 (прочитав несколько статей по Ораклу)
Установка таких параметров для курсоров ускорило запуск и навигацию по некоторым интерфейсам (УМП) раза эдак в 1,5-2.
Включение и подбор параметров оптимизатора существенно повысило быстродействие ряда отчетов (Отчет по реализации в разрезе контрагентов вообще висел), т.к. использование составных индексов не всегда быстрее безиндексного доступа.
Про версию 5 атлантиса ничего пока сказать не могу.

[cruger]

Сообщаю, что с 5.4.22 Атлантис не то, что б официально поддерживает RAC, но доработки, связанные с устранением принципиальных причин неработоспособности и явной причиной замедления, выполнены.
Если будет интерес заказчиков, то на их площадке можно будет устроить тестирование работоспособности и производительности используемых алгоритмов.