Preparing Impact Analysis to Determine Potential Restrictions for Business

This section introduces the Impact Analysis. Impact Analysis works based on (production) statistical data and Software Update Manager (SUM) table classification data to help determine potential impacts on business processes during a Zero Downtime Option (ZDO) maintenance event.

Running an upgrade using a downtime-optimization approach can result in certain kinds of impacts for the ongoing business operations on the bridge subsystem. Hence, the Impact Analysis is an important step in the preparation of the ZDO procedure.

In the case of ZDO, the following impacts are checked by the Impact Analysis:

• Read-only restrictions for end users on the bridge instance
• Database triggers might have to be removed from certain tables or an initial load is needed after the completion of the upgrade
• Additional database space needed for the clone tables
• Tables that will be smart-switched but have a high number of changes

To prevent unexpected occurrence of such impacts during the maintenance event on your production system, you would like to identify them in advance. This can be achieved by exporting table statistics from your production system and providing them to the Software Update Manager in your very first cycle running in a sandpit environment. The Impact Analysis is equipped with the capabilities to give a projection on "what would happen if the defined upgrade scope would be applied in the production system?"

It is important to understand that the results of the Impact Analysis are based on these facts:

• The defined scope (list of software components as well as the source and target levels of the software components versions) must be identical in all systems that should be upgraded in your project. When changing the stack definition, the results will be different and need to be interpreted again.
• The exported table statistics should be representative of the time the business operations will work on the bridge subsystem. All relevant business processes should be captured accordingly in the exported statistics file.

The analysis is based on statistical data retrieved from the productive system, as only there real end-user activity is happening. To perform the export of the statistical data, the Software Update Manager (SUM) Toolbox has to be available in the productive system. SUM Toolbox is available using TCI SAP Note (TCI: transport-based correction instruction). In addition, the tool will be shipped with the regular software delivery of SAP_BASIS. SUM Toolbox includes a tool which does the export of the statistical table access data. Additionally, a dialog version of the Impact Analysis is included.

The data that is exported using SUM Toolbox is later analyzed by SUM in phase RUN_IMPACT_ANALYSIS_ZDO. Furthermore, the analysis can be performed in dialog mode using SUM Toolbox like described in the following lessons.

This figure shows the procedure flow at a high-level. All steps will be explain in separate lessons during this unit.

One part of the upgrade procedure is called table classification, which calculates how the tables are handled during the upgrade. This includes both sets of tables: customer-created and SAP-delivered tables. Technically, the table classification happens in phase RUN_RSPTBFIL_ZDM_CLASSIFY.

The most important table classification types are as follows:

• Share [upgrade does not touch the table or just adds a new non-key field]: These tables will not be cloned. No restrictions apply.
• Clone [that is, upgrade delivers table content or a structural change]: Additional database space required for table clone and change record and replay. No restrictions apply.
• Clone read-only [that is, upgrade delivers a complex structural change or an XPRA accesses the table]: Additional database space required for table clone and change record and replay. Table will be read-only for the business users while working on the bridge subsystem.

Schematic Illustration of the Impact Analysis

Following the example, Table-B will be cloned and set to read-only for the bridge subsystem. This could potentially lead to a business impact for end users working on the bridge subsystem since read-only tables are blocked against write accesses. If the table statistics file (ZDIMPANA.ZIP) contains the information that the Table-B changed, the Impact Analysis will throw an error. The result needs to be interpreted in a way to see whether the bridge subsystem really needs to write into the table. It is now important to figure out which business processes write into the read-only tables. If the processes are identified it has to be verified with the responsible business process owner and key users whether the read-only constraint can become critical for the business.

Table-D will be cloned as the upgrade will perform a change on the table. However, Table-D will be fully available with read and write accesses for the bridge subsystem. As Table-D will be cloned but has database triggers of type SLT, an error is displayed. After SUM is finished, an initial reload is needed for clones tables with database triggers (for details, see lesson SLT Database Trigger Handling in ZDO of unit 3).

Lastly, Table-D will be smart-switched since the table is being cloned. Tables that will be smart-switched will be renamed on-the-fly in phase EU_SWITCH_ZDM. Dependent on the load, this could impact the SUM tool since renaming tables requires an exclusive table lock on database level.

Further details on how the result of the Impact Analysis should be evaluated and interpreted can be found in lesson Results of the Impact Analysis in unit 4.

This section shows how to retrieve statistical table data from the production system.

Exporting the table statistics is the first step in running the Impact Analysis. The export report retrieves all table changes (updates, inserts, and deletes) as well as size and database trigger information. The output is stored in a compressed archive named ZDIMPANA.ZIP.

The Impact Analysis as well as the tool to export the table statistics is part of the Software Update Manager (SUM) Toolbox, which has to be present in the production system. The export works as follows:

1. Call the transaction code SUMTOOLBOX in the production system.
2. Select the tool Export data for Impact Analysis in the navigation tree.
3. Use the F4 help to provide a file name and path like in this example (C:\Temp\ADM330e\ZDIMPANA.ZIP). In addition, enter a start and end date for the data which should be displayed in the result screen.
   Note

   The start and end date fields are optional. If no dates are entered, all available periods are shown in the ALV grid.
4. The button Display Period will query the data available in the system and update the ALV grid below. Important: This action will not start the export into the ZIP file.
   Note

   The column Contains Imports indicates that during that time, transports or other software changes like updates of software components were imported into the system. If you have, for instance, daily imports running into the system, all lines will have the flag set in this column that means that these lines have to be exported. This can potentially lead to false-positive results as also the import of transports or other software changes change data in the tables. Further information on how to reduce the number of false-positive results in that case can be found in the lesson. 'Best Practices to run the Impact Analysis' of this unit.
5. Now, select the timeframe, which should be exported like in this example the weekly data from March 7, 2022 to March 13, 2022. Hold the CTRL key on the keyboard to select multiple lines.
   Hint

   The exported table statistics should be representative of the time when the upgrade is running. In particular, it is important to consider the time when business users operate the bridge subsystem. The ideal time frame would be a data set that captures all activities and business processes like the time of the week when the SUM is performing the upgrade.
6. Last, choose the Export button to start exporting the table statistics for the selected period(s) into the compressed file.

Provide the exported file ZDIMPANA.ZIP to the SUM/abap/save directory. The directory will not be available right after extracting SUM as SUM creates it as part of the per-processing activities. When the save directory is shown as sub directory of SUM/abap, the provisioning can take place.