Ну его и зарелизили не так давно, да и не до конца
Нотка 1133230

Представители SAP рекомендуют все же DB/2.
Почему?

1. SAP с Oracle в очередной раз поругались
2. Если рекомендацию дает не SAP СНГ, то может быть связано с тем, что в Европе DB2 больше распространена
3. Связано с тем, на каком оборудовании/оси Вы собираетесь работать, и SAP это знает

А вот помню, какое-то время назад SAP с MS заключили какое-то партнерское соглашение.
И саповские маркетологи активно рекомендовали MS SQL. Скидками заманивали
Так что на вопрос "почему"...

Как раз она!

Оборудование и платформа все еще в стадии выбора.
Так почему они именно DB/2 рекомендуют?

Так спросите у них, да?

Кстати, дополнительный вопрос по теме DB2.
Работаем на DB2 на удаленном базисе, который полностью поддерживается аутсорсером у них на application provider площадке.
Недавно вылетела база. Как оказалось у аутсорсера бекапы были битые. Они объяснили тем, что на DB2 нет он-лайн проверки бекапа на правильность.

На основании этого они рекомендовали нам перейти на Оракл, но обслуживание будет стоить дороже.

Это правда или нам "слепили отмазку"?

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

к людям тоже привязываться не хорошая идея, на мой взгляд
у нас один клиент, на этапе старта захотел на SQL сервере - ИТ-шник предпочел её.
потом, кажется еще до продуктивного старта он ушел, а система так и живёт на SQL сервере. новый ИТ-шник жалеет, что не Oracle на линуксе. правда я не знаю как насчет цены.

В принципе все правильно:) НО! солярщиков много - аксоидов сейчас прибавляется - поскольку на рынке вот такая чехарда происходит - НО в принципе - все равно все железо на поддержке у интегратора:). Так что есть время и выучить своих и в принципе больших проблем не поиметь - если выбрать нормального интегратора конечно и нормальный договор составить:) По поводу DBA - в САПе знания реального DBA (ну например уровня OCP) нужны на очень узком участке - там где базы - как минимум больше 1 Тб и очень серьезная нагрузка. В принципе - это практически только ретейл. В остальном уровень OCA вполне достаточен....

Ну да ораклисты дешевле DBтушников:) и сановцы дешевле в принципе аиксоидов - на сегодняшний момент времени...
а так - да никакой разницы. Только возможности самой СУБД - потянет не потянет.

насчет онлайн проверки бэкапов - вообще-то у САпа существуют рекомендации для любой базы данных - восснанавливаться периодически:)
Аутсорсинг был ОБЯЗАН обеспечить. Не устаю повторять - тщательно нужно выбирать аутсорсеров - а не брать "домашние" компании или что подешевле...

Эти рекомендации как то оформлены в ноту?

Под восстанавливаться, Вы имели ввиду поднятия бэкапа на тестовом сервере?

Ноты оформляются по конкретным проблемам. А это рекомендации, основанные на элементарном здравом смысле.
В общем случае, восстановление из бэкапа требуется редко, и связано, чаще всего, с disaster recovery.
За время жизни системы эта процедура может вообще никогда не понадобиться.
Но если вдруг потребуется восстановить систему, хотелось бы иметь уверенность, что бэкап сделан правильно и персонал умеет его восстанавливать как на старом железе, так и при подъеме с нуля.
А чтобы иметь такую уверенность, надо периодически тренироваться в восстановлении системы из бэкапа. Ну и иметь регламент на все процедуры. С расписанием ответственных лиц.
Правда, на моей практике, была только одна компания, которая при закупке железа предусмотрела отдельный сервер для проведения тестовых процедур восстановления системы из бэкапа.

Зато на всех проектах через некоторое время после продуктивного старта обязательно у кого-нибудь да возникает зуд необходимости поднять копию продуктива. Да еще и обновлять ее относительно регулярно. Вот вам и тренировка поднятия и проверка читаемости бэкапа, по полной схеме.

Только не абстрактную копию продуктива, а скопировать данные в Q&A или в разработку А это без бэкапа проще делать.
А зачем, в нормальных условиях, делать копию продуктива? Да и с точки зрения секьюрити не совсем хорошая идея иметь дублированные продуктивные данные

Когда размер продуктива считается уже сотнями гигов, то копирование продуктива в тест уже с дури-то не сделаешь. С бэкапа поднять получается гораздо проще. На таких объемах копирование манданта просто не выполнится, по крайней мере за приемлемое время.
С другой стороны, у меня был случай, когда получив систему в эксплуатацию с давней историей, обнаружил, что там имелась привычка регулярно, раз в пару месяцев, накрывать тест продуктивом. Просто восстановлением из бэкапа. Вот где коры были...

А на кой ляд это нужно, обычно для самого загадка.
Все объяснения сводятся к "нам нужно протестировать/проверить на реальных данных". Или "нам нужно состояние системы на такой-то момент в прошлом"