![]() |
#1 |
Участник
|
![]()
Собственно - хотим переходить с MS на Oracle. Поскольку вышла 11 версия подумалось, что переходить на старую версию как-то не айс.
Но тут вопрос в совместимости - с 10g потестили - вроде ничего работает, а 11 пока нет возможности поставить, посему если кто пробовал - отпишитесь о результатах, плиз ! |
|
![]() |
#2 |
Участник
|
Интересны аргументы для перехода с MS SQL на Oracle.
|
|
![]() |
#3 |
Участник
|
Аргумент в общем-то 1 - блокировки. Только, плиз не надо про то, что все решается!
Просто скажите (кто знает) - работает с 11 версией или нет! |
|
![]() |
#4 |
Участник
|
Работает. Правда приложение и база не боевые, но пока проблем не замечено.
|
|
![]() |
#5 |
Участник
|
|
|
![]() |
#6 |
Участник
|
|
|
![]() |
#7 |
Участник
|
|
|
![]() |
#8 |
Модератор
|
Сиквел 2005 версии? Включу READ_COMMITTED_SNAPSHOT за 5% стоимости оракловых лицензий
![]()
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: gl00mie (2). |
![]() |
#9 |
Участник
|
Цитата:
Цитата:
Невозможно выбрать запись в "Проводки складского заказа" ("WMSOrderTrans") Тип: Заказ на отгрузку, .
Тупиковая ситуация. Один или несколько пользователей одновременно блокировали всю таблицу или ее часть. |
|
![]() |
#10 |
Участник
|
Может быть дело в модификациях?
|
|
![]() |
#11 |
Модератор
|
А Вы уверены, что на оракле эта ситуация не повторится? Вы разобраться в том, что на сиквеле происходит, пробовали? А то третьей СУБД, на которую в случае чего можно будет перебраться, нет (native не в счет)
![]()
__________________
-ТСЯ или -ТЬСЯ ? |
|
![]() |
#12 |
Участник
|
В 4ке вероятность блокировок снижена изменением алгоритма разноски документов. Не является ли проект миграции на новую версию приложения более целесообразным инвестированием?
|
|
![]() |
#13 |
Участник
|
Цитата:
Если их нет - то оракл не поможет. - Там то же самое будет. Тогда действительно лучше на 4-ку переходить. Если же есть эскалации, то для начала можно попробовать памяти на сервак добавить, тогда меньше вероятности что он эскалацию блокировок делать будет. Если и это не поможет, то тогда пожалуй только оракл. Последний раз редактировалось Logger; 12.08.2008 в 18:38. |
|
![]() |
#14 |
Участник
|
Отвечаю сразу всем - на Оракле такого нет - тоже проверили.
На 4 переходить не будем - ждем 5 ;-) Эскалации нет, памяти хватает - сервер вполне себе соответствует нагрузке. |
|
![]() |
#15 |
Участник
|
Хм. Интересно, тогда в чем же дело ?
Скорее всего на оракле просто быстрее работает - запросы быстрее пролетают и не успевают дедлоки возникнуть. |
|
![]() |
#16 |
Участник
|
Цитата:
Возможно это и борется в рамках Аксапты, но уж сильно глубоко копать нужно. |
|
![]() |
#17 |
Administrator
|
Нельзя забывать, что информация о блокируемой записи в SQL Server хранится в памяти, а в Oracle - в самой записи в отдельном поле. И это запатентованная идея. И как бы не пыхтел Микрософт - не догнать ему Оракл в этом плане. Т.е. Оракл на блокировки вообще память не требует - а значит он может ее использовать по другому назначению.
Плюс, в SQL Server реализован "интеллектуальный" построитель плана запросов. Т.е. если программист делает выборку и не создал соответствующий индекс - то SQL Server пытается "догадаться" как строить план запроса. Это ему иногда удается, а иногда не удается. Отловить сию граблю естественно достаточно тяжело. Оракл - он тупой. Нет индекса - full scan. Это дисциплинирует программиста и заставляет при написании выборки сразу задуматься об индексах. Из-за этого тоже возможны проигрыши по производительности (и как следствие блокировок) в SQL Server. Ну конечно - если код написан так, что будет блокировка - тут уже ничего не спасет - блокировка будет ![]()
__________________
Возможно сделать все. Вопрос времени |
|
![]() |
#18 |
Участник
|
В предыдущих версиях Oracle работали два оптимизатора планов выполнения запросов: RBO (оптимизатор базирующийся на правилах) и CBO (стоимостный оптимизатор). RBO использовал правила построения планов, заложенные в него на все предусмотренные случаи. CBO более гибкий. Он анализирует, на основе статистики, стоимость выполнения запроса с индексом и без него. При этом full scan это не тупость, а наилучший план выполнения запроса, а чтобы он выполнялся быстрее, разбейте большую таблицу на несколько физических носителей и используйте параллельное чтение. В последних версиях RBO не используется вовсе.
|
|
![]() |
#19 |
Участник
|
Цитата:
![]() |
|
![]() |
#20 |
Участник
|
|
|
Теги |
ax3.0, oracle |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|