Skip to Content
Technical Articles

Downtime Optimization Approach – Let’s talk all about different ZERO’s

The goal of this blog is to provide information on different downtime optimization approach especially that has “ZERO” in it, and has been introduced by SAP over the years. As being from IT service industry, I always encounter questions from customers or even from colleagues on how we can reduce downtime and which downtime optimization technique can be useful for upgrade/migration/conversion project. So, in this blog I would try to explain different downtime optimization technique which can be used based on the project scenario.

Before we go into the details of downtime optimization technique, it would be better if we first understand different implementation scenario that’s usually being encountered.

Source – ADM328: SAP S4HANA Conversion and SAP System Upgrade

It’s been seen that people use update and upgrade interchangeably, but it’s crucial to understand the difference. In order to get more insight on why the target release EHP8 for ERP 6.0 is considered as upgrade not update, read the blog Why EHP 8 is different by Boris Rubarth.

Also out of the above listed scenarios, DMO and Conversion are the most time consuming ones as the entire procedure for this scenarios include several steps like migration, update and conversion (applicable only for last scenarios). So in order to help customer achieve minimum downtime, SAP has came up with different downtime optimization approach over the years. Following are the downtime optimization approach with their respective supported scenarios.

In order to provide more light on when to use above mentioned approach, you can check below graphical representation. It highlights which approach is applicable based on your scenario, like nZDM/ZDO approach is only available for update and upgrade and it is only available as Pilot Project

Source: CAA602 – Prepare for Downtime Optimization Approaches of Software Update Manager

So now we got to know all scenarios and its respective downtime approach, we will now try to understand each downtime optimization approach in detail.


near-Zero Downtime Maintenance (ABAP) – nZDM


As the name suggest, near-Zero Downtime Maintenance (nZDM) capabilities of Software Update Manager (SUM) is applicable only when you are performing Support Package Stacks installation or Enhancement Packages (EHP) installation or during upgrade of SAP System. You cannot use nZDM, when you are performing HANA migration or S/4HANA Conversion.

nZDM feature is generally available since SUM 1.0 SP07, where you enable this functionality in Configuration phase. Starting from SUM 2.0 SP02, nZDM is available for S/4HANA.

In older SUM release i.e. 2.0 SP05 or less, we can activate nZDM feature under Advanced configuration. But that has changed in SUM 2.0 SPS 06.

But in new Software Update Manager (SUM 2.0 SP 06) dialog sequence is changed and the above screens are modified. So from the mentioned SUM version, advance mode is retired, instead the tool offers the option downtime-optimized (based on near-Zero Downtime Maintenance (nZDM)) option directly on the main dialog screen when you select “No Migration” under database migration option.

The main benefit of nZDM is the significant reduction of the Business Downtime compared to previous update tools because more of the downtime-relevant update phases are executed while the system is still up and available for business users. The following deployment phases are executed in nZDM during uptime:

  • Table structure adjustment including conversions, based on Record & Replay technique
  • Main import, based on Record & Replay technique

When it’s said that it uses “Record & Replay” technique it means that the database changes during uptime of the maintenance process create triggers, which records the changes. The recordings are only needed for tables which are used for the update / upgrade in the shadow. With the help of the recording the shadow tables will be updated after the upgrade/update phases in the uptime. The majority of the recording updates are run in the uptime. Only the delta (last 10%) has to run just before the switch in the downtime.

In order to get more insight on this feature, you can refer below blogs, wiki and SAP Note.

For more information on the new dialog sequence, you can below blog form Boris Rubarth

New dialog sequence with SUM 2.0 SP 06


Zero Downtime Option (ZDO)


ZDO is already available since three and half year for SAP Business Suite and now from last year, SAP has extended this offerings to S/4HANA customers as pilot project. This optimization technique is available as project which need to be requested as per the instruction mentioned in below SAP Notes. So obviously this approach is not generally available

Business Suite: 2163060 – Prerequisites and Restrictions of Zero Downtime Option of SUM

S/4HANA: 2707731 – Prerequisites and restrictions of Zero Downtime Option of SUM for SAP S/4HANA

In this blog, we will focus the ZDO approach with respect to S/4HANA System. So when we talk about S/4HANA System update/upgrade, there are three approaches that is being offered by Software Update Manager (SUM) – standard, nZDM and ZDO

Source: CAA301 – Leveraging Zero-Downtime Maintenance for SAP S/4HANA (TechEd 2019)

Above pictures describes that if business tries to optimize downtime, then there is more effort required in the project. This effort includes project planning effort, as well as testing effort which is higher in case of zero-downtime updates.

