Known Issues

This part of the document contains additional information on how to proceed when you want to correct known problems during the ZDO procedure.

If a problem is not listed here, or if you need additional assistance, report an incident on component BC-UPG-DTM-TLA. Use the following convention for the short description: [ZDO of SUM] - <Issue short description>

The following issues are known:

Running SUM with ZDO After a Previous Run Has Been Reset

Symptom	Solution
During the reset of a ZDO update, newly added database tables are not dropped.	Make sure in transaction DB02 that there are no additional database tables that belong to SAP.

Reset: Error in Phase RUN_RSDB02CK_REV

Symptom	Solution
One of the following tables does not exist in the database: TEST_POOL1 VER_SEC_INDX VER_SEC_TAB1 CRR_CHCNC CRR_CHCWC CRR_CHENC CRR_CHEWC CRR_CHLNC CRR_CHLWC CRR_CHSNC CRR_CHSWC CRR_CH_LOCK CRR_CH_SI CRR_CSCWC CRR_CT1P CRR_CT1S1 CRR_CT1S2 CRR_CT1S3 CRR_CT2P CRR_CT2S1 CRR_CT2S2 CRR_CT3P CRR_CT3S1 CRR_CT3S2	Create the tables manually in the database using transaction SE14. Afterwards repeat the phase.

Cleaning up the Orphaned Update Records

Symptom	Solution
SUM stops in phase MAIN_NEWBAS/RUN_UPDATE_CHECK with the following error message: `A2EESZDM 669 Record in VBHDR found for update: key "<UPDATE KEY>" report "<REPORT>" state "2" date <TIME STAMP>`	Call transaction SM13 on the bridge subsystem and enter date and time of the error message. A list of all update records is displayed. Using the menu item Settings Layout Current..., add the additional column name Update Key to the displayed columns of the update records table. Filter the list by the update key from the error message. Clean up the update records found by the filter condition.

Symptom

Solution

SUM stops in phase MAIN_NEWBAS/RUN_UPDATE_CHECK with the following error message:

A2EESZDM 669 Record in VBHDR found for update: key "<UPDATE KEY>" report "<REPORT>" state "2" date <TIME STAMP>

Call transaction SM13 on the bridge subsystem and enter date and time of the error message. A list of all update records is displayed.
Using the menu item Settings Layout Current..., add the additional column name Update Key to the displayed columns of the update records table.
Filter the list by the update key from the error message.
Clean up the update records found by the filter condition.

Error in File LONGPOST.Log

Symptom	Solution
You see the following error in log file Longpost.log: `### CURRENT PHASE: RUN_RSUPGDDLSCREATE` `1PEPU203X--> Messages extracted from log file "RSUPGDDLSCREATE.Y20" <--` `A4PEDDUT 368 Create statement view "ACMAUTE639F7F4D8" could not be generated`	You can ignore this error because it is a generated CDS view that was additionally handled during the update in the XPRA phase. The view should therefore exist in the database and no further action is required.

Symptom

Solution

You see the following error in log file Longpost.log:

### CURRENT PHASE: RUN_RSUPGDDLSCREATE

1PEPU203X--> Messages extracted from log file "RSUPGDDLSCREATE.Y20" <--

A4PEDDUT 368 Create statement view "ACMAUTE639F7F4D8" could not be generated

You can ignore this error because it is a generated CDS view that was additionally handled during the update in the XPRA phase.

The view should therefore exist in the database and no further action is required.

Error in Phase MAIN_POSTCLEAN/TOOLIMP_DELETE_ABAP

