Start of Content Area

Function documentation SAP Upgrade  Locate the document in its SAP Library structure

Use

This section describes SAP software upgrades. An upgrade updates an existing SAP system to a new release. The upgrade contains program code and data changes or introduces new areas of functionality. New SAP Releases are issued periodically and are delivered as independent units that you must apply sequentially.

SAP is continually improving the upgrade procedure to reduce downtime. For example, we reduced downtime by around 30 to 40% upgrading to 4.6C compared to upgrading to 4.6B. This was achieved by parallel execution of key processing steps. Depending on the upgrade strategy used, the new upgrade procedure for upgrades to SAP Web Application Server Release 6.10 and higher will reduce downtime considerably by moving certain execution steps from downtime to uptime.

SAP Downtime Assessment Service

To help you optimize downtime, we offer the SAP Downtime Assessment service, in which SAP experts analyze your upgrade project from the perspectives of runtime and downtime.

To help with the technical upgrade strategy for your production system upgrade, we offer you tailor-made optimization measures and recommendations. For more information on the SAP Downtime Assessment service, see SAP Service Marketplace at:

service.sap.com/upgradeservices

If you are upgrading to SAP R/3 4.6C or SAP R/3 Enterprise 4.70, we might recommend you to use SAP Customer-Based Upgrade in order to meet your individual requirements for system availability. The SAP experts discuss this recommendation and its consequences with you and, if agreed, initiate all necessary follow-up steps.

Integration

SAP administrators must normally deal not only with new releases of SAP software but also with upgrades to the operating system (OS) and database management system (DBMS). However, OS and DBMS upgrades are not discussed here.

An upgrade has to take into account the data in the customer system and other dependencies on external resources. A full upgrade consists of the following sections:

        Operating system upgrade

        Database upgrade

        SAP system upgrade

The interaction of these areas makes upgrading an SAP system a complex task.

Recommendation

We recommend you to upgrade the SAP system separately from database, operating system or application software upgrades. You can use SAP Downward-Compatible Kernel to achieve this.

Prerequisites

SAP aims to reduce the downtime during an upgrade, which depends on the:

        Hardware you are using – this is the most important factor

        Release from which you are upgrading and the release to which you are upgrading

        Database type and size

        Applications used

        Upgrade strategy

        Productive applications

        Number of clients

        Installed languages

        Modifications

        Number of support packages included

You can now perform preparations – using the PREPARE program – and post-installation activities while the SAP system is online, so reducing downtime.

Features

All upgrades to SAP Web AS 6.10 and higher now use the System Switch method, which greatly reduces downtime compared to previous methods.

Caution

For more information on upgrade strategies, you must read the current SAP upgrade documentation before performing an upgrade. For more information see SAP Service Marketplace at:

service.sap.com/upgrade

The following summarizes the upgrade strategies:

        Downtime-minimized

Shadow system and production system can run in parallel. Certain actions can be performed during uptime which reduces downtime considerably.

        Resource-minimized

Operation of production and shadow system is only possible independently of each other. Production operation stops before the import of the substitution set into the shadow tables or, at the latest, before the shadow instance is started for first time.

Comparison of Upgrade Strategies for System Switch

This graphic is explained in the accompanying text

Note

On DB2 UDB for OS/390 and z/OS, database actions occurring during the upgrade are saved by database mechanisms. Therefore, logging is always on regardless of the upgrade strategy. This lets you recover the database to the current status during the entire upgrade.

Therefore, for DB2 UDB for OS/390 and z/OS, the upgrade strategy influences downtime but has no effect on database logging.

Starting with the upgrade to 4.6B, the application instance can run on OS/390, so that the overhead of network transmission is reduced. For more information, see the OS/390 upgrade documentation.

Processing Sequence with Upgrade Strategies for System Switch

This graphic is explained in the accompanying text

Activities