Both standard and nZDM approaches contain major improvements for minimizing the technical downtime and are generally available for all customers. But neither of the two can reduce the technical outage down to zero. In order to achieve that, SAP has introduced next level of downtime optimization: ZDO (Pilot Project)

In order to get holistic view on where ZDO approach stands, let us compare all the three approaches side by side.

Source: CAA301 – Leveraging Zero-Downtime Maintenance for SAP S/4HANA (TechEd 2019)

In above figure, you can see that with ZDO, the technical downtime can be eliminated completely but it is replaced by “Uptime on Bridge”. SAP has introduced bridge terminology with ZDO, where part of your existing system will run in parallel to the upgrade instance where the maintenance event is triggered by the Software Update Manager. Usually, at a certain point of time, end-users will be logged-off from the system and the technical downtime starts. In case of ZDO, all users will be transferred to the so-called bridge sub-system. The good thing: the users don’t even realize this since the transition to bridge happens in the background.

Bridge is basically the clone of your system but the good part is that it does not clone entire schema instead it will just clone tables that will be touched by the update procedure.

Source: CAA301 – Leveraging Zero-Downtime Maintenance for SAP S/4HANA (TechEd 2019)

Let take a look on how it works. You have started SUM and now the procedure is running and it has created a bridge and all the users are now connected to the system via that bridge. If the upgrade procedure is not doing anything with the tables, then the tables are kept as it is. If this is the case, then that tables are shared which means the business user who are now connected via bridge can perform read/write in this table but the upgrade does not do anything to it.

But if the upgrade is doing things like structural changes in table i.e. it is adding one more field, then the procedure will create a clone of table (V1) with new version V2 which will have new structural change of target release. As user is reading or writing changes to table (V1), we have to make sure that it is replicated to target table V2, this is achieved by having synchronous replication using database triggers. So whenever changes happens to V1 it will be replicated to V2 and after completion of SUM procedure, table V2 will be our main table and table V1 will be deleted.

As we are using database trigger to replicate changes between two version of a table, there are cases where it is not possible to cover all changes like complex structural changes i.e. data type changes from integer to character. In such complex changes, we need to set that table to read only. Example if you have 100000 tables and out of that 1000 is set to read only. It sounds a lot, but most of the read only tables are customizing tables, but anyways during upgrade customization is locked. In order to understand what is the impact of read only table in our system, SAP has came up with SUM impact analysis tool.

In order to get insight on how SUM impact analysis tool works and how to analyze the result, I recommend to listen to SAP TechEd Session from Jens Figer – CNA306 – Get Your SAP S/4HANA Ready for Running a Zero-Downtime Update Project, 2018 Las Vegas. I recommend you to listen to this session.

Few key takeaways about ZDO for S/4HANA

Availability

  • ZDO is an option of Software Update Manager: The standard tool. So you don’t need separate license or tool for this functionality
  • For SAP S/4HANA 1709 and 1809, ZDO is available to pilot customers. Below is the current availability for S/4HANA using ZDO

Source: CAA301 – Leveraging Zero-Downtime Maintenance for SAP S/4HANA (TechEd 2019)

Advantages

  • ZDO considers the overall business downtime for updates, upgrades and customer releases.
  • Significantly reduces the downtime to a single restart of the application servers.
  • Further reduction of business downtime by incorporation of customer transports along with the SAP software update.

In order to get more insight on this feature, you can refer below blogs and SAP Notes.

If you want to stay updated on the latest optimization approach, kindly follow Jens Fieger in SAP Community as he is the Product Manager for Downtime Optimization Technique


downtime-optimized Database Migration Option


downtime-optimized DMO approach is basically used when you are migrating your database to HANA, so it can be used for Business Suite migration from AnyDB to HANA or S/4HANA Conversion from ECC (check below Notes & Limitation section).

downtime-optimized DMO approach was in pilot mode, but it is now generally available with SUM 2.0 SPS 06.

Source: iENT113 – Business Downtime Optimization Using doDMO (TechEd 2019)

The technology behind this approach is to migrate large application tables during uptime processing of DMO, thereby reducing the migration time during downtime.

Let us dig further on how this technology works. As you are aware that during uptime the source system is still available for end users. End user activity in the system may change application tables, so if these tables have already been migrated to the target database (SAP HANA database), the changes have to be recorded and transferred to the target database as well. A dedicated technology offers the required procedure to set triggers on the respective application tables to create log entries, frequently analyze the logs, and transfer the delta to the target database.

Source: openSAP Course – Key Technical Topics in a System Conversion to SAP S/4HANA

In order to get detail insight on how technology works, kindly read the blog – DMO: downtime optimization by migrating app tables during uptime by Boris Rubarth

