Zero Downtime Option for SAP Business Suite

Technical Details of the Zero Downtime Option

This section deals with the Zero Downtime Option (ZDO) from a technical point of view.

The basic principle of the ZDO is to update an SAP system while production is running in parallel. When updating with ZDO, the SAP system runs productively on the old release while the update process is performed at the same time. In this way, the update has no technical downtime.

The following figure illustrates how the technical downtime is already reduced when using the nZDM approach. With the ZDO approach, the technical downtime can be eliminated and replaced by the uptime on the bridge.

The General Solution Approach

The bridge subsystem is a part of the existing system that runs in parallel to the update subsystem during system maintenance. In the standard approach and the nZDM approach, all users are logged off from the system at a certain point in time, and the technical downtime starts. With the ZDO approach, all users are transferred transparently and in the background to the bridge subsystem. The Software Update Manager connects the users from one database schema to another database schema.

The following picture shows the basic steps of the ZDO procedure:

  1. Business users work with release 1 while the update is running in the uptime.

  2. Business users are smoothly transferred and reconnected to the bridge subsystem without any interruption.

  3. While productive business operations continue on the source release, the remaining update phases run in parallel on the subsystem that is being updated. In this way, the Software Update Manager can perform during uptime activities that are performed in other approaches during downtime.

  4. At the end of the update, the application server must be restarted to activate the new release version, which usually takes between 5 and 15 minutes. The database is not restarted.

    Afterwards, the system is on the new release 2.

The Bridge Concept

  1. At the beginning of the ZDO procedure, the upgrade system is running on the original version. During an update with ZDO, SUM works on a single database with two schemas: The bridge schema (for example in the following figure SAPABAP1SHD) and the original schema (SAPABAP1 in this example).

  2. The Software Update Manager generates for each SAP-specific or customer-specific table a view in the bridge schema, which then refers to the original tables. At this point in time, only one version of the tables (V1) exists, which represents the source release. The original schema continues to be used productively.

  3. When the rollover to the bridge subsystem is initiated in phase REQ_USER_ROLLOVER_PREP (see also Transition of Users to Bridge Subsystem), all work processes are automatically reconnected to the bridge schema in phase BRIDGE_RECONNECT (see also Database Reconnect Transition Method).

    After all users have been transferred to the bridge subsystem, the default database schema of the production system is renamed by appending SHD to its name. For example, the SAPABAP1 database schema is renamed to SAPABAP1SHD.

    The upgrade subsystem with which the upgrade is performed, is still connected with the original database schema (SAPABAP1 in the example).

  4. While the upgrade is being performed on the target release tables (V2 tables), the generated views (view 1 in the example illustration) continue to point to the source release tables (tab1 V1 in the example). As a result, the productive use can continue on the bridge subsystem.

    If no adjustment of the table structure is required during the upgrade, no additional V2 table is created (in the example, tab 2 V1=V2), and the generated view (in the example, view 2) still points to this table.

  5. At the end of bridge phase, the system needs must be shut down. As with any other upgrade, activities are required such as:

    • cleanup of queues

    • descheduling of jobs

    • check for erroneous update processes

    • logging off all users

    • locking the system

  6. After the restart of the system, business users are connected back again to the original schema and the business operations can continue.