Symptom	Solution
The phase MAIN_POSTCLEAN/TOOLIMP_DELETE_ABAP fails with an error message similar to: `2EEDA480 Update fails (mode flag "D" to "X" in DDXTT. Table: "<TABNAME>")` The reason is that a new instance of batch job RDDIMPDP was scheduled for the upgrade subsystem in phase MAIN_NEWBAS/JOB_RDDNEWPP. After switching off the subsystem isolation in phase MAIN_POSTPROC/SUBMOD_BRIDGE_POSTPROC/RUN_RLFW_SYSTEMSEP_OFF, this additional instance of batch job RDDIMPDP becomes active on the target system. This is not supported.	Execute transaction SM37 in client 000. Select as follows: Job Name: RDDIMPDP User Name: * Job Status: Released Or after event: SAP_TRIGGER_RDDIMPDP Multiple instances of the RDDIMPDP batch job must not be displayed. Delete them all. Then schedule a new instance of the batch job RDDIMPDP. Use the RDDNEWPP program for this, as described in SAP Note 34964 . Then repeat the phase.

Symptom

Solution

The phase MAIN_POSTCLEAN/TOOLIMP_DELETE_ABAP fails with an error message similar to:

2EEDA480 Update fails (mode flag "D" to "X" in DDXTT. Table: "<TABNAME>")

The reason is that a new instance of batch job RDDIMPDP was scheduled for the upgrade subsystem in phase MAIN_NEWBAS/JOB_RDDNEWPP. After switching off the subsystem isolation in phase MAIN_POSTPROC/SUBMOD_BRIDGE_POSTPROC/RUN_RLFW_SYSTEMSEP_OFF, this additional instance of batch job RDDIMPDP becomes active on the target system. This is not supported.

Execute transaction SM37 in client 000. Select as follows:

Job Name: RDDIMPDP
User Name: *
Job Status: Released
Or after event: SAP_TRIGGER_RDDIMPDP

Multiple instances of the RDDIMPDP batch job must not be displayed. Delete them all.

Then schedule a new instance of the batch job RDDIMPDP. Use the RDDNEWPP program for this, as described in SAP Note 34964 Information published on SAP site .

Then repeat the phase.

Error in Phase MAIN_NEWBAS/XPRAS_AIMMRG

Symptom	Solution
You see in phase XPRAS_AIMMRG the following error message: `[...]` `A2EERSAR 203 Source system "<LOGSYSNAME>" does not exist` `2EESY530 An exception was raised` `A2 ERSBK 034 Generate D versions from "DTP_7MODTUOAGKW6IILPKSNI78RCH" ("R/3730" -> "<LOGSYSNAME>")` `A2EERS_EXCEPTION 120 Operation &3"0TCTTABCAT_TEXT` `<LOGSYSNAME>get_access" could not be carried out for &1"DTPA" &2"DTP_46MRIQEWUMPPSW8YXAMKD4JMZ"` `[...]`	See SAP Note 1649901 .

Symptom

Solution

You see in phase XPRAS_AIMMRG the following error message:

[...]

A2EERSAR 203 Source system "<LOGSYSNAME>" does not exist

2EESY530 An exception was raised

A2 ERSBK 034 Generate D versions from "DTP_7MODTUOAGKW6IILPKSNI78RCH" ("R/3730" -> "<LOGSYSNAME>")

A2EERS_EXCEPTION 120 Operation &3"0TCTTABCAT_TEXT

<LOGSYSNAME>get_access" could not be carried out for &1"DTPA" &2"DTP_46MRIQEWUMPPSW8YXAMKD4JMZ"

[...]

See SAP Note 1649901 Information published on SAP site .

Performance of Phase SQLRUNTASK_FDCT_TRANSFER on SAP HANA DATABASE

