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

[egorych]

Собственно хочу поделиться с общественностью - на праздники был совершен "переворот" - перевели рабочую базу на Oracle 10g. Axapta 3 KR2.
Собстенно перенос данных прошел где-то за сутки.
Если кому что интересно - спрашивайте.

[fed]

Я так понимаю - переходили с MS SQL 2005 x64 ? И как данные переносили ? Через SQL Integration services или есть какая-то Оракловская тулза для переноса данных ?

И как впечатления (первые) по поводу сравнения быстродействия Аксапы на MS SQL 2005 x64/Oracle 10g ?

[egorych]

Да, переходили с MS SQL 2005 x64, но это тоже был переходный вариант (чтобы Windows 2003 x64 поставить на рабочий сервер). Насчет тулзов сложнее - предварительно были опробованы и SSIS и оряклячие переносилки (и прочее) - ни одна нормально не работает с image и text (в терминологии МС) полями! Пришлось рисовать генератор скриптов и т.д. - подготовительных исследований много было.
Пока по скорости не понятно - не было "боевой" нагрузки, но для 60-70 человек визуально практически одниаково. Мы расчитываем на другой выигрыш - отсутствие длительных и "многопользовательских" блокировок (разных видов).

[Vadik]

Цитата:

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

Да, переходили с MS SQL 2005 x64, но это тоже был переходный вариант (чтобы Windows 2003 x64 поставить на рабочий сервер)

т.е. Oracle под Windows крутится? брр..

Цитата:

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

А что ж read_committed_snapshot не включили ? Часовой RTFM мог бы избавить от вышеописанного геморроя с миграцией

[sukhanchik]

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

