Assessing Update/Upgrade Process Downtime

LESSON OVERVIEW

This lesson covers the assessment of update/upgrade process downtime.

LESSON OBJECTIVES

After completing this lesson, you will be able to:

• Assess update/upgrade process downtime

Elements of Downtime

Uptime I p^rep^aration

Preparing the installation or installation

Figure 121: Technical Downtime

Business downtime

Technical Downtime Update process

running. Table switch, structural

changes, ...

• Types of adjustments during SAP maintenance:

, -,

Upti^me

Structural adjustment of tables/indexes (AL TERs and table conversions)

Import of new (table) content (INSERT /UPDATE/DELETE)

Semantic adjustments, for example, activation of SAP objects; adjustment of application data to new SAP version (for example, split of data, initialization of new tables or fields)

• Applications & table formats/contents are not fully compatible all the time during the SAP maintenance procedure.

• Downtime is needed to resolve the inconsistencies!

�

Unit 10: Downtime

What are the elements of production downtime?

• Installation technical runtime (SUM) ^-most of this is not production downtime!

• Post-installation transports & manual adjustments

• Business ^validation & acceptance testing

• Possibly pre- and post-installation system backups

• Business ramp-down & ramp-up

Figure 122: Production Downtime During Update/Upgrade

• Operations

down

• Begin and end of downtime is not only a 'click' but could be a complex process. For example, stopping the production line with all its implications.

• Both could take hours of time. So, this should be called 'ramp down' and 'ramp up' instead of just 'stop' and 'start'.

Possibilities to Reduce Downtime

go/no-go decision

down

Business

validation backup? Basis tests

go/no-go ^decision

Lesson: Assessing Update/Upgrade Process Downtime

Speeding up the delta transports and manual tasks

Speeding up business validation test (for example using tools like eCATT)

Hardware oftware onfiguration trategy

• Type & performance of • Start & target release • SUM parameterization • Usage of Incremental

the stora e Version of SUM Conversion (ICNV)

(110 throughput) Productive processes) Number and type of applications/ add-ons • Number of clients CPUs forthe or Industry solutions

appllcatlon & DB server

Type & performance of Start & target release SUM p�rameterization • Usage of Incremental the storage Number of Included (e.g. number of Conversion (ICNV) Number and type of SAP Support Packages processes)

Number of Number of Installed

application & DB server modifications on languages standard SAP objects

Version of SUM

• Productive

applications/ add-ons or Industry .solutions

Each SAP system is highly individual regarding its configuration and application data � runtime/downtime forecasts are only possible when analyzing results of a test installation with production data !

Figure 124: Influencing Factors for Runtime and Downtime

• Update/upgrade runtime: Total duration of the time controlled by SUM including preparation and uptime activities.

• Runtime and downtime depend on:

Hardware and operating system: The whole installation runtime depends on the hardware and operating system you use.

Hard disk configuration: Input/output throughput, backup speed Database: Size of tables, database configuration. parameter tuning Number of modifications: SPDD and activation time

Number of data structure conversions: Phase PARCONV _UPG; depends on start/target releases; bigger leaps mean more data conversions

Productive applications: More productive applications mean more data conversions Number of clients: Client cascade in phase TABIM_UPG

Number of installed languages: More data import

• A test update/upgrade on a production system mirror (sandbox system) and thorough

analysis of the installation log files can highlight many possibilities for effective manual tuning activities early in the project.

�

Unit 10: Downtime

Reduction of installation downtime

• Large tables are now converted during uptime

• Only switch to new structure d

u

ring downtime (in phase PARCONV_UPG)

Easy handling

• Fully integrated into updatefupgrade process

Configurable conversion process

• Exclusion ti^mes

• Progress prediction

fn<:f'emental convenion

dt ft1':. 1tl l cUU lo'lioltf•I"

P.:.O '•Mltl;I "'" C-tl't .

�

Figure 125: Transaction ICNV: Reduction of Downtime

Because most data is converted before the beginning of downtime, downtime can be reduced by several hours. The actual reduction depends on the table size. The dependence of downtime on the database size is also strongly reduced. The downtime can be predicted more accurately.

Business uptime Business uptime

�

utilization &

configuration

hne I

Reaction time on

Downtr"me ^of

dialog steps modification$

dependi 'lJ on ? ^{Number of}

Number of

\

selected

in$ta11ed

languages usages

& SPs

Key take aways

Number of applications/

clients �^dd^·ons or industry s.oluttons

As each SAP system is hi9hly individual regarding it's configuration and application data.

• A forecast of runtime and downtime is only possible when analyzing results of an test run with representative set of data!

