Есть две новости, хорошая и плохая. Такая миграция работает - это хорошая новость, но работает очень медленно.
В процессе миграции целевая система почти не использует ресурсов, в то же время если в HANA Studio зайти в "Performance" -> "SQL Plan Cache", то вижу там очень много "Statement_String", следующего вида:
/* procedure: "_SYS_STATISTICS"."STATISTICS_SCHEDULABLEWRAPPER" variable: ::ROWCOUNT line: 3 col: 46648 (at pos 47690) */ update _SYS_STATISTICS.statistics_schedule set status='Idle' where id=__typed_Integer__($1) and latest_start_snapshot_id=__typed_Longdate__($2) and status='Scheduled'
/* procedure: "_SYS_STATISTICS"."STATISTICS_SCHEDULABLEWRAPPER" variable: ::ROWCOUNT line: 3 col: 46533 (at pos 47575) */ update _SYS_STATISTICS.statistics_schedule set start_count=0 where id=__typed_Integer__($1)
/* procedure: "_SYS_STATISTICS"."STATISTICS_SCHEDULABLEWRAPPER" variable: USED_VALUES line: 3 col: 32597 (at pos 33639) */ select current_utctimestamp snapshot_id, null type, null index, null name, null value, null value_nclob from sys.dummy where 1=0
/* procedure: "_SYS_STATISTICS"."COLLECTOR_STREAMING_SUBSCRIBERS_STATISTICS" variable: ::ROWCOUNT line: 8 col: 2 (at pos 824) */ insert into _SYS_STATISTICS.STREAMING_SUBSCRIBERS_STATISTICS_BASE (snapshot_id, server_timestamp,SCHEMA_NAME,PROJECT_NAME,PROJECT_INSTANCE,CLIENT_IP,CLIENT_PORT,CPU_SYSTEM_UTILIZATION,CPU_USER_UTILIZATION,CPU_UTILIZATION,ROW_THROUGHPUT,TRANSACTION_THROUGHPUT)
select __typed_Longdate__($1), current_timestamp,SCHEMA_NAME, PROJECT_NAME, PROJECT_INSTANCE, CLIENT_IP, CLIENT_PORT, CPU_SYSTEM_UTILIZATION, CPU_USER_UTILIZATION, CPU_UTILIZATION, ROW_THROUGHPUT, TRANSACTION_THROUGHPUT FROM (SELECT DISTINCT SCHEMA_NAME, PROJECT_NAME, PROJECT_INSTANCE, CLIENT_IP, CLIENT_PORT, CPU_SYSTEM_UTILIZATION, CPU_USER_UTILIZATION, CPU_UTILIZATION, ROW_THROUGHPUT, TRANSACTION_THROUGHPUT FROM SYS.M_STREAMING_PROJECT_SUBSCRIBERS)
/* procedure: "_SYS_STATISTICS"."STATISTICS_SCHEDULABLEWRAPPER" variable: USED_VALUES line: 3 col: 28542 (at pos 29584) */ select current_utctimestamp snapshot_id, null type, null index, null name, null value, null value_nclob from sys.dummy where 1=0

Таких строк почти 4 тысячи. В Логах самой Hana подозрительных ошибок не обнаружено.

В общем лыжи едут, но медленно. Так миграция базы объемом 350ГБ длится около 48 часов. Делал ли кто миграцию с помощью DPAgent?

а зачем такой экзотический способ?
с помощью hdblcm не работает?


это сбор статистики по хане, возможно на момент миграции её нужно отключить.
собирает статистику или солман или HANA COCKPIT


не совсем уверен, но в процессе миграции у вас случаем не происходил переход с XSC на XSA?
в таком случае тормоза из-за перезда аудит логов

Миграция идет для SAP CAR, а там помимо основной SCHEMA созданы дополнительные для систем сателитов. В итоге просто бэкап -> рестор невозможен, т.к. BE -> LE, а миграция с помощью SWPM перенесет только основную SCHEMA, что без сателитных SCHEMA не имеет смысла.

Единственный способ - это DPAgent, но он ужасно медленный.

извиняюсь за любопытство (с SAP CAR не сталкивался), а в результате миграции для "дополнительные для систем сателитов" созданы отдельные тенанты?
по аналогии солман мигрировали с Oracle12 -> HANA1.0 -> HANA2.0, перед 2.0 тенант выделили, там 2 schema (ABAP & JAVA)

ABAP и Java schema - это стандарт и с ними проблем нет. У нас SAP CAR - только ABAP (schema SAPSR3) но, помимо нее есть еще AAACLNT010, BBBCLNT010, CCCCLNT010 и т.д, и вот эти schema все стандартные способы миграции и гетерогенного копиривания, игнорируют.

Перечисленные стейтменты - это обычная активность Statistics Service, она светится в план кэше, когда нет пользовательской нагрузки на системе.
Чтобы понять, почему может быть медленная заливка, надо посмотреть в M_SERVICE_THREADS монитор (пообновляв его в течение нескольких секунд) - чаще всего проблемы не на стороне бд, из опыта. А вообще, миграция с помощью SDA - это достаточно оригинально..
Кстати, совет - если объем исходных таблиц большой, вне зависимости от сценария миграции, рекомендую проверить размер дельты для них, в 2.0 внутренний формат поменялся, и при последующем мерже стартанет переконвертация, которая может (при определенных условиях) на время исполнения заблочить модификацию оных.