Планируется переход на MSSQL ожидают прирост производительности.
Есть у кого то опыт работы с разными СУБД под SAP? Действительно ли будет получен ощутимый выигрыш и за счет чего?
Буду рад развернутым аргументированным ответам.

Зачем вам рассуждения о сферическом коне от людей, которые ничего не знают о вашей системе?
Спросите лучше того, кто принимал это решение насчет перехода - уж он то наверняка в курсе насчет ожидаемого ощутимого выигрыша.
И напишите его аргументы сюда, тогда уже можно будет что то обсуждать

George Nordic, перенесите пожалуйста тему в базис. Админы с удовольствием поучаствуют

С какой субд? Если с оракле, я бы с удовольствием послушал доводы, человека принявшего такое решение.
Чувствую, довод один ("я в оракле ничего не понимаю, значит MSSQL будет работать лучше").

Не, чаще всего доводы другие.
Вариант 1: У нас уже есть сервер с MS SQL, вот туда вашу сапу и добавим
Вариант 2: У нас есть администраторы MS SQL, вот они заодно и сапу поадминят, и с базой позанимаются.

второй довод имеет место быть, админы по МС действительно есть и вроде как матерые. скорее всего довод в отказе от услуг тех кто нынче отвечает за администрирование нынче..
первый довод навряд ли звучит, новый ЦОД закупили, с нуля поднимать какая разница какую СУБД?

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

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

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

например на базах свыше 10 Терабайт при высокой нагрузке более 2000 одновременно работающих пользователей сервера на Oracle показывают лучшую производительность, или наоборот?

1. Наличие специалистов по MS SQL, не знающих архитектуру SAP, никак не поможет в оптимизации базы. На кривой настройке и отсутствии оптимизации самой системы - это ловля блох.
2. Аналогично по Oracle
3. Нужен качественный базисник, который знает общие принципы оптимизации SAP и умеющий читать технический английский. С доступом на SAPNet.
4. Если поддержка оплачена - можно заказать анализ системы, с рекомендациями, SAP'у. Там есть люди, которые могут выполнить такую работу.
5. Идея со сменой базы из-за тормозов напоминает анекдот: - Дорогая, что с детьми делать будем? Старых помоем или новых наделаем?
6. Oracle на больших объемах (кстати, 10 Tb вовсе не огромная база) чаще всего обеспечивает лучшую производительность на сопоставимом железе. Другими словами масштабируемость у него лучше
7. По поводу производительности - попробуйте найти выходы на ритейлеров (например X5), если очень приперло пообщаться за производительность системы. Производительность упирается вовсе не в базу, если, конечно, там налажено правильное её обслуживание, типа индексы не трехлетней давности, старые и ненужные данные не лежат в загашнике...

Как-то так.

to avlag - согласен


если матерые по MS, то в сторону Sybase посмотрите
правда если насчет конкретных примеров производительности и тестов, то в САП СНГ обратитесь, они вам могут показать примеры


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

ох блин... забыл... насчет "общих вариантов оценки производительности" - ну это в конфигуратор и по SAPSам

воще начинать обсуждение надо с железо/ось. имхо, под виндой, может быть, таки есть. Так же как DB2 на IBM и ракель на соляре/спарк.

Это конечно мое ИМХО, но MSSQL с 10тер базой - это фантастика.
Для оракла - это средняя база, к примеру в Х5 ритейл, бд, если я не ошибаюсь больше 25 тер., и они вот как - то на MSSQL переходить не планируют
Проведите сайзинг, если будете ставить с 0, как раз самое время. Больший упор надо делать именно на железо и схд, а потом уже на базу. Любую технологию можно прогнуть при безграмотном подходе, не зная специфики.

Дааа ... тут вам MSSQl поможет прям сходу ) Может не поскупятся ваши товарищи , наймут нормальных контрактников или как там они называются , посмотрят вашу систему ,
скажут что к чему , ИМХО оракл , особенно последние версии 11+ прям тюнятся на ура. По опыту скажу , все тормоза-висяки и тд на 80% это кривые отчеты , неправильные индексы , короче
оптимизация внутри БД + по базису конечно нужно смотреть , ибо видел системы где в ораклином буфере ноликами промахивались и удивлялись потом что так сё тормозит с 5 гигами кеша.
P.S.
У нас базы 10-16 треабайт на оракле , пользователей как вы просите >2000 , теперь найдите такое же на MSSQL пожалуйста.

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

здесь на форуме было, что при переезде на другую СУБД производительность повышается не от другой БД, а от дефрагментации её файлов.

Ох.
Что-то ни кто из матёрых базисников не сказал важнейшей вещи.
А почему вы решили, что тормозит именно СУБД.
Почему не APP-сервер?
Вобще, performance tuning - нетривиальный вопрос.
Проблема может быть в железе. Например мало памяти или CPU, торможение дисковой подсистемы.
Торможение может быть из-за неправильной конфигурации.
Например надо дать больше памяти для определенных буферов или же просто не хватает диалоговых процессов.
Может надо посто создать несколько индексов в БД.
А может и ABAP-еров поменять.
и т.д.

В общем, обратитесь к базиснику.

Дайте мне поправить профили инстанции и оракла.
Я вам организую тормоза на любом железе и в любом ЦОД-е.