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

[vshor]

Планируется внедрение Аксапты. Возникли вопросы по поводу СУБД, мнения как всегда разделились. Общая картинка такова. AOS. В перспективе количество активных пользователей более 1000. Режим 24х7. Прогнозируется 30% рост данных ежемесячно (ориентируемся на 1TB через год работы). Территориально распределенная компания. Вопрос админов и стоимости софта не стоит. Хотелось бы услышать мнения спецов.

[raz]

Цитата:

Вопрос админов и стоимости софта не стоит

Остальное уже не имеет значение, ИМХО, Oracle.

[George Nordic]

Цитата:

Изначально опубликовано vshor
количество активных пользователей более 1000. Режим 24х7

Oracle

С Уважением,
Георгий.

[Михаил Андреев]

Интересно было бы послушать тех, кто ратует за MS SQL...

[Ace of Database]

Таких нет

[db]

ну почему же нет. есть, видел сам

есть, ратуют, говорят что майкрософт обещал, что все будет круто на их немерянных объемах и пользователях, внедряют, запускают 3 пользователя, радуются, что были правы, льют дерьмо на тех, кто говорил наоборот, запускают еще сотню, пользователи воют, система висит, не верят все равно, мучаются, оптимизируют, переписывают полсистемы, все равно все висит, все равно все орут

далее по выбору - выкидывают систему или переходят, наконец, на оракл
оракл не хотят, потому что нужен грамотный админ, который стоит типа дорого, но на все переписки-оптимизации и нервы тратят бабла как минимум раз в 10 больше, чем стоит этот админ в год

[fed]

Ну я бы сказал что при таком объеме пользователей MS SQL не выдержит.
Имеется следующая техническая подробность:
Хотя Xeon уже года 4 как умеет адресовать до 64 Гбайт памяти, но до недавнего времени (до введения поддержки технологии EM64T), доступ приложения к всему что находится за пределами первых трех гигабайтов делался, мягко говоря, очень непрямолинейным путем. (Там что-то типа сегментных регистров как в 8086 использовалось).
Соответственно - хотя Windows 2000/2003 Datacenter Edition и поддерживал работу с большим объемом памяти, SQL Server всю память за пределами первых трех гигов использовал только под дисковый буфер. Таблицы блокировок, планы запросов, и вообще всяческие остальные внутренние данные должны были помещаться в первые три гига.
При числе пользователей до 250-300 - есть шансы что эти данные в первые три гига помещаться будут. А вот если пользователей больше - то кранты, сколько памяти не ставь - все равно производительность сильно расти не будет.
В принципе - в этом году должны выйти Windows 2003 64Bit Edition и SQL Server 2005 64Bit Edition, которые позволят обойти это ограничение (правда не факт что Аксапту сразу сертифицируют для работы на SQL Server 2005).

Если сервер нужно покупать уже сразу и сейчас - можно купить машину на Itanium и поставить туда специфичную версию Windows 2000/SQL Server 2000 (которые изначально 64битные и позволяют адресовать всю память). Правда обойдется такая машина в сумму сопоставимую с ценой RISC-сервер от Sun или HP.

Так что если у вас дейстительно много денег и вы можете позволить себе дорогую технику и специалистов - я бы советовал покупать RISC-сервер и Oracle.
Если денег поменьше - можно попытаться купить хороший многопроцессорный сервер на последнем поколении процессоров Xeon (которые с поддержкой EM64T), с большим объемом памяти и поставить туда Linux и Oracle(у меня кстати был клиент у которого аксапта работала с Oracle под Fedora Linux).

А если вообще от вашей конкретной ситуации отвлечься, то на мой взгляд при сколько- нибудь больших объемах данных Oracle выигрывает. Причем выйгрыш выражается не в том что при одинаковом железе он работает быстрее чем MS SQL, а в том что когда MS SQL тормозит - его ускорить удается только апгрейдом железа (который быстро упирается в ограничения по памяти), а когда тормозит Oracle, то его в большинстве случаев удается ускорить настройкой сервера, четким прописыванием плана запроса (через outline) или скажем достроением специфичных оракловских средств ускорения запроса (ну скажем bitmap indexes или materialized view).

