SAP Learning Journey

Troubleshooting Common ZDO Issues

Objectives
After completing this lesson, you will be able to:

After completing this lesson, you will be able to:

  • Find relevant log files
  • Check the consistency of database tables
  • Analyze errors in table classification
  • Troubleshoot issues during or right after rollover to bridge subsystem
  • Report an Incident for illegal table accesses in the upgrade subsystem
  • Start and stop the bridge subsystem

Log Files of Software Update Manager

This section show how to find and read log files from Software Update Manager (SUM) to troubleshoot issues and track the progress.

When an issue occurs, we recommend that you view the error using the SUM UI as your very first step. In many cases, the SUM UI displays an excerpt of a log file that is a good starting point for analyzing the errors.

In this example, the phase RUN_IMPACT_ANALYSIS_ZDO failed. The SUM UI already displays the file name where you can find the detailed information for this phase. In this example, the detailed error is written in file IMPANAUPG.PPM where the last three letters represent for the system ID. This information can also be retrieved from the file, PHASE_RUN.ELG.

If you have no information on which log file was written by a specific phase, check the file SAPup.log that shall point you to the correct log file. Taking again the example of phase RUN_IMPACT_ANALYSIS_ZDO, SAPup.log shows the following information:

Code snippet
CURRENTPHASE MAIN_SHDIMP/SUBMOD_SHD2_RUN/SUBMOD_LC4BRI_PREP/RUN_IMPACT_ANALYSIS_ZDO
...started at 20210422120446
# Using phase log file 'PHASE_RUN.LOG'.
...begin processing at 20210422120446
# Resource usage self:     0.0/    0.0/0MB usr/sys/mem, children     0.0/    0.0/0MB usr/sys/maxmem.
...finished at 20210422120449 with status FAILED.
# Error message set: 'Single errors (code <= 8) found in logfile 'PHASE_RUN.ELG''
Copy code

If the failed phase is already passed but you still want to check for the relevant log file, the content of the ELG file might has been appended already to the SAV file. In this case, check PHASE_RUN.ELG or PHASE_RUN_ELG.SAV to find the right output. The file PHASE_RUN_ELG.SAV contains the following information:

Code snippet
...
################################################################################################
Phase: RUN_IMPACT_ANALYSIS_ZDO # Description: Analysis of the impact of table classification to productive usage statistics ERRORS
################################################################################################
#==============================================================================================#
# Find the detailed information in log 'IMPANAUPG.PPM':
#==============================================================================================#
A4 ESUPG 665 Report name ...: "RSUPG_RUN_IMPACT_ANALYSIS" Component: "BC-UPG-TLS-TLA" "(Upgrade Tools for ABAP)"
A4 ESUPG 002 " "
A4 ESUPG 001 -------------------------------------------------------------------------
A4 ESUPG_IMPANA 007 Report "RSUPG_RUN_IMPACT_ANALYSIS" started
A4 ESUPG_IMPANA 001 -------------------------------------------------------------------------
...
Copy code

As seen in the SUM UI already, the relevant log file for phase RUN_IMPACT_ANALYSIS_ZDO is named IMPANAUPG.PPM.

To show all log files, you can either stay in the SUM UI or you navigate to the directory SUM/abap/log, using transaction AL11 in your ABAP system or use OS command tools.

In general, check the most recent files first since the SUM updates the log files frequently. In some cases, it might be helpful to check the most recent log files in the directory SUM/abap/tmp.

Consistency Check of Database Tables

This section introduces enhanced consistency checks as a prerequisite for a successful execution of a Zero Downtime Option (ZDO) maintenance event.

When running a zero-downtime upgrade, it is essential that the ABAP Dictionary objects and CDS views are in a consistent state prior the start of the ZDO procedure. In order to prepare the database schema used by the bridge subsystem, SUM will create views for every database table in the system. Additionally, the existing CDS views will be generated for the bridge subsystem. In case objects are inconsistent, the generation of those objects would fail. Hence, it's important to check the consistency in an early state of the upgrade procedure.

For ABAP Dictionary objects, SUM is equipped with an additional consistency check running during the ZDO procedure as part of the Checks roadmap step. The ZDO consistency check is split into three phases:

Phases of ZDO Consistency Check in SUM

