This section introduces the different subsystems that Zero Downtime Option (ZDO) of Software Update Manager (SUM) utilizes during the procedure.
Note
When the business users operate on the bridge subsystem, restarting the bridge subsystem can be done using theSAPup executable that is delivered with SUM.Different Subsystems during SUM Execution
| Type | Software Release | Database Connection | Description |
|---|---|---|---|
| Original system | Before the upgrade: Source release (version 1) After the upgrade: Target release (version 2) | Original schema (like SAPHANADB) | The original system represents the state of the system before and after SUM execution. Business users are also operating on the original system during the pre-processing phases when the shadow system runs in parallel. |
| Shadow system | Target release (version 2) | Shadow schema (like SAPHANADBSHD) | The shadow system is used to prepare the repository and dictionary objects of the target release in the shadow database schema. |
| Bridge subsystem | Source release (version 1) | Bridge schema (like SAPHANADBSHD) | The state of the system when all existing application servers are reconnected to the bridge database schema. From a technical perspective, the bridge database schema reuses the shadow database schema. |
| Upgrade subsystem | Target release (version 2) | Original schema (like SAPHANADB) | Finalization of the target release repository. The upgrade subsystem operates on the original database schema. |
The transition of end users from the original to the bridge subsystem happens seamlessly without any interruption for the end user. In order to activate the target release, the application servers have to be restarted. The next three figures illustrate on which set of database tables the bridge and upgrade subsystems operate.
During the ZDO procedure, the Software Update Manager works on a single database with two schema: the bridge schema (technically, the shadow database schema is reused, like SAPHANADBSHD) and the original schema (like SAPHANADB).
At the beginning of the ZDO procedure, until phase REQ_USER_ROLLOVER_PREP is reached, the end users operate on the original system.
At the end of the pre-processing milestone, SUM generates views in the bridge schema pointing to the tables stored in the original schema. For each table in the system (SAP-owned and customer created), a view is generated. For example, if there are 100.000 tables in the original schema, 100.000 views are also generated in the bridge schema.
At this point in time, only one version of the tables is present, the so-called V1, which represents the source release.
When initiating the rollover to the bridge subsystem (technical phase name: REQ_USER_ROLLOVER_PREP, for details, see lesson Rollover to the Bridge Subsystem in unit 6). Work processes of all application servers are automatically reconnected to the bridge schema (technical phase name: BRIDGE_RECONNECT).
After transitioning, all end users to the bridge subsystem, the default database schema of the production is no longer SAPHANADB, but SAPHANADBSHD in this example.
The upgrade subsystem that is used to finalize the upgrade, connects to the original database schema (like SAPHANADB).
While the upgrade is performed on the target release tables (V2 tables), the generated views in the bridge schema still point to the source release tables (V1 in this example). Tables that are either not changed by the upgrade or the structural change can be compensated by the database view does not require two versions of a table. These tables are available for both the bridge and upgrade subsystem.
Note
All existing application servers of the system are reconnected to the bridge subsystem. End users do not have to logoff and logon as the transition from the original to the bridge database schema happens seamless triggered by the ABAP kernel in phaseBRIDGE_RECONNECT.
At the end of bridge runtime (technical phase name: REQ_USER_ROLLBACK_PREP), the system needs to be ramped down. As in every other upgrade this requires activities like:
- cleanup of queues
- de-schedule batch jobs
- stop inbound and outbound interfaces
- check for erroneous update processes
- logoff all dialog users
- lock users
- and so on
After the cut-over, which is restarting the application servers and ramp-up activities, the business users are reconnected to the original schema and the business operations can continue.