SAP R/3 Enterprise came onto the market with a strategy which is new to SAP R/3 systems, Ramp up. The Ramp up strategy replaces the previous method of First Customer Shipment (FCS). In contrast to an FCS release, a Ramp up release can go into live operation straight away. The response to SAP R/3 Enterprise was very enthusiastic. During the Ramp up program, which lasted from July 2002 until January 2003, the participating customers were provided with intensive support by SAP. Their feedback was used in the continued development of the software. In the meantime, customers who did not receive the software until after the ramp-up phase and carried out their project independently are now also using the software operationally.
Two options for the release upgrade
The average duration for a project to upgrade to SAP R/3 Enterprise is four months. One drawback of an upgrade project is the downtime, i.e. the time during which neither the old nor the new release is available. When upgrading to release SAP R/3 3.x, the average downtime was 15 hours. The technical downtime for the release upgrade to SAP R/3 4.x was around ten hours.
The new “system switch” upgrade technology of the integration and application platform SAP NetWeaver is used for the upgrade to SAP R/3 Enterprise. System switch is a component of the Software Life Cycle Management of SAP NetWeaver and is shipped with the SAP Web Application Server (SAP Web AS) 6.20. The technology offers two options for an upgrade: Either “Resource Minimized” for moderate use of system resources or “Downtime Minimized” with which downtime can be minimized. While the average downtime in the case of an upgrade with “Resource Minimized” was approximately 16 hours, it was only seven hours with “Downtime Minimized”.
The upgrade already begins during the productive period
The “Downtime Minimized” option allows some of the upgrade phases which have extended downtime in the past to be moved to the productive period. In the case of previous upgrades carried out with repository switch technology, the downtime was extended due to e.g. the number of integrated support packages and languages. Now these phases and the data dictionary adjustment (SPDD transaction) phase both take place in the productive period. The upgrade can thus already begin during the day without the system users noticing anything.
The “shadow instance” makes the difference
This is possible because a second instance of SAP Web AS is compiled in the productive database at the start of the upgrade. This “shadow” system is already supported by the software version of the target release. Important object handling operations which until now took place during system downtime can now be performed on the inactive shadow system in parallel with productive operation. SAP MCOD (Multiple Components in One Database) is used when installing the shadow instance. A second system is installed in the same database instance in which the SAP Web AS tables are stored. The accompanying diagram illustrates the database layout during the upgrade. The tables of the shadow instance and the tables of the start release are loaded into the database.
Only the standard users DDIC for dictionary tasks and SAP* with full permission are copied into the shadow instance. The SPDD adjustment cannot be performed with the user DDIC. It is therefore necessary to copy this user to a new name in transaction SU01. Because the application tables in the shadow instance are not accessible, company data remains protected.
The shadow instance is accessed exclusively with the new kernel and the tools of SAP Web AS 6.20. It is thus necessary to install SAP GUI 6.20 on at least one client in the company so that the SPDD adjustment, i.e. the dictionary adjustment, can be carried out. After the upgrade, SAP GUI 6.20 must have been installed on all the clients that are to work with SAP R/3 Enterprise. Because SAP GUI 6.20 is downward compatible, it can already be installed on all the clients in advance of the upgrade project.
Manual follow-up work is reduced
In order not to load the working memory and the CPU of the central instance with the additional shadow instance, it is possible to specify another host to install it on. A look at the process list of the central instance shows that the shadow instance is operational. Most of the upgrade phases now run on this second instance in the productive phase. This includes the integration of support packages for the target release. This enables users to go immediately to the latest version of the support packages when upgrading without extending downtime or having to load the support packages manually after the upgrade. The SPAM/SAINT Package, which is used to load the support packages, can also be integrated in the operational phase, which means that manual follow-up work is also not required here. Further necessary follow-up work is set out in the upgrade guidelines.
It is only in the ModProfTrans upgrade phase that production on the old system is shut down. Until then, all the application servers can continue to operate as normal and plan in all background jobs. It is only when confirming the ModProdTrans phase that it is necessary to plan out all background jobs and isolate the central instance. A full backup should now be performed. This allows the upgrade to be reset at any time during the following upgrade phases. There is also the possibility of allowing the backup to run online during the whole upgrade process. However, a rollback using database resources is usually more difficult than reloading the backup.
The SPAU adjustment (program adjustment) is to be carried out after the technical downtime. To save time, the transports should now be loaded from the test system. It is subsequently also necessary to load the customized transports of the specialist departments. Depending on the number and size of these transports, this can take several hours. The upgrade guidelines list further follow-up work that has to be done. This includes filling in the language tables, generating the ABAP programs or deleting table spaces which are no longer required. The system is now running on the SAP R/3 Enterprise release. The actual downtime is thus made up of the technical downtime, the follow-up work and the backup.
Only the release of the system now remains in order to complete the upgrade process. A system test is normally carried by the key users. After a successful test, the system can be released for the end users.
Usually no new hardware is required
Lots of customers wonder what resources are required for SAP R/3 Enterprise. The accompanying diagram illustrates the resources required in comparison to SAP R/3 3.1I. The CPU requirement of the application server when upgrading from release SAP R/3 4.0b to SAP R/3 Enterprise is increased by 43%. This compares to only 5% additional CPU requirement when upgrading from SAP R/3 4.6C to SAP R/3 Enterprise. In most cases, it is thus possible to continue to operate the hardware used for SAP R/3 4.6C. This means that no new costs for hardware are incurred.
Details on questions about performance are contained in SAP Notes 89305, 151508, 178616 and 323263.
For further information on ERP see the print edition of SAP INFO.