Symptom	Solution
The Fast Data Copy transfer, which is executed in the phase SQLRUNTASK_FDCT_TRANSFER, has an impact on the performance of the SAP HANA database. Especially, the I/O performance of a production system must be monitored during the execution of this phase. See SAP Note 1999993 for more information on a health check of your SAP HANA database. It describes how to use and interpret the results of the SAP HANA mini checks. To ensure a stable and consistent data copy, SUM sets the number of processes for the execution of the SQL statements of phase SQLRUNTASK_FDCT_TRANSFER by default to 2. You can increase the number of parallel DDL processes if you have business requirements to minimize the runtime of phase SQLRUNTASK_FDCT_TRANSFER a performance analysis SAP HANA database of the productive system shows that more parallel processes can be used without affecting the performance and stability of the SAP HANA database	Add to file SAPup_add.par the following line to increase the number of DDL processes: /SQLRUNTASK_FDCT_TRANSFER/HDB/parprocs/DDL = <numer of parallel processes> The file SAPup_add.par is located in the subdirectory bin of the SUM directory. If this file does not exist yet, create it. Note: Consider also the load on the productive system during this analysis. Setting the number of DDL processes to a higher value can lead to a massive impact on the productive system and a significant database slowdown.

Symptom

Solution

The Fast Data Copy transfer, which is executed in the phase SQLRUNTASK_FDCT_TRANSFER, has an impact on the performance of the SAP HANA database. Especially, the I/O performance of a production system must be monitored during the execution of this phase.

See SAP Note 1999993 Information published on SAP site for more information on a health check of your SAP HANA database. It describes how to use and interpret the results of the SAP HANA mini checks.

To ensure a stable and consistent data copy, SUM sets the number of processes for the execution of the SQL statements of phase SQLRUNTASK_FDCT_TRANSFER by default to 2.

You can increase the number of parallel DDL processes if

you have business requirements to minimize the runtime of phase SQLRUNTASK_FDCT_TRANSFER
a performance analysis SAP HANA database of the productive system shows that more parallel processes can be used without affecting the performance and stability of the SAP HANA database

Add to file SAPup_add.par the following line to increase the number of DDL processes:

/SQLRUNTASK_FDCT_TRANSFER/HDB/parprocs/DDL = <numer of parallel processes>

The file SAPup_add.par is located in the subdirectory bin of the SUM directory. If this file does not exist yet, create it.

Note: Consider also the load on the productive system during this analysis. Setting the number of DDL processes to a higher value can lead to a massive impact on the productive system and a significant database slowdown.

During Reset System Separation Between Bridge System and Upgrade System Isn't Correctly Reset

Symptom	Solution
During the reset, the system separation between bridge subsystem and upgrade subsystem is not reset correctly. This can cause problems, such as scheduled background jobs that are not recognized correctly by the system and therefore are not triggered as expected. For example: A transport is to be imported into the system and seems to hang after the DDIC import. In the SLOG*, you see messages such as: `ERROR: Background job RDDIMPDP could not be started or terminated` `ERROR: Please check that the R/3 system is running.` `ERROR: Please check the system. Use transactions SM21, SM37, SM50..`	Delete the RFC connection SAP_UPGRADE_UPG_SYSTEM using transaction SM59. Then execute program RLFW_SYSTEM_SEPARATION in transaction SE38. Use the parameter p_action = DEACTIVATE and logfile = RLFW_SYSTEMSEP_OFF.

Symptom

Solution

During the reset, the system separation between bridge subsystem and upgrade subsystem is not reset correctly. This can cause problems, such as scheduled background jobs that are not recognized correctly by the system and therefore are not triggered as expected.

For example: A transport is to be imported into the system and seems to hang after the DDIC import. In the SLOG*, you see messages such as:

ERROR: Background job RDDIMPDP could not be started or terminated

ERROR: Please check that the R/3 system is running.

ERROR: Please check the system. Use transactions SM21, SM37, SM50..

Delete the RFC connection SAP_UPGRADE_UPG_SYSTEM using transaction SM59.

Then execute program RLFW_SYSTEM_SEPARATION in transaction SE38. Use the parameter p_action = DEACTIVATE and logfile = RLFW_SYSTEMSEP_OFF.

Oracle Only: Known Issue with LOB Column Replication

Symptom	Solution
Internal tests show the following error: `ORA-12008: error in materialized view refresh path` `ORA-01400: cannot insert NULL into (<schema>.<table>.<column>)`	The error is temporary. Repeat the phase.

