Добрый день всем.
Столкнулся тут с такой проблемой - необходимо выявить все узкие места MaxDB и проработать перевод продуктивного ландшафта с Oracle на MaxDB.

Не подкините ли инфы, уважаемые?

ЗЫ покопавшись по форуму, нашел самое интересное в: Опрос SAP DB/ MAX DB vs. Oracle. Ничего более стоящего не накопал.
Но во-первых ветка очень старая, а во-вторых хотелось бы больше информации.

Буду очень признателен всем за любые мысли-идеи-советы-слова.

А можно поинтересоваться, чем Oracle так сильно не устраивает?

Честно?
Только ценой.

А как он может не устраивать ценой, если уже установлен?
Или поддержка меньше станет?

И поддержка и расширение (если надо) и к тому же "установлен" и "куплен с правильным набором лицензий" - не одно и тоже.

Уважаемые, обычно такими вещами не страдают(и других дел хватает), потому что переход с одной СУБД на другую - это не только технический вопрос, упирающийся в финансы...
Выделят вам ресурсы(время,деньги) на переобучение ? Выделят вам ресурсы(время,деньги) на тестирование ?
Насколько сильно изменится производительность ? Как изменится время восстановления системы ?
Как будет проиходить процесс создания резервных копий....etc...
Чтобы заниматься заменой платформы должны быть очень серьёзные аргументы....

Кроме того, Оракл в конторе может быть не только для SAPa, но и сам по себе....
А плодить зоопарк СУБД, тоже обычно "не комильфо...".....

Я лично согласен с этим на 150%%, но попробуйте объяснить это "кому надо". Включая производительность (ну мы же не используем ничего "такого"), бэкапы (там САП все сам делает - че такого), обучение (ну надо будет - научитесь).

ЗЫ из всех "веделят вам ресурсы" смело можно выкинуть слово "деньги" - однозначно нет! Смысл этого финта - уменьшить TOC (Total cost of ownership - общая стоимость владения). И основная зацепка - бесплатность МаксДБ. (все было бы клево если бы ее использовать с первого дня). И лично я в курсе что сам САП говорит об исключительности ситуации когда приходиться менять СУБД "на лету". Причем гарантий нет (даже в случае вызова ИХ спеца).

ЗЗЫ и все же - ну мало ли.... ну не может быть чтобы я один такой попавший был.

"Всяко бывало, но такое в первый раз", сочувствую, коллега.

вроде бы цена оракла включена в сап
вопрос - различается ли цена лицензий при использовании оракл и максдб ?

Реклама MaxDB от SAP (правда, 2007-года): http://maxdb.sap.com/events/MaxDB_Infod ... eister.pdf

Про цену лицензии не помню, но ежегодный сбор на обслуживании существенно ниже. Если не забуду, спрошу точные цифры.

Вообще, в Германии уже какое-то время клиенты переходят с Oracle на MaxDB и DB2. Лично сам сейчас в двух таких проектах участвую. Есть даже массовые переходы, по 50-100 систем. Экономия ежегодных сборах, в итоге, ощутимая, но, реализация, как уже сказал bdmalex, дело трудоёмкое и дорогостоящее.

Нет нет и нет!

Цена СУБД не включается в стоимость САПа
Можно приобрести СУБД у поставщиков САПа "в комплекте", но в последнее время, если мне не изменяет память они от этого отходят. Т.е. "мухи отдельно, котлеты отдельно".

Цена лицензий на САП? нет не отличается. Т.к. лицензируються пользователи. Netweaver User, BW User и проч. Чисто функционально, но не зависимо от СУБД и чего-то еще.

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



bdmalex сказал конечно. И трудоемкость примерно представима. Но вопрос в том - есть ли реальный опыт а не домыслы?
Вот например кто-нибудь пытался продуктивную систему (или весь ландшафт - 5 систем) перенести в процессе работы на другое железо? Теоретически сложность сопастовимая с рассматриваемым вопросом (т.е. "да это сложно и просто так такие вещи "уважаемые" не делают ну и бла-бла-бла"). А я такое делал и могу сказать - в случае успеха это займет X дней минимум + Y дней на "доводки". В случае неуспеха возможно ...(и по списку).

