Near-zero downtime maintenance (nZDM) isn't possible for:
Software Update Manager with Database Migration Option (DMO).
Software Update Manager with SAP S/4HANA Conversion if DMO is contained.
For availability and scenarios, check SAP Note 1678565 – Prerequisites, Terms, and Conditions for nZDM/Software Update Manager.
With nZDM, a significant reduction of business downtime, compared to current standard update and upgrade tools is possible.
Because nZDM can be executed integrated and automatically, there can be a significant TCO (Total Cost of Ownership) reduction for standard software maintenance activities compared to customer-specific downtime minimization services based on NZDT and other technologies.
Software Update Manager nZDM addresses AS ABAP-based SAP systems.
The record and replay technique for business transactions is used to handle changes that were made after the procedure has started.
The benefit is the execution of more relevant phases while the SAP system is still available for users:
Mass generation of enhancement objects, and generation of enqueue objects.
Main import (based on the record and replay technique).
Table structure adjustment including conversions (based on the record and replay technique).
Allows binding of customer transports into the uptime part of the procedure.
Starting the procedure: an end-to-end tool-based installation procedure addresses different Software Update Manager scenarios.
The temporary shadow instance on the same host is installed. No additional hardware is required to use nZDM features.
Based on the transport piece list of the target release, all application tables subject to change are identified (change tables).
All change tables are part of the record and replay technique and receive a trigger mechanism with logging tables to record all changes of production usage.
Change tables containing data are copied with an R3trans-based procedure into the shadow database.
Now, the record mechanism is in place and active. All data changes (INSERTS, UPDATES, DELETES) to change tables are recorded into special logging tables.
Meanwhile, the technical installation goes on with regular installation steps.
The final step before accessing the downtime is the replay mechanism: all data recorded into logging tables is transferred to the shadow system. This data replay ensures a synchronized status of all change tables. A newly designed cockpit allows you to monitor and control this process.
Once the data replay has reached approximately 90% or more, the installation can proceed with the technical downtime step.
First, all remaining data are copied to the shadow tables. Now, the tables are synchronized. The shadow system tables replace tables of the original system (system switch procedure). Further technical activities are executed (kernel switch, XPRAS, and so on) as part of the downtime.
Cleaning the temporary shadow system and logging tables are the final technical activities. Now, all customer-related tasks such as validating the system can be performed.
Replay
Recording in the "productive" system is usually done with database triggers and logging tables.
Replay must consider complex SAP data formats.
Application
Keep applications and data compatible all the time.
Keep transactional and repository data separate.
Enablement of AIMs (After-Import Methods) for execution on shadow.
Problems with shortened primary keys (can cause duplicate records).
Select nZDM in the Configuration roadmap step of the Software Update Manager. No additional configuration is needed.
Use the CRR Control Center of the Software Update Manager UI to perform the following actions:
Monitor the progress.
Identify error situations.
Restart broken conversions.
Stop and start the conversion.
Change the number of parallel processes.
An impact analysis is possible for downtime optimized procedures as part of the Software Update Manager 2.0. You can find more information on impact analysis at https://blogs.sap.com/2018/03/08/impact-analysis-as-part-of-software-update-manager-2.0/
In case of nZDM, the following impacts are possible:
Additional daily database growth due to change recording.
Database triggers might have to be removed from certain tables.
Additional database space requirements due to table cloning.
You can decide if a table should be handled during uptime: using SAPup parameter isu_max_tab_size, the default value (50 GB) can be overwritten. For details, see SAP Note 1678564 – Restrictions, Database-specific Settings, and Troubleshooting of nZDM for the Software Update Manager.
It's possible to exclude certain tables. See the Software Update Manager guide for Software Update Manager 2.0, 3.10.3 Using the Record and Replay Technique in nZDM: Including or Excluding Tables from the Data Transfer.
If you must include or exclude single tables into or from the data transfer, proceed as follows:
In the DIR_PUT/control sub directory of the Software Update Manager directory, open the template file CRRTABLIST.LST.
To include a single table, add the following entry to the existing entries of the CRRTABLIST.LST template file using the following format: I Tabname.
To exclude a single table, add the following entry to the existing entries of the CRRTABLIST.LST template file using the following format: E Tabname.