Symptom

Solution

Internal tests show the following error:

ORA-12008: error in materialized view refresh path

ORA-01400: cannot insert NULL into (<schema>.<table>.<column>)

The error is temporary. Repeat the phase.

Oracle Only: Known Issue with Creating Materialized Views

Symptom	Solution
An error message similar to the following is displayed: `3 ETQ398 SQL: CREATE MATERIALIZED VIEW "GVD_SQL~~_MV" BUILD IMMEDIATE REFRESH FAST` `3 ETQ398XSQL: WITH ROWID ON COMMIT AS SELECT "SNAPSHOT_ID", "INST_ID", "HASH_VALUE",` `3 ETQ398XSQL: "CHILD_ADDRESS", "SQL_TEXT" FROM "GVD_SQL~~"` `1 ETQ000 ==================================================` `4 ETQ010 Date & Time: 201509151955061EETQ008 Error message: DBSL error 99 (db code 1031)`: `ORA-01031: insufficient privileges` `1EETQ003 exit code: "12"4 ETQ399 Rollback.` `1EETQ008 Error message: DBSL error 99 (db code 1031):` `1EETQ009XORA-01031: insufficient privileges` `1EETQ003 exit code: "20"`	Proceed as follows: on Unix level, log on as user ora<SID>. Enter the following SQL script: `cd $ORACLE_HOME/dbs` `cp /usr/sap/<SID>/SYS/exe/run/sapdba_role.sql sapdba_role.sql` `sqlplus /nolog @sapdba_role <SID>` If the following error message appears, you can ignore it: `Error accessing PRODUCT_USER_PROFILE` `Warning: Product user profile information not loaded!` `You may need to run PUBLD.SQL as SYSTEM.`

Symptom

Solution

An error message similar to the following is displayed:

3 ETQ398 SQL: CREATE MATERIALIZED VIEW "GVD_SQL~~_MV" BUILD IMMEDIATE REFRESH FAST

3 ETQ398XSQL: WITH ROWID ON COMMIT AS SELECT "SNAPSHOT_ID", "INST_ID", "HASH_VALUE",

3 ETQ398XSQL: "CHILD_ADDRESS", "SQL_TEXT" FROM "GVD_SQL~~"

1 ETQ000 ==================================================

4 ETQ010 Date & Time: 201509151955061EETQ008 Error message: DBSL error 99 (db code 1031):

ORA-01031: insufficient privileges

1EETQ003 exit code: "12"4 ETQ399 Rollback.

1EETQ008 Error message: DBSL error 99 (db code 1031):

1EETQ009XORA-01031: insufficient privileges

1EETQ003 exit code: "20"

Proceed as follows:

on Unix level, log on as user ora<SID>.
Enter the following SQL script:

cd $ORACLE_HOME/dbs

cp /usr/sap/<SID>/SYS/exe/run/sapdba_role.sql sapdba_role.sql

sqlplus /nolog @sapdba_role <SID>
If the following error message appears, you can ignore it:

Error accessing PRODUCT_USER_PROFILE

Warning: Product user profile information not loaded!

You may need to run PUBLD.SQL as SYSTEM.

Table TEST_POOL1 is Missing After Reset

Symptom	Solution
The table pool TEST_POOL1 is missing in the database after a reset.	The table pool TEST_POOL1 has been delivered with SAP_BASIS 740 SP07 and was deleted again with SAP_BASIS 740 SP09. The error occurs after the reset of the ZDO procedure, when the source release is SAP_BASIS 740 SP08 and phase PARCONV_UPG has already been passed. In this phase, the table pool was deleted. The reset procedure could not restore the pool. To resolve the issue, activate the table manually in the ABAP Dictionary.

Symptom

Solution

The table pool TEST_POOL1 is missing in the database after a reset.

