Очередная небольшая революция - переход на Oracle

[gl00mie]

Цитата:

Сообщение от sukhanchik

как минимум индексы применяются по-другому и то, что раньше "летало" - могло существенно затормозиться

Да уж, теперь стоит внимательно почитать на форуме темы, наподобие Axapta 3.0 sp3+oracle 10.2.0.3 optimizer_index_cost_adj, и готовиться выправлять многочисленные "придури" оракла, возникающие из-за этого. В частности, замечено, что его оптимизатор, порой, как-то "своеобразно" подбирает "наиболее подходящий" индекс и строит совершенно дикие планы запроса - возможно, как раз из-за перекоса весов различных параметров, используемых им при оценке стоимости использования того или иного плана. И не дай Бог вам по малодушеству начать лечить такие "придури" outline'ами - будете огребать спонтанные тормоза из-за отваливания этих outline'ов при любом изменении запроса (ну, там, поле добавили или переименовали).

Цитата:

Сообщение от egorych

Пришлось рисовать генератор скриптов и т.д. - подготовительных исследований много было.

Интересно, а кто-нить заморачивался тем, чтобы посчитать и соотнести затраты на эти вот исследования, перенос данных, на тот же Оракл, на поиск и наем Oracle DBA (а без него у вас "само собой" ничего нормально не заработает) - к примеру, в сравнении с докупкой ндцати гигов памяти под сервер БД с Ms SQL 2005 x64?..

Цитата:

Сообщение от egorych

Мы расчитываем на другой выигрыш - отсутствие длительных и "многопользовательских" блокировок (разных видов).

А вы разбирались в причинах блокировок? А то ведь бывают случаи, когда сменой СУБД ничего не решить, к примеру, вот:
inventItemLocationSelectLocked

[sukhanchik]

Цитата:

Сообщение от gl00mie

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

Ну тут могу сказать, что я наоборот, сталкивался с тем, что Oracle, в отличие от SQL Server чаще выберет FULL TABLE SCAN, нежели неоптимальный индекс. Хотя справедливости ради надо отметить, что порой он действительно "своеобразно" подбирает индекс и без Oracle DBA (или человека, исполняющего эту роль) будет тяжело обходиться.

Цитата:

Сообщение от gl00mie

Интересно, а кто-нить заморачивался тем, чтобы посчитать и соотнести затраты на эти вот исследования, перенос данных, на тот же Оракл, на поиск и наем Oracle DBA (а без него у вас "само собой" ничего нормально не заработает) - к примеру, в сравнении с докупкой ндцати гигов памяти под сервер БД с Ms SQL 2005 x64?..А вы разбирались в причинах блокировок? А то ведь бывают случаи, когда сменой СУБД ничего не решить

Тут ведь есть вот такой нюанс. Бывают случаи, когда Oracle, как и SQL Server официально не закупаются (пиратские). Т.о. организация не ощущает на себе стоимость лицензий. И решение принимается исходя из слов "В Oracle будет все тип-топ, а SQL Server я плохо знаю" ответственного сотрудника. Докупать память - это деньги - а тут вроде как "своими силами" обходимся (которые кстати все равно фактически не бесплатные, но об этом часто забывают).

Кстати, в оракле - есть хороший анализатор выполняющихся запросов. Мы так нашли почему постоянно виснет разноска. Оракл показал на запрос UPDATE NumberSequenceTable. Нехитрые исследования показали, что проблема в непрерывных номерных сериях. Т.к. освобождение номера (в отличие от выделения) идет не в отдельной транзакции. В результате - мы максимально сняли везде галку "Непрерывная" (ессно убедившись, что это не приводит к трассировкам стека) и увеличили кол-во номеров на предварительное выделение у наиболее востребованных номерных серий (типа ваучера).
Я по себе скажу - что в SQL 2000 такого механизма в помине не было (формально блокировок не было). Насчет 2005 - не знаю, но есть ощущение - что в Оракл все равно выдавал больше нужной информации.

[belugin]

Цитата:

Сообщение от sukhanchik

Я по себе скажу - что в SQL 2000 такого механизма в помине не было (формально блокировок не было). Насчет 2005 - не знаю, но есть ощущение - что в Оракл все равно выдавал больше нужной информации.

Странно, я на SQL 2000 сам находил такую же плюшку (выделение в отдельной ранзакции а возврат в той же). Блокировки там были (sp_lock например). Там не было ВЗАИМНЫХ блокировок с точки зрения MS SQL.

Кстати, есть всякие дополнительные нашлепки для SQL админов типа dbArtisan

[sukhanchik]

Цитата:

Сообщение от belugin

Странно, я на SQL 2000 сам находил такую же плюшку (выделение в отдельной ранзакции а возврат в той же). Блокировки там были (sp_lock например). Там не было ВЗАИМНЫХ блокировок с точки зрения MS SQL.

