Executing Impact Analysis to Determine Potential Restrictions for Business

As part of the SUM upgrade procedure, the report RSUPG_RUN_IMPACT_ANALYSIS is called in phase RUN_IMPACT_ANALYSIS_ZDO on the shadow instance. This phase uses the file ZDIMPANA.ZIP stored in the directory SUM/abap/save.

If the file cannot be found, phase RUN_IMPACT_ANALYSIS_ZDO will stop with the following error message: A2EESUPG_IMPANA 101 Cannot open file "/usr/sap/<SID>/SUM/abap/save/ZDIMPANA.ZIP". Please provide statistics according to SAP Note "0002402270".

Note

Make sure that the file is available and the file name is spelled correctly using capital letters like ZDIMPANA.ZIP.

In case of any finding, SUM will stop in phase RUN_IMPACT_ANALYSIS_ZDO with the error Batchjob RSUPG_RUN_IMPACT_ANALYSIS on shadow system failed. The following errors were detected in the log files:. The log fileIMPANAUPG.<SID> can be found in the SUM/abap/log directory.

Hint

If SUM fails in phase RUN_IMPACT_ANALYSIS_ZDO with errors, you can proceed with the upgrade by choosing the option "Ignore phase errors and proceed to next phase" in the UI. However, assuming that this is the first sandbox iteration, checking the finding might take some time. Hence, the technical upgrade can continue while the findings are checked and interpreted. Make sure to follow-up on every single finding shown in the Impact Analysis result. Further details can be found in later in this unit.

While SUM continues with the upgrade, the Impact Analysis findings will be checked in detail. This can be done by utilizing the dialog version of the Impact Analysis in transaction SUMTOOLBOX. After completion of phase RUN_RSPTBFIL_ZDM_CLASSIFY, the tool can be called either in the original system or also on the bridge subsystem in case you are already rolled over to the bridge subsystem.

Since the Impact Analysis has been moved into the SUM Toolbox, the user-interface has been harmonized, unified, and simplified. Dependent on which system, the Impact Analysis tool is started, the input files may differ as shown in the following image.

In general, the section File Selection has two mandatory input fields:

• Table classification data holding the information about how tables are handled by SUM during the ZDO procedure.
• Table statistics from the productive system holding information like table change rates, table size, and database triggers.

The following three scenarios are covered:

1. Execution of the Impact Analysis on the system where a ZDO upgrade procedure is active:
   1. The table classification data is retrieved from the database table in the system holding this information.
   2. The table statistics are retrieved from the ZDIMPANA.ZIP file stored in SUM/abap/save directory.
2. Execution of the Impact Analysis on the system where a ZDO upgrade procedure is active, but usage of a new table statistics file:
   1. The table classification data is retrieved from the database table in the system holding this information.
   2. The table statistics are uploaded using SAP GUI. This can be beneficial if you want to follow the best-practice described in unit 4's lesson, 'Best practices to run the Impact Analysis'.
3. Remote Impact Analysis: Execution on any other system in the same landscape (for example, development system):
   1. The table classification data was exported using the SUM Toolbox from a system where ZDO has been completed. The output file PUTTB_SHD.ZIP is uploaded using SAP GUI.
   2. The table statistics are uploaded using SAP GUI.

Note

Further details on the remote Impact Analysis can be found below in the section, Remote Impact Analysis.

The dialog screen of the Impact Analysis is split into five sections:

1. File Selection: In this section, the relevant data to run the Impact Analysis is provided. Further details have been described in the section above.
2. Header: The header shows information like the export date, source system ID, the number of evaluated days, and if during the exported time software changes like import of transports are included.
3. Overall Summary: Here, the overall numbers like total number of cloned tables, read-only tables, and additional database space for cloned tables are provided. Additionally, the total change volume for all tables in the system and the online replication volume for cloned tables per day is shown. This number helps to get a better understanding about the ratio of the tables that will be cloned compared to the total number of changes in the system.
4. Impact Analysis Findings: It summarizes and aggregates the issues. In addition, gives an estimate on the required database free space for the clone tables.
5. Result table in ALV grid: It shows the findings on severity, category, and table level.

Caution

All results need to be checked carefully as these findings might lead to impacts on certain business processes during productive operations on the bridge subsystem.

The File Selection of the Impact Analysis provides the option to not only upload the table statistics (that is, ZDIMPANA.ZIP) through SAP GUI, but also to upload the SUM table classification data (that is, PUTTB_SHD.ZIP). Here is the process flow for running the Impact Analysis remotely.