The table pool TEST_POOL1 has been delivered with SAP_BASIS 740 SP07 and was deleted again with SAP_BASIS 740 SP09.

The error occurs after the reset of the ZDO procedure, when the source release is SAP_BASIS 740 SP08 and phase PARCONV_UPG has already been passed. In this phase, the table pool was deleted. The reset procedure could not restore the pool.

To resolve the issue, activate the table manually in the ABAP Dictionary.

CDS View SACM_CDS_SHOW_SO Does Not Exist or is Not Active

Symptom	Solution
Phase BRIDGE_CHECKCDS stops because CDS view SACM_CDS_SHOW_SO could not be found or could not be activated.	Log on to bridge subsystem and activate the CDS view manually with transaction SE11.

Oracle Only: Deadlock in ZDO Smart Switch

Symptom	Solution
During the Postprocessing roadmap step, you see in phase EU_SWITCH_ZDM the error message: `Deadlock detected while waiting for resource.` if the corresponding update statement was `UPDATE PUTTB_SHD SET BRISWTC = 'X' WHERE TABNAME = ….`	Set the value ORACLE INITRANS for table PUTTB_SHD to at least 20. For more information, see SAP Note 84348 .

Symptom

Solution

During the Postprocessing roadmap step, you see in phase EU_SWITCH_ZDM the error message:

Deadlock detected while waiting for resource.

if the corresponding update statement was UPDATE PUTTB_SHD SET BRISWTC = 'X' WHERE TABNAME = ….

Set the value ORACLE INITRANS for table PUTTB_SHD to at least 20.

For more information, see SAP Note 84348 Information published on SAP site .

IBM DB2 for z/OS Only: Error in Phase SQLRUNTASK_LC4BRI_CRESHAREDTRIG

Symptom	Solution
SUM stops in phase SQLRUNTASK_LC4BRI_CRESHAREDTRIG. You see the following error message in the log files: `"THE STATEMENT IS TOO LONG OR TOO COMPLEX" is shown.`.	The error is temporary. Repeat the phase.

Symptom

Solution

SUM stops in phase SQLRUNTASK_LC4BRI_CRESHAREDTRIG.

You see the following error message in the log files: "THE STATEMENT IS TOO LONG OR TOO COMPLEX" is shown..

The error is temporary. Repeat the phase.

Microsoft Windows Server Only: Restart of the Bridge Subsystem

Symptom	Solution
After restarting a bridge subsystem application server, the kernel of the new target version was loaded. The reason for this is that SUM performs several temporary changes in the instance profiles, for example, it comments out sapcpe. Because Windows Server caches the profile parameters in the sapstartsrv.exe file, the changes are not reflected in the cache profiles.	Restart MS Windows service SAP Start Service before you manually restart the bridge subsystem.

Symptom

Solution

After restarting a bridge subsystem application server, the kernel of the new target version was loaded.

The reason for this is that SUM performs several temporary changes in the instance profiles, for example, it comments out sapcpe.

Because Windows Server caches the profile parameters in the sapstartsrv.exe file, the changes are not reflected in the cache profiles.

Restart MS Windows service SAP Start Service before you manually restart the bridge subsystem.

DB6 Only: Remove Hidden Columns After ZDO Update Reset

Symptom	Solution
After resetting an update with ZDO, some tables can have hidden columns that have to be removed before starting a new update with ZDO.	To remove the hidden columns, use the tool DB6CONV. The documentation is attached to SAP Note 1513862 .

Symptom

Solution

After resetting an update with ZDO, some tables can have hidden columns that have to be removed before starting a new update with ZDO.

To remove the hidden columns, use the tool DB6CONV.

The documentation is attached to SAP Note 1513862 Information published on SAP site .

DB6 Only: Deschedule Tables (Performance) Data Collector

