This section contains information about recommended execution cycles and further important planning aspects such as rollover to bridge subsystem.
Before performing the upgrade using Zero Downtime Option in the productive system, it is essential to plan and prepare the project. This includes the execution of test upgrade cycles in non-productive systems.
The first upgrade cycle is essential for the overall success of the upgrade project. Based on this, you will determine if ZDO is the right approach to follow in your upgrade project.
Purposes of running the first cycle in a sandbox environment
- Familiarize with the technical upgrade approach ZDO
- Understand and set expectations regarding the business downtime
- Technical and functional validation of the bridge subsystem
- Performing business validation tests on the bridge subsystem in the sandbox system help to verify that all core business processes are functional when running on the bridge subsystem
- Analyze potential conflicts and impacts on critical business processes using the Impact Analysis
- Address technical and functional findings to the responsible teams
- Start creating an upgrade cookbook
Exemplary High-Level Project Plan
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.
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.
Additional Steps for ZDO
In addition to the standard update procedure using SUM, consider the following enhanced steps for ZDO.
Interpreting the results of the Impact Analysis
This part is essential and must not be skipped. By ignoring the results, you can hit severe business impact in production if business-relevant tables that were not checked beforehand are set to read-only.
Functional validation during the bridge runtime on a non-productive system
All business processes that need to be available for day-by-day operations on the bridge subsystem should be tested. This essentially means that the source release must be validated again. Compared to standard upgrades, where typically only the target release is tested, the effort for testing may significantly increases.
Considering load verification
Like the functional validation, a load verification is recommended to be triggered on a non-productive system during the time when users work on the bridge subsystem. From upgrade tool perspective, there is no requirement in having real users on the system. The load can also be generated using any load generation and testing tool.
Testing the Database Replication Setup
Database triggers used by SAP Landscape Transformation (SLT) scenarios require more attention in case of ZDO.
The right timing for rollover and rollback
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 report
RSTBX_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.
The productive bridge runtime should be calculated as follows:
- 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.