Нужен совет: Oracle или MS SQL

[Vadik]

Да, и еще... Fed, Вы конечно правильно написали про работу с памятью 32-битного MSSQL. Правда, забыли упомянуть, что SGA на 32bit тоже не резиновый Проблемы-то те же, просто в других терминах описываются

В любом случае, задача (если масштабы не были завышены) imho не для x86, так что тут обе СУБД в 32-битных редакциях сравнивать что с RISC, что с IA64 не совсем корректно. Тем более, что бюджет есть

[fed]

Цитата:

Изначально опубликовано Vadik


А что, forceNestedLoops и forceSelectOrder недостаточно для управления планом запроса ? Какого мегахинта от MSSQL не хватает для полного счастья ?

Ээээ. Ну мне пару раз не хватало { LOOP | MERGE | HASH } JOIN.
Кстати - для Оракла по большому счету в 90% случаев нехватки хинта - тоже не хватает способа указания метода Join.

[fed]

Цитата:

Изначально опубликовано Vadik
Да, и еще... Fed, Вы конечно правильно написали про работу с памятью 32-битного MSSQL. Правда, забыли упомянуть, что SGA на 32bit тоже не резиновый Проблемы-то те же, просто в других терминах описываются

В любом случае, задача (если масштабы не были завышены) imho не для x86, так что тут обе СУБД в 32-битных редакциях сравнивать что с RISC, что с IA64 не совсем корректно. Тем более, что бюджет есть

Угу. Вообще-то надо бы всю эту тему в FAQ какой-нибудь запихнуть - к mazzy скажем на форум.

Ну и в свое оправдание хочу сказать, что я имел в виду что Oracle 64битный - это достаточно типовой вариант последние пару лет, а MS SQL 64bitный - это пока жесткий экстрим

[Vadik]

Цитата:

Изначально опубликовано fed
Ээээ. Ну мне пару раз не хватало { LOOP | MERGE | HASH } JOIN.

LOOP JOIN есть (forceNestedLoops), MERGE JOIN и так порой сам слишком часто включается

[fed]

Уговорил - не хватало в основном hash join

[mazzy]

Цитата:

Изначально опубликовано fed
Угу. Вообще-то надо бы всю эту тему в FAQ какой-нибудь запихнуть - к mazzy скажем на форум.

Дело в том, что здесь еще нет ответов.
Но обсуждение действительно интересное. Спасибо за мысль. Перенес эту ветку в Базу знаний на этом форуме. Сделал ссылку сюда из FAQ.

[yasha]

А разве Application Server в Axapta масштабируется? По-моему нет особого смысла меряться производительностью базы данных, если ляжет сама Axapta.

[mazzy]

Цитата:

Изначально опубликовано yasha
А разве Application Server в Axapta масштабируется?

Если вопрос был "можно ли AOS организовать в кластер?"
Да, можно.
Но к выбору СУБД этот вопрос имеет очень косвенное отношение.

[Serge Kotov]

Цитата:

Изначально опубликовано fed


... Oracle 64битный - это достаточно типовой вариант последние пару лет, а MS SQL 64bitный - это пока жесткий экстрим

Подскажите пожайлуста примеры использования Axapta на Oracle 64.

[fed]

Ну - конкретного примера не приведу - не видел.
Но вообще-то живой Oracle 64 я видел. Не бог весть какая экзотика. И как-то мне трудно предположить по какой причине на нем аксапта не сможет работать

[ALES]

Цитата:

Изначально опубликовано mazzy
Дело в том, что здесь еще нет ответов.

Их тут и не будет никогда, ответы "как внедрить под штуку конкурентных юзверей", получают в офисе, в лучшем случае полезным будет "у нас под СУБД такой-то N юзверей уверенно живут ."

[Serge Kotov]

Цитата:

Изначально опубликовано fed
Ну - конкретного примера не приведу - не видел.
...

Понятно, ну то есть как обычно, как только обсуждение переходит от бла бла к конкретике, мифическая крутизна Oracle блекнет.

Пару лет как я уже при каждом удобном случае интересуюсь мнением серьезных администраторов - профи, которые работали с обоими системами. Обощенное мнение - нет однозначного предпочтения в производительности, при этом SQL Server более предсказуем, т.е. ситуация примерно так как выше высказался xonix.

Подбирая систему под заявленные характеристики однозначно отпадают все 32 разрядные решения (по причине скудости адресации памяти) для сервера БД вместе со многими смешными заявлениями, сделанными выше.

Соответсвенно, можно ссузить рамки обсуждения между подбором 64 разрядной архитектуры. Т.к. по крайней мере одна документально подтвержденная успешная реализация Axapta под IA64 есть, хотелось бы постараться сравнить с нечто подобным на Oracle...

К тому же, подбирая серъезное решение на годы вперед не стоит забывать о колоссальной ответственности за успех / неудачу проекта в перспективе. Здесь много и других рисков кроме производительности СУБД.

[mazzy]

Цитата:

Изначально опубликовано Serge Kotov
Т.к. по крайней мере одна документально подтвержденная успешная реализация Axapta под IA64 есть, хотелось бы постараться сравнить с нечто подобным на Oracle...

http://axapta.mazzy.ru/articles/axapta_itanium/
Одновременно эта статья Сергея Котова может служит ответом на

Цитата:

Изначально опубликовано ALES
в лучшем случае полезным будет "у нас под СУБД такой-то N юзверей уверенно живут ."

Знаю реализации и на Оракле. Знаю и людей...
Может расскажете о параметрах своих баз публично? Чтобы в дальнешем, при подобных обсуждениях, можно было ссылаться на публично доступные сведения.

Пока есть вот такие результаты опросов
http://forum.mazzy.ru/index.php?showtopic=2201
http://forum.mazzy.ru/index.php?showtopic=2204

[fed]

Цитата:

Изначально опубликовано Serge Kotov


Понятно, ну то есть как обычно, как только обсуждение переходит от бла бла к конкретике, мифическая крутизна Oracle блекнет.

Прошу прощения, но я рассказал о вполне конкретных преимуществах Oracle перед MS SQL. (outlines, partitioning и еще кое-какие вещи связанные с настройкой производительности). Могу уверенно сказать что я этими возможностями пользовался на конкретных проектах. Я в общем-то делал проекты (и довольно много) на обоих платформах. Применялся и Oracle (хорошо - 32битный) и MS SQL. На каждом проекте в каждом случае были свои проблемы. Но лично у меня сложилось впечатление что в случае проблем с производительностью, опять таки лично мне их было легче решать в случае оракла.
Если ты считаешь нужным рассказать о каких-то конкретных преимуществах MS SQL, которые я не упомянул - добро пожаловать. Не претендую на роль абсолютного знатока обоих систем и готов выслушать альтернативные мнения.

Если же ты собираешься поднимать holy war "MS SQL vs Oracle" в духе приведенной выше твоей цитаты - добро пожаловать в личную переписку...

P.S. Кстати - в той фирме в которой я сейчас работаю стоит как раз Windows 2000/MS SQL 2000 на сервере с 8 гигами и поддержкой EM64T процессором. Так что когда Windows 2003/MS Sql Server 2005 for x86 64bit отрелизятся и стабилизируются - мы на них обязательно перейдем...

[mazzy]

Согласен. Войн не нужно. Нужны данные.

Цитата:

Изначально опубликовано fed
(outlines, partitioning и еще кое-какие вещи связанные с настройкой производительности).

partitioning - Да!
outlines - наверное.
Какие еще вещи ты имел в виду?

Может постараемся собрать инфу применительно к Аксапте в одном месте?

[Vadik]

Цитата:

Изначально опубликовано fed
Если же ты собираешься поднимать holy war "MS SQL vs Oracle" в духе приведенной выше твоей цитаты - добро пожаловать в личную переписку...

Да полно вам. Оба продукта хорошие. Но любимый - он всегда один

[fed]

ну я еще однажды использовал bitmap index. Но это и вправду суровая экзотика. Еще была попытка ускорить процесс рассчета остатков по inventSum с помошью materialized view. К моему глубокому сожалению - не доведенная до конца . Просто как показала практика - при разноске больших складских журналов списания - куча времени уходит на рассчет себестоимости по InventSum. На MS SQL я кстати тоже пробовал применять тамошний аналог persistent view (cluster indexed view - если я правильно помню терминологию). Там это существенно ускорило рассчет мгновенной себестоимости списания. Правда - при этом еще и неприлично замедлило обновление inventTrans . Поскольку в oracle работа с persistent view сделана на мой взгляд несколько правильнее чем в MS SQL - была надежда что там это позволит кардинально решить проблему. Но честно говоря - просто времени не хватило на исследования - да и у заказчика MS SQL стоял.

Outlines штука полезная. Я ее несколько раз применял на практике, когда Оракл какой-то уж очень кривой план запроса генерировал, а с помошью хинтов аксапты его вылечить не удавалось.

Ну и то что partitioning рулит - думаю все согласятся. У нас тут на одном из проектов прогноз продаж строился на основании данных по продажам за три года (ну там где-то миллиона три складских проводок было - как я помню). Так вот после того как клиентские админы распартиционировали эту таблицу на несколько дисков по дате проводки, время построения этого прогноза продаж упало где-то в 6-7 раз. (Точную цифру не скажу, просто раньше они этот процесс срубали часов через 6, а после перебиения таблиц у них все это стало строится за 45 минут примерно).

[Serge Kotov]

to fed

извини, ничего личного.
спасибо за интересную информацию

[xonix]

Про partitioning
2 стороны медали всегда.. Если по большинству запросов будет ограничние на поле, по которому сделано разбиение - то да, суммарный выигрыш есть.
В протовном случае для запросов, где ограничение на это поле нет (читай - просмотр всех партишенов), производительность будет падать.
Партишионинг рулит конечно, но я думаю, всегда есть методы и получше...

[fed]

Если у тебя многопроцессорный сервер, то выборка по нескольким partition будет выполнятся несколькими процессорами. ТО есть - даже в списке исполняемых запросов можно будет кроме первичного select from table видеть несколько нагенеренных ядром системы запросов select from table(part1), select from table(part2) и тд. За счет чего, собственно и был достигнут положительный эффект в приведенном примере. Правда - пришлось чуть-чуть подконопатить аксапту, так чтобы при создании таблиц она указывала клаузу parallel.
Кстати - именно для этой ситуации в Oracle и сделано hash partitioning. То есть - не для выборки по полю, а для параллельной выборки с многих дисков, многими процессорами