Кстати, есть всякие дополнительные нашлепки для SQL админов типа dbArtisan

Сия плюшка существует как я понимаю еще со времен 2.5. Но не зная ее - ее обнаружить - для этого нужна доп инфа со стороны БД. В некоторых случаях сам догадываешься (исследуя код), иногда - старшие товарищи помогают... Либо БД указывает. Для моего тогдашнего уровня знаний - эта доп инфа сильно помогла.

Ну... в отношении доп нашлепок не скажу - но стандартная поставка оракла все равно побогаче будет. Нравится мне его Enterprise Manager с веб-интерфейсом.

[ZVV]

Цитата:

Сообщение от sukhanchik

Сия плюшка существует как я понимаю еще со времен 2.5. Но не зная ее - ее обнаружить - для этого нужна доп инфа со стороны БД. В некоторых случаях сам догадываешься (исследуя код), иногда - старшие товарищи помогают... Либо БД указывает. Для моего тогдашнего уровня знаний - эта доп инфа сильно помогла.

Ну... в отношении доп нашлепок не скажу - но стандартная поставка оракла все равно побогаче будет. Нравится мне его Enterprise Manager с веб-интерфейсом.

Quest Spotlight можете ещё посмотреть, тоже клёвая вещь, не нравится... По многим позициям удобнее OEM, как мен кажется. По не бесплатная и в втандартной поставе не идёт. )) Но она имеется и для SQL Server тоже, правда я сам не видел сиквельного варианта.

А насчёт информации о выполняющихся запросах в Оракле и МССКЛ - тут я так понимаю дело в том, что с сиквелом аксапта работает на уровне курсоров, если так можно выразиться, и в итоге со стороны Studio видно, что выполняются операции с курсором (fetch,например), но не видно что конкретно за запрос висит. Это конечно действительно напрягает и не удобно. С Ораклом как-то проще такие моменты отслеживаются, согласен.

[ZVV]

Цитата:

Сообщение от sukhanchik

Цитата:

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

Ну тут могу сказать, что я наоборот, сталкивался с тем, что Oracle, в отличие от SQL Server чаще выберет FULL TABLE SCAN, нежели неоптимальный индекс. Хотя справедливости ради надо отметить, что порой он действительно "своеобразно" подбирает индекс и без Oracle DBA (или человека, исполняющего эту роль) будет тяжело обходиться.

Согласен и с тем и с другим, хотя в случае Аксапты с первым больше. И это не только из-за optimizer_index_cost_adj...
Насколько я понимаю, это всё из-за функциональных индексов, с которым оптимизатор (по крайне мере 9i) временами как-то с трудом справляется, даже при наличии самой полной статистики.
Я проводил небольшие "исследования", моделируя одинаковые по сути ситуации, но с участием либо FBI, либо и обычных индексов. В результате было очень заметно, что в случае обычных индексов оптимизатор выбирает отличные оптимальные планы, используя по максимуму всё, что нужно по смыслу. В случае же FBI результаты бывают просто непредсказуемые.
Навскидку помню следующие две проблемные ситуации, хотя их, конечно, больше:
(правда данные эффекты я наблюдал на оракле на Винде. есть шанс, что на каком-нить *nix-e он себя и лучше поведёт)
- Берётся абсолютно левый индекс, иногда даже в котором (кроме компании конечно) нет ни одного поля из запроса! И начинает по нему сканировать. Со всеми вытекающими по производительности. Приходится в таких ситуациях в Аксапте лечиться конкретным индекс-хинтом.
- В ситуации, когда имеем запрос типа select a.. что-то ещё .... [not]exists join b ... join c.
Предполагаем, что а соединено с b, а b c с по селективных индексам, которые можно и нужно использовать.. С обычными индексами Оракл бы "пропихнул" нужное условие на таблицу "b" в джоин a+b+c и выполнил бы по индексам нестед лупами с минимальной стоимостью и, соответственно, мгновенной скоростью запроса. С FBI же такую красоту он сделать уже отказывается. Рассматривает джоин b+c как независимое представление, которое и "разрешает" отдельно, обычно hash-джоином, естественно включая фулл-скан на обе таблицы (b & c). Стоит ли говорить о том, как страдает скорость, когда вместо доступа к нескольким строчкам по индексу, оракл начинает сканировать 2 большие таблицы. Приходится либо переписывать запросы, если это возможно и допустимо, либо "забивать".

[Alexius]

Цитата:

Сообщение от gl00mie

А вы разбирались в причинах блокировок?

Цитата:

Сообщение от egorych

Разбирались, кончно. Кое-где их удалось убрать модификацие кода. Но не везде. Были проведены тестовые "игры" в разных вариантах, в общем это тема ваще отдельная...

А можно поподробнее ? Где не удалось убрать блокировки или привести их к приемлемой работе?

PS. Лучше действительно в отдельной теме.