SAP Technical Upgrade is a periodic project that is implemented across companies to upgrade their SAP system to the latest released version. Most of the upgrade activities are done by the technical team and the role of functional consultants is limited and mostly confined to regression testing.
Reasons for SAP Technical Upgrade :
Since technology and businesses evolve, companies need to maintain a technological infrastructure that can support that change. This is the major reason why companies should undertake a technical upgrade of their SAP system. Of course there are many secondary reasons, the significant one being the fact that like all software vendors SAP supports a released version of its software only for a limited period.
We have already discussed about the SUM in previous blog, You can use below link for details
Software Update Manager (SUM) in SAP
Now we can go through the detailed phases included in SUM upgrade process.
SUM Having mainly 6 steps,
- Extraction
- Configuration
- Checks
- Preprocessing
- Execution
- Postprocessing
Below the very detailed briefing of each step involved in SUM process for ABAP system.
Step 1.Extraction
- DDIC username and password
- Identify database & SAP version
- Checks the stack xml file
- Scanning of download directory where all the patches are placed
- Extract files to move to EPS/in
- Check SPAM version. Skip this if SPAM is already in latest version
- <SID>ADM credentials
- Pre-upgrade S-note list implementation
- Checks if the source and target system is valid for update
- Checks SAP system release
- Checks the system profiles
Phase name | Brief details |
CHECK4NOTES_TOOL phase: | SUM asks to implement some necessary SAP Notes |
CHECKPROF_INI phase: | SUM checks the system profiles for problems |
CHECKSYSSTATUS phase: | SUM reads the profiles and checks the state of the running instances |
CONFCHK_IMP phase: | In this phase SUM checks the Operating System and Database Version |
DBCHK_PRE phase: | SUM Determines database version and SAP release |
DBCONNCHK_INI phase: | SUM tests if new tools can connect to the database |
DBQUERY_PRE phase: | SUM checks the database state and asks database dependent questions |
DETMAINMODE phase: | SUM checks the stack xml file and decides about the main program mode |
EXTRACTKRN_PRE phase: | SUM tests a kernel DVD to install SUM in /usr/sap/<dir>/SUM/abap/exe |
INITPUT_PRE phase: | SUM reads profiles and initializes knowledge about the system |
INSTANCELIST_PRE phase: | SUM will gather information about the instances of the system |
JOB_RSUPDTEC phase: | In this phase a batch job RSUPDTEC will be started. This job resolves inconsistencies in TABART-TABSPACE mapping. Log files: PSUPDTEC.LOG PSUPDTEC.ELG |
KX_CPYORG phase: | SUM Copies the original kernel to $(PUTPATH)/exe |
PROFREAD phase: | SUM reads the profiles and prompts for required passwords |
READCVERS_DUMP phase: | SUM reads the CVERS table content |
READDATA_EXP phase: | SUM tests a kernel DVD to install SUM in /usr/sap/<dir>/SUM/abap/exe |
SCAN_DOWNLOADDIR phase: | SUM scans the download directory and extracts the packages |
TOOLCHECKXML_INI phase: | SUM determines and checks the tool versions in SYS (the active SAP kernel directory) |
TOOLIMPD phase: | SUM prepares the ABAP dictionary for importing upgrade tools on the standard instance |
TOOLVERSXML_UNI phase: | SUM checks the tool versions if the system is UNICODE |
VALCHK_INI phase: | SUM checks if the source and target system is valid for update |
VERSCHK_INI phase: | SUM checks if the SAP system release |
Step 2. Configuration
- Input parameters for type of upgrade (downtime optimizes, higher complexity, high resource assignment)
- Keep database archiving on
- Execution strategy for transaction SGEN
- Maximum number of processes to be used for load generation. SGEN Processes
- Batch Process(Uptime) & Batch Process(Downtime)
- Maximum number of DDL processes (Uptime and Downtime)
- Number of parallel import processes (R3trans -Uptime and Downtime)
- Parallel Phases (Uptime and downtime)
- Update Instances
- Enhancement package inclusion
- Add-On selection
- Modification Adjustment (SPDD transport request and SPAU transport request)
Phase name | Brief details |
ADDON_QCALC phase: | SUM calculates the queue for selected add-ons |
ADJUSTPRP phase: | This phase prepares adjustment calculation: Imports command file flagged in other system, if necessary |
EHP_INCLUSION phase: | SUM calculates the Enhancement Package (EHP) included into the stack xml file |
INITSUBST phase: | In this phase you can configure the SUM tool parameters which influence the update runtime and resource requirements |
IS_SELECT phase: | During the IS_SELECT phase, you will have to decide how the installed and delivered add-ons are to treated during the upgrade |
LANG_SELECT phase: | Language handling during the Upgrade |
LIST_LOAD phase: | SUM retrieves information regarding the tables in the database |
SHDINST_DB_PREP phase: | SUM checks database-specific settings |
SHDINST_OS phase: | SUM Performs operating system-specific actions |
Step 3. Checks
- Space check in database, if space is Insufficient then extend tablespaces with script
- BW checks and phases
- Activation and conversion checks
- Modification support
- Preliminary upgrade processing
- List Locked SAP objects
Phase name | Brief details |
ACTREF_CHK phase: | This phase checks whether activation errors might occur during the installation. Log file: <SUM_DIR>/log/ SAPupConsole.log |
BATCHCHK_GEN phase: | SUM tests whether background server can access the upgrade directory |
CHECK4NOTES_PACKAGES phase: | SUM asks to implement some necessary SAP Notes |
CHECKS Roadmap Step: | In this roadmap step SUM executes various checks: database, kernel, os, space calculation, leftovers from conversions, older upgrades, etc |
ENVFILES_CHECK phase: | This phase checks environments of <sid>adm and whether profiles of user <sapsid>adm can be modified |
FREECHK phase: | This phase checks free space in the file system |
JOB_RSAUCHK_DUP phase: | This phase checks for double F rules in the table RSUPDINFO |
JOB_RSUPGRCHECK_PRE phase: | This phase checks consistency of generated repository |
LIST_LOAD_SPC phase: | In this phase SUM retrieves information regarding the tables in the database |
RUN_CHECK_SLT_TRIGGER_PRE phase: | SUM will check the switch tables for existing triggers |
SPACECHK_INI or SPACECHK_OPT phase: | checks the database free space |
Syntax errors in CHECKS Roadmap Step: | After SUM reaches the CHECKS Roadmap Step,(Step 5.1) Running some transactions, such as BP produces to check syntax error. |
TABSPC_PREP phase: | calculates which tables are part of import into old tables |
TR_GET_SPCREQ_ADD phase: | calculates the amount of data in add-on and language requests |
TR_GET_SPCREQ_IMP phase: | calculates the amount of data from the upgrade requests |
Step 4. Preprocessing
- Check for locked objects
- ABAP Workbench locking
- Run shadow system for preparation of new release (ACT_UPG, PARDIST, SGEN)
- SPDD Adjustments
- Downtime Starts
Phase name | Brief details |
ACT_UPG phase and SPDD: | In ACT_UPG phase, you are asked to perform modification adjustment for dictionary objects using transaction SPDD in shadow instance firstly before ACT_UPG starts. If you do not perform modification adjustment using SPDD before ACT_UPG starts, all modification on dictionary objects will be overwritten by sap standard version of the target release. If you have performed SPDD adjustment in DEV system, you can include the SPDD adjustment request which was generated in development system into the update in the QAS/PRD systems. Then it will be no necessary for you to perform adjustment in SPDD again in QAS/PRD system, which will greatly save the whole upgrade time. Please make sure that all the dictionary objects in SPDD in shadow instance are correctly adjusted. Otherwise, it will lead to activation errors in later SACT_UPG's running. As SPDD adjustment is performed in shadow instance during uptime phase, please make sure NOT to activate your change in shadow instance. What you should do is to save your change in the inactive (modif. version) version of the dictionary objects, and release the relevant task(s) in the SPDD adjustment request. Please do not try to release the SPDD adjustment request. The upgrade tool (SUM) will release the SPDD adjustment request in the later phase. From SAP_BASIS release 750, the new version of SPDD was released. You can still use the old version with transaction SPDD_OLD |
BATCHCHK phase: | SUM tests whether background server can access the upgrade directory To do this, the background job RDDIT008 is started on the specified background server. This job writes a test log in subdirectory tmp of the abap subdirectory of the update directory |
BIND_PATCH phase | In rare cases, you might have to include support packages of certain software components, such as HR packages, because these packages have a shorter release cycle than the complete support package stack. For these cases, in the phase BIND_PATCH, you have the option to add the additional support packages to those that have already been included in the SELSTACKXML phase. If you answer Yes to the prompt about including support packages, SUM displays a list of support packages in which you can select those that you want to include into the update. |
DBCLONE phase: | In this phase the target system (shadow system) will be copied from the current system. the Software Update Manager starts a number of background jobs to create copies of the tables required for operating the shadow system. Depending on your system and your hardware, this operation can take several hours. These background jobs are executed on the background server that is configured with the BATCH HOST parameter. The number of jobs is determined by the parameter MAX BATCH PROCESSES. It cannot be higher than nine or the number of background processes configured on the background server. Each table is copied with a single INSERT statement. Therefore, the administrator has to take care that the undo-logs can grow accordingly. |
DOWNCONF_DTTRANS phase: | SUM executes checks and asks all the questions necessary for entering the downtime |
EU_CLONE_CRE_SHDVIEWS phase: | In this phase SUM Creates views on Shadow |
EU_CLONE_MIG_UT_RUN phase: | In this phase Entries of *UT* group tables are exported from shadow repo and imported to HANA in parallel. R3load pairs are doing the export and import. The first R3 load (part of the shadow kernel) is exporting the data, the second R3load (part of the target kernel) is importing the data into SAP HANA DB. |
EU_IMPORT1 or EU_IMPORT2 phases: | In this phase (parallel) R3load processes will be started to import data from DVDs to the database. If you chose the preconfiguration mode single system, these phases run during downtime. Log file: SAPup.log <update directory>/log/EU_IMP1.ELG/EU_IMNDB.* |
ICNVINIT phase: | SUM checks the volumes of the ICNV candidates and initializes successful candidates |
ICNVREQ phase: | SUM prompts you to start transaction ICNV if there are candidates for the ICNV,but ICNV has not yet been started |
JOB_RSVBCHCK2 phase: | If there are any outstanding or incomplete updates, the update stops in phases JOB_RSVBCHCK2 (in Preprocessing roadmap) or in JOB_RSVBCHCK_D (Execution roadmap) with a message |
PARDIST_SHD phase: | SUM starts the distributor on the shadow instance in parallel jobs |
PARMVNT_SHD phase: | SUM activates nametab entries |
REPACHK_CLONE phase: | This step is relevant if you perform an enhancement package installation or an SPS update. If you have chosen preconfiguration mode standard or advanced, the Software Update Manager asked you in this phase to confirm the locking of the ABAP Workbench on all SAP instances. In contrast to the release upgrade, the Software Update Manager requires the lock in this phase only. This lock prevents development objects (for example, ABAP reports, table definitions, and so on) from being changed during the update since these modifications would be lost. You can continue to use your SAP system in production operation, even if you confirm that the ABAP Workbench can be locked. However, after you have confirmed the ABAP Workbench lock, no more transports can be made into or out of the SAP system. Some further actions might be blocked that either check for this lock as well or for the running update. This is especially known in the area of Business Intelligence and SAP Solution Manager. |
REPACHK2 phase: | This phase is relevant in release upgrades. This phase displays all the repairs that are still in open transport requests. They are also written to the REPACHK2.LOG file. Release these transport requests so that you can continue; otherwise, the objects contained in these repairs are locked. Note SUM checks in this phase also for inactive development objects. Before you continue, you have to release and confirm all the open repairs; otherwise, the objects in them are locked. |
RUN_CHECK_SLT_TRIGGER_DTTRANS phase: | SUM will check before downtime the switch tables for existing triggers |
RUN_FDC_STRUCT_ANALYZER: | SUM analyses structure changes to prepare Fast Data Copy |
RUN_FDC4UPG_PREPROC phase: | After SUM analyses structure changes to prepare Fast Data Copy, it will read server list & starts tasks in parallel processing using batch processes |
RUN_FDCT_TRANSFER phase: | This phase is executed by SUM in FDC scenario. ast Data Copy (FDC) is a table copy procedure that makes use of (partly database-specific) optimizations to get maximum copy performance. In SUM with the nZDM option switched on it is used to reduce the time needed for copying tables into the shadow. |
RUN_RDDIT006 phase: | In this phase SUM runs report RDDIT006 The report determines deviations of the current system from the future standard SAP system (objects and modifications that need to be copied) |
RUN_RSDROPCDSBAS phase: | SUM deletes CDS views |
RUN_RSGEN phase: | A background job called RSPARAGENER8M will be executed in the system during the SGEN phase. It will generate ABAP load on shadow instance in the update phase called SUBMOD_SHD2_RUN/RUN_RSGEN |
RUN_RSPTBFIL_TRINIT phase: | SUM runs report RSPTBFIL to generate trigger names and to create transports |
RUN_RSUMOD10_SPAU_SHD phase: | In this phase SUM runs report RSUMOD10 for SPAU preparation on the shadow instance |
SCEXEC_ALIAS phase: | SUM Creates aliases/views/synonyms |
SCEXEC_GRANT phase: | SUM Creates grants on shadow tables |
SHADOW_IMPORT_INC phase: | The shadow import phases are run during the shadow instance. On these phases, data is imported on the shadow tables and on new tables. The shadow import is a feature aimed to reduce the application downtime caused by the import of the Support Packages. The idea behind this feature is to import, activate and convert all objects belonging to the Support Packages into a shadow repository, and at the end of all phases, switch to the new coding. The import of these packages is performed via the transport tools tp and R3trans. |
SHADOW_IMPORT* phases: | data is imported on the shadow tables and on new tables |
SHDUNINST_DB phase: | SUM deletes the shadow schema DB user |
SPDD in upgrade: | Here system compares all the dictionary objects – data elements, database tables and structures of the latest system (say ECC 6. EPH8) with the previous or the old system (e.g ECC EHP7). |
START_SHDI_FIRST phase: | SUM starts the shadow instance the first time |
START_SHDI_PREPUT phase: | SUM starts the shadow instance the first time |
START_SHDI_SHD2 phase: | In this phase SUM starts the shadow instance the second time to execute further actions as replicating changes or running the SGEN on shadow instance. |
STOP_SHDI_RES phase: | SUM stops the shadow instance if the SUM reset was selected |
TABIM_POST_SHD phase: | During the TABIM (table import) phase, additional data is loaded in tables that belong to the SAP name range. All SAP table classes S, W, E, C and G are affected by row insertions, modifications and deletions – except for class A, which is protected against row modifications, where only insertions are allowed. |
Step 5. Execution
- Merging of shadow and Real Instance
- system upgrade
- Table conversion
- Downtime Complete
Phase name | Brief details |
ACT_TRANS phase and SPDD: | REMARK: If you selected Downtime-Minimized Update strategy, the activation will be executed in the ACT_UPG phase |
EU_CLONE_MIG_DT_RUN phase: | SUM migrates data from the source database to the target HANA database |
JOB_RSVBCHCK_D phase: | If there are any outstanding or incomplete updates, the update stops in phases JOB_RSVBCHCK2 (in Preprocessing roadmap) or in JOB_RSVBCHCK_D (Execution roadmap) with a message. |
KX_SWITCH phase: | SUM installs the standard instance target release kernel |
MODPROF_TRANS or MODPROFP_UPG phase: | SUM will modify the system profiles for the upgrade |
MVNTAB_UPG phase: | SUM Converts application views and activates remaining nametab entries |
PARCONV_UPG or PARCONV_UPG_DS or PARCONV_TRANS phase | In this phase, the application tables are adjusted to the structure of the target release. Here, several conversion program processes (in the SAP system) and tp processes run simultaneously. |
PARDISTPRE_TRANS phase: | This phase is executed by SUM if Resource-Minimized Update strategy – Single system preconfiguration mode was selected. SUM starts the distributor in parallel jobs. |
PARMVNT_TRANS phase: | In this phase SUM activates nametab entries |
PARMVNT_XCNV phase: | In this phase SUM activates nametab entries for external conversions |
RUN_CRR_LAST phase: | SUM is performing final data transfer of change recording framework. |
RUN_RENAME_KONV_AVOID_CONVERS phase: | In this phase SUM executes steps to avoid conversion of table “KONV” |
RUN_RUTCNVFUNCCRE phase: | SUM runs job RUTCNVFUNCCRE which creates necessary DB-functions for DDIC SQL-views |
RUN_RUTDDLSCREATE phase: | SUM runs job RUTDDLSCREATE which creates CDS Views after the migration |
RUN_SYSTEM_SHUTDOWN phase: | SUM runs BW related checks before entering to downtime, SPDD in upgrade if Single system mode was selected:: |
SQLRUNTASK_DROP_CDSBASVIEWS phase: | Drop CDS-views on switch tables |
START_SHDI_SHD3 phase: | SUM starts the shadow sytem (3rd) |
STARTSAP_NBAS phase: | SUM starts the standard instance after kernel switch with the target kernel |
STARTSAP_PUPG or STARTSAP_TBUPG phase: | SUM starts the standard instance for postprocessing |
STARTSAP_TRANS phase: | SUM starts the standard instance before kernel switch with the source release kernel |
TABIM_POST_CLONE phase: | During the TABIM (table import) phase, additional data is loaded in tables that belong to the SAP name range. All SAP table classes S, W, E, C and G are affected by row insertions, modifications and deletions - except for class A, which is protected against row modifications, where only insertions are allowed. |
TABIM_POST_UPG phase: | During the TABIM (table import) phase, additional data is loaded in tables that belong to the SAP name range. All SAP table classes S, W, E, C and G are affected by row insertions, modifications and deletions – except for class A, which is protected against row modifications, where only insertions are allowed. |
TABIM_TRANS phase: | TABIM_TRANS phase is executed if the Single system.preconfiguration mode was selected |
TABIM_UPG phase: | During the TABIM (table import) phase, additional data is loaded in tables that belong to the SAP name range. All SAP table classes S, W, E, C and G are affected by row insertions, modifications and deletions – except for class A, which is protected against row modifications, where only insertions are allowed. The TABIM phase is run through tp and R3trans. Additionally the RDDGEN0L job will be started ( table conversion, etc. ) |
XPRAS_TRANS XPRAS_UPG and XPRAS_AIMMRG phases: | XPRA or “Report after Put” is an ABAP program or Function Module that is executed during a transport request import sequence, the import of a Support Package and during Upgrades/Enhancement Package installations. The reports that are executed during XPRA are application-related conversions, adjustments, data mergers or alignments for the conversion of release-specific SAP-shipped customizing that need to be adjusted during the upgrade. The runtime of the XPRA phase differs from one application component to another – however XPRAs are used by all SAP modules and applications. The XPRA phase reports are run as one of the last steps of the upgrade. However, due to the fact that table content is adjusted, the XPRA phase needs to be done at application downtime. XPRA can also run as part of the activation of extension sets and IS add-ons. All XPRAs are executed by a system job, named RDDEXECL |
Step 6. Post-processing
- SPAU change
- Backup
- Create folder in trans directory (EHPi)
Phase name | Brief details |
RUN_RSREGENLOD phase: | The transaction SGEN Generate ABAP loads on shadow system during uptime and automatically starts again asynchronously after the downtime during the Post processing Configuration road map step to regenerate the ABAP loads that were invalidated during the downtime in the phase MAIN_POSTP/RUN_RSREGENLOD |
RUN_RSUPG_ISU_CRR_CLEAN phase: | SUM runs cleanup of change recording framework |
TOOLIMP_DELETE_ZDM_CRR phase: | SUM deletes ZDM, CRR and internal tools |
To know the exact downtime taken for this upgrade, Please find UPGANA.XML file for detailed information from the below mentioned path:
Location of the file as below
./SUM/abap/htdoc/UPGANA.XML for SUM 1.0
../SUM/abap/doc/analysis/UPGANA.XML for SUM 2.0
For more details you can refer SAP Note 2517492
Troubleshooting
Logs overview:
Main log file of TABIM_POST_CLONE: TABUPOSTCLONE.ELG ,
Logfile of conversion step: N<YYMMDD>.<SID>
Joblog of RDDGEN0L in SM37
References:
https://wiki.scn.sap.com/wiki/display/SL/TABIM_POST_CLONE+phase
https://wiki.scn.sap.com/wiki/display/SL/SUM+for+ABAP+-+Troubleshooting+Guide
- SAP Managed Tags:
| User | Count |
|---|---|
| 5 | |
| 5 | |
| 5 | |
| 4 | |
| 4 | |
| 4 | |
| 4 | |
| 4 | |
| 3 | |
| 3 |