We recommend the following measures to reduce downtime during an upgrade:

        Start upgrade preparations early

        Identify modifications early (PREPARE)

        Plan modification adjustment

        Use the Modification Assistant

        Choose the right upgrade strategy

        Use the Upgrade Assistant

        Use enhanced PREPARE

        Use incremental table conversion (ICNV)

These measures are explained in more detail below:

Recommendation

Rehearse the upgrade in an appropriate test system

Whichever upgrade you are performing, the best recommendation of all is to rehearse it using a test system, that is, either a copy of your production system or a separately created and maintained development system with a representative set of application data. The test system should preferably have the same release and extent of modifications as the production system. This also gives you the advantage outlined in the next recommendation.

Recommendation

Automatic incorporation of customizations from test system

Customers with test systems that can be used to stage upgrades prior to upgrading the production system have the benefit that all customizations performed on the test system can be automatically imported into the production system.

Recommendation

Plan the upgrade carefully

Whichever upgrade you are performing, take the time to plan it carefully. This can be a laborious process but it helps to anticipate problems and avoid unplanned downtime. A full rehearsal with a system copy of the production system generates a detailed upgrade script, containing each single step as well as a timeline. This helps you to monitor your production system upgrade process and check whether it is still within the schedule.

Recommendation

Use the PREPAREprogram before the upgrade

From Release 4.0, you can prepare for the upgrade using the PREPARE program while the SAP system is online, so reducing downtime. If necessary, you can use some of the PREPARE modules several times.

By using all PREPARE modules, including the optional ones, you can get precise information to help you with the modification adjustment using the transactions SPDD and SPAU. Also, PREPARE provides information to help you reduce the number of conversion errors due to lack of disk space during an upgrade.

Recommendation

Accept automatic modification adjustment for SAP objects in your live system

When you upgrade your live or quality assurance system, you can accept modification adjustments that have been made in your development system (assuming the development system is equivalent to your live or quality assurance system) and that are available as a modification adjustment transport request. This avoids the manual effort of performing this process with transactions SPDD and SPAU.

Recommendation

Use downtime-minimized strategy for shortest possible downtime

This strategy offers the best way to minimize downtime if you are upgrading to SAP Web Application Server Release 6.20 and higher.

Recommendation

Create a database backup after upgrade

Always create a complete backup immediately after a successful upgrade if transaction logging has been turned off during the upgrade.

Otherwise – that is, if transaction logging has not been turned off – an online backup is acceptable after an upgrade.

Recommendation

Set import destination time

You have the option of setting an import destination time at the beginning of the upgrade if you are using the downtime-minimzed strategy. This enables you to optimize the extra system load due to the upgrade by “stretching” the import time for the new repository.

Recommendation

Increase number of parallel background processes for import

On multi-processor machines with sufficient main storage, you can reduce downtime by specifying up to four import processes to run in parallel.

Recommendation

Monitor the upgrade continuously

From Release 4.0, you can remotely (therefore, continuously) monitor the upgrade using the Upgrade Assistant. This allows you to avoid unnecessary downtime because you can react immediately if the upgrade program stops for any reason.

Recommendation

Consider using striped disks

Using striped disks can reduce the bottleneck problem caused by multiple importers competing for I/O resources. Note that this is a general approach to solving I/O bottleneck problems and is not specific to the SAP system.

For more information about striped disks in the context of redundant arrays of independent disks (RAID), see Disk Technology.

Recommendation

Consider using incremental table conversion

You can reduce downtime during the upgrade by performing table conversions incrementally, that is, during production operation and before you start the upgrade. For more information, see SAP Incremental Table Conversion.

Recommendation

Choose host names correctly if you use switchover software

If you use switchover software, see SAP Note 96317, which describes problems with host names.

 

See also:

Upgrade with Oracle

Upgrade with Informix

Upgrade with MaxDB

Upgrade with DB2 UDB for UNIX and Windows

Upgrade with DB2 UDB for OS/390

Upgrade documentation issued by SAP

End of Content Area