- SAP Managed Tags:
When you’re planning a maintenance for your SAP ABAP system, you need to consider different aspects for planning and, depending on the available maintenance window, you might be looking at downtime optimization options of Software Update Manager 2.0.
For updates and upgrades of SAP S/4HANA® system you might want to consider
- near-Zero Downtime Maintenance (nZDM)
- Zero Downtime Option (ZDO)
For system conversions to SAP S/4HANA there are
- Downtime-optimized Database Migration Option (downtime-optimized DMO)
- Downtime-optimized Conversion
ℹ️ For more information on the scenarios, please refer to Software Update Manager page in SAP Support Portal.
Each of these approaches saves technical downtime*. However, the saving comes at a cost: Each approach introduces additional complexity to the maintenance. To understand potential impacts of the procedure that are relevant in uptime, SAP offers the Impact Analysis delivered with Software Update Manager Toolbox.
*It is important to note that downtime doesn't just involve the technical unavailability of the system. It also includes activities such as ramping down the system, ramping it back up and testing, all of which is not productive use, that is business downtime. When I mention downtime in this blog, I’m referring specifically to the technical downtime caused by Software Update Manager.
Why is there an impact on business in uptime?
To ensure that the former downtime steps that Software Update Manager executes in uptime are isolated from production operation and all changes on production are available after the upgrade in the target release, data consistency mechanisms are in place. This may include cloning tables to make them available in both the old and new release versions, as well as restricting write access to tables. Software Update Manager classifies every table in the system to determine the appropriate mechanism to be used, with the classification determining the handling during maintenance.
Which impacts are considered by Impact Analysis?
The impacts which can be expected on production depend on the Software Update Manager scenario that is chosen. Following impacts are analyzed:
Additional database space requirements due to table cloning
To enable Software Update Manager to work on the target release in parallel to production which operates on the source release, tables might be cloned. The clones consume additional database space which is forecasted by Impact Analysis.
Additional daily database growth due to change recording
As just mentioned, some tables might need to be cloned. The changes that happen on production are captured and replicated to the target table. This additional database space needed for replication is forecasted by Impact Analysis.
Temporary read-only restrictions for end users during the maintenance
To avoid conflicts between input from production and maintenance by Software Update Manager, tables may be classified as read-only. This means that for a specified timeframe during the procedure, production cannot write into those tables. However, production statistics show, that those tables receive changes.
Busy tables potentially conflicting with the smart-switch operation
During certain phases - the so-called smart-switch - Software Update Manager requires short exclusive access to database tables for single actions. This is necessary when a table needs to be cloned during the maintenance procedure to isolate the source and target version from each other. However, if such a database table is being used frequently and Software Update Manager is unable to acquire exclusive access, it stops on error and may require several repeats of the SUM phase.
Impact on database triggers
Database triggers may be present on the production system. During the maintenance with Software Update Manager, the underlying tables might be changed in a way that does not allow the triggers to be preserved. This requires the trigger either to be dropped completely, or in case of System Landscape Transformation (SLT), to execute an initial load after the system maintenance.
The following table shows which impact may occur for which Software Update Manager scenario.
nZDM | ZDO | downtime-optimized DMO | downtime-optimized Conversion | |
Additional database space | X | X | (database is moved) | X (or database is moved) |
Additional daily database growth | X | X | X (on source database) | X |
Temporary read-only restrictions |
| X |
| X |
Busy tables relevant for smart switch |
| X |
|
|
Database triggers | X | X | (database is moved) | X (or database is moved) |
X = relevant for
How is Impact Analysis executed?
Impact Analysis compares table usage and size statistics from production system (stored in a file called ZDIMPANA.ZIP) with the table classification and identifies potential impacts.
Impact Analysis is delivered with Software Update Manager Toolbox. The Software Update Manager Toolbox is available by default with SAP_BASIS releases or can be installed/updated via transport-based correction instruction (TCI).
In Software Update Manager Toolbox, the tool to export table statistics from production (1) , the tool to expert classification data from a system on which Software Update Manager already passed classification (2), as well as the Impact Analysis itself (3) are available.
The following screenshot shows the screen of Impact Analysis in Software Update Manager Toolbox for scenario Zero Downtime Option.
- File selection screen: Here the paths to the Table classification file and to the table statistics file are provided.
- Header data: Information about the system, the scenario, and the statistics.
- Overall summary: This is the summary of the overall impact.
- Impact Analysis Findings: This is the summary of the findings which need analysis.
- Detailed findings of Impact Analysis
Additionally, Software Update Manager executes Impact Analysis during the maintenance process if the statistics file is available in the download directory.
⚠️ Please note: For Downtime-optimized Conversion and Zero Downtime Option, Software Update Manager Toolbox and Impact Analysis are mandatory.
The following picture illustrates the steps of Impact Analysis.
Step 1: Export table statistics from production system
To determine the impact that is expected to happen on production, the table statistics need to be exported from production system. The table statistics contain information about size, change rate and usage of each table. The statistics need to be exported with Software Update Manager Toolbox and are stored in file ZDIMPANA.ZIP. It is important to note that the statistics should be up to date.
Step 2a: Impact Analysis runs in Software Update Manager.
The statistics file ZDIMPANA.ZIP needs to be provided in download directory. Software Update Manager will automatically consume it and executes Impact Analysis. It will stop on error in phase RUN_IMPACT_ANALYSIS_STBX_UPG and display an extract from the identified impacts on the screen. Details can be found in the corresponding log file.
Step 2b: Run Impact Analysis manually.
It is important to understand that Impact Analysis relies on historical production statistics to determine the impact. It is crucial that the statistics are from a timeframe that closely resembles the timeframe in production in which the impact occurs. The Impact Analysis in Software Update Manager Toolbox can be conducted multiple times as necessary. Especially for Zero Downtime Option it is recommended to experiment with different statistics files (e.g., from different weeks) to better understand recurring versus rare findings.
Step 3: Check and interpret the results.
The findings of Impact Analysis need to be carefully checked and analyzed. They contain valuable insights of impacts on production operation. For details on the meaning for different scenarios, please refer to the listed SAP Notes below.
How to interpret the results of Impact Analysis?
The result of the Impact Analysis can contain five basic issues:
- Additional database space requirements due to table cloning
- Additional database space requirements due change recording
- Read-only restrictions on tables
- Database triggers that must be removed
- Tables with a high change rate to which Software Update Manager needs exclusive access
For 1 and 2 the estimated database space needs to be available on production to ensure a smooth maintenance. Additionally, reduction in the source tables (e.g. Archiving) can be considered.
3 Read-only restrictions mean that no user can write into that table for a limited period during the maintenance event. Each table with a read-only restriction needs to be analyzed for the potential impact on the business processes.
4 Not all database triggers can be preserved during the maintenance event. Potentially, database triggers may need to be dropped, or in case of SAP Landscape Transformation Replication Server, an initial load may be needed after the procedure. The impact of the deleted triggers and the additional time needed for initial load need to be considered for the project.
5 During certain phases, Software Update Manager requires exclusive access to database tables. It is important to plan these phases for a time when the tables are experiencing less load. The Software Update Manager Toolbox provides a tool called the "Database table lock analyzer" which can help identify these timeframes.
Summary
The Impact Analysis provides valuable insights into additional considerations for optimizing downtime scenarios with the Software Update Manager. This feature is included in the Software Update Manager Toolbox. For further information, please refer to the links provided below. If you encounter any issues, please open a ticket with SAP using the component BC-UPG-DTM-TLA. And last but not least, feel free to post your comments.
Further information
2402270 - Executing Impact Analysis for Software Update Manager maintenance scenarios
3092738 - Software Update Manager Toolbox - Central SAP Note - SAP for Me