Symptom	Solution
In phase EU_SWITCH_ZDM, lock timeout errors for tables DD02L and DD0L occur.	To prevent the error, deschedule the Tables (Performance) data collector in the data collection framework in the DBACOCKPIT. The collection interval must not be set to not scheduled on the bridge subsystem from phase REQ_USER_ROLLOVER_PREP to REQ_USER_ROLLBACK_FINAL.

Symptom

Solution

In phase EU_SWITCH_ZDM, lock timeout errors for tables DD02L and DD0L occur.

To prevent the error, deschedule the Tables (Performance) data collector in the data collection framework in the DBACOCKPIT.

The collection interval must not be set to not scheduled on the bridge subsystem from phase REQ_USER_ROLLOVER_PREP to REQ_USER_ROLLBACK_FINAL.

Error in PARRUN_ZDO_CONSISTENCY_CHECK or RUN_ZDO_CONSISTENCY_CHECK_POST

With Regard To The SLT Setup

Symptom	Solution
You are using an SLT server setup. SUM stops in phase PARRUN_ZDO_CONSISTENCY_CHECK or RUN_ZDO_CONSISTENCY_CHECK_POST with one of the following two error messages: `A2EESUPG 763 Table <table> has no SLT triggers, but has an SLT logging table <logging table>` `A2EESUPG 764 Table <table> has no SLT logging table in DDIC, but has an SLT trigger <SLT trigger>`	Check if the table is part of SLT replication. If so, check the connection of the SLT setup: Is the SLT replication done using an RFC connection or a second database connection? Possible solutions are: If the table is not part of the SLT replication, delete the SLT triggers and the found logging table. Then repeat the phase. If the table is part of the SLT replication based on an RFC connection, regenerate the missing SLT objects. If the table is part of SLT replication based on a second database connection, the Software Update Manager does not support SLT handling in the bridge subsystem. In this case, we recommend changing the connection to an RFC-based connection. Alternatively, reset SUM, restart the procedure from the beginning and deactivate the SLT handling in phase SUMASK_RFC_2_SLT_SERVER.

Symptom

Solution

You are using an SLT server setup. SUM stops in phase PARRUN_ZDO_CONSISTENCY_CHECK or RUN_ZDO_CONSISTENCY_CHECK_POST with one of the following two error messages:

A2EESUPG 763 Table <table> has no SLT triggers, but has an SLT logging table <logging table>

A2EESUPG 764 Table <table> has no SLT logging table in DDIC, but has an SLT trigger <SLT trigger>

Check if the table is part of SLT replication.
If so, check the connection of the SLT setup: Is the SLT replication done using an RFC connection or a second database connection?
Possible solutions are:
1. If the table is not part of the SLT replication, delete the SLT triggers and the found logging table. Then repeat the phase.
2. If the table is part of the SLT replication based on an RFC connection, regenerate the missing SLT objects.
3. If the table is part of SLT replication based on a second database connection, the Software Update Manager does not support SLT handling in the bridge subsystem. In this case, we recommend changing the connection to an RFC-based connection.
  
  Alternatively, reset SUM, restart the procedure from the beginning and deactivate the SLT handling in phase SUMASK_RFC_2_SLT_SERVER.

With Regard To ABAP Dictionary Objects

Symptom	Solution
The ZDO consistency check detects that ABAP Dictionary objects are inconsistent. The system displays error messages such as: `A2EESUPG 642 Index "XYZ" of table "TABLE1" does not exist in DDIC(DB-Idx Name:"TABLE1~YXZ")` `A2EESUPG 234 Table "TABLE2" is inconsistent in key information NT <-> DB` `A2EESUPG 007 Unable to determine the table delta between "TABLE3" and "TABLE3"`	Resolve the inconsistencies using the ABAP Dictionary tools provided with the transactions SE11 and SE14. If you cannot resolve the inconsistencies, report an incident on component BC-UPG-DTM-TLA.

Symptom

Solution

The ZDO consistency check detects that ABAP Dictionary objects are inconsistent. The system displays error messages such as:

A2EESUPG 642 Index "XYZ" of table "TABLE1" does not exist in DDIC(DB-Idx Name:"TABLE1~YXZ")

A2EESUPG 234 Table "TABLE2" is inconsistent in key information NT <-> DB

A2EESUPG 007 Unable to determine the table delta between "TABLE3" and "TABLE3"

Resolve the inconsistencies using the ABAP Dictionary tools provided with the transactions SE11 and SE14. If you cannot resolve the inconsistencies, report an incident on component BC-UPG-DTM-TLA.

Error in Phase RUN_RSPTBFIL_ZDM_CHECK_BW

Symptom	Solution
SUM stops in phase RUN_RSPTBFIL_ZDM_CHECK_BW with following error message: `A2EESZDM_SRC 074 System scope is DATA_WAREHOUSE, ZDO is not supported, see SAP note 2707731` Furthermore, the log file contains detailed information about why the scope DATA_WAREHOUSING was determined. Example messages: `A4 ESZDM_SRC 076 Advanced Data Stores: 2` `A4 ESZDM 002 0EPM_ADSO1` `A4 ESZDM 002 0EPM_ADSO2` `A4 ESZDM_SRC 077 Data Stores: 1` `A4 ESZDM 002 0BPM_DS01` `A4 ESZDM_SRC 078 Info Cubes: 1` `A4 ESZDM 002 0BPCBPFVPX` `A4 ESZDM_SRC 079 Persistent Staging Areas: 0` Caution The output of the log file RSZDM_CHK_BW.<SID> written by the Software Update Manager can be incomplete because the number of lines per object type is limited to 25. To get a complete object list, execute the report RSUPG_CHECK_BW.	The ZDO of SUM does not support the DATA_WAREHOUSE scope of SAP BW. During the analysis, you must find out why the SAP BW objects are active in the system and whether they are used at all. We recommend the following procedure: Clarify with your functional teams which business applications are used in SAP S/4HANA and use the determined SAP BW objects (Advanced Data Stores, Data Stores, InfoCubes, or Persistent Staging Areas). If the functional teams confirm that SAP BW objects are used by the business applications, the SUM procedure with ZDO is not possible. If in doubt, report an incident on the application component that uses the active SAP BW object. If you can confirm that SAP BW is not used by the functional teams, but the check has determined the active use of data warehousing, open an incident on component BC-UPG-DTM-TLA.

Symptom

Solution

SUM stops in phase RUN_RSPTBFIL_ZDM_CHECK_BW with following error message:

A2EESZDM_SRC 074 System scope is DATA_WAREHOUSE, ZDO is not supported, see SAP note 2707731

Furthermore, the log file contains detailed information about why the scope DATA_WAREHOUSING was determined. Example messages:

A4 ESZDM_SRC 076 Advanced Data Stores: 2

A4 ESZDM 002 0EPM_ADSO1

A4 ESZDM 002 0EPM_ADSO2

A4 ESZDM_SRC 077 Data Stores: 1

A4 ESZDM 002 0BPM_DS01

A4 ESZDM_SRC 078 Info Cubes: 1

A4 ESZDM 002 0BPCBPFVPX

A4 ESZDM_SRC 079 Persistent Staging Areas: 0

The ZDO of SUM does not support the DATA_WAREHOUSE scope of SAP BW. During the analysis, you must find out why the SAP BW objects are active in the system and whether they are used at all. We recommend the following procedure:

Clarify with your functional teams which business applications are used in SAP S/4HANA and use the determined SAP BW objects (Advanced Data Stores, Data Stores, InfoCubes, or Persistent Staging Areas).
If the functional teams confirm that SAP BW objects are used by the business applications, the SUM procedure with ZDO is not possible. If in doubt, report an incident on the application component that uses the active SAP BW object.
If you can confirm that SAP BW is not used by the functional teams, but the check has determined the active use of data warehousing, open an incident on component BC-UPG-DTM-TLA.