При копировании мандантов между системами рекомендуется сравнить репозитарии систем. Что, в общем то, я и делаю.
Планируется копия одного манданта из теста в разработку. А на разработке какой-то кал устанавливался для одного из модулей, но он остался невостребованным и никуда больше не переносился. Репозитарии на этот мусор и различаются.
Нутром ощущаю, что ничего критичного произойти не должно (тестовый прогон прошел без ошибок), но, на всякий случай, хочу уточнить у спецов с обширным опытом, что они думают по этому поводу.
Можно используя параметр NO_RFCCHK (подробности в ноте 446485)
Подробности пугают "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 від Липень 19, 2007, 04:46:43 ПП
В принципе, если расхождения только по таблицам из пользовательского пространства имен, то с этим параметром можно делать копию с продуктива, а с несросшимися таблицами потом можно отдельно разобраться если сильно потребуется, но обычно на такие мелочи забивают.
Копирование то пойдет? Не отфутболит меня система из-за того, что репозитарии различаются? Без применения указанной ноты. Разница продуктива и разработки состоит в некотором кол-ве недокаченных пакетов обновлений в продуктиве и пары никому ненужных Z* в разработке (последним в продуктиве не место, а в разработке никто о них не вспомнит).
Цитата: sapzvezda від Липень 19, 2007, 05:02:03 ПП
Копирование то пойдет? Не отфутболит меня система из-за того, что репозитарии различаются? Без применения указанной ноты.
Без ранее упоминавшегося параметра копирование не запустится...
Судя по количеству просмотров, тема интересна многим... тогда из моей практики:
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 из исходной системы в целевую, но конечно же некая неконсистентность данных будет иметь место :( ...
Цитата: № 1 від Липень 31, 2007, 08:34:22 ПП
Судя по количеству просмотров, тема интересна многим... тогда из моей практики:
1. Подготовка целевой системы к копированию:
б) делаем удаление целевого клиента. Как вариант, чтобы ускорить процесс можно через SE14
не понял? что значит "удаление"?
Цитата: Skif від Вересень 25, 2009, 10:36:24 ДП
не понял? что значит "удаление"?
Имелось в виду, что делается рефреш уже существующего.
Если это чистый (новый), то этот шаг можно пропустить
Цитата: № 1 від Вересень 25, 2009, 10:39:19 ДП
Имелось в виду, что делается рефреш уже существующего.
Если это чистый (новый), то этот шаг можно пропустить
а то - удалить, удалить...а потом из него юзеров выгрузить ;)
оррригинально звучит
те там может каша получится, если не подчистить? а может действительно грохнуть в scc4 и заново создать?
Цитата: Skif від Вересень 25, 2009, 11:21:46 ДП
те там может каша получится, если не подчистить? а может действительно грохнуть в scc4 и заново создать?
Я же там писал "из моей практики"... Оказалось, что раздельное удаление и потом копирование проходит быстрее, поскольку система не занимается сравнением данных по таблицам при копировании.
Цитата: № 1 від Вересень 25, 2009, 12:23:31 ПП
Я же там писал "из моей практики"... Оказалось, что раздельное удаление и потом копирование проходит быстрее, поскольку система не занимается сравнением данных по таблицам при копировании.
я говорюб мандант нафик грохнуть и создать чистый ;)
Цитата: Skif від Вересень 25, 2009, 12:51:39 ПП
я говорюб мандант нафик грохнуть и создать чистый ;)
хм....у меня системы одна целевая SR2 а откуда - SR3 сцуко
spl разные, да и пакеты...pi_basis 2005 # 2006
упрется наверно копирование...
Цитата: Skif від Вересень 25, 2009, 02:08:48 ПП
хм....у меня системы одна целевая SR2 а откуда - SR3 сцуко
spl разные, да и пакеты...pi_basis 2005 # 2006
упрется наверно копирование...
Желательно выровнять.
Можно сделать тестовый прогон и если не будет ругани по стандарту, то можно копировать
Цитата: № 1 від Вересень 25, 2009, 02:20:14 ПП
Цитата: Skif від Вересень 25, 2009, 02:08:48 ПП
хм....у меня системы одна целевая SR2 а откуда - SR3 сцуко
spl разные, да и пакеты...pi_basis 2005 # 2006
упрется наверно копирование...
Желательно выровнять.
Можно сделать тестовый прогон и если не будет ругани по стандарту, то можно копировать
да выровняю..
тест должен быть как продуктив
а система без базисника дожна лежать ;)