SUM directory file system size approximate values in EHP upgrades

SUM directory file system size

SUM Directory - 30 -> 50GB (depends on how many SPs you downloading & upgrading)

Download Directory - 20 -> 40GB (depends on how many SPs you downloading)

DIR_TRANS - 30 -> 50GB

Database free space - approximate 20 -> 40% of your current Database size. Again, this is highly depends on how many level of Software Component s you are deploying. Large space is needed to build and store shadow repository in your current database. However, there's  < 10% increase of your current DB size after upgrade as the old DDIC, nametab, and etc will be deleted and replaced.

*SUM will alert if insufficient DB free space at the end of "Check" phase. For Oracle, you need to create tablespace PSAPSR370X manually.

Take my recent upgrade for example:

DB size before upgrade -> 348GB

DB size after shadow repository created (end of "Pre-Processing") -> 420GB

DB size after upgraded to EHP5 (downtime completed, before SGEN) -> 350GB (sometimes you'll notice your DB size is slightly smaller or same with size before upgrade due to the DB-Platform specific compression feature, eg: MSSQL 2008, Oracle 11g, DB6)

Different SAP upgrade tools

Different SAP upgrade tools

As there are differences in SAP technology components along with evolution of SAP software there are also different SAP upgrade tools. Let me share short overview of them within this post.

      1. SAPUp: Are standard SAP upgrade tools coming in two flavors:    

     a.     For ABAP Stack – SAPup

     b.   For JAVA Stack - SAPJup

          It consists of two programs:

         a.  Upgrade program – performing the upgrade

         b.    Control program - so called GUI to upgrade process (Upgrade GUI of SDT GUI)

Upgrade GUI is user interface where you can see the upgrade phases/progress via roadmap steps. With this tool you can perform Combined Upgrade (CU) and Unicode Conversion (UC) as well.

       2. SAP Enhancement Package Installer (SAP EhPi): Primarily used for Enhancement package (EhP) installations. EhP are aimed to enhance functionality of SAP Business Suite 7 and higher and SAP NetWeaver 7.0 and higher based systems. Used for systems based on both ABAP and JAVA Stacks. Moreover you can upgrade dual stack based system via synchronized procedures. You can also use SAPehpi for SAP Support Packages only.

SAP introduced its enhancement package strategy for SAP ERP as a means to simplify the way customers manage and deploy new software functionality. Customers can electively implement these software innovations from SAP and activate the software upon business demand. As a result, customers can isolate the impact of software updates and bring new functionality online faster through shortened testing cycles.
Learn here more about the enhancement package concept which is the first of its kind in the industry, offering customers greater long-term value and an easier methodology for managing software innovations.
 

 When is the best time to install an enhancement package?

SAP strongly recommends installing the enhancement package for SAP ERP when performing a regular SP stack implementation. The installation of enhancement packages and the application of the SP stack should be done together in one queue in the SAP add-on installation tool (known as transaction SAINT) or the SAP enhancement package installer. This reduces the downtime and manual effort for the whole installation procedure. In addition, you can leverage synergies concerning modification adjustment as well as regression testing for all software components at that time. 

Note: Effectively as of 21.4.2011 SAPehpi 7.10 is replaced by Software Update Manager (SUM) see below.

3. Software Update Manager – SUM (Software Logistics Toolset) – Software logistics tool for different kinds of implementation processes.

The Software Update Manager 1.0 is the tool for system maintenance:

• Release upgrade (major release change)
• System update (EHP installation)
• applying Support Packages (SPs) / Support Package Stacks
• applying Java patches
• correction of installed software information

The term update is the generic term for all of these activities, and it is used in the SUM documentation as well.

SUM is used for all SAP Net Weaver based systems, so systems either based on AS ABAP, or AS Java, or based on a dual-stack system.

Successor of other tools

The Software Update Manager replaces tools for upgrade, update, and implementing SPs:

• SAPehpi: SAP Enhancement Package Installer
• SAPup: tool for upgrading ABAP-based systems
• SAPJup: tool for upgrading Java-based systems
• JSPM: Java Support Package Manager
• CEupdateManager: tool for updating Composition Environment systems
• SolManUp: tool for updating and upgrading SAP Solution Manager systems
• SUM 1.0 SP10 is available since March 2013

  

     4. SPAM / SAINT / JSPM: tools to be used for installation and upgrade of add-ons, Support Packages, subsequent installation of additional technical usages of EhPs. Coming again in two flavors:    

a.    For ABAP Stack – SAINT and SPAM

b.    For JAVA Stack - JSPM 

SPAM and SAINT are hosted directly by ABAP AS and therefore are platform in depended.

SPAM: Support Package Manager.

If you are upgrading the patches of your existing components to the latest or to your required patch level, we will do it by using SPAM.

Ex: SAP_BASIS is on pl 9 .for upgrading this to latest(pl 13 or 14)

We will do this from SPAM.

SAINT: Add-On Installation Tool

If you want to install a new component in your system, which is not there in the system we will do this by SAINT.

For ex: ST-PI is not existing in your system want to install then u need to install the add-on for that component by SAINT.

After the installation you have to patch this to latest by using SPAM.

If you want to upgrade the release of the component we have to perform this by using SAINT.

Ex: PI_BASIS is on 2003_1_640 if u want upgrade this to 2004_1_640 then u need to perform this by using SAINT

       5. Application Specific Upgrade (ASU) – Tool hosted by ABAP Stack to collect all before / after upgrade activities, tasks etc.

Speaking of not only tools but even about upgrade methodology there is an initiative within SAP started: Near Zero Downtime for ERP. The purpose is to reduce downtime of ERP system while upgrade. It uses technologies like synchronizing of software changes between system and its copies – delta reply (workbench from System Landscape Optimization (SLO)).

ICNV Table conversion During Upgrades

ICNV Table conversion During Upgrades

ICNV is a configurable process that can be can be stopped and restarted. It allows for the conversion of large tables during system uptime. It is recommended that you execute ICNV as early as possible. This requires more careful planning. ICNV is only available if you are using the downtime-minimized upgrade strategy (High resource use).

SAP upgrades invariably lead to changes in the structure of database tables. Sometimes, this means that a complete restructure is necessary, with the conversion of each row in the table. In previous SAP Releases, this conversion occurred during upgrade downtime, so increasing that downtime. Incremental table conversion with transaction ICNV now lets you perform conversions before the upgrade, that is, during production operation.

The benefits of incremental table conversion are:

·        Reduced downtime during upgrade

·        Simpler conversion back to SAP standard for modified tables

·        Conversion of large tables during production operation

Execution

If you have tables that might benefit from incremental conversion, then the system asks you in phase ICNVREQ to start transaction ICNV, leading to the following:

The system asks you:

1.     Which modified tables you want to incrementally convert back to the standard SAP table definition    

2.     Which non-modified tables you want to incrementally convert

SAP recommends that you:

·         Do not archive tables that are being incrementally converted. Instead, archive before the conversion.

·         Do not attempt to modify tables that are being incrementally converted. These tables are locked until the end of the upgrade, so updates (including transaction SE11) are not possible.

·         Observe the resource usage of the database so that you can spot bottlenecks early on. You might have problems because:

–         Extra space is required, as each converted table has to be replicated before conversion

–         Extra transactions are produced, leading to increased logging activity

·         Make sure that enough batch work processes are available, preferably one batch work process for each table to be converted. If you are converting a large number of tables, transactionICNV distributes the tables to the available batch work processes.

·         Only start the upgrade when at least 95% of tables have been converted. This means that you have the greatest possible advantage in reducing downtime. You can easily observe the progress of the conversion using transaction ICNV.

 Steps 

SAPup will prompt you to start ICNV during the Upgrade process 

Start the incremental conversion (Login with TCODE ICNV – Source environment) 

Monitor the progress

Monitor the ICNV process & the DB growth closely. ICNV requires additional resource usage of the database, as well as a sufficient number of background work processes. It is also recommended that you execute ICNV as early as possible. This requires more careful planning.

The system estimates the time taken for the conversion, so helping you to plan the start of the upgrade. Large tables are converted during uptime but the switch to the new structure is made only during downtime(PARCONV_UPG).