Sapforum.Biz
Инструменты => Администрирование (BC) => Тема начата: sapzvezda от Июль 19, 2007, 12:40:51 pm
-
При копировании мандантов между системами рекомендуется сравнить репозитарии систем. Что, в общем то, я и делаю.
Планируется копия одного манданта из теста в разработку. А на разработке какой-то кал устанавливался для одного из модулей, но он остался невостребованным и никуда больше не переносился. Репозитарии на этот мусор и различаются.
Нутром ощущаю, что ничего критичного произойти не должно (тестовый прогон прошел без ошибок), но, на всякий случай, хочу уточнить у спецов с обширным опытом, что они думают по этому поводу.
-
Можно используя параметр 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"
-
Если копирование идет из продуктива, то выравнивание словаря не самый хороший выход, поскольку всегда есть некие разработки, которые пока еще нельзя вкатывать в продуктив, а есть (особенно в системе разработки) некие предпроектные изыски, появление которых в продуктиве только из-за того чтоб выровнять словарь - смертельно...
Вот и выбирай... ;)
-
Ну я как человек очень далекий от базиса все таки рекомендую словарь в системе разработки не выравнивать дабы не быть битым потом разработчиками. Из практики если уж очень хочется сделать выравнивание, то предупреди разрабочикво, чтобы все запросы были деблокированы и занычкованы, а после копирования накати их снова... ну у меня так делали.
-
В принципе, если расхождения только по таблицам из пользовательского пространства имен, то с этим параметром можно делать копию с продуктива, а с несросшимися таблицами потом можно отдельно разобраться если сильно потребуется, но обычно на такие мелочи забивают.
-
В принципе, если расхождения только по таблицам из пользовательского пространства имен, то с этим параметром можно делать копию с продуктива, а с несросшимися таблицами потом можно отдельно разобраться если сильно потребуется, но обычно на такие мелочи забивают.
Копирование то пойдет? Не отфутболит меня система из-за того, что репозитарии различаются? Без применения указанной ноты. Разница продуктива и разработки состоит в некотором кол-ве недокаченных пакетов обновлений в продуктиве и пары никому ненужных Z* в разработке (последним в продуктиве не место, а в разработке никто о них не вспомнит).
-
Копирование то пойдет? Не отфутболит меня система из-за того, что репозитарии различаются? Без применения указанной ноты.
Без ранее упоминавшегося параметра копирование не запустится...
-
Судя по количеству просмотров, тема интересна многим... тогда из моей практики:
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. Подготовка целевой системы к копированию:
б) делаем удаление целевого клиента. Как вариант, чтобы ускорить процесс можно через SE14
не понял? что значит "удаление"?
-
не понял? что значит "удаление"?
Имелось в виду, что делается рефреш уже существующего.
Если это чистый (новый), то этот шаг можно пропустить
-
Имелось в виду, что делается рефреш уже существующего.
Если это чистый (новый), то этот шаг можно пропустить
а то - удалить, удалить...а потом из него юзеров выгрузить ;)
оррригинально звучит
те там может каша получится, если не подчистить? а может действительно грохнуть в scc4 и заново создать?
-
те там может каша получится, если не подчистить? а может действительно грохнуть в scc4 и заново создать?
Я же там писал "из моей практики"... Оказалось, что раздельное удаление и потом копирование проходит быстрее, поскольку система не занимается сравнением данных по таблицам при копировании.
-
Я же там писал "из моей практики"... Оказалось, что раздельное удаление и потом копирование проходит быстрее, поскольку система не занимается сравнением данных по таблицам при копировании.
я говорюб мандант нафик грохнуть и создать чистый ;)
-
я говорюб мандант нафик грохнуть и создать чистый ;)
хм....у меня системы одна целевая SR2 а откуда - SR3 сцуко
spl разные, да и пакеты...pi_basis 2005 # 2006
упрется наверно копирование...
-
хм....у меня системы одна целевая SR2 а откуда - SR3 сцуко
spl разные, да и пакеты...pi_basis 2005 # 2006
упрется наверно копирование...
Желательно выровнять.
Можно сделать тестовый прогон и если не будет ругани по стандарту, то можно копировать
-
хм....у меня системы одна целевая SR2 а откуда - SR3 сцуко
spl разные, да и пакеты...pi_basis 2005 # 2006
упрется наверно копирование...
Желательно выровнять.
Можно сделать тестовый прогон и если не будет ругани по стандарту, то можно копировать
да выровняю..
тест должен быть как продуктив
а система без базисника дожна лежать ;)