Planning a ZDO project

In general, it is recommended that you follow the same upgrade approach (either standard, nZDM, or ZDO) throughout the complete landscape for all systems. Hence, the following exemplary project plan for a 3-tier landscape that includes all systems from sandbox to production.

Cycle 1 and cycle 2 might be combined into one test cycle that will focus on both the technical validation of the ZDO procedure and the functional validation of the source release when running on a bridge subsystem.

Note

The results of cycles 1 and 2 need to be checked carefully, especially if the results of the Impact Analysis should be interpreted and discussed with the respective functional teams. Based on these findings, a go or no-go decision for the further ZDO project should be taken.

ZDO is used in general for all systems including development and quality assurance test systems. The last cycle before production has to run on a recent copy of production to rehearse to overall upgrade sequence. This ensures that the test shows all potential issues that might occur in production.

This section deals with the estimation of the correct timing for rollover and rollback.

We recommend that you perform the rollover to the bridge subsystem at off-peak hours. Some steps after the rollover like the smart-switch in phase EU_SWITCH_ZDM need to acquire an exclusive database lock on the table to switch the table on-the-fly. Software Update Manager (SUM) Toolbox offers the feature "DB Table Lock Analyzer" to identify periods of time in which SUM can acquire required database locks. From SUM Toolbox reportRSTBX_LOCK_DATA_COLLECTOR can be scheduled as a regular background job in the production system. The job collects information about database locks that are requested during production operation. The results listing busy tables are available in SUM Toolbox. Optionally, SUM table classification data from any previous SUM run with the same software stack (for example, sandbox system) can be uploaded to narrow down the result.

Analyze the system utilization (dialog and batch load) and the alignment of the rollover to the bridge system in close collaboration with the functional teams. From this time onwards, the read-only restrictions on the read-only tables are active.

Calculate the rollover to the bridge subsystem based on the runtimes from the test cycle.

Assuming, as per the upgrade analysis file (UPGANA.XML), the net-runtime of the bridge subsystem in the dress rehearsal cycle took approximately 19 hours. Then, to calculate the recommended runtime of the bridge subsystem in production, a buffer of 24 hours should be added.

Note

The buffer of 24 hours is highly recommended to compensate unexpected longer runtimes as well as unforeseen issues.

• Take the value Bridge Time stated in the upgrade analysis file. In this example, the net-runtime in the dress rehearsal was like 19 hours
• Recommended runtime of the bridge subsystem in production should be at least 19 hours + 24 hours = 43 hours

Now, by knowing that the recommended minimum runtime of the bridge subsystem in the example above should be approximately 43 hours, the timing for the rollover to bridge can be calculated.

Note

There is no maximum runtime of the bridge subsystem. As long as there are not restrictions for the business, you can extend the bridge runtime to fit your project requirements.

In classic procedures like standard or near-Zero Downtime Maintenance, the functional validation of business processes happens after all upgrade activities of Software Update Manager are finished and the system was handed over to the functional teams.

When you are performing a zero-downtime upgrade project, key users of functional teams and test managers should be involved in the entire upgrade project. This starts when you plan the first sandbox system and ends when the productive SAP S/4HANA system has been successfully upgraded.

• Functional testing of crucial business processes
• Load verification after the rollover to the bridge subsystem

Testing and verifying the system in different system states (prior, during, and after the ZDO upgrade or update) is essential for a successful zero-downtime project. As we have previously said, the functional teams and test managers should be part of the complete project cycle starting with the first upgrade happening in the sandbox environment. A recommendation on the number of test cycles is given in the lesson, 'Project Planning for Zero-downtime Upgrades' in unit 3.

Note

It is highly recommended that you plan and execute testing activities as part of the first sandbox upgrade. The results of the testing activities will be the foundation for taking a decision if the Zero Downtime Option approach meets the requirements and expectations from the business teams in terms of the availability of crucial business processes.

(1) Baseline testing of the source release prior the upgrade is started

• Baseline testing refers to the validation of the processes and specifications on which test cases are designed.
• This test ensures that all business processes are functional before the ZDO upgrade is started.
• If the baseline test is skipped but an error is found either during the bridge or after the upgrade, it will be hard to identify the root cause for the issue.

Note

In case a system is newly built up for performing an upgrade test, it is always recommended that you perform baseline testing. This holds true independently of the upgrade approach.

(2) Bridge testing of the source release during the ZDO procedure:

• This is the most crucial testing activity. All relevant business processes should be tested thoroughly in a non-productive environment.
• Proving that all business processes triggered by end-users, interfaces, and background jobs are fully available and functional during the bridge runtime is the ultimate goal of testing on the bridge.
• Performing functional validation on the bridge subsystem helps to identify if crucial business processes would be blocked in case an application table would become read-only but one or more business processes require to change the table. Of course, the Impact Analysis would also identify such tables as long as the provided table statistics file is accurate. For details on the Impact Analysis, see unit 4.

Note

Some applications might be only restricted available during the bridge runtime. SAP Note 2707731 contains a list of known restrictions during the runtime of the bridge subsystem.

(3) Final testing of the target release after the upgrade is finished. Testing the target release after the ZDO upgrade follows the same best practices like in any other upgrade approach.

• Verify the business processes that will run on the bridge subsystem.
• Proof that read-only restriction found using the Impact Analysis do not block critical business processes.
• Proof known restrictions to applications listed in SAP Note 2707731.

The goal of load verification is to simulate production-like load in a non-productive environment. When you are performing load verification, the following activities should be considered - similar to what is shown in the illustration above:

(A) Activation of batch jobs (internally and externally scheduled)

• Even in a non-productive system, it is highly recommended to simulate all jobs that are scheduled in production.
• Especially, when rolling over to the bridge subsystem, it should be proven that all active batch jobs are taken over to the bridge subsystem.
• As long as the batch jobs regularly perform an implicit commit, the rollover of active batch jobs will be done automatically by the reconnect feature which is triggered by the SAP Kernel.

(B) Simulation of end-user load (that is, using test automation tools)

• In non-productive systems, typically only very few users are operating on the system.
• Hence, the user load of end-users and interfaces can also be simulated using test automation tools.

Note

Performing a load test becomes especially important in case the productive system constantly shows a significant load. Load verification should be considered from phase REQ_USER_ROLLOVER_PREP until the end of the bridge runtime (phase REQ_USER_ROLLBACK_PREP).

The following upgrade phases should be focused on when performing a load test:

• BRIDGE_RECONNECT: Reconnection of all users to the bridge subsystem as part of the rollover to bridge.
• EU_SWITCH_ZDM: Renaming cloned tables during the smart-switch.
• SQLRUNTASK_FDCT_TRANSFER: Creation of cloned tables.
• PARCONV_UPG: Execution of DDL statements on cloned and shared tables.

• Simulation of load impact to the overall system performance.
• Proof that load can be handled by SUM replication process when creating cloned tables.
• Verify that exclusive database locks can be acquired to perform the smart-switch of cloned tables in phase EU_SWITCH_ZDM.