[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

Цитата:

Сообщение от 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 большие таблицы. Приходится либо переписывать запросы, если это возможно и допустимо, либо "забивать".

[ZVV]

Цитата:

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

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

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

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

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

[egorych]

Драсти! Отдыхал немножко, поэтому задержка с ответами, итак:

Цитата:

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

Quest Spotlight ...

Эту вещь юзаю и для МС и для Оракла - мне нравится!

Цитата:

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

А насчёт информации о выполняющихся запросах в Оракле и МССКЛ - тут я так понимаю дело в том, что с сиквелом аксапта работает на уровне курсоров...

Насколько я разбираюсь в медицине - курсоры это ваще главна проблема всех "проблем" в аксапте! Ибо это самый э-э-э, неправильный режим работы а MSSQL.

Цитата:

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

т.е. Oracle под Windows крутится? брр..

Не знаю что там брр, но вполне нормально работает, сие решение было принято после консультаций со знакомыми "собаководами", которые юзают ораклу ну очень давно! Утверждается, что для наших задач разницы практически нет! Есс-но если вдруг будет RAC, то конечно, будет *nix.

Цитата:

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

А что ж read_committed_snapshot не включили ? Часовой RTFM мог бы избавить от вышеописанного геморроя с миграцией

Не надо думать, что Вы одни такие умные! Ax3 этот read_committed_snapshot как зайцу стоп сигнал. Возможно в 4 что-то и дает, но мы включали его - ни каких изменений в поведении не произошло.

Цитата:

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

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

Размер БД исходный около 200Г, получившийся - где-то 100Г. Разница заключается в любимой табличке SysDatabaseLog, которая не переносилась.
Приложение пока не модифицировалоь специально для Оракла - возможно чуть поработаем и что-то выявится.

Цитата:

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

Да уж, теперь стоит внимательно почитать на форуме темы, наподобие Axapta 3.0 sp3+oracle 10.2.0.3 optimizer_index_cost_adj, ...

Есс-но все сообщения на форуме о каких-то траблах изучаются и анализируются применимо к нашей ситуации.

Цитата:

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

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

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

[fed]

Кстати - в продолжение давней дискуссии на которую тут ссылаются - нашел интересную статью по поводу того, как работать со статистикой при использовании FBI:
http://richardfoote.wordpress.com/20...-no-surprises/

[Vadik]

Цитата:

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

Не знаю что там брр, но вполне нормально работает

Ну вот и славно

Цитата:

Ax3 этот read_committed_snapshot как зайцу стоп сигнал. Возможно в 4 что-то и дает, но мы включали его - ни каких изменений в поведении не произошло

Если "никаких изменений в поведении не произошло" относится к

Цитата:

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

, значит, у Вас есть проблемы с обновлением данных несколькими сессиями (несколько "писателей"). Чем в данном случае может помочь Oracle - непонятно.
Ну да ладно. Софт, как я понимаю, по карману компании не ударил , экспириенс получен, система работает, все довольны. Удачи

[egorych]

Цитата:

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

...у Вас есть проблемы с обновлением данных несколькими сессиями (несколько "писателей"). Чем в данном случае может помочь Oracle - непонятно.

мсье телепат? Я уже писал об том, что происходит Axapta 3.0 и Oracle 11 - кто-нить пробовал ?
В нашем случае помогает и даже очень!
ps Хотел чег-то дописать, но воздержусь.

[Alexius]

Цитата:

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

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

Цитата:

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

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

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

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

[Андре]

Цитата:

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

Кстати - в продолжение давней дискуссии на которую тут ссылаются - нашел интересную статью по поводу того, как работать со статистикой при использовании FBI:
http://richardfoote.wordpress.com/20...-no-surprises/

А в чем суть поста? Не забывать использовать 'method_opt=> ‘FOR ALL HIDDEN COLUMNS SIZE 1′ в dbms_stats.gather_table_stats?

Согласен, но зачем вообще использовать dbms_stats.gather_table_stats, когда есть dbms_stats.gather_scheme_stats, которая прекрасно обновляет статистику по FBI:

Connected to:
Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options

demas@ORCL> create table pink_floyd(table_name varchar2(50));

Table created.

demas@ORCL> insert into pink_floyd values('one');

1 row created.

demas@ORCL> insert into pink_floyd values('One');

1 row created.

demas@ORCL> insert into pink_floyd values('ONE');

1 row created.

demas@ORCL> select * from pink_floyd;

TABLE_NAME
--------------------------------------------------
one
One
ONE

demas@ORCL> select column_name, num_distinct, hidden_column, virtual_column from dba_tab_cols where 
table_name='PINK_FLOYD';

COLUMN_NAME                    NUM_DISTINCT HID VIR
------------------------------ ------------ --- ---
TABLE_NAME                                  NO  NO
SYS_NC00002$                                YES YES


demas@ORCL> begin
  2  dbms_stats.gather_schema_stats(ownname=>'DEMAS',cascade=>TRUE);
  3  end;
  4  /

PL/SQL procedure successfully completed.

demas@ORCL>  select column_name, num_distinct, hidden_column, virtual_column from dba_tab_cols where
 table_name='PINK_FLOYD';

COLUMN_NAME                    NUM_DISTINCT HID VIR
------------------------------ ------------ --- ---
TABLE_NAME                                3 NO  NO
SYS_NC00002$                              1 YES YES

[ZVV]

Цитата:

Сообщение от Андре

А в чем суть поста? Не забывать использовать 'method_opt=> ‘FOR ALL HIDDEN COLUMNS SIZE 1′ в dbms_stats.gather_table_stats?

Согласен, но зачем вообще использовать dbms_stats.gather_table_stats, когда есть dbms_stats.gather_scheme_stats, которая прекрасно обновляет статистику по FBI:

.................

забыли создать индекс

Да нет, суть поста немножко не в этом, как я понял. Скорее в основном он в том, чтоб знать о том, что статистика на эти спрятанные колонки должна быть собрана. Ну и в том, что она не собирается автоматом когда вы создаёте индекс (FBI), а при этом создаётся только статистика на сам индекс.
В итоге, если вы хотите, чтоб оптимизатор нормально работал с новым индексом, то вам нужно дособрать статистику на "спрятанные" колонки.

А dbms_stats.gather_table_stats собирает статистику на эти колонки так же хорошо, как и dbms_stats.gather_scheme_stats - проверьте сами.
И в режиме for all columns и в режиме for all indexed columns.
И стандартный GATHER_STATS_JOB, кстати, тоже...

[Андре]

Цитата:

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

забыли создать индекс

Не, создать не забыл, а вот в приведенный листинг не включил.

create index pf_i on pink_floyd(upper(table_name));

Если бы индекс не создал - вот этого не было бы:

demas@ORCL> select column_name, num_distinct, hidden_column, virtual_column from dba_tab_cols where 
table_name='PINK_FLOYD';

COLUMN_NAME                    NUM_DISTINCT HID VIR
------------------------------ ------------ --- ---
TABLE_NAME                                  NO  NO
SYS_NC00002$                                YES YES

Цитата:

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

Да нет, суть поста немножко не в этом, как я понял. Скорее в основном он в том, чтоб знать о том, что статистика на эти спрятанные колонки должна быть собрана. Ну и в том, что она не собирается автоматом когда вы создаёте индекс (FBI), а при этом создаётся только статистика на сам индекс.

При создании индекса статистика не создается даже на индекс. Ее надо собрать.

Цитата:

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

А dbms_stats.gather_table_stats собирает статистику на эти колонки так же хорошо, как и dbms_stats.gather_scheme_stats - проверьте сами.

Дык не в том вопрос. dbms_stats.gather_scheme_stats - стандартная периодическая операция выполняемая минимум раз в неделю. Почему именно scheme? Потому что мне лень все таблички перебирать

А если мы уже используем dbms_stats.gather_scheme_stats, то смысл в exec dbms_stats.gather_table_stats пропадает.

[egorych]

А кстати никто не разбирался, родной, Аксаптовский job и пакет "правильно" статистику собирает?