Я вот что-то подобное хочу выяснить.

на другое железо? Или миграция базы данных? это несколько разные вещи. Если например просто Oracle перенести на другое железо - то вообще можно обойтись без downtime - существуют технологии (и это не теоретические измышления а самый что ни на есть практический опыт:), а миграция без downtime не обойдется. Занимает по разному количество времени. В зависимости от объема базы данных прежде всего. Неуспех невозможен. Все определяется временем downtime. И что-то Вы темните:) В процессе выясняется что надо другую версию Oracle бла-бла-бла. Так апгрейдтесь - кто мешает-то?:) И в цену лицензии SAP входит цена за базу данных, если только именно клиент не настаивал, что ему на фик не надо базу покупать у меня есть и много (вот тут-то и наступает та ситуация, которую описал автор):) Купить отдельно можно - но зачем? И не платить за поддержку САПу можно конечно - но только в случае если развивать дальше проект не планируете...

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

На данный момент учавствую двух таких проектах:

1. перенос трёх-системного ландшафта (плюс Solution Manager) с AIX/ORACLE на AIX/DB2,
2. перенос трёх-системного ландшафта с AIX/ORACLE na WIN/MaxDB, включая конвертацию в Unicode и последующим Upgrade до SAP ERP 6.0.

По-первому проекту вчера и сегодня перенёс Solution Manager. ABAP-Stack закончен, однако выявились проблемы с JAVA-Stack. Завтра буду разбираться.

По-второму делал тестовый Export с конвертацией в Unicode, коллега делал импорт и послемиграцонные активности, на 16 июля запланирован Upgrade.

Ответить на вопрос, сколько времени потребуется на export и import, наобум трудно, т.к. на это влияют разные факторы, например, размер базы данных, наличие очень крупных таблиц, быстродействие "железа", соответствие минимальным требованиям для миграции (может быть необходимо сначала пачить систему-источник), и т.д.

Лучше всего проделать тестовую миграцию, она даст вам примерные представления об этом чуде.

Да, для продуктива настоятельно рекомендуется SAP OS/DB Migration Check, но тогда вам необходимо будет указать в заявке сертифицированного SAP Migration Partner.

Migration of Operating System or Database
• SAP OS/DB Migration Check. In addition to performing a
standard system check, this service offers recommendations
for reconfiguration of the system, including hardware. This
service is performed when migrating to a new operating system
or database.

http://www.sap.com/services/pdf/Serv_ID ... IDC-WP.pdf

Я понимаю что разные. Это будет зависить от ряда факторов - делать на одном железе или с перездом сервера. Скорее всего со сменой железа (но на аналогичное).


А при чем тут "перенести Оракл"???


Это не я темню. Я простой базисник - мне сказали копать, я копаю. Соответственно закупкой я не занимался. Просто выяснилось что вначале была приобретена СУБД отдельно от САП и с неверным набором лицензий. ПРоапгрейдить мешает только одно - как объяснить руководству "неожиданную потребность" в скажем 50 или 100 тысячах долларов. Просто вот "вдруг случайно выяснилось..."

И все-же исходя из моего личного опыта общения с САП-СНГ - они могут посоветовать СУБД, но чаще клиент приобретает ее отдельно. По крайней мере сосчитать правильные лицензии они не могут.


Пожалуйста не надо вот этого "у тех кто знает...". Уверяю вас - неуспех возможен и еще как. При конвертации СУБД - очень даже. Сам САП предлагает для этих целей своих спецов. Они это сделают быстрее и качественнее чем я скажем, но и они (внимание!!!) НЕ ГАРАНТИРУЮТ 100% успех. Это за Х кило-евро в день за спеца. Спецов должно быть от 2х штук и более. Так что я бы не кидался словами "неуспех невозможен"


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