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

[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'ов, которые слетают при любом изменении таблицы/запроса.

[sukhanchik]

Цитата:

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

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

Согласен с этим утверждением.... Просто психологически (с т.з. руководства) - лучше 1 большая жопа, чем 10 маленьких ("у нас проблема в одном месте а не в 10"). Хотя тупит Оракл реже, но стоимость исправления его тупизны может быть дороже, нежели аналог со SQL Server.

Тут тяжело сравнивать. Переход с одной БД на другую - нельзя сказать что делается легко и непринужденно. Были проблемы на SQL2000, перешли на Оракл - проблемы исчезли. Редкая тупизна Оракла (в смысле что какие-то запросы редко зависают по непонятным с ходу причинам) ... ну да решается конечно... Пришлось разориться на Oracle DBA. Вышел SQL 2005. Кто даст гарантии, что при переходе с Оракла на 2005 будет все ок? А если опять проблемы возникнут - кто будет в ответе? И каким образом (это ж все деньги)? Лицензии опять-таки (если говорить о легальном использовании софта) не бесплатные (особенно ораклиные)
А туда-сюда метаться - тоже никаких денег не хватит . Да, в общем-то и по SQL Server тоже по хорошему DBA нужен... Работу-то делать надо.

[Timofey_k]

Цитата:

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

Были проблемы на SQL2000, перешли на Оракл - проблемы исчезли. Редкая тупизна Оракла (в смысле что какие-то запросы редко зависают по непонятным с ходу причинам) ... ну да решается конечно... Пришлось разориться на Oracle DBA.

Красиво излагаешь. Правда мне ситуация почему-то совсем иначе запомнилась. И к Ораклу у меня теперь жесточайшая идиосинкразия на всю жизнь.

MS SQL x64 + МНОГО памяти будет дешевле и бескровнее, чем скрещивать трепеную лань с конем.

[sukhanchik]

Цитата:

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

Красиво излагаешь. Правда мне ситуация почему-то совсем иначе запомнилась.

Ну.... ежли так - тогда даже спорить не буду - ибо ты был ближе к "гуще событий" . Наверное я просто так близко с ним не познакомился как ты .

Но тут в соседней ветке Ромка верно заметил:

Цитата:

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

сможете всем эти рулит - полетит, не сможете - в лучшем случае будет ползать и мотать нервы.

Я со своей стороны после SQL 2000 сильно проникся Ораклом. Ромка заразил

[Timofey_k]

Цитата:

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

Я со своей стороны после SQL 2000 сильно проникся Ораклом. Ромка заразил

Ну Ромы ситуация немного другая. Он изначально использовал мощное 64бит железо (а кое-кто поставил Оракл, в надежде поднять произоводительность на том же железе), плюс он не стесняется переписывать любые куски в Аксапте, если они ему чем-то не нравятся.

Я считаю, что на адекватном железе и SQL будет неплохо шевелиться. А если он не шевелится, то миграцией на Oracle положение не спасешь. Возможно не время станет лучше, но в долгосрочной перспективе случится то самое место, из которого у многих руки растут.

И вообще, кесарю кесарево, а Аксапте - майкрософтово. Поддержка Oracle в AX сделана чисто для галочки и похоже деградирует.

[ZVV]

Цитата:

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

Поддержка Oracle в AX сделана чисто для галочки и похоже деградирует.

Это однозначно, примерно так и было сказано в конце прошлого года в Москве на мастер-классе... Кто был наверное помнит.
Обоснование звучало примерно так: "Нам не выгодно, чтоб Аксапта с Ораклом работала лучше чем с SQLсервером."
Логика железная...
Жалко.

[ring]

Цитата:

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

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

Оракл хватает не те индексы как раз потому что АКСПАТА по своему усмотрению меняет важные оракловые параметры Axapta 3.0 sp3+oracle 10.2.0.3 optimizer_index_cost_adj

[Logger]

Цитата:

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

Оракл хватает не те индексы как раз потому что АКСПАТА по своему усмотрению меняет важные оракловые параметры Axapta 3.0 sp3+oracle 10.2.0.3 optimizer_index_cost_adj

У нас по дефолту стоит то же что и Аксапта ставит - все равно были проблемы с оптимизером.

[ring]

Цитата:

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

У нас по дефолту стоит то же что и Аксапта ставит - все равно были проблемы с оптимизером.

Охотно вам верю, но в данном случае запросы проверялись через обычный sqlplus который не меняет умолчательных парметров в сессии и разница очень существенна,больше всего раздражает то что аксапта, впрочем как и многие другие програмные продукты к которым мелкософт приложила свои руки, решает за администартора какие параметры выставлять...имхо бред, поэтому говорить о тонкой настройке БД не приходиться...