Axapta 3.0 и Oracle 11 - кто-нить пробовал ?

[egorych]

Собственно - хотим переходить с MS на Oracle. Поскольку вышла 11 версия подумалось, что переходить на старую версию как-то не айс.
Но тут вопрос в совместимости - с 10g потестили - вроде ничего работает, а 11 пока нет возможности поставить, посему если кто пробовал - отпишитесь о результатах, плиз !

[Morpheus]

Интересны аргументы для перехода с MS SQL на Oracle.

[egorych]

Аргумент в общем-то 1 - блокировки. Только, плиз не надо про то, что все решается!
Просто скажите (кто знает) - работает с 11 версией или нет!

[madm]

Работает. Правда приложение и база не боевые, но пока проблем не замечено.

[Logger]

Цитата:

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

Аргумент в общем-то 1 - блокировки. Только, плиз не надо про то, что все решается!
Просто скажите (кто знает) - работает с 11 версией или нет!

А какая версия SQL у вас ?
Режим Snapshot Isolation использовали ?

[Morpheus]

Цитата:

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

Аргумент в общем-то 1 - блокировки. Только, плиз не надо про то, что все решается!
Просто скажите (кто знает) - работает с 11 версией или нет!

Не планировал переубеждать... А еще нескромный вопрос, Oracle покупать будете?

[egorych]

Цитата:

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

А какая версия SQL у вас ?
Режим Snapshot Isolation использовали ?

У нас Axapta 3.0, поэтому не получится

Цитата:

Oracle покупать будете?

Собираемся

[Vadik]

Цитата:

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

А какая версия SQL у вас ? Режим Snapshot Isolation использовали ?

Цитата:

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

У нас Axapta 3.0, поэтому не получится

Сиквел 2005 версии? Включу READ_COMMITTED_SNAPSHOT за 5% стоимости оракловых лицензий

[egorych]

Цитата:

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

Сиквел 2005 версии? Включу READ_COMMITTED_SNAPSHOT за 5% стоимости оракловых лицензий

При включенном получается тоже самое (проверяли !)-

Цитата:

Невозможно выбрать запись в "Проводки складского заказа" ("WMSOrderTrans") Тип: Заказ на отгрузку, .
Тупиковая ситуация. Один или несколько пользователей одновременно блокировали всю таблицу или ее часть.

[madm]

Может быть дело в модификациях?

[Vadik]

Цитата:

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

При включенном получается тоже самое (проверяли !)-

А Вы уверены, что на оракле эта ситуация не повторится? Вы разобраться в том, что на сиквеле происходит, пробовали? А то третьей СУБД, на которую в случае чего можно будет перебраться, нет (native не в счет)

[Morpheus]

В 4ке вероятность блокировок снижена изменением алгоритма разноски документов. Не является ли проект миграции на новую версию приложения более целесообразным инвестированием?

[Logger]

Цитата:

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

При включенном получается тоже самое (проверяли !)-
...
Невозможно выбрать запись в "Проводки складского заказа" ("WMSOrderTrans") Тип: Заказ на отгрузку, .
Тупиковая ситуация. Один или несколько пользователей одновременно блокировали всю таблицу или ее часть.

Я бы сперва удостоверился что нет эскалации блокировок.
Если их нет - то оракл не поможет. - Там то же самое будет. Тогда действительно лучше на 4-ку переходить.

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

[egorych]

Отвечаю сразу всем - на Оракле такого нет - тоже проверили.
На 4 переходить не будем - ждем 5 ;-)
Эскалации нет, памяти хватает - сервер вполне себе соответствует нагрузке.

[Logger]

Хм. Интересно, тогда в чем же дело ?

Скорее всего на оракле просто быстрее работает - запросы быстрее пролетают и не успевают дедлоки возникнуть.

[egorych]

Цитата:

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

Скорее всего на оракле просто быстрее работает - запросы быстрее пролетают и не успевают дедлоки возникнуть.

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

[sukhanchik]

Нельзя забывать, что информация о блокируемой записи в SQL Server хранится в памяти, а в Oracle - в самой записи в отдельном поле. И это запатентованная идея. И как бы не пыхтел Микрософт - не догнать ему Оракл в этом плане. Т.е. Оракл на блокировки вообще память не требует - а значит он может ее использовать по другому назначению.
Плюс, в SQL Server реализован "интеллектуальный" построитель плана запросов. Т.е. если программист делает выборку и не создал соответствующий индекс - то SQL Server пытается "догадаться" как строить план запроса. Это ему иногда удается, а иногда не удается. Отловить сию граблю естественно достаточно тяжело. Оракл - он тупой. Нет индекса - full scan. Это дисциплинирует программиста и заставляет при написании выборки сразу задуматься об индексах. Из-за этого тоже возможны проигрыши по производительности (и как следствие блокировок) в SQL Server.
Ну конечно - если код написан так, что будет блокировка - тут уже ничего не спасет - блокировка будет

[Morpheus]

Цитата:

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

Оракл - он тупой. Нет индекса - full scan. Это дисциплинирует программиста и заставляет при написании выборки сразу задуматься об индексах.

В предыдущих версиях Oracle работали два оптимизатора планов выполнения запросов: RBO (оптимизатор базирующийся на правилах) и CBO (стоимостный оптимизатор). RBO использовал правила построения планов, заложенные в него на все предусмотренные случаи. CBO более гибкий. Он анализирует, на основе статистики, стоимость выполнения запроса с индексом и без него. При этом full scan это не тупость, а наилучший план выполнения запроса, а чтобы он выполнялся быстрее, разбейте большую таблицу на несколько физических носителей и используйте параллельное чтение. В последних версиях RBO не используется вовсе.

[gl00mie]

Цитата:

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

Плюс, в SQL Server реализован "интеллектуальный" построитель плана запросов. Оракл - он тупой. Нет индекса - full scan. Это дисциплинирует программиста и заставляет при написании выборки сразу задуматься об индексах.

Практика показывает, что Oracle "тупой" немного по-иному Индексы-то на таблицах есть почти всегда, так вот, Oracle подчас хватает совсем не те индексы, которые, бывает, специально ему под определенные запросы создаешь. Получается, конечно, не full scan, но на больших объемах - все равно слишком долго, причем выявляется это, порой, лишь на сопоставимой с рабочей по объему и наполнению тестовой базе, а то и вообще только на рабочей. Не зная настроек оптимизатора и конкретики собранной им статистики, очень сложно бывает "въехать", какого фига Oracle так тупит. И дисциплинирует это не столько программиста, сколько руководство - в плане того, что надо искать очень дорого Oracle DBA, который бы мог разруливать такие ситуации подкруткой весов различных параметров, используемых оптимизатором запросов, а не тупым прикручиванием outline'ов, которые слетают при любом изменении таблицы/запроса.

[Logger]

Цитата:

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

блокируется строка(бывает и страница) таблицы и страница индекса - и такой вот итог. Ну не всегда конечно, но частенько.

Так я эт и имел в виду, когда писал про эскалацию блокировок !
Теперь все понятно.