Здравствуйте коллеги. Посоветуйте, правильно ли я организую системный ландшафт: у меня 2-е виртуальные машины под управлением Win2008 на одной установил Oracle на другую центральный инстанс SAP. Предполагается наличие 3-х клиентов: DEV, TEST, PROD. Нужно разделять системы DEV,ТEST и PROD на разные системы? То есть устанавливать отдельный экземпляр БД для DEV, TEST и отдельный для PROD и соответственно устанавливать две центральных инстанции для DEV, TEST и PROD. Или все делать в одной системе? Но если на одной то манданто-независимые настройки будут применятся сразу и на продуктов. Посоветуйте как сделать правильно.
SAP ERP 6.0, Oracle 10.2.0.4

Вы, я так подозреваю, с оракловских аппсов в SAP подались?
Начните с курсов.

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

мда...

остальное малоцензурно

прямо с регулярностью "трудных дней"

Спасибо за ответ. А не подскажите нужно выносить в отдельную систему продуктив? Курсы ADM100 и ADM102 я читал, но в их терминалогии не очень понятно как все реализовать.

По системному ландшавту курс ADM 325
Продуктивная система обычно состаит из кластера , два сервера.

Ну подумайте сами, можно ли смешивать на одном сервере продуктивную систему с чем либо еще, что будет кушать ресурсы? Я уже и не говорю про возможные конфликты, когда требуется перезапуск OS.

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

2 Grif,

Весьма категоричное высказывание
Прекрасно знаком с продуктивами не в кластерной конфигурации. Также знаком с продуктивами в реализации "два датацентра разнесенных на расстояние не менее 1000 км". Есть и экзотические реализации с переносом, в случае необходимости, продуктивной системы на сервер с системой кволити. Последняя автоматически гасится.
В общем то все упирается в требование заказчика по допустимому времени простоя продуктивной системы. Ну, и финансовые возможности тоже играют определенную роль.

Это все понятно, но нет у меня больше сервера И хотелось бы из данной ситуации выйти с наиболее грамотным решением...

Простите, что отвечаю вопросом на вопрос, но интересно - на какой стадии у вас находится проект?
Дело в том, что если проект только начинается, тогда вы определенное время можете обойтись без тестовой системы, есть проекты где ее вообще нет, хотя риски при этом существенно повышаются, это первое. Второе, продуктивная система вам понадобится за 1-2 месяца до начала опытно-промышленной эксплуатации. Думаю, что у вас есть время на то чтобы убедить "ответственных товарищей" на покупку отдельного сервера/серверов для продуктивной системы. Учитывая стоимость внедрения, серверное оборудование в этих суммах занимает небольшой процент.
По поводу систем/БД. Конечно, как вам писали выше, оптимально иметь отдельную БД для каждой системы, но в моей практике было несколько случаев, когда разработка и тест жили в одной базе. Конечно у этого решения есть свои минусы, как то - останов одной базы приводит к останову всех систем, тестирование обновлений, восстановление из бэкапа и пр. Важность этих нюансов определяете только вы. Но продуктивная система должна использовать "свою" БД, стоять она должна на отдельном сервере/разделе сервера и т.п., необходимо предусматривать резервирование и масштабирование по оборудованию.
Использование виртуалок не исключает взаимного влияния, а это не хорошо.

Э-э-э... Я правильно понимаю ситуацию, что есть только одна железка, и на нее надо поставить разработку, тест и продуктив?

Видимо так и есть, и на этой железке есть 2 виртуалки. Самое простое решение в одну виртуалку поставить разраб и тест с раздельной БД(не мкод). Во вторую витруалку поставить продуктив. При появлении новой железки легко переедете продуктивом на нее.

Да Вы понимаете правильно

Vit
теперь представьте работоспособность такого ландшафта...

до 10 пользователей при условии что они будут ходить не дальше экрана приветствия... ни о каком наполнении систем не может идти речи... ни о какой установке патчей, или хуже - апгрейда (EHP4) тьфу тьфу тьфу....

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

все остальное - это вышивание крестиком на бетонной стене..

Минимум 13-14 Gb памяти, 3 приличных физических диска на SAS или SCSI плюс один под головную ось, 4 процессорных ядра. И попробовать взлететь. Хотя бы чуть-чуть. Про надежность речь не идет.

Характеристики сервака: 36 Гб оперативки 2-а проца по 4-е ядра диск системный SAS но небольшой. Сервак подключен к СХД где собственно и будут лежать базы. Ну вобщем из всех обсуждений я делаю вывод что каждую систему нужно выделить отдельно (т.е. отдельная инстанция и отдельная БД) и продуктив лучше вынести на отдельную виртуалку вместе с БД продуктива для последующего переноса на другой сервер при внезапном его появлении Так ?