Копия манданта через SCC9 – RFC System Comparison

[sapzvezda]

При копировании мандантов между системами рекомендуется сравнить репозитарии систем. Что, в общем то, я и делаю.

Планируется копия одного манданта из теста в разработку. А на разработке какой-то кал устанавливался для одного из модулей, но он остался невостребованным и никуда больше не переносился. Репозитарии на этот мусор и различаются.

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

[№1]

Можно используя параметр NO_RFCCHK (подробности в ноте 446485)

[sapzvezda]

Подробности пугают "Therefore, this option may only be used as a very last option for special experimental situations and SAP cannot provide any support for copies made using this option"

[№1]

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

[Uukrul]

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

[№1]

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

[sapzvezda]

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

Копирование то пойдет? Не отфутболит меня система из-за того, что репозитарии различаются? Без применения указанной ноты. Разница продуктива и разработки состоит в некотором кол-ве недокаченных пакетов обновлений в продуктиве и пары никому ненужных Z* в разработке (последним в продуктиве не место, а в разработке никто о них не вспомнит).

[№1]

Копирование то пойдет? Не отфутболит меня система из-за того, что репозитарии различаются? Без применения указанной ноты.

Без ранее упоминавшегося параметра копирование не запустится...

[№1]

Судя по количеству просмотров, тема интересна многим... тогда из моей практики:
1. Подготовка целевой системы к копированию:
    а) выставляем параметр NO_RFCCHK
    б) делаем удаление целевого клиента. Как вариант, чтобы ускорить процесс можно через SE14
        удалить таблицы размером больше 500Мб (находим через DB02 или ST04) и таблицы с
        количеством записей большим 1000000 (можно посмотреть в таблице DBSTATTORA),
        ну или удалить с уровня базы через truncate - кому как удобнее  :).
        Внимание: удалению подлежат исключительно таблицы с прикладными данными!!!   
        Если в системе несколько клиентов, то перед удалением таблиц нужно сделать транспорт
        копии удаляемых таблиц (R3TR TABU <table>) в каждом клиенте, которые после
        удаления таблиц целевого импортируются обратно в соответствующие клиенты.
    в) Делаем экспорт из целевого клиента пользователей через SCC8. Хотя при удаленном
        копировании пользователи не копируются, но роли и полномочия – копируются, что
        приводит к очевидному косяку.
2. Планируем удаленное копирование через SCC9. При планировании копирования следует
    указать параллельное выполнение через Goto->Parallel processes. Число процессов 10-12.
3. По окончании копирования выполнить импорт пользователей и полномочий обратно в
    целевой клиент.
4. Запустить сбор статистики – транзакция DB20ORA
5. Поправить логические системы через BDLS

Вроде ничего не забыл.... хотя есть ньюанс: в случае, если в системе, из которой велось копирование, продолжали работать пользователи, то неизбежно расползание диапазонов номеров и наличие/отсутствие части записей по документам. В таком случае полезно после окончания копирования отдельным запросом перенести содержимое таблицы NRIV из исходной системы в целевую, но конечно же некая неконсистентность данных будет иметь место  :( ...

[Skif]

Судя по количеству просмотров, тема интересна многим... тогда из моей практики:
1. Подготовка целевой системы к копированию:
        б) делаем удаление целевого клиента. Как вариант, чтобы ускорить процесс можно через SE14

не понял? что значит "удаление"?

[№1]

не понял? что значит "удаление"?

Имелось в виду, что делается рефреш уже существующего.
Если это чистый (новый), то этот шаг можно пропустить

[Skif]

Имелось в виду, что делается рефреш уже существующего.
Если это чистый (новый), то этот шаг можно пропустить

а то - удалить, удалить...а потом из него юзеров выгрузить ;)
оррригинально звучит
те там может каша получится, если не подчистить? а может действительно грохнуть в scc4 и заново создать?

[№1]

те там может каша получится, если не подчистить? а может действительно грохнуть в scc4 и заново создать?

Я же там писал "из моей практики"... Оказалось, что раздельное удаление и потом копирование проходит быстрее, поскольку система не занимается сравнением данных по таблицам при копировании.

[Skif]

Я же там писал "из моей практики"... Оказалось, что раздельное удаление и потом копирование проходит быстрее, поскольку система не занимается сравнением данных по таблицам при копировании.

я говорюб мандант нафик грохнуть и создать чистый ;)

[Skif]

я говорюб мандант нафик грохнуть и создать чистый ;)

хм....у меня системы одна целевая SR2 а откуда - SR3 сцуко
spl разные, да и пакеты...pi_basis 2005 # 2006
упрется наверно копирование...

[№1]

хм....у меня системы одна целевая SR2 а откуда - SR3 сцуко
spl разные, да и пакеты...pi_basis 2005 # 2006
упрется наверно копирование...
Желательно выровнять.
Можно сделать тестовый прогон и если не будет ругани по стандарту, то можно копировать

[Skif]

хм....у меня системы одна целевая SR2 а откуда - SR3 сцуко
spl разные, да и пакеты...pi_basis 2005 # 2006
упрется наверно копирование...
Желательно выровнять.
Можно сделать тестовый прогон и если не будет ругани по стандарту, то можно копировать

да выровняю..
тест должен быть как продуктив
а система без базисника дожна лежать ;)