Lesson: Assessing Update/Upgrade Process Downtime

Decoupled OS, DB and SAP Upgrade

New SAP version may require

• new database version

• ne.v operating system version

The start release of SAP software runs on

DB OS

• target release DB and

• target release OS

Destination release configuration

Start rel ease configuration

SAP DB OS

System downtime

Recommendation: split into different maintenance slots!

Figure 127: Decoupling of OS, DB, and SAP Upgrade

• SAP usually also releases 'older' SAP releases on DB and OS versions higher than those used initially

• This enables customers to run an SAP release on the latest DB and OS versions if required.

Thus the maintenance periods of SAP releases can be enlarged.

• During the update/upgrade of an SAP I DB I OS combination this feature may be used to split up the system downtime (e.g. into two different weekends):

Firstly, do the upgrade of DB and OS to the version required by the target release of SAP system.

Secondly, update/upgrade SAP system to target release.

�

Unit 10: ^Downtime

SUM Configuration

Initialization Extraction Configuration Checks Preprocessing Execution Postprocesslng Finalization

Cl>

-0 Standard/Advanced, archiving on

Figure 128: SUM Configuration

Database Size

Downtime

• No direct relation between DB size and update/upgrade downtime

Scatter plot downtime vs. DB-Size

• Some tables that undergo structural changes may have to be converted and therefore affect the downtime

Update/Upgrade:

Q) E

� c:

c �

Archive and delete only selectively Unicode conversion:

._. ..

Archive and delete as much as possible

Figure 129: Database Size and Update/Upgrade Downtime

•

Lesson: Assessing Update/Upgrade Process Downtime

Structural changes of the table or index such as changed field length and altered index will lock the table and can only take place during downtime. The fewer records are contained in that table, the faster the operation can be performed.

Functional and design changes require an update of the table content.

• Note: Besides reducing the table content. other technical tuning options such as

parallelization of the index creation should be investigated because they may be easier to implement than archiving or deletion.

• Will new fields added to an existing table cause downtime? No, only in the case of these exceptions:

iSeries (AS/ 400): To change the table structure all records of the previous table have to be copied and transferred to the new table structure.

All DB systems: In some cases the new fields are initialized with a default value. This value has to be updated in every record of the table and will therefore require downtime.

• How to determine which tables may increase upgrade downtime? The most precise way is to do a test upgrade and evaluate the upgrade log, especially the parts: DD Ls, conversions and XPRAs.

LESSON SUMMARY

You should now be able to:

• Assess update/upgrade process downtime

�

Unit 10 Lesson 3

Identifying Near Zero Downtime Maintenance (nZDM) Capabilities of SUM

LESSON OVERVIEW

This lesson covers the near zero downtime maintenance (nZDM) capabilities of SUM.

LESSON OBJECTIVES

After completing this lesson, you will be able to:

• Identify Near Zero Downtime Maintenance (nZDM) capabilities of SUM

nZDM capabilities of SUM

Significant downtime reduction when using the nZDM capabilities of Software Update Manager for the Business Suite 7i2011

System Details:

• OS/DB: AJX/Oracle

• OB size: 1,7 TB

• System clone from a customer Source:

SAP ECC 6.0 Target:

SAP ECC6.06 Technical Usages:

Sll�.1withoot nZDM feature

Central Applications 11Cl:OO 1):00 J4:00 :lb:()I) .t*.00 60:00

• Human Capital Management IS-Utilities

• Strategic Enterprise Management Generation of ABAP toads during uptime

hours

• tlpJinl<' a Oownl.irn•.� (T<1d 1 i• .(1

Sa.HE< TP ::r;,LMTOOL:-b10HWJ'\lTOT.>

Figure 130: TCO Lab Preview: nZDM for Update to SAP ECC 6 06

Lesson: Id entifying Near Zero Downtime Maintenance (nZDM) Capabilities of SUM

Current standard procedure:

Upllme .+ Business Downtime

I A't'°'iiDry *Wilch

--- --------.

'Downtime-Optimized' procedure using nZDM-capalllltles of SUM:

Uptune �usiness Downtime

Significant Reduction of Business Downtime

included in SUM 1.0 (depending on the target release enablement for nZDM capabilities).

Figure 131: SUM with Near Zero Downtime Maintenancen ZDM Capabilities

• Significant Reduction of Business Downtime compared to current standard update and upgrade tools

• Significant TCO-Reduction for standard software maintenance activities compared to customer-specific Downtime Minimization Service based on NZDT and other technologies

• Addresses AS ABAP based SAP systems

• SUM has been extended with nZDM-Capabilities:

