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

[egorych]

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

[Morpheus]

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

[egorych]

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

[Logger]

Цитата:

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

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

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

[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") Тип: Заказ на отгрузку, .
Тупиковая ситуация. Один или несколько пользователей одновременно блокировали всю таблицу или ее часть.

[Morpheus]

Цитата:

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

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

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

[madm]

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

[madm]

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

[Morpheus]

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

[egorych]

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

[Logger]

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

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

[egorych]

Цитата:

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

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

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

[Logger]

Цитата:

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

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

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

[egorych]

Цитата:

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

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

Вам не правильно понятно, это не эскалация!
Эскалация подразумевает переключение режимов блокировки - строка->страница->таблица->база
в моем случае происходит сразу блокировка страницы индекса/таблицы - могу заверить со всей ответственностью, что MS не всегда использует построчную блокировку.

[Alexius]

Цитата:

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

в моем случае происходит сразу блокировка страницы индекса/таблицы

Основные причины такого поведения:
1. Отсутствует PRIMARY KEY
2. Отсутствует кластерный индекс
3. Попытка заблокировать большое число записей
4. Нехватает индекса(ов), т.е. нет подходящего для выбора требуемых записей
5. Недостаточно оперативной памяти для реализации блокировки по записям

Цитата:

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

- могу заверить со всей ответственностью, что MS не всегда использует построчную блокировку.

Беcспорно !!!

[RumataEstor]

Цитата:

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

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

Позвольте осведомиться, сколько пользователей одновременно работает?

[sukhanchik]

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

[Morpheus]

Цитата:

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

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

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