Как копировать продуктивные данные в тестовый мандант?

Pride

frEd написал:

Pride написал(а):

а зачем в тесте смотреть FI-ские документы?
не нужно их смотреть, мы таким копированием лишь выравниваем репозитарий, и имеем необходимый набор боевых данных, чтобы можно было делать корректные тесты, подходящие для продуктива.

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

рассматривался вопрос о целесообразности смены логического адреса в тестовой системе после копирования, необходимо это или нет. Если это действительно важно, то умнее будет на это просто указать. И если у тебя нет на этот счёт каких-либо ценных замечаний, кроме как тупых наездов, то и [censored] сюда и лезть.

frEd

Pride написал(а):

frEd написал:

Pride написал(а):

а зачем в тесте смотреть FI-ские документы?
не нужно их смотреть, мы таким копированием лишь выравниваем репозитарий, и имеем необходимый набор боевых данных, чтобы можно было делать корректные тесты, подходящие для продуктива.

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

рассматривался вопрос о целесообразности смены логического адреса в тестовой системе после копирования, необходимо это или нет. Если это действительно важно, то умнее будет на это просто указать. И если у тебя нет на этот счёт каких-либо ценных замечаний, кроме как тупых наездов, то и [censored] сюда и лезть.

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

№1

Ну начинается! :evil:

frEd

№1 написал(а):

Ну начинается! :evil:

все закончилось уже

Pride

frEd написал:

Pride написал(а):

frEd написал:

Pride написал(а):

а зачем в тесте смотреть FI-ские документы?
не нужно их смотреть, мы таким копированием лишь выравниваем репозитарий, и имеем необходимый набор боевых данных, чтобы можно было делать корректные тесты, подходящие для продуктива.

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

рассматривался вопрос о целесообразности смены логического адреса в тестовой системе после копирования, необходимо это или нет. Если это действительно важно, то умнее будет на это просто указать. И если у тебя нет на этот счёт каких-либо ценных замечаний, кроме как тупых наездов, то и [censored] сюда и лезть.

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

Похвально, что ты так заботишься о людях, но вместо заботы лучше бы всё-таки дал дельный совет! Менять логическое имя нужно или нет? И если да, то как это сделать корректно? всё-таки изначально вопрос так ставился. Вот и ответь, если всё знаешь.
P.S. На будущее, грубить не надо. Если ты в чём-то хорошо разбираешься, то просто поделись опытом.

Pride

всё, ладно!
прошу прощения за мусор в форуме.....

№1

Если выполнялось копирование манданта через экспорт/импорт, то после него в целевой системе выполняется SCC7 и там это все пролечивается с логическими именами. При удаленном копировании все делается на автомате в конце копирования.

qdublin

frEd написал:

Pride написал(а):

ну если в ландшафте используется обмен например idoc-ов по ale, и тест тоже в этом задействован, то естественно нужно менять. в противном случае, необязательно, так как логическое имя использует RFC-адрес, который после копирования всё равно работать не будет, и можно на лог. имя просто забить.

Вот тут-то возникает проблема ходят але и идоки, и логическое имя изменять приходится, но со сменой логического имени приходит другая проблема, документы (например FI-ские) становятся не видны, т.е. они в системе есть, но обычными средствами их не посмотришь

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

frEd

[/quote]документов после прогона BDLS.[/quote]
qdublin ай маладЭц, а я все практически тоже самое ручками делал, лазия по таблицам

) огромное спасибо

andivanov

qdublin написал:

frEd написал:

Pride написал(а):

ну если в ландшафте используется обмен например idoc-ов по ale, и тест тоже в этом задействован, то естественно нужно менять. в противном случае, необязательно, так как логическое имя использует RFC-адрес, который после копирования всё равно работать не будет, и можно на лог. имя просто забить.

Вот тут-то возникает проблема ходят але и идоки, и логическое имя изменять приходится, но со сменой логического имени приходит другая проблема, документы (например FI-ские) становятся не видны, т.е. они в системе есть, но обычными средствами их не посмотришь

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

Добрый день!
влезу и со своим вопросом..
по ale настроено хождение idoc'ов. Из продуктива мандант в тестовую систему загоняем через удаленное копирование (scc9, sap_appx)
после каждой копии приходиться рихтовать (ручками) модель расперделения, т.к. в вновь скопированном манданте настройки ale (bd97), естесственно, некорректные...
собственно вопрос - можно ли это дело как-то автоматизировать?
т.е. сохранить настройки, а потом восстановить? или нереально?

tr0ublemaker

опять поднимаю старую тему.

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

но есть одно "но": найденое руководство, инструментарий и т.д. и т.п. предназначено для R/3 4/6D ORA 8.1.7. скопировать же необходимо систему R/3 4.7 Web AS 6.20 на ORA 9.2. (тестовая система так же R/3 4.7 Web AS 6.20 на ORA 9.2)

получается процедура и инструменты те же самые? потому что в руководстве для 6.20 нет ни слова про копирование из бэкапа

Kauftunn

Svetlana написал(а):

а я вообще не понимаю зачем манданты копировать по САП_АЛЛ -я копирую целиком систему. Это быстрее гораздо.

Тема старая, но мы все идёт по одному пути. Я нахожусь в самом начале и прошу быть снисходительными.

Необходимо получить копию продуктива в тестовой системе, с сохранением консистентности. Мы наработали 300 ГБ данных и SCC9 нас не спасает, так как максимальный останов - 9 часов. Бэкап идёт прямо на ленту через агента Veritas NetBackup, который даёт возможность вернуть данные только непосредственно в продуктивную систему (на Veritas'e невозможно изменить точку восстановления). Мне даже подумать страшно, что будет если эти данные недельной давности пойдут в продуктивную систему (лирика). Можно поподробнее рассказать как вы копируете систему целиком?

qdublin

Kauftunn написал:

Бэкап идёт прямо на ленту через агента Veritas NetBackup, который даёт возможность вернуть данные только непосредственно в продуктивную систему (на Veritas'e невозможно изменить точку восстановления).

Вы в этом абсолютно уверены?

Kauftunn

Нет, я не уверен насчет этого. Для меня SAP - это вообще большая загадка и чем больше я узнаю, тем больше круг моего незнания.

Честно говоря просто не знаю, но:

1) Веритас не позволяет выбрать бэкапы для восстановления, если они сделаны типом политики "Sapproduct". Насколько мне известно/понимаю, к указанным данным обращается только процесс запущенный из продуктивной системы.
2) Даже если процесс восстановления не начнётся сразу же, то всплывает другая проблема - на диске нет места чтобы выложить на него бэкап.

Bully

Kauftunn написал:

Необходимо получить копию продуктива в тестовой системе, с сохранением консистентности.

Есть струмент GAMMA Infoshuttle

Цитата:

Replicate Production Data to Non-Production Systems

The most valid data for SAP functional specialists, developers and testers is current production data. However, getting new data into existing non-production environments using traditional utilities, without disruption of active projects, is nearly impossible. Similarly, entering records manually offers a poor alternative due to the many intricate dependencies that exist between SAP data objects.

By using comprehensive processes to select and replicate data between environments through an SAP standard interface, Data On Demand:

• Provides easy access to current, relevant production data
• Automatically captures business process data and all dependencies
• Eliminates manual record entry
• Reduces storage space requirements

На одном из проектов использовали, мне понравилось.

Правила форума

Как копировать продуктивные данные в тестовый мандант?

Кто сейчас на конференции