• Introduction of capabilities for extended downtime optimization

• Introduction of 'Record & Replay' technique for business transactions

• Benefit: more relevant phases will be executed while SAP system is still available for users Selected, long-running After Import Methods

Mass-generation of enhancement objects, generation of enqueue objects

Main import (based on Record & Replay technique)

Table structure adjustment incl. conversions (based on Record & Replay technique) Allows binding of customer transports into uptime part of the procedure

Selected, long-running After Import Methods Mass-generation of enhancement objects, generation of enqueue objects Main import (based on Record & Replay technique) Table

structure adjustment incl. conversions (based on Record & Replay technique) Allows binding of customer transports into uptime part of the procedure

�

Unit 10: Downtime

SUM will allow to use the nZDM capabilities for the following standard software maintenance activities:

SAP Support Packages Updates Upgrades

Apply SPs to AS ABAP Update AS ABAP based Upgrade AS ABAP based

based SAP system SAP system SAP system

•Target release based on •Target release based on •With target release based SAP NetWeaver 7.02, SAP NetWeaver 7.02, on SAP NetWeaver 7.03 SPS 8 or higher SPS 8 or higher or higher

•Example -Apply SPS 7 for •Example - Update from •Example - Upgrade from SAP ECC 6.05 SAP ECC 6.04 to SAP SAP R/3 4.6C to SAP

ECC 6.06 ECC 6.06

Figure 132: nZDM Capabilities for SAP Business Suite Release and Platform Coverage

Procedure of the SUM nZDM Approach

Update/Upgrade/SPs

Figure 133: SUM nZDM Approach Procedure Overview

Shadow/Mirror

• System 1 (shadow or origin) - to be (partially) upgraded

Lesson: Identifying Near Zero Downtime Maintenaⁿce (nZDM) Capabilities of SUM

• Replay

Recording in "productive" system usually done with database triggers and logging tables Replay needs to consider complex SAP data formats ^- SAP Migration Workbench (MWB)

• Application

No/only limited changes to data format/content Keep applications and data compatible all the time Keep transactional and repository data separate XPRA/ Al M enablement for shadow

Installation preparation PIU>

ECCGOO HosiA

Shadow system creation

• STARTING the installation: an end^-^t^o-end tool based installation procedure addresses SPs, Updates and Upgrades.

• Installation of temporary shadow instance on same host. No additional hardware required to use nZDM featu^res.

Figure 134: SUM nZDM Approach Step by Step (1)

�

Unit 10: Downtime

temporary

nZDM: Copy to shadow

ter11poia1y

Based on the transport piece list of the target release all application tables subject to change are identified (=change tables).

All change tables are part of the record & replay technique and receive a trigger mechanism with logging tables to record all changes of production usage.

Change tables containing data are copied with R3trans based procedure into the shadow database.

Figure 135: SUM nZDM Approach Step by Step (2)

nZDM: Change Recording

tempomry

nZDM: Data replay

NOW the record mechanism is in place and active. All data changes (INSERTS, UPDATES, DELETES) to "change tables" are recorded into special logging tables.

• Meanwhile the technical installation is ongoing with regular installation steps.

Final step before accessing the downtime is the replay mechanism: all data recorded into logging tables are transferred to the shadow system. This data replay ensures a synchronized status of all change tables. A newly designed cockpit allows to monitor

and control this process. _,

Figure 136: SUM nZDM Approach Step by Step (3)

Lesson: Identifying Near Zero Downtime Maintenance (nZDM) Capabilities of SUM

tempo-rary

I

^{___ -}

---ECC607

• Once the data replay has reached app. 90% or more the installation can proceed with the technical downtime step.

• First all remaining data are copied to the shadow tables. Now the tables are synchronized. Tab.les of the original system are replaced by the shadow system tables (system switch procedure). Further technical activities are executed (kernel switch, XPRAS, ... ) as part of the downtime.

• Cleaning up temporary shadow system and logging tables are final technical

activities. Now all customer related tasks (e.g. validation of system) can be executed.

Figure 137: SUM nZDM Approach Step by Step (4)

Downtime Solutions

Use case Dellvery

Model

nZDM SAP NW Process Integration

nZDM for SAP NetWeaver Portal

wllhnZDM Capabllies (Business Suite)

Figure 138: Summary Downtime Solutions Solution Map

LESSON SUMMARY

You should now be able to:

• Identify Near Zero Downtime Maintenance (nZDM) capabilities of SUM

�

Unit 10

Lesson 4

In document Sap Adm328 en Col15 Nw 7.31 Part Nw (Page 151-164)