Посмотрите на производительность сети. Курсы тут не помогут.

а базато какого объема? если куча терробаитов то возможно



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

( однажды лицезрел такую фигню у одного коллеги в 4.7 )

ну или всётаки действительно жестоко раскиданные сервера с наихреновейшей связью?

Имею в виду именно копирование манданта.
Сервера рядом, через гигабитный хаб ходят.
Объем базы примерно 250 гиг.
Сеть работает отлично.
Пользователей можно высадить только на 8-10 часов, дольше - никак.
Перенос данных тр-цией SCC9 - дистанционное копирование мандантов.

250 гиг - 7-12 дней? этого быть не может. Курсы не помогут. Надо смотреть что происходит.

Правильно ваш базис руками разводит. Меньше нескольких суток (4-5-6) не скопируется. А при возникновении ошибок - и вся неделя.
Продуктивные манданты таких размеров (а базе продуктива 250 Гб - наверняка почти все данные в продуктивном манданте).

Читайте признания вендора - Note 67205 - CC-INFO: Copying large and productive clients

Для обновления данных в тесте из продуктива большого объема САП придумал SAP TDMS.. Позволяет скопировать не все транзакционные данные, а лишь, например, "за последний квартал".

Правда - мало кто его пользовал, похоже...

Если через SCC9, то очень даже запросто. Собственно сам механизм весьма тормознутый, что в SAP и не особенно скрывают.

В процитированной мной ноте:
"............
1. A productive client contains several GB of data. This data must be read and then written again during a client copy. The database interface limits the throughput to 100 - 500 MB/hour. From this, a runtime of 1 - 2 hours results for Customizing clients and a longer runtime - up to several weeks - for productive clients.
a) Parallel processes
As of Release 4.6 a parallel client copy program is available which can significantly reduce the runtime. You can distribute the process to several application servers. You should then pay special attention to the database server. Two processes per CPU of the database server is a practical limit of the total number of processes.
..............."
Вот и считаем 4 CPU * 2 RFС процесса * 500 Мб/час = 4 Гб/час - вот производительность копирования (в лучшем случае).
Т.е. 120 Гб в сутки - макисмум.
То есть - 2 суток - в идеале...
На практике - найдется куча bottleneck'ов, которые все в пару раз увеличат...

Может-может Смотреть... Куда?

Узкое место, на самом-то деле, невозможность выгнать пользователей из системы, как следствие - блокированные таблицы\неконсистентность данных и балаган 2хнедельного копирования манданта.


Ноту почитаю.
qdublin А каким еще способом? [/b]

а зачем делать копирование манданта тогда две недели, если можно сделать бэкап за 1 час, и восстановить это дело на другом сервере? и играйтесь с ним сколько угодно... Хотя бэкап 250Гб за 1 час? что-то чересчур быстро...

Если тестирование проходит в отдельной системе, то гомогенное копирование или восстановление из резервной копии продуктива. Все же значительно быстрее будет.
Ну а если в манданте тестируете, можно экспорт/импорт манданта попробовать.

Экспорт/импорт манданта будет работать бесконечно - по сравнению с remote client copy - т.к. нет распараллеливания, сам SAP про это пишет.

Гетерогенное копирование - это конечно быстро - но имеет минусы - получите в итоге клон продуктива - со всеми исходящими интерфейсами, тем же номером манданта и прочими одинаковостями. Ладно если такой тест примут за продуктив, а если потом в продуктиве эксперимент проведут, думая, что это тест ?:)

Это как это, если хосты разные? Ну и роли с полномочиями в продуктиве никто не отменял.

не согласен, просто надо творчески подойти к процессу.
имопрт базы порядка 300-350 Гб проходил за 36-40 часов
ну а через scc9 база 500 Гб копировалась 2-е суток, правда одна табличка не скопировалась, но это можно было и предотвратить.
т.е. тоже такой объем в двое суток можно запихать.

Тестовый мандант и продуктивный находятся на разных серверах, в разных системах.
Но! В той же системе находится и настроечный мандант.

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

Так что резервная копия продуктива отпадает, да?
А гомогенное копирование тож не пойдет, продуктив у нас под UNIX, тест под Windows.

Гомогенное/гетерогенное копирование отпадает по той же причине, что и восстановление из резервной копии.