Phase NameDescriptionLog File(s)
RUN_ZDO_CONSISTENCY_CHECK_INITInitializes the check by filling an internal control table with the relevant ABAP Dictionary tables.ZDO_CONSISTENCY_CHECK_INIT.<SID>
PARRUN_ZDO_CONSISTENCY_CHECKExecutes the consistency check in parallel processes.ZDO_CONSISTENCY_CHECK_*.<SID>
RUN_ZDO_CONSISTENCY_CHECK_POSTCollects the findings and writes the output in the CHECKS.LOG file if errors were found.ZDO_CONSISTENCY_CHECK_POST.<SID>

The initialization phase RUN_ZDO_CONSISTENCY_CHECK_INIT collects all ABAP Dictionary tables and writes the information into an internal control table. Exemplary log file output (ZDO_CONSISTENCY_CHECK_INIT.<SID>):

Code snippet
4 ETG057 Job name ......: "CL_ZDM_CONSISTENCY_CHECK" Component: "BC-UPG-TLS-TLA" "(Upgrade Tools for ABAP)"
4 ETG040 Start time ....: "16.11.2021" "15:28:58"
4 ETG011 " "
4 ETG039 -------------------------------------------------------------------------
A4 ESUPG 654 "149.617" objects added to SZDM_DDIC_CHECK
4 ETG039 -------------------------------------------------------------------------
4 ETG011 " "
4 ETG057 Job name ......: "CL_ZDM_CONSISTENCY_CHECK" Component: "BC-UPG-TLS-TLA" "(Upgrade Tools for ABAP)"
4 ETG040 Start time ....: "16.11.2021" "15:28:58"
4 ETG041 End time ......: "16.11.2021" "15:28:58"
Copy code

In case an inconsistency is found for any of the database tables, the phase PARRUN_ZDO_CONSISTENCY_CHECK stops with an error. In this example, two tables are found by the check which are in an inconsistent state.

Exemplary log file output (ZDO_CONSISTENCY_CHECK_*.<SID>)

Code snippet
4 ETG039 -------------------------------------------------------------------------
4 ETG011 " "
4 ETG057 Job name ......: "CL_ZDM_CONSISTENCY_CHECK" Component: "BC-UPG-TLS-TLA" "(Upgrade Tools for ABAP)"
4 ETG040 Start time ....: "16.11.2021" "15:29:00"
4 ETG011 " "
4 ETG039 -------------------------------------------------------------------------
A4 ESUPG 652 Start "parallel" processing of consistency check
...
A4 ESUPG 651 "ZTABLEMODIFDB" is consistent
A4 ESUPG 650 Check consistency of "ZTABLENODB"
A2EESUPG 006 Unable to retrieve the DB fields of table "ZTABLENODB" due to rc "4"
A2EESUPG 007 Unable to determine the table delta between "ZTABLENODB" and "ZTABLENODB"
A4 ESUPG 650 Check consistency of "ZTABLENOINDEX"
A2EESUPG 234 Table "ZTABLENOINDEX" is inconsistent in key information NT <-> DB
A2EESUPG 007 Unable to determine the table delta between "ZTABLENOINDEX" and "ZTABLENOINDEX"
A4 ESUPG 650 Check consistency of "ZTIMESTAMP"
A4 ESUPG 651 "ZTIMESTAMP" is consistent
4 ETG039 -------------------------------------------------------------------------
4 ETG011 " "
4 ETG057 Job name ......: "CL_ZDM_CONSISTENCY_CHECK" Component: "BC-UPG-TLS-TLA" "(Upgrade Tools for ABAP)"
4 ETG040 Start time ....: "16.11.2021" "15:29:00"
4 ETG041 End time ......: "16.11.2021" "15:30:37"
Copy code

When SUM is resumed without correcting the inconsistencies, the third phase RUN_ZDO_CONSISTENCY_CHECK_POST collects and aggregates the error messages. The consolidated error messages are written into the file CHECKS.LOG that is used at the end of the sub-module. Furthermore, this phase writes its own consolidated log file ZDO_CONSISTENCY_CHECK_POST.<SID> like in this example:

Code snippet
4 ETG057 Job name ......: "CL_ZDM_CONSISTENCY_CHECK" Component: "BC-UPG-TLS-TLA" "(Upgrade Tools for ABAP)"
4 ETG040 Start time ....: "16.11.2021" "15:31:29"
4 ETG011 " "
4 ETG039 -------------------------------------------------------------------------
A4 ESUPG 652 Start "serial" processing of consistency check
A4 ESUPG 650 Check consistency of "ZTABLENODB"
A2EESUPG 006 Unable to retrieve the DB fields of table "ZTABLENODB" due to rc "4"
A2EESUPG 007 Unable to determine the table delta between "ZTABLENODB" and "ZTABLENODB"
A4 ESUPG 650 Check consistency of "ZTABLENOINDEX"
A2EESUPG 234 Table "ZTABLENOINDEX" is inconsistent in key information NT <-> DB
A2EESUPG 007 Unable to determine the table delta between "ZTABLENOINDEX" and "ZTABLENOINDEX"
4 ETG039 -------------------------------------------------------------------------
4 ETG011 " "
4 ETG057 Job name ......: "CL_ZDM_CONSISTENCY_CHECK" Component: "BC-UPG-TLS-TLA" "(Upgrade Tools for ABAP)"
4 ETG040 Start time ....: "16.11.2021" "15:31:29"
4 ETG041 End time ......: "16.11.2021" "15:31:29"
Copy code

Note
To proceed with the ZDO procedure, the inconsistencies have to be resolved. If the inconsistencies are not resolved, the upgrade procedure will not move ahead. In case you need support, open a support incident for component BC-UPG-DTM-TLA.

The following section describes how the inconsistency of the two examples seen above can be resolved.

Example 1

Example 1 shows an error for table ZTABLENODB. The error log shows the following messages:

Code snippet
A2EESUPG 006 Unable to retrieve the DB fields of table "ZTABLENODB" due to rc "4"
A2EESUPG 007 Unable to determine the table delta between "ZTABLENODB" and "ZTABLENODB"
Copy code

The first step to check the root cause is to run a database object check. This can be done through the SAP GUI, either using transaction SE11 or SE14.

The database object check for table ZTABLENODB returns Table is not created in the database. When you create the database table and re-running the same check, the issue is resolved.

Example 2

Moving on to example 2 for table ZTABLENOINDEX. The error log shows the following messages:

Code snippet
A2EESUPG 234 Table "ZTABLENOINDEX" is inconsistent in key information NT <-> DB
A2EESUPG 007 Unable to determine the table delta between "ZTABLENOINDEX" and "ZTABLENOINDEX"
Copy code

Similar to example 1, also in this case, the database object check shows the root cause. For table ZTABLENOINDEX, the primary index is missing on the database. After creating the database index and re-running the same check, the issue is resolved.

When you have resolved all inconsistencies, SUM can be resumed. The consolidated log file ZDO_CONSISTENCY_CHECK_POST.<SID> is updated and shows the success message No objects found:

Code snippet
4 ETG057 Job name ......: "CL_ZDM_CONSISTENCY_CHECK" Component: "BC-UPG-TLS-TLA" "(Upgrade Tools for ABAP)"
4 ETG040 Start time ....: "16.11.2021" "15:48:38"
4 ETG011 " "
4 ETG039 -------------------------------------------------------------------------
A4 ESUPG 652 Start "serial" processing of consistency check
A4 ESUPG 653 No objects found
4 ETG039 -------------------------------------------------------------------------
4 ETG011 " "
4 ETG057 Job name ......: "CL_ZDM_CONSISTENCY_CHECK" Component: "BC-UPG-TLS-TLA" "(Upgrade Tools for ABAP)"
4 ETG040 Start time ....: "16.11.2021" "15:48:38"
4 ETG041 End time ......: "16.11.2021" "15:48:38
Copy code

Consistency Check for Core Data Services (CDS) Views

As part of the ZDO procedure, the consistency of ABAP Dictionary objects is checked in phase PARRUN_ZDO_CONSISTENCY_CHECK. However, this phase does not consider Core Data Services (CDS) views. As an optional step, CDS views can be checked prior the upgrade.

In order to verify the consistency of CDS views, it is recommended to run the report RUTCHKAC_FOR_ZDO prior the ZDO update procedure. The report is available is available from SAP S/4HANA 2020 SPS 04 and SAP S/4HANA 2021 FPS 02. If the system is running on a lower support package, SAP Note 3123580 can be applied.

DDIC Consistency Check in SUM Toolbox