By providing both files to the Impact Analysis in SUM Toolbox, the analysis can be run on any other system in the landscape having the same software version level. This can be beneficial in case not the latest version of SUM Toolbox was applied prior the ZDO upgrade procedure in the sandbox system.

The required file having the SUM table classification data can be exported in the system that is upgraded using ZDO when the phase RUN_RSPTBFIL_ZDM_CLASSIFY is completed.

Tables that will be read-only for the bridge subsystem can lead to limitations for certain business processes. Hence, it is crucial to check every finding in detail together with the responsible functional team in your company. Ideally, each table can be mapped to the relevant business process. Only by having this information, it will be possible to decide if the business will be able to continue their day-by-day work during the ZDO procedure on the bridge subsystem or if a critical business process will be blocked when operation on the bridge subsystem.

To identify the business processes, the SAP Basis team should involve the functional team as early as possible. It might be helpful to get further details on the read-only tables using transaction SE11. There, you can navigate further to the package and software component information through the Attributes tab. Additionally, the Delivery and Maintenance tab shows you if the table is for instance an application table (A) or customizing table (C).

TABL POWL_QUERY will become read-only, but has 4,2 changes/day on ref. system S4H
TABL UCONFILLCUST will become read-only, but has 1,0 changes/day on ref. system S4H
TABL EKET will become read-only, but has 1.216,6 changes/day on ref. system S4H

ZDO is able to keep the SLT replication active during the ZDO upgrade procedure. The message shown in the Impact Analysis is different, but this is dependent if SLT triggers should be kept active during the bridge time or switched off.

For all tables having an SLT trigger, but one that will not be cloned, nothing will happened and no further action is required.

TABL STXL SLT replication has to be paused or suspended before rollover to bridge (REQ_USER_ROLLOVER_PREP)

• As per the table statistics, SLT replication for this table is active in production but the current ZDO upgrade where the Impact Analysis was started, does not run with an active SLT scenario.
• If you would choose that SLT replication is turned off when upgrading the productive system, the replication for all tables would have to be paused or suspended before the rollover to the bridge subsystem happens in phase REQ_USER_ROLLOVER_PREP.
• In case SLT is used productively, it is recommended to also set up the non-productive systems to be able to test the replication during the test upgrade cycles using ZDO.

TABL STXL SLT replication requires initial reload after rollback (REQ_USER_ROLLBACK_FINAL)

• As said, the SLT replication can be kept active when performing a ZDO upgrade. However, for cloned tables an initial load in SLT is required as the database trigger will no longer be available after the switch to the target release which happens between phases REQ_USER_ROLLBACK_PREP and REQ_USER_ROLLBACK_FINAL.
• Involve the responsible team that takes care for the replication scenario. When performing the ZDO upgrade in the productive system, the colleagues should be ready to start the initial load for the cloned tables.

TABL STXL will be copied, but has size of 153,005 GB on ref. system S4H

• In general, very large application tables should not be cloned as the structural changes delivered for such tables have been validated by SAP. However, there might be exceptions where cloning a table cannot be avoided as the structural change is critical and must be delivered.
• In this example, the table STXL has a size of 153 GB which is still not too big. The error shown in the Impact Analysis is more a heads-up than a critical finding.
• As a rule of thumb, if tables that are very huge like bigger than 250 GB, it should be checked why those tables will be cloned. Potentially, a wrong decision in SPDD was taken the database object is inconsistent.
• Raise an incident using SAP ONE Support Launchpad for component BC-UPG-DTM-TLA in case you need support.

TABL COVRES will be smart-switched, but has 14,5 changes/second on ref. system S4H
TABL STXL will be smart-switched, but has 30,2 changes/second on ref. system S4H

TABL BKPF will get comp. view, but has 13,9 changes/second on ref. system S4H
TABL /AIF/STD_IDX_TBL will get comp. view, but has 16,7 changes/second on ref. system S4H

• The two tables COVRES and STXL in this example will be cloned but are very frequently changed. All clone tables have to be renamed in phase EU_SWITCH_ZDM for which an exclusive table lock is needed.
• Followed by BKPF and /AIF/STD_IDX_TBL that will be kept as shared but new fields have to be added to the table. To hide the new fields for the bridge subsystem that runs on the source release, a compensation view is used. In phase PARCONV_UPG, the fields will be added. Similar to renaming a table, the alter table statements also requires an exclusive lock in the table.
• Such findings are similar to the category cloned tables, more a heads-up than a real error.