Проблема только в том, что хорошего оракловского админа очень тяжело найти. Их вообще на рынке мало, и они все хорошо пристроены. Так что будьте готовы к тому что вам либо придется перекупать админа на сумму большую процентов на 40 чем его реальная стоимость, либо придется заключать договор на консультации с какой-нибудь консалтинговой фирмой (явно не аксаптовской) отукуда периодически будет приезжать админ и за очень неплохую почасовку помогать вашему (допустим вменяемому, но не выдающемуся) админу бороться с узкими местами.

Ну и под конец хотелось бы упомянуть что в аксапте есть несколько мест (скажем - та же зарплата или некоторые куски в книгах покупок/продаж) которые явно не тестировались и не оптимизировались под Oracle. И либо вашим программистам для таких мест придется довольно неочевидным образом править исходные тексты аксапты (она далеко не все оракловские хинты поддерживает и часто приходится бороть проблему тормознутости запроса методом перебора), либо просить админа настроить outline для данных тормознутых запросов (что тоже не всегда хорошо потому что при изменении запроса outline придется переделывать).
Но при ваших масштабах - как мне кажется - другого пути просто нету в принципе.

Кстати - в террабайт после года работы я как-то слабо поверил
То есть - живому пользователю в день больше килобайт 30-40 данных не внести. Пользователей у вас тысяча, дней в году 365, после разноски исходного документа данные будут занимать максимум раза в 4 больше чем было в исходном документе (и то вряд ли). Накладные расходы на хранение данных (ну индексы там всякие и тп) занимают примерно 50% от исходных данных. Итого:
40000 *1000 * 4 *1.5 *365 = 80Гигабайт примерно.
Так что до террабайта придется наверное дет 5-7 расти - даже с учетом роста фирмы.

P.S. После того как я это написал - возникла довольно обширная переписка по поводу того что для 32битных платформ для Oracle характерны те же проблемы с памятью. Полностью с этим согласен. Просто когда я писал это сообщение - я не сформулировал четко ту мысль, что на мой взгляд MS SQL 64Bit - это пока-что достаточно экзотичная вешь, а Oracle 64Bit - штука все таки уже достаточно распространенная.

[George Nordic]

Спасибо, fed!

Очень хороший и развернутый ответ!
Но, господа, глядя на подобные объемы, меня начинают мучать смутные сомнения....

Может, вопрос стоило поставить так: Axapta или ...?

С Уважением,
Георгий.

[ppson]

Цитата:

Изначально опубликовано fed
Ну и под конец хотелось бы упомянуть что в аксапте есть несколько мест (скажем - та же зарплата или некоторые куски в книгах покупок/продаж) которые явно не тестировались и не оптимизировались под Oracle.

fed, как же так?! ты забыл как мы поработали полигоном при запуске зарплаты на еще Damgaard Axapta+Oracle?
Ты же мне запросы оптимизировал, когда она (Аксапта) налоги расчитывала по 30 часов .
Вроде третий год у клиента все пучком .

[ALES]

Цитата:

Изначально опубликовано vshor количество активных пользователей более 1000. [/B]

Oracle и дело не (столько) в "железных" тех. подробностях а в "отличиях" взаимодействия системы с SQLом и Ora.

[Koriolis]

Цитата:

Изначально опубликовано George Nordic
Может, вопрос стоило поставить так: Axapta или ...?

Адназначна ИЛИ! Все-таки Axapta позиционируется как SMALL Busines Solution

[ppson]

Цитата:

Изначально опубликовано Koriolis
Все-таки Axapta позиционируется как SMALL Busines Solution

middle market solution!

[Vadik]

Цитата:

Изначально опубликовано ALES
Oracle и дело не (столько) в "железных" тех. подробностях а в "отличиях" взаимодействия системы с SQLом и Ora.