The documentation for each tool is embedded in the SUM Toolbox and can be opened there.

For more information about SUM Toolbox, see:

Errors in Table Classification

This section introduces you to possible errors that may occur during table classification of Software Update Manager (SUM).

Error in Phase RUN_RSPTBFIL_ZDM_PREP

This phase checks if all application-defined procedures like After-Import-Methods, XPRA programs, and XCLA classes are zero-downtime enabled. The enablement, which is a set of customizing entries for the procedures, is shipped by the software vendor.

Symptom

An After-Import-Methods, XPRA programs, or XCLA class is scheduled to run by the ZDO upgrade but the ZDO enablement is missing. SUM stops with an error in phase RUN_RSPTBFIL_ZDM_PREP. An example of this is as follows:

Code snippet
A2EESZDM 197 AIM "TEST_AFTER_IMPORT" for object "L" "TSTS" is not enabled for ZDM
Copy code

Log file

Phase RUN_RSPTBFIL_ZDM_PREP writes into the log file, RSPTBFIL_ZDM_PREPARE.<SID>.

Solution

Create an incident using SAP ONE Support Launchpad for the responsible application component. If the component cannot be identified, create the incident for component BC-UPG-DTM-TLA.

Error in Phase RUN_RSPTBFIL_ZDM_CLASSIFY

This phase calculates the table classification result for every table in the system.

Symptom

The table classification can abort for various reasons. One example might be that a table should be cloned but a table clone cannot be created. This applies for instance to tables like ACDOCA, CDPOS, or CDHDR. Example:

Code snippet
A2EESZDM 287 "Transparent" table "CDHDR" has no BRITYPE
...
A2EESZDM 663 XCLA table "CDHDR" has invalid change of BRITYPE from '"S"' to '"C"' 
A2EESCRR_GENERAL_INF 102 Operation "CL_CLASSIFY_OP_ACTION" for table "CDHDR" failed
Copy code

Log files

Phase RUN_RSPTBFIL_ZDM_CLASSIFY writes into multiple the log files:RSPTBFIL_ZDM_CLASSIFY*.<SID>.

Solution

Create an incident using SAP ONE Support Launchpad for component BC-UPG-DTM-TLA.

Exclusive Locks during ZDO Execution

Specific phases of Zero Downtime Option (ZDO) require exclusive access to database tables by Software Update Manager (SUM). This may lead to errors in SUM tool, if the lock cannot be acquired due to parallel productive operations.

When performing zero-downtime upgrades, all structural and functional changes to database objects will be done in uptime. Here is an excerpt of such changes:

  • Table field changes
  • Index-related changes
  • Table content changes
  • And so on

As described in the lesson 'Concept of Cloned and Read-only Tables' of unit 2, all changes performed during the upgrade have to be hidden for the end users working productively on the bridge subsystem based on the source release. Dependent on the type of change, a table can be kept as shared or the table has to be cloned. For both, shared and cloned tables, the ZDO procedure has to execute certain database operations on tables that are accessed by the end users on the bridge subsystem as well as in parallel by Software Update Manager.

With SAP HANA 2.0, database operations executed on shared tables are preferably performed online, which does not require an exclusive lock. These activities include:

  • Creation of database triggers required by ZDO that prevent the upgrade subsystem changing content in shared database tables
  • Adding new non-primary key fields without default values
  • Adding new indexes on non-primary key fields
  • And so on

For all tables that will be cloned by the ZDO procedure, a rename table statement has to be executed. This so-called smart-switch happens in phase EU_SWITCH_ZDM directly after the rollover to the bridge subsystem (phase REQ_USER_ROLLOVER_FINAL). This example shows the technical upgrade phases (excerpt of log file SAPupConsole.log):

Code snippet
...
MAIN_BRISETUP/REQ_USER_ROLLOVER_PREP (2021/09/15 04:15:17)
...
MAIN_BRITRANS/BRIDGE_RECONNECT (2021/09/15 04:23:31)
...
MAIN_BRITRANS/REQ_USER_ROLLOVER_FINAL (2021/09/15 04:26:31)
...
>> START OF PHASE MAIN_SWITCH/EU_SWITCH_ZDM (2021/09/15 04:33:50)
  Determine list of tables to be switched. ...
  0:14: Checking which tables exist on the database...
  0:14: Checking which indexes exist on the database...
  0:15: Renaming 29054 indexes to old names...
  6:01: Switching 1097 indexes...
  7:12: Performing smart switch for 27954 tables...
  1:10:09: Switching 946 tables to new ones...
  ...
  1:10:27: Finished!