Specific considerations compared to “standard” DMO

  • You need to determine large application tables and create a text file with each table name in a separate line. This tables will be migrated during uptime and should be provided when prompted during execution of SUM procedure (shown in below screen). As this approach is generally available, it’s our responsibilities to identify the big application tables and then need to tell the tool which tables shall be migrated in uptime. We can only provide those tables that are not impacted by new data model

Source: iENT113 – Business Downtime Optimization Using doDMO (TechEd 2019)

  • The approach is available with SUM 2.0 (SP 06 and higher), which means:The allowed target release of SAP_BASIS is 750 or higher
  • The source system has to be on Unicode already

Note & Limitations

  • SUM uses its own delta record and replay technology CRR ), no DMIS AddOn is required
  • downtime-optimized DMO works for SAP Business Suite systems (not for SAP BW)
  • downtime optimized DMO IS supported for the scenario System Conversion (targeting SAP S/4HANA) as well, if the source system is not yet on SAP HANA database
  • Current restriction: downtime-optimized DMO is not currently supported for targeting SAP S/4HANA 1909

Below are some of the useful SAP Notes


downtime-optimized Conversion


This approach is basically used when you want to convert your ECC 6.0 system to S/4HANA On Premise. As described earlier, downtime-optimized DMO approach is influenced by migrating large application tables during uptime, whereas downtime-optimized Conversion taking technical downtime optimization a step further by performing data conversion of the application tables from old to new data model.

downtime-optimized Conversion is currently available in pilot project, so you need to raise request with SAP as per below SAP Note

2293733 – Prerequisites and Restrictions of downtime-optimized conversion to SAP S/4HANA

Source: openSAP Course – Key Technical Topics in a System Conversion to SAP S/4HANA

The idea behind this approach is to move downtime activities (like data conversion from old to new data model) and database migration (in case of source system on non-HANA database) to uptime processing of SUM.

In standard conversion, the FIN data migration has to be executed after the SUM has finished by respective IMG activities (e.g. FI customizing, FI data migration). The downtime-optimized approach will even move the FI data migration (partly) into the SUM uptime processing.

When you start SUM, in the entry screen it will ask for stack.xml (as show above) and if your xml contains a scenario where it is planning for a S/4HANA Conversion from ECC, it will ask you the scenario strategy in the next screen.

As the tool knows that you are planning for S/4HANA Conversion, it will provide you with three option where third option is only visible if you are doing S/4HANA Conversion. You can choose the second option “Downtime-optimized (based on downtime-optimized DMO)” which mean uptime migration of large tables, it is not the full blown downtime optimized conversion as this approach is not generally available yet.

Conditions for Piloting downtime optimized conversion

  • Downtime Optimized Conversion is available as pilot for the following scenario:
    Source product: SAP ERP 6.0 EHP 0 … 8 , Unicode
    Target product: SAP S/4HANA 1809 FPS1 (or higher)
  • Customer projects will have to request participation as pilot project (SAP colleagues have to be engaged into the Project)
  • Accepted projects benefit from direct development support , and reduced downtime
    project will require at least one test run without optimization and one test run with
    optimization
  • Pilot requests can be posted via incident on component BC UPG DTM TLA
    acceptance depends on system landscape, SAP involvement , and capacity of development team

Below are some import SAP Notes and blogs for downtime optimized Conversion


near-Zero Downtime Technology (NZDT)


Unlike all near-Zero downtime approach, nZDT is basically different from the rest as this is service based offering by SAP. The method of delivery for this approach is not via SUM instead it is a customer specific procedure that is technically a clone approach.

When using nZDT service, the maintenance is performed on the clone of the production system. All changes are recorded and transferred to the clone after the maintenance tasks are completed. During the final downtime, only a few activities are executed, including a switch of the production to the new system (clone).

The nZDT is very flexible regarding planned downtime activities. Database upgrades or migrations, OS migrations or Unicode migrations can be done on the clone in parallel to SAP upgrades as well.

Important Notes

  • NZDT requires a significant customer-specific effort
  • NZDT reduced considerably the business downtime

You can raise request for this service by following below SAP Note

693168 – Minimized Downtime Service (MDS)

Below are some of the important SAP Note for nZDT

NOTE: As this is service offering by SAP, there is no technical details available for this approach.

For latest update on SL Toolset and Optimization technique, do follow –

Boris Rubarth – Product Manager for SL Toolset

Jens Fieger – Product Manager for Downtime Optimization Technique

Regards,

Dennis Padia

Be the first to leave a comment
You must be Logged on to comment or reply to a post.