Если есть время, поясните, пожалуйста, что Вы имели в виду

[fed]

Цитата:

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


fed, как же так?! ты забыл как мы поработали полигоном при запуске зарплаты на еще Damgaard Axapta+Oracle?
Ты же мне запросы оптимизировал, когда она (Аксапта) налоги расчитывала по 30 часов .
Вроде третий год у клиента все пучком .

Но в стандартной поставке-то запросы от exists join так и не избавили...
Так что это мы с тобой локально проблему решили...

[fed]

А мне кажется что вариант "или" следует рассматривать не с точки зрения числа пользователей, а с точки зрения использования функционала. На большом числе пользователей другие системы будут вести себя также.
Собственно - если функционал устраивает, то в плане производительности в аксапте до недавнего времени было только два неразрешимых узких места, которые не лечились простой заменой железа на более мощное:
1. Закрытие склада (рассчет себестоимости то есть)
2. Сводное планирование на большом объеме.


Первая проблема была решена после того как в Axapta 3.0Sp2 был разработан рассчет себестоимости с нескольких машин параллельно.
Вторая проблема - по идее должна решаться аналогичным образом, но я не знаю - есть ли она в планах по разработке. Кстати - по разведданным в Baan и R/3 есть развертывание сводного плана с нескольких компьютеров одновременно.

Все остальные узкие места в аксапте так или иначе лечаться установкой хорошего железа и иногда оптимизацией кода или запросов.

[ALES]

Цитата:

Изначально опубликовано Vadik
...поясните...

например эскалацию блокировок

[xonix]

Проработав с Ораклом не один год (почти администратором) на базах по 200 ГБ (правда не Аксаптовских) и занимаясь вопросоми тюнинга (и настроек сервера, и запросов) могу сказать следующее (9.2 по сравнению с 2000):
Есть примеры, где сиквеловский оптимизатор запросов умнее ораклового. Не встречал обратного.
Почти всегда существенный прирост быстродействия (в разы) возможен ТОЛЬКО оптимизацией плана запроса/(иногда с добавлением индексов). Эта опция доступна и в той и в другой системе.
"Игры" с настройками могут дать максимум 20% прирост (кроме совсем клинических случаев).
Соседи работали с сиквеловскими базами по 500 ГБ, не сильно жалуясь на быстродействие.
"Кривизна" наблюдалась в обоих СУБД в совершенно неожиданных местах.
У Оракла удобнее отладка.
В целом, с сиквелом проблем было меньше.

Примечание: оптимизировалось под скорость выполнения больших запросов, а не под много маленьких.

[fed]

to xonix:
Маленькая тонкость - в Аксапте свой диалект SQL который не пропускает 80% оракловских хинтов (да кстати и MS SQLных тоже). В Oracle это можно обходить через outline. А в MS SQL я аналогичного способа не знаю.
Ну и кроме того в MS SQL нету такой замечательной фичи как partitioning. Она ОЧЕНЬ полезна на больших объемах данных. Все прочие хитрые индексы и persistent view - это действительно экстремизм. Хотя в некоторых случаях тоже выручают.

Так что применительно к Аксапте - на оркале легче бороться с неправильным планом запроса.
(А про тормозное исполнение exists join ораклом я и самзнаю - это как раз то из за чего аксаптовская зарплата на оракле тормозит сильно

[Vadik]

Цитата:

Изначально опубликовано fed
Маленькая тонкость - в Аксапте свой диалект SQL который не пропускает 80% оракловских хинтов (да кстати и MS SQLных тоже).
..
Так что применительно к Аксапте - на оркале легче бороться с неправильным планом запроса

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

[Тимур]

Вообще есть средние компании, у которых в месяц по 300 000 транзакций в таблице продаж. К тому же у Axapta отсутствуют стандартные механизмы архивации транзакций, поэтому, как предлагал Mazzy, лучше использовать Oracle, в котором можно настроить процедуры оптимизирующие работу с актуальными данными.