<< END OF PHASE MAIN_SWITCH/EU_SWITCH_ZDM (2021/09/15 05:44:17)
...
Copy code

This pseudo code describes the steps performed by phase EU_SWITCH_ZDM:

  • Acquire an exclusive table lock for table tab1
  • Rename table tab1to tab1temp
  • Release the exclusive table lock for table tab1
Note
Smart-switching tables require an exclusive lock for tables on database level. In case of frequently updated tables (approx. more than 10 changes / second), this can be difficult in peak load hours. Hence, the timing of rolling over the end users to the bridge subsystem should be chosen carefully. For details, see lesson Project Planning for Zero-downtime Upgrades in unit 3.

If business processes on the bridge subsystem are holding database lock for a long time, SUM will not be able to acquire an exclusive table lock in phase EU_SWITCH_ZDM. The ultimate goal is to not impact business users. Hence, SUM will fail with an error in phase EU_SWITCH_ZDM if the exclusive lock cannot be acquired. The business process will not be interrupted.

Exemplary error message in log file SAPupConsole.log.

Code snippet
<< 2021/09/14 19:57:01 END OF PHASE MAIN_SWITCH/EU_SWITCH_ZDM
=========== Repeat Phase ===========
Severe error(s) occurred in phase MAIN_SWITCH/EU_SWITCH_ZDM!
Last error code set:
1 errors during parallel execution of processes, check 'SQLSTMTSTD.*' for details
*ERROR* :
The following errors were detected in the log files:
# /usr/sap/S4H/SUM/abap/log/SMART_SWITCH03.LOG:
4 ETQ393 START Statement with ID 'ZDM3185' already executed - skipped.
4 ETQ393 START Statement with ID 'ZDM3185' already executed - skipped.
4 ETQ393 START Statement with ID 'ZDM3185' already executed - skipped.
1 ETQ000 ==================================================
4 ETQ010 Date & Time: 20210914195447 1EETQ008 Error message: DBSL error 99 (db code 131):
1EETQ009Xtransaction rolled back by lock wait timeout: Lock-wait time out
1EETQ009Xexceeded [OWNER=32392647202, TYPE=OBJECT_LOCK, CURRENT_MODE=EXCLUSIVE,
1EETQ009XREQUESTED_MODE=EXCLUSIVE]

A trouble ticket and an archive with all relevant log files have been generated.
Trouble ticket: "/usr/sap/S4H/SUM/abap/log/SAPup_troubleticket.log"
Log archive: "/usr/sap/S4H/SUM/abap/log/SAPup_troubleticket.sar"

01) * Repeat phase MAIN_SWITCH/EU_SWITCH_ZDM to continue at the point it stopped
02) - Exit program : Repeat phase MAIN_SWITCH/EU_SWITCH_ZDM to continue at the point it stopped
================================================================================
Copy code

In most cases, the error in phase EU_SWITCH_ZDM can be overcome by repeating the phase once or several times. As soon as SUM is able to acquire the exclusive table lock, the rename statement will be executed and the phase finishes.

If SUM still fails even after several retries to repeat phase EU_SWITCH_ZDM, the exclusive lock holder (work process ID) has to be identified. This can be done for instance using SAP GUI transactions DB01 or DBACOCKPIT. Then, decide together with the process owner whether to wait until the process finishes or if the process has to be canceled in order to proceed with the SUM procedure.

DB Table Lock Analyzer of SUM Toolbox

As part of the Software Update Manager (SUM) Toolbox a tool called DB Table Lock Analyzer is delivered which helps to find a suitable time to perform database lock intense phases like EU_SWITCH_ZDM.

Hint
The full documentation of the tool can be found in the application help of the transaction itself. Just choose the information icon next to the OK code field.

The result of the DB table lock section should be checked carefully. The rollover to bridge, which is followed by the smart-switch phase, should be planned around the timings where the system is less busy.

However, not all yellow and red marked line items are potentially causing an issue. To further analyze this, the SUM table classification data from the sandbox system can be utilized.

Note
The file PUTTB_SHD.ZIP that contains the SUM table classification data can be downloaded in the sandbox system after the phase RUN_RSPTBFIL_ZDM_CLASSIFY is completed. The download is performed using the tool Export of SUM classification data in SUM Toolbox.

Choose the Upload button and select the file exported (default file name would be PUTTB_SHD.ZIP) from the sandbox system. The result table is automatically refreshed. In this particular example, after merging the information of the DB table lock analyzer and the SUM table classification result, all time frames are marked as green.

The reason for this is simple: only tables classified as clone will be handled by the smart-switch phase EU_SWITCH_ZDM. All other tables which remain shared, are not affected by the smart-switch procedure. If the tables that are listed in the table lock details section are classified as shared, the will be considered as uncritical and the line turn from a yellow or red state into green.

Potential Issues in Transition to the Bridge Subsystem

This section offers steps to troubleshoot potential challenges during transition to bridge subsystem.

Error in Phase BRIDGE_RECONNECT

This phase reconnects all work processes (disp+work) from the original database schema (like SAPHANADB) to the bridge database schema (like SAPHANADBSHD). For details on the different subsystems, see lesson 'Explaining the Roles of the Different Subsystems' in unit 2.

Symptom

After starting the rollover to the bridge subsystem in phase REQ_USER_ROLLOVER_PREP, all users have to be transferred to the bridge database schema. In case of distributed installations having multiple application servers, the rollover failed in phase BRIDGE_RECONNECT. An example of this is as follows:

The following errors were detected in the log files:

Code snippet
# /usr/sap/PPM/SUM/abap/log/RLFW_RFC_RECONNECT.PPM:
A4 ESUPG 302 Log name: "/usr/sap/PPM/SUM/abap/log/RLFW_RFC_RECONNECT.PPM"
A4 ESUPG 304 Start time.....: "11.11.2021" "08:03:05"
A4 ESUPG 002 " "
A4 ESUPG 001 -------------------------------------------------------------------------
A4 ESZDM 232 Starting RLFW_GET_RECONNECT_STATE to get the reconnect state.
A2EESZDM 233 Reconnect state could not be determined. Error: "An exception was raised.".

A4 ESZDM 513 Schema check action "BRIDGE_CHECK": call direct from SUM. Logfile "RLFW_RFC_RECONNECT.PPM"
A4 ESZDM 521 Schema check Start, action:"BRIDGE_CHECK" schema:"SAPHANADBSHD" version:"2"
A4 ESZDM 503 Bridge Read V1 schema: "SAPHANADB" of "20211111" "080220" on " host_primary_PPM_00"
A4 ESZDM 504 Bridge schema is: "SAPHANADBSHD" at "20211111" "080315" on " host_primary_PPM_00"
A2EESZDM 509 Bridge schema check, RFC couldnt get schema of instance "host_dialoginstance_PPM_00" on "host_primary_PPM_00"
Copy code

The error A2EESZDM 509 describes that the primary application server cannot connect using RFC to at least one of the additional application servers.

Log files

Phase BRIDGE_RECONNECT writes into multiple log files:

  • RLFW_RFC_RECONNECT.<SID>
  • BRIDGE_RECONNECT.<SID>

Solution

If distributed installations have multiple application servers, the hdbuserstore should be shared across these instances. If the phase BRIDGE_RECONNECT fails with this error, the hdbuserstore is only available locally and has to be kept in sync manually. SUM requires to update the hdbuserstore with a new key used by the bridge subsystem. If the hdbuserstore is not shared and not in sync, the respective application servers are not able to connect to the bridge database schema using the user like SAPHANADBSHD.

Note

The phase REQ_USER_ROLLOVER_PREP already shows this information if more than one application server is detected:

"If the Bridge System is configured for a connection to the database using hdbuserstore, make sure that either all application servers instances have access to the shared hdbuserstore. If the hdbuserstore is stored on a local file system, follow the steps that are described in the SUM Guide, section 'Start of User Roll-Over to Bridge System'."

Incident for Illegal Table Accesses in the Upgrade Subsystem

This section provides recommendations for potential errors during execution of Software Update Manager (SUM).

Error in Phase RUN_CHECK_ILLACCESS

The upgrade subsystem is not supposed to write into tables classified as shared. Additionally, the upgrade must only write into cloned tables that have been declared by the developers as application-defined procedures like After-Import-Methods, XPRA programs, and XCLA classes. All accesses that were not declared beforehand are called illegal table accesses. For more information, see lesson 'Illegal Table Accesses in the Upgrade Subsystem' in unit 2.

Symptom

An After-Import-Methods, XPRA programs, or XCLA class is executed. The coding writes into a non-declared cloned table or tried to write into a shared table. The errors are collected and displayed in phase RUN_CHECK_ILLACCESS in which SUM will stop with an error:

Code snippet
4 EPU201XBEGIN OF SECTION BEING ANALYZED LASTOFFSET               103212 NOW BEGIN OF RUN_CHECK_ILLACCESS ======
A4 ESUPG 001 -------------------------------------------------------------------------
A4 ESUPG 002 " "
A4 ESUPG 301 Report name ...: "RSZDM_CHECK_ILLACCESS"
A4 ESUPG 302 Log name: "SUM/abap/tmp/CHECK_ILLACCESS.PPM"
A4 ESUPG 304 Start time.....: "15.01.2021" "16:17:41"
A4 ESUPG 002 " "
A4 ESUPG 001 -------------------------------------------------------------------------
A4 ESZDM 320 Report "RSZDM_CHECK_ILLACCESS" started
...
A4 ESZDM 330 Phase "XPRAS_AIMMRG" containing illegal table access started at "210113 17:38:08"
A2EESZDM 324 Illegal access on table "TESTTABLE1" at "210113 19:05:50"
A4 ESZDM 325 Phase "XPRAS_AIMMRG" containing illegal table access finished at "210113 20:28:00"
A4 ESZDM 321 Report "RSZDM_CHECK_ILLACCESS" successfully finished
A4 ESUPG 001 -------------------------------------------------------------------------
A4 ESUPG 002 " "
A4 ESUPG 301 Report name ...: "RSZDM_CHECK_ILLACCESS"
A4 ESUPG 304 Start time.....: "15.01.2021" "16:17:41"
A4 ESUPG 305 End time ......: "15.01.2021" "16:17:42"
A4 ESUPG 002 " "
A4 ESUPG 001 -------------------------------------------------------------------------
4 EPU202XEND OF SECTION BEING ANALYZED END OF RUN_CHECK_ILLACCESS ==========================================
Copy code

Log file

Phase RUN_CHECK_ILLACCESS writes into the log file CHECK_ILLACCESS.<SID>.

Solution

Create an incident using the SAP ONE Support Launchpad for the responsible application component of the affected table. If the component cannot be identified, create the incident for component BC-UPG-DTM-TLA.

Commands to Start and Stop the Bridge Subsystem

This section provides an overview of tooling provided by SAP to stop or start the bridge subsystem.

After the rollover to the bridge subsystem, all application servers are connected to the bridge database schema (like SAPHANADBSHD). In general, the standard commands such as Start, Stop, StartSystem, or StopSystem of the sapcontrol framework can be used to handle the bridge subsystem - especially, if only a subset of application servers should be restarted, this way would be preferred.

Note
The startsap and stopsap commands are deprecated. SAP recommends that you do not use them any longer. For more information, see SAP Notes 1763593 and 809477.

Alternatively, the upgrade executable SAPup is also equipped to restart the application servers.

Note
Both ways, sapcontrol and SAPup, ensure that after the restart, the application servers are connected again to the bridge database schema.

Starting the Bridge Subsystem

  1. Change to the bin sub-directory of SUM:
    1. Unix / Linux: cd <DIR_PUT>/SUM/abap/bin
    2. Windows: cd <DIR_PUT>\SUM\abap\bin
  2. Call the SAPup executable:
    1. Unix / Linux: ./SAPup startbri
    2. Windows: .\SAPup startbri
  3. The output will display the following success message: Starting the bridge instances...

Stopping the Bridge Subsystem

  1. Change to the bin sub-directory of SUM:
    1. Unix / Linux: cd <DIR_PUT>/SUM/abap/bin
    2. Windows: cd <DIR_PUT>\SUM\abap\bin
  2. Call the SAPup executable
    1. Unix / Linux: ./SAPup stopbri
    2. Windows: .\SAPup stopbri
  3. The output will display the following success message: Stopping the bridge instances...

Save progress to your learning plan by logging in or creating an account

Login or Register