Introduction

This document provides a starting point for the planning of your migration procedure of SAP systems to SAP HANA in an on-premise landscape. Beginning with an overview of available migration path options, we provide a general recommendation and further aspects and guidance how to identify the best procedure for your requirements. Take these aspects into the discussion with your cross-functional teams and use them as basis for an individual assessment based on the boundary conditions you are facing.

Overview of Migration Path Options

ABAP-Based SAP Systems

For the migration of ABAP-based SAP systems to SAP HANA, several migration path options are offered:

1. In case you want to change your existing solution landscape in the course of a migration project, there are several transformation offerings from SAP Landscape Transformation, where you install a new system for the transformation, such as performing a step-wise or partly migration of an SAP system or the consolidation of several systems into one system running on SAP HANA.
2. The classical migration of SAP systems to SAP HANA (that is, the heterogeneous system copy using the classical migration tools software provisioning manager 1.0 and R3load) is using reliable and established procedures for exchanging the database of an existing system - it is constantly improved especially for the migration to SAP HANA.
3. To further smooth the way to SAP HANA, SAP is providing a one-step procedure that combines system update and database migration for the migration to SAP HANA. This is provided with the database migration option (DMO) of Software Update Manager (SUM).

The options are outlined in an overview video. Spend 15 minutes to get a quick-start to the available migration options to SAP HANA for SAP ABAP systems:

Slides used during this video are also available as separate SCN document here.

In addition, see the corresponding End-to-End Implementation Roadmap guides that also outline available migration path options.

Java-Based SAP Systems

For Java-based SAP systems, the classical migration is available, as outlined above.

How to Choose the Right Option for You?

1. See the Standard Recommendation from SAP

Use the following recommendations as starting point for an individual assessment - that is, take the recommendation and relevant aspects into the discussion with your cross-functional teams and use them as basis for an individual assessment based on the boundary conditions you are facing.

For ABAP-based SAP systems, the following recommendation applies:

• The general recommedation is to use the database migration option of SUM, as it has become our standard procedure for migrations to SAP HANA - with it, you can profit from a simplified migration to SAP HANA, performed by one tool, with minimized overall project cost and only one downtime window.
• As reasonable alternative to our standard recommendation, in case the database migration option of SUM does not fit your requirements, consider to use the classical migration procedure with software provisioning manager, which is also continuously improved especially for the migration to SAP HANA. Reasons might be that the database migration option of SUM does not support your source release or if you prefer a separation of concerns over a big bang approach as offered by DMO of SUM.
• As possible exception, there are further migration procedures for special use cases, such as the consolidation of SAP systems in the course of the migration project or the step-wise migration to SAP HANA, as oultined above.

For Java-based SAP systems, use the classical migration approach (and skip step 2 below).

2. Individually Assess Your Situation

Based on the standard recommendation from SAP, find the best option depending on your individual requirements and the boundary conditions you are facing. To support you in this process, SAP provides a decision matrix in the End-to-End Implementation Roadmap for SAP NetWeaver AS ABAP guide (SMP login required), which is intended to highlight important aspects for your decision on the right migration procedure, including these key considerations (see the guide for the lastest version of the matrix) - the matrix is also described in this blog:

• What is the release and Support Package level of your existing SAP system? Is an update mandatory or desired as part of the migration procedure?
• Is your existing SAP system already Unicode?
• Do you plan any landscape changes - such as changing the SAPSID of your SAP system or the hardware of your application server - as part of the migration or do you rather prefer an in-place migration?
• Do you plan the migration of your complete system or a partial migration?
• Are your operating system and your database versions supported according to the Product Availability Matrix (PAM) of the target release or are corresponding updates required?
• Do you expect a significant downtime due to a large database volume?

All these aspects are reflected in the matrix, which is intended as a starting point for your individual assessment as outlined above.

Further Aspects

In this blog, several relevant aspects for planning a migration project to SAP HANA are gathered - such as prerequisites, sizing, deployment options, custom code, test management, and project plans.

Motivation

If you want to migrate an existing SAP system (running on anyDB) to a SAP HANA database, required steps may be a dual-stack split, a unicode conversion, a database upgrade of anyDB, an upgrade of your SAP software, and a database migration to SAP HANA. The Software Update Manager (SUM) includes an option that combines the upgrade with the database migration "database migration option" (DMO) for SUM. It is sometimes referred to as the one-step migration procedure, compared to the classical migration (i.e. heterogenous system copy,  using Software Provisioning Manager).

The DMO is an inplace-migration (instead of a new installation): it upgrades and migrates the existing system while keeping the system-ID, host name, and connectivity settings stable.

DMO for SAP NetWeaver BW and for SAP Business Suite systems

DMO is available with Software Update Manager 1.0 SP09 and higher, and can be used for systems based on AS ABAP. It can be used for SAP BW systems from 7.0 SP17 (and higher) to migrate to 7.31 (and higher). And it can be used for systems like SAP R/3 4.6C or systems part of the SAP Business Suite 7.0 (and higher) to migrate to a level corresponding to SAP BASIS 7.40 (for example "SAP enhancement package 7 for SAP ERP 6.0").

DMO processing overview

The processing sequence is based on the shadow system functionality of SUM: the SUM creates the shadow repository on the traditional database until downtime phase, while in parallel the SAP HANA database is setup (client, schema, ...). Then the shadow repository is copied to SAP HANA,  the database connection of the SAP system is switched to SAP HANA database, and then the downtime starts. After migration of the application data (including data conversion), the upgrade is finalized and the SAP system runs on SAP HANA. The traditional database continues to run and the application data in it are not modified, so it remains a fallback throughout the complete process.

DMO is using SAPUI5

Althought DMO is based on the "standard" SUM, a new user interface (UI) is used. The UI is based on SAPUI5, so it's running in a browser, and offers some comfortable features like checking the log files without having to log on to the OS of the application server. The new UI is meanwhile the default also for other SUM scenarios like update/upgrade (but not yet for the maintenance of a dual-stack system).

Please note that for a SAP Business Suite system based on SAP NetWeaver 7.40 (i.e. systems part of SAP Business Suite 7 Innovations 2013), your SAP NetWeaver Hubs must be on 7.30 or higher. For details, see http://wiki.scn.sap.com/wiki/display/SLGB/Strategy+beyond+SAP+Business+Suite+7+Innovations+2011

Further information

SAP Note 2161397 on Database Migration Option for SUM 1.0 SP14

DMO Guide

• Use the quicklink /sltoolset in SAP Service Marketplace, choose "SL Toolset 1.0",
  scroll down to the table of documentation, open section "system maintenance"
• SAP First Guidance - Migration BW on HANA using the DMO option in SUM

Blogs on DMO

• Migration to SAP HANA: Overview Video of Database Migration Option DMO
• DMO: introducing the new UI
• DMO: technical background
• DMO: background on table split mechanism
• Optimizing DMO Performance
• DMO: optimizing system downtime ...
• DMO: table comparison and migration tools
• DMO: introducing the benchmarking tool
• DMO: comparing pipe and file mode for R3load
• DMO: downtime optimization by migrating app tables during uptime (preview)
• Phases behind DMO R3load parallel export/import during UPTIME and DOWNTIME to target HANA DB

Blogs on related topics

• Migration of SAP Systems to SAP HANA
• A better way to migrate your SAP NetWeaver BW from any database to SAP HANA
• Decision Matrix to Choose Best Migration Option of ABAP Systems to SAP HANA
• Software Update Manager (SUM): introducing the tool for software maintenance
• Best Practice Guide - Classical Migration of SAP NetWeaver AS ABAP to SAP HANA
• http://wiki.scn.sap.com/wiki/display/SLGB/Strategy+beyond+SAP+Business+Suite+7+Innovations+2011

SAP Education offering

• HA250: "Migration to SAP HANA using DMO" - two days classroom training

Watch out for more details in further blogs that will be listed here as well.

Boris Rubarth
Product Management, Software Logistics, SAP AG

This document provides an overview of the classical migration procedure of an existing SAP system based on SAP NetWeaver to SAP HANA, including latest improvements, best practices and downtime-optimization options. For ABAP-based SAP systems, there are further options in addition to the classical migration, as outlined on the Migration of SAP Systems to SAP HANA overview page.

Migration Process Overview

For the classical migration procedure, the activities outlined in this section are required, which are valid both for ABAP-based and for Java-based SAP systems.

The following figure provides an overview of the migration process and the activities included:

First, you have to prepare your system for SAP HANA:

• If you should have an optional dual-stack system, you have to perform a dual-stack split.
• If you should have a non-Unicode system, you have to perform a Unicode conversion:

  • The Unicode conversion procedure is similar to a system copy procedure as offered by software provisioning manager.

  • Optionally, you can combine it with the database migration procedure, as outlined below.

Then, you have to bring your existing SAP system to a release supported by SAP HANA - for more information, see the Product Availability Matrix (SMP login required). For this, you perform a classical update with the Software Update Manager - for more information, see the Software Maintenance page. If required, this might imply the update of your operating system and database version (for example, if the current database version does not support the target release of the maintenance activity of your SAP system).

Finally, you perform a heterogeneous system copy of your SAP system with the software provisioning manager:

1. As the procedure is constantly improved especially for the migration to SAP HANA (see corresponding section on this page below), you always download the latest version of software provisioning manager from the Software Logistics Toolset page in SAP Service Marketplace (SMP login required).
2. You perform an export of your traditional source database in a database-independent format.
3. You create your target system on SAP HANA by using the database load exported in the previous step.
4. You perform post-migration activites as described in the system copy documentation (also available on the Software Logistics Toolset page).

For more information, see:

• This overview presentation, providing a more detailed overview of the classical migration procedure to SAP HANA.
• The System Copy and Migration page, providing general information for the system copy with software provisioning manager.
• The sections below on this page that provide best practices and an overview of the downtime-minimization options for the classical migration procedure.
• This demo video, providing a recording of the export and import phase of a migration from a traditional database to SAP HANA.

Best Practices and Improvements

The classical migration to SAP HANA is constantly improved especially for ABAP-based systems, as we see most of the demand here (for example, due to the size of ABAP-based SAP systems and the role they play in customer system landscapes). Therefore, see the following best practice information and improvements are made available for the migration of ABAP-based SAP systems to SAP HANA:

• Find general expert and best practice information in the Best Practice Guide - Classical Migration of SAP NetWeaver AS ABAP to SAP HANA to ease and accelerate your procedure. Besides an overview of involved tools and important information, the focus lies on best practice information, such as about table and package splitting. Also, an example is provided for the optimization of the runtime of a test system migration.
• Get detail information in blogs and documents from Stefan Seemann about latest corrections and improvements of software provisioning manager especially for the migration to SAP HANA:
  • For software provisioning manager 1.0 SP3 PL6, see this blog, describing many improvements
  • For software provisioning manager 1.0 SP4 PL4, see this document, describing a new SAP HANA client installation option
• See the following very helpful blogs from Stefan Seemann, providing further information especially for the classical migration to SAP HANA with the software provisioning manager:
  • Migration to SAP HANA using Software Provisioning Manager: How to Begin? provides information about how to prepare your source and target system and involved tools
  • Migration to SAP HANA: SAP Kernel update for the migration provides background information about the R3* tools involved in a migration (R3ldctl, R3ta, R3szchk, R3load), which get provided with the SAP kernel
  • In case of issues, see Migration to SAP HANA: Analyzing Problems within Software Provisioning Manager

Downtime-Minimization Options

In general, to optimize the runtime of the classical migration to SAP HANA, we strongly recommend to perform several test runs, where you can try different optimization methods and gain further experience concerning parametrization and handling of the available options.

Below, you can find a rough overview of some of the available approaches:

• If you want to migrate a non-Unicode system to SAP HANA, consider to combine the Unicode conversion either with the upgrade (for more information, see SAP Note 928729) or with the database migration
• Optimiziation of the upgrade part: use downtime-minimized capabilities for the upgrade with Software Update Manager
  • Implies the usage of an additional shadow database with record & replay
  • Available as of Software Update Manager 1.0 SP7
  • Applicable for the upgrade as part of the classical migration procedure as outlined above
  • For more information, see SAP Note 1678565 (SMP login required)
• Optimization options for the migration part:
  • Optimize the export + import with table and package splitting, integrated into the standard migration procedure of software provisioning manager - for more information, see the Best Practice Guide - Classical Migration of SAP NetWeaver AS ABAP to SAP HANA
  • Consider to use parallel export and import, also as offered by the standard migration procedure of software provisioning manager - for more information, see the system copy guide
  • Consider to use additional application servers for the export
  • Consider to use an SAP HANA standby node for the import
  • After a migration (test) run, analyze occurred runtimes and try to identify bottlenecks and further optimization options (such as number of R3load jobs and table splitting)
• Especially for SAP Business Warehouse (SAP BW), you can complement the migration procedures by a downtime-minimized approach:
  • Idea is to create a parallel shadow system of your SAP BW system via homogeneous system copy, on which all required changes (upgrade, migration, ...) are performed
  • This is supported by automated post-copy configuration and an automated cloning of the delta queues in the SAP BW source systems, making sure that the copied system results in a consistent state, although the production SAP BW system can continue to work
  • This way, the production SAP BW system only faces a reduced downtime (for the export of the homogeneous system copy), while there is no technical downtime for the SAP BW source systems
  • For more information, see the document Easier Migration to SAP BW powered by SAP HANA

Introduction

With the new downtime-minimized upgrade procedure “Zero Downtime Option of SUM (ZDO)”, you can expect a downtime reduced to only one re-start. Additionally, the ZDO procedure decreases the cool down duration.
After one year of performing ZDO upgrades in several customer pilot projects we are making the next step: With SUM 1.0 SP16 or higher, we are shipping ZDO of SUM on request (“available on request”).

How does “available on request” work?

The ZDO procedure is validated and in principle available with the latest SUM version. However, we still want to be in close contact with our customers to get feedback and also to see further improvements.

You can find the all the relevant information in SAP Note 2163060 “Prerequisites and Restrictions of Zero Downtime Option of SUM”:

http://service.sap.com/sap/support/notes/2163060

This SAP Note contains all prerequisites regarding start release, target release, minimum and DB release in order to verify whether ZDO is usable for your upgrade project or not.

This slide explains the high-level ZDO focus:

Maybe you don’t use the enabled DB or your product is not officially available for request, such as SAP CRM. In this case, you can still think about going with a pilot (project basis). With the pilot release you have a service and the SAP consultants / CoE support you to get the upgrade successfully done and that you are well prepared also for the next updates with ZDO. For further questions, please get in contact with your service contact or with me.

However the most common products and DB are already “available on request”. 

And after you have read SAP Note http://service.sap.com/sap/support/notes/2163060  and verified that your product, release, and DB is enabled for ZDO, you just start the quick procedure to get ZDO incl. support from SAP development.

With “available on request” the SAP Software Lifecycle department is still in close cooperation with you:

• Answer your request to use ZDO
• Telco to verify scope, functionality, schedule and open questions
  • Productive support on request

Additional service support is still recommended for knowledge ramp up / cookbook optimization or productive upgrade

Request to use ZDO

Create a support incident under component BC-UPG-DTM-TLA.

The incident header should contain the title "[ZDO/SUM]: Request for registration". Within the long text of your support incident please provide the following information:

• Address data:
  • Customer name
  • SAP customer ID according to OSS/CSN
  • Contact person to SAP (name & contact relevant data, i.e. address, phone, email)
  • Place of work (City, Country)
• Data per concerned system:
  • System name (SAP System-ID)
  • System role (i.e. Test, Evaluation/Sandbox, QA, Production)
  • Operating system of server running the central instance (name, release, version, SP level, patch level)
  • Operating system of database server (name, release, version, SP level, patch level)
  • Database (name/vendor, release, version, SP, patch level)
  • Product release information (i.e. SAP ERP 6.0), Enhancement Package and Support Package Stack
  • Additional installed software-components and/or custom development components (yes/no; if yes, which?)
  • Target Support Package level (i.e. SP5, SP6,#)
  • Planned maintenance date
• Additional information / comments / special requests

Telco for final clarification

After first contact via OSS a telco is helpful to share further details about the ZDO procedure or to answer your open questions.

Finally, you will get access to another SAP Note including all info about how to activate ZDO. It also contains the ZDO guide.

If you want to get additional support from SAP to speed up the learning curve or improve the cookbook steps, we will involve our experienced colleagues from SAP Support / Consulting. However, this is, of course, optional.

Preparation of ZDO Upgrade / Update / Customer Release

You can use ZDO of SUM for the following activities:

• Update / Upgrade (SP, EHP) of SAP
• Combined Upgrade / Update of SAP with customer transport requests
• Customer release only

In all cases you start with a sandbox test (copy of production system) to ramp up your knowledge, get first key indicator of the upcoming maintenance activity and finally analyze that ZDO does not harm your business.

When you start your project, you might still need support from SAP in case of issues. For related ZDO issues you can use the existing request message or create a new one and inform us. Because of “available on request” you get a special support.

After pre-clarified milestones, e.g. after Sandbox test, upgrade of quality system and production upgrade we will have a call. In this call we clarify open issues and also get feedback from you.

This overall way of cooperation has been proven with several other procedures and functions of SUM. And also for ZDO we think it is the logical next step and a win-win for you our customers and for the development department as well.

For further details about ZDO, see also Zero Downtime Option of SUM (ZDO) is available on request.

Near-Zero Downtime Maintenance for SAP Business Suite Systems

Improvements of downtime minimization capabilities for Software Update Manager (SUM)

The downtime minimization feature nZDM for SUM has been general available for some months.
After a very successful period of controlled projects on customer site all over the world this feature is now included in the Software Update Manager 1.0 (SUM). Until it was shipped with SP7 it has been used on customer side in more than 150 executions, 40 productively. It is a main improvement to reduce the business downtime significantly.

The nZDM feature in SUM is still considered for continuous improvement activities.

What do you have to invest?

There are no separate license fees for using the downtime minimization capabilities of SUM. SUM is part of the SL Toolset and the newest version can be downloaded from the SAP Service Market Place.
This document describes the new available feature and the benefits you can expect regarding downtime optimization of SUM. It will be regularly updated to keep you up to date.

Benefits of nZDM for SUM

In SUM you have the option to use one of the following pre-configurations:

• “Single System” =  no use of shadow instance (update) or shadow instance runs exclusively (upgrade)
• “Standard” = similar to EHPi or SAPup
• “Advanced” = intention to minimize the downtime

In SAP’s Software Update Manager (SUM) the advanced pre-configuration mode is used for extensive downtime optimization. Using the shadow instance for the main import (nZDM for SUM) is the main option in the “advanced” pre-configuration mode.

For further details about the shadow instance in SUM, see SCN blog http://scn.sap.com/community/it-management/alm/software-logistics/blog/2014/04/02/sum-introduction-to-shadow-system

Considering all downtime minimization capabilities which are offered in the advanced pre-configuration mode of SUM you can select the following capabilities:

• Intensive use of parallelization for Batch processing, DDL processes and R3TRANS
• SGEN in the shadow instance
• Customer transports import

With this feature, you consider the customer transports of your target release to the SUM procedure. The business downtime is reduced because repository related customer transports are imported during the uptime phase. In combination with nZDM the customer transports import can be used to execute z-table conversions in uptime.
The customer transports import is fully integrated with SPAU / SPDD, Transport Management System (TMS) and Change Request Management (ChARM). For further details please read SCN Blog: Import of customer transports for upgrades and customer releases available in SUM

When you use customer transports in SUM the screen to maintain SPAU and SPDD transport is not needed anymore. The procedure knows which of the transports are SPAU transports or SPDD transports. This also means that you can use as many transports for SPAU and SPDD as you want.    

• nZDM for SUM

You can select which capabilities you need, the features are optional.

How to activate the offered downtime minimization capabilities?

See Settings to activate downtime minimization capabilities in SUM

nZDM for SUM can be used to apply Support Packages, applying enhancement packages (EHP) or to upgrade an ABAP-based SAP Business Suite or SAP NetWeaver system.

Which improvement can you expect when nZDM is used in SUM?

The downtime minimization benefit depends on the level of your update. An update of ECC 6.0 EHP1 to EHP7 is much more benefitial than an SPS implementation of SP9 to SPS10. Therefore the main focus of customer activities is on EHP implementations or upgrades.

Based on the already made experiences on customer site nZDM for SUM enables a minimum downtime of around 2:30h – 3:00h when implementing an EHP or running an upgrade.
The overall technical downtime (= minimum downtime + post-processing) is reduced significantly although the post-processing phase is extended due to the nZDM feature to around 0:45h – 1:00h
So in total we have an overall technical downtime of 3:15h – 4:00h

Just compare it with your key figures of your last EHP update.

Please find below 4 examples from real customer projects and a comparison between the overall technical downtime with SUM without nZDM or EHPi and SUM with nZDM:

As you see all the data we got are roughly 2 years old. At this time we offered nZDM of SUM on request and so we got a very good overview about working in different system environments and sizes.

After available on request we get feedback only based on the SUM upgrade info that are sent to us
Based on our experiences the technical downtime reduction seems to be stable and independent from database or data size as nZDM for SUM was tested by big customers as well.

The following measure shows an internal comparison between SUM for SAP ERP 6.0 with and without nZDM for SUM.
Also in this example the technical downtime is reduced  > 55%!

In this blog you find the answers to the most important questions we realized when communicating to customers, partners, and consultants.

You find the newest information about the near-Zero Downtime Maintenance (nZDM) for SUM in the SUM1.0 Guide and in SAP Notes 1678565 and

1678564.

How to get key figures about the net process runtime and savings in your environment?

In the SUM directory under /abap/htdoc you will find the log file UPGANA.XML. When you copy this file and the UpgAnalysis.xsl file in a local directory and call the XML file you see it directly in a browser window.
When you run the SUM with nZDM on a test system at first you can use the figures to forecast your next run in production environment.

How to verify the needed database disc space?

As mentioned, the needed additional database disc space is minimized due to the focus on update/upgrade relevant tables for the copy to shadow operation. In order to calculate the needed DB disc-space you can use the experiences made in the first run.
In SUM directory under /SUM/abap/bin you find the log file “ALLTABU.DAT”, which shows the tables used by the R3TRANS. Besides of AIMs and conversions this table shows most of the table names part of the nZDM change recording.

Large tables (e.g. with size of 50 GB or more) can be identified with the help of the database analysis transaction in the Suite System (transaction DB02).

How to avoid long runtime of copy to shadow due to tables STXH and STXL?

In the previous SPs of SUM 1.0, when nZDM capabilities were delivered only on request, it was possible to get long copy to shadow runtime in pre-processing phase due to the STXH and STXLtables . Both tables are excluded from the shadow update with SUM 1.0 SP7.

Since the shipment of SUM 1.0 SP8 the copy to shadow is mainly taken over by a new technique "fast data copy". Issues regarding long running copy to shadow might be solved with this new technique finally.

Dumps in shadow system: PXA_NO_FREE_SPACE

If the parameter ABAP/buffersize is too small you'll get short dymps during the transfer process in the shadow. We recommend to extend the ABAP/buffersize to 800.000. (Trans.: RZ10)

See SAP Note 1678564, section 5 (Troubleshooting).

Why tables are not copied to the shadow?

The following exception have to be considered:

• Cluster tables
• Pool tables
• G tables
• Tables with large names (16 Characters with Secondery Indexes with 3 Letters)
• Index of tables

Big tables might be excluded from shadow operation due to a sapup parameter.

With the parameter set_max_tab_size = ON this feature is activated (default value). The parameter isu_max_tab_size = value in Kbyte (default 50 GB) is the threshold. See also SAP Note 1678564

When operating an SAP system landscape, there might be situations where you want to rename an existing SAP system. For example:

• You want to rename an SAP system provisioned by using SAP Landscape Virtualization Management as part of the offered easy, fast and reliable end-to-end system copy and refresh procedure.
• You want to change characteristics of an existing SAP system, such as for changing a physical hostname to a virtual hostname or for changing the SAP system ID.

Offering

With the system rename procedure being offered as option in software provisioning manager 1.0, change the hostname, instance number, or system ID (SAP system ID or database system ID) or any combination of these parameters of an existing SAP system based on SAP NetWeaver 7.0x, SAP NetWeaver 7.3x, and SAP NetWeaver 7.4. These changes have officially been possible only by performing a homogeneous system copy.

As a consequence, the system rename procedure can enable a faster system copy procedure for certain scenarios, as it allows to quickly adapt key characteristics of an SAP System or to make cloned systems operational (for example, you can use system rename to configure a system that has been copied to another file system along with services, users, permissions, and hostnames to be operational on the new host).

The system rename procedure is performed on the primary application server, while additional application server instances have to be re-installed. See the information below for further details, prerequisites and constraints (such as supported releases and use cases on your platform).

How to Get It?

System rename is provided with Software Logistics Toolset 1.0 as part of software provisioning manager 1.0.

Feature Requests

Influence the future of the system rename procedure by collaborating on ideas for new features in SAP Idea Place, the public channel to participate in innovation at SAP. System rename belongs to the idea session Software Logistics, category System Transformation. Submit new ideas, vote for existing ideas and connect directly with the team that builds the system rename procedure!

Further Information

• This presentation provides an overview of the system rename offering
• This presentation provides technical details about the system rename procedure

• For more information about the procedure, the tool and how to use it, see the System Rename Guide for your platform available on SAP Help Portal at: http://help.sap.com/sltoolset→ System Provisioning→ Rename Option
• For more information about current coverage and restrictions, see SAP Note 1619720 (Release Note - SMP login required)
• For troubleshooting information, see the list of Troubleshooting documents for Software Provisioning Manager

This document provides frequently asked questions for the installation of SAP systems.

1 Installation Frameworks

1.1 What is the difference between SAPinst and software provisioning manager?

SAPinst is the software provisioning tool for SAP systems. Whether you are going to install an SAP NetWeaver system, an SAP Business Suite system or a standalone engine, you can handle all these installations flexible and reliable with SAPinst on all supported platforms. Software provisioning manager 1.0 provides the latest SAPinst version for several product versions (with the goal that all product versions are supported by software provisioning manager).

1.2 What are the advantages of using software provisioning manager?

Profit from one download location and the same handling and behavior for several product versions. Profit from the latest fixes, features and platform support also for older product versions. Profit from less issues described in SAP Notes and less workarounds you have to perform manually, as the latest version of the software provisioning tool already has solved them.

1.3 Do I have to use software provisioning manager?

Usage of software provisioning manager 1.0 is optional, so you do not have to change your reliable procedures using the old tool versions, if you are fine with them. So, software provisioning manager is an additional offering to make your system provisioning processes easier and more reliable, while the basic behavior stays the same.

1.4 Where do I get software provisioning manager?

Software provisioning manager is available via Software Logistics Toolset - just always go to SAP Help Portal at http://help.sap.com/sltoolset (SMP login required) and download the latest version of the software provisioning manager documentation and tool - no searching for the right download location or installation media depending on the product or version you want to install.

2. Supported Installation Types

2.1 Can I install my SAP system as dual-stack system?

SAP recommends to move away from dual-stack SAP systems where possible, SAP Business Suite 7i2011 will be the last SAP Business Suite release with dual-stack support – the same applies for SAP NetWeaver 7.31. As a consequence, you can no longer install dual-stack application systems as of SAP Business Suite 7 and of SAP NetWeaver 7.0 Enhancement Package 1. Only exceptions: you can still install mandatory dual-stack systems (such as SAP Process Integration up to release 7.4x and SAP Solution Manager 7.1) and there is a workaround to install dual-stack SAP NetWeaver Business Warehouse 7.0 Enhancement Package 1, as described in SAP Note 1181025 (SMP login required).

2.2 Can I install my SAP system on a 32-bit platform?

As of SAP NetWeaver 7.0 SR3 (SPS 14), you can install only dialog instances on 32-bit platforms. All remaining instances (central instance, database instance, central services instance (SCS), ABAP central services instance (ASCS)) can only be installed on 64-bit platforms.

2.3 Can I install my SAP system as a non-Unicode system?

You can install an SAP NetWeaver 7.0 SR1 or SR2 ABAP system as a non-Unicode system. When you install an SAP NetWeaver 7.0 SR1 or SR2 dual-stack system (ABAP+Java), the ABAP part of this system can also be installed as non-Unicode, while the Java part can only be installed as Unicode.
As of SAP NetWeaver 7.0 SR3, you cannot install an SAP NetWeaver ABAP system or the ABAP part of an SAP NetWeaver dual-stack system as non-Unicode any longer. However, non-Unicode is still supported when you perform the system copy of an SAP system upgraded to SAP NetWeaver 7.0 SR3.

This document provides frequently asked questions for the installation of SAP systems. In addition, also see SAP Note 547314.

01. What takes place during a homogeneous system copy?

The main purpose of a homogeneous system copy is to build a test, demo or training system or to move a system to a new hardware. The difference to a heterogeneous system copy is that both the database and operating system remain the same. Because of this, there is the possibility on some platforms to perform the copy using database-dependent methods (such as backup/restore). Note that no matter if you change the version or bit version of either the operating system or the database, the system copy is still considered to be a homogeous system copy (for example, the system copy from Microsoft Windows 2000 32-bit to Microsoft Windows 2003 x64).

02. What takes place during a heterogeneous system copy (migration)?

The main purpose of a heterogeneous system copy is to create a copy of an already existing SAP system on the platform where either operating system, or database, or both differ from the operating system/database of the source system. The whole migration process consits of five main steps (described in detail in the system copy documentation):

1. Preparation steps on the source system
2. Export of the source system data into database-independent format
3. Transfer of the exported files to the target host
4. New system installation together with data import
5. Post-processing steps within the target system

03. What post-copy activities are required?

To bring the target system into operation and to adapt it to its new identity, several post-copy activities are required, such as:

• Cleaning up settings that got copied from the source system, but are no longer valid for the target system (such as cleaning up of ABAP basis tables, batch jobs, DBA cockpit configuration,  RFC in/outbound queue, spool requests, and TRUST manager configuration)
• Adapting the configuration of the target system (that is, adaptation of basis and application-specific configuration settings, such as the configuration of standard jobs, licenses, logon groups, system profiles, operation  modes, secure store, spool and TMS, and the scheduling in the DBA planning calendar)

The post-copy activities are described in the system copy guide. In addition, see the blog How to Deal with Landscape Data Created during System Copy for information how to adapt corresponding data in the system landscape directory (SLD).

Instead of performing required tasks for post-copy manually, you can optionally use automation  to perform configuration tasks in an automated way. This is offered by SAP Landscapce Virtualization Management, offering an automated end-to-end system copy and refresh procedure, where you get guided through the configuration processes and benefit from automated post-copy configuration tasks reflecting SAP expert knowledge. This results in less effort and cost, faster configuration procedures with less expertise required, and a higher reliability and a ‘standardization’ of tasks.

04. Which tools are used during a migration on source and target systems?

The main program used for the migration is Software Provisioning Manager. During execution, it calls other programs for particular purposes (such as R3LOAD, R3LDCTL, R3SZCHK) that use different command files. For a technical overview, see this document.

Depending on the kernel release, former tools might be involved, such as R3SETUP and SAPinst.

05. What is the purpose of the files that are used during a migration?

• DDL<db_type>.TPL is used for creation of table/index definition in database-specific syntax and contains negative list of tables, views and indexes, assignment of TABARTs to storeage unit and next extent size of table/index. TABART stands for a data class. For more information, see SAP Note 46272 (SMP login required).
• SAP<TABART<.STR contain table/index definitions from the ABAP Dictionary.
• SAP<TABART.CMD contain definitions of path and names for corresponding STR, TOC, EXT files, DDL<db_type>.TPL, export directory, block and file sizes.
• SAP<TABART>.<nnn> (<nnn> = 001, 002, ...), so called dump files, contain the data of all tables of a tabart in a non-platform-specific file format. These are binary files and they should never been changed/edited!
• SAP<TABART>.EXT contain initial sizes for tables and indexes. Not applicable to some databases (such as for Microsoft SQL Server).
• SAP<TABART>.TOC contain position of table data within the corresponded dump file, name of the dump file, time stamp of unload, and table rows number. TOC files must never be changed without approval of SAP support.
• SAP<TABART>.log contain log file information in case of errors and for restarting.
• SAP<TABART>.TSK are files used by R3load - for more information, see SAP Note 455195 (SMP login required).

06. What interdependencies to kernel versions have to be considered?

For the ABAP kernel tools used during a migration, some rules should be followed:

1. Tools used at the export on the source system must have the same version as on the target system.
2. Tools used must all have the same kernel version (do not mix up kernel tools of different releases, as otherwise, different versions of the called programs - such as R3load - might be used for export and import).
3. Tools must have the same kernel release as the system that is migrated.

These rules should be applied, unless specified otherwise in an installation/migration SAP Note or documentation. Keep this in mind when downloading a patched version of any mentioned tool from SAP Help Portal!

The Java system copy tools do not depend on the kernel version and you can always use the latest version of these tools.

For more information about dependencies to kernel versions for ABAP and Java systems, see SAP Note 784118 (SMP login required).

07. What requirements should be met before a migration starts?

See SAP Note 82478 (SMP login required).

08. Is a migration of a specific product/OS+DB combination supported?

First, check whether both the source and the target product/OS+DB combination is supported - for this, refer to the Platform Availability Matrix available in SAP Service Marketplace at: http://service.sap.com/pam (SMP login required).

In addition, check both the system copy documentation and the relevant SAP Notes for any possible restrictions.

09. Where can I find information on how to optimize the overall runtime of a system copy?

See the corresponding documents on the System Copy and Migration document.

Especially for the migration of ABAP systems to SAP HANA, see the Best Practice Guide - Classical Migration of SAP NetWeaver AS ABAP to SAP HANA.

10. Is it possible to perform a final migration of a productive system without a "test" run?

No, you should always perform a test migration on a comparable hardware with a system that is using a copy of the production database. This is necessary both to get an idea about the overall runtime of the production migration and to recognize possible major issues of the procedure before the final migration.

11. What aspects do I have to consider for a migration to SAP HANA?

For more information about a migration to SAP HANA, see the document Classical Migration to SAP HANA, which provides further details, such as an overview and further details of the procedure, best practices, demo video, and more information about options to minimize the downtime.

12. Are there alternative approaches to a classical system copy?

Yes, depending on your use case, several alternatives exist:

• The system rename procedure can be a faster alternative to the classical system copy for certain scenarios, as it allows to quickly adapt key characteristics of an SAP system (such as hostname, system ID, instance number) or to make cloned systems operational.
• The product SAP Landscape Virtualization Management helps customers simplify and optimize provisioning, deployment, and management of their SAP systems through the use of virtualization and Infrastructure as a Service (IaaS) cloud technology. One of its key features is a framework for SAP system cloning, copy and refresh, including fully automated post-copy tasks, eliminating manual effort. Customers can use it to reduce the total cost of operations of their SAP system landscape and enhance their flexibility and business agility.
• Especially for the migration of ABAP systems to SAP HANA, further options exist as outlined on the Migration of SAP Systems to SAP HANA page.

Introduction

Summary

If you develop industry-, company-, or country-specific enhancements to SAP solutions, the SAP Add-On Assembly Kit can help you plan and deliver those enhancements as software add-ons. The SAP Add-On Assembly Kit guarantees quality software development by using a standardized process flow from planning to delivering the add-on. The delivery tools work smoothly with SAP’s maintenance strategy, helping you integrate new developments into your existing environment and providing maintenance throughout the enhancement’s life cycle.

The SAP Add-On Assembly Kit and its comprehensive documentation help ensure high-quality product development from the planning phase. The add-on tools also help you efficiently install, update, and maintain the enhancement.

Documentation

The documentation of the SAP Add-On Assembly Kit can be found in the SAP Help Portal.

It is also available as PDF document.

Video Tutorials

1 Reserving a Namespace

2 Reserving an Add-On

3 Creating a Delivery

4 Performing an Object List Check

5 Releasing a Change Piece List

6 Creating a Component Piece List and an Exchange Component Piece List

7 Assembling an Installation Package

8 Installing an Installation Package

9 Creating an Attribute Change Package (ACP)

10 Uninstalling an Add-On via ACP

Feature Requests

Influence the future of the SAP Add-On Assembly Kit by collaborating on ideas for new features in SAP Idea Place, the public channel to participate in innovation at SAP. The SAP Add-On Assembly Kit belongs to the idea session Software Logistics, category Change control management. Submit new ideas, vote for existing ideas and connect directly with the team that builds the SAP Add-On Assembly Kit!

This document provides an overview of the classical migration procedure of an existing SAP system based on SAP NetWeaver to SAP HANA, including latest improvements, best practices and downtime-optimization options. For ABAP-based SAP systems, there are further options in addition to the classical migration, as outlined on the Migration of SAP Systems to SAP HANA overview page.

Migration Process Overview

For the classical migration procedure, the activities outlined in this section are required, which are valid both for ABAP-based and for Java-based SAP systems.

The following figure provides an overview of the migration process and the activities included:

First, you have to prepare your system for SAP HANA:

• If you should have an optional dual-stack system, you have to perform a dual-stack split.
• If you should have a non-Unicode system, you have to perform a Unicode conversion:

  • The Unicode conversion procedure is similar to a system copy procedure as offered by software provisioning manager.

  • Optionally, you can combine it with the database migration procedure, as outlined below.

Then, you have to bring your existing SAP system to a release supported by SAP HANA - for more information, see the Product Availability Matrix (SMP login required). For this, you perform a classical update with the Software Update Manager - for more information, see the Software Maintenance page. If required, this might imply the update of your operating system and database version (for example, if the current database version does not support the target release of the maintenance activity of your SAP system).

Finally, you perform a heterogeneous system copy of your SAP system with the software provisioning manager:

1. As the procedure is constantly improved especially for the migration to SAP HANA (see corresponding section on this page below), you always download the latest version of software provisioning manager from the Software Logistics Toolset page in SAP Help Portal.
2. You perform an export of your traditional source database in a database-independent format.
3. You create your target system on SAP HANA by using the database load exported in the previous step.
4. You perform post-migration activites as described in the system copy documentation (also available on the Software Logistics Toolset page).

For more information, see:

• This overview presentation, providing a more detailed overview of the classical migration procedure to SAP HANA.
• The System Copy and Migration page, providing general information for the system copy with software provisioning manager.
• The sections below on this page that provide best practices and an overview of the downtime-minimization options for the classical migration procedure.
• This demo video, providing a recording of the export and import phase of a migration from a traditional database to SAP HANA.

Best Practices and Improvements

The classical migration to SAP HANA is constantly improved especially for ABAP-based systems, as we see most of the demand here (for example, due to the size of ABAP-based SAP systems and the role they play in customer system landscapes). Therefore, see the following best practice information and improvements are made available for the migration of ABAP-based SAP systems to SAP HANA:

• Find general expert and best practice information in the Best Practice Guide - Classical Migration of SAP NetWeaver AS ABAP to SAP HANA to ease and accelerate your procedure. Besides an overview of involved tools and important information, the focus lies on best practice information, such as about table and package splitting. Also, an example is provided for the optimization of the runtime of a test system migration.
• Get detail information in blogs and documents from Stefan Seemann about latest corrections and improvements of software provisioning manager especially for the migration to SAP HANA:
  • For software provisioning manager 1.0 SP3 PL6, see this blog, describing many improvements
  • For software provisioning manager 1.0 SP4 PL4, see this document, describing a new SAP HANA client installation option
• See the following very helpful blogs from Stefan Seemann, providing further information especially for the classical migration to SAP HANA with the software provisioning manager:
  • Migration to SAP HANA using Software Provisioning Manager: How to Begin? provides information about how to prepare your source and target system and involved tools
  • Migration to SAP HANA: SAP Kernel update for the migration provides background information about the R3* tools involved in a migration (R3ldctl, R3ta, R3szchk, R3load), which get provided with the SAP kernel
  • In case of issues, see Migration to SAP HANA: Analyzing Problems within Software Provisioning Manager

Downtime-Minimization Options

In general, to optimize the runtime of the classical migration to SAP HANA, we strongly recommend to perform several test runs, where you can try different optimization methods and gain further experience concerning parametrization and handling of the available options.

Below, you can find a rough overview of some of the available approaches:

• If you want to migrate a non-Unicode system to SAP HANA, consider to combine the Unicode conversion either with the upgrade (for more information, see SAP Note 928729) or with the database migration
• Optimiziation of the upgrade part: use downtime-minimized capabilities for the upgrade with Software Update Manager
  • Implies the usage of an additional shadow database with record & replay
  • Available as of Software Update Manager 1.0 SP7
  • Applicable for the upgrade as part of the classical migration procedure as outlined above
  • For more information, see SAP Note 1678565 (SMP login required)
• Optimization options for the migration part:
  • Optimize the export + import with table and package splitting, integrated into the standard migration procedure of software provisioning manager - for more information, see the Best Practice Guide - Classical Migration of SAP NetWeaver AS ABAP to SAP HANA
  • Consider to use parallel export and import, also as offered by the standard migration procedure of software provisioning manager - for more information, see the system copy guide
  • Consider to use additional application servers for the export
  • Consider to use an SAP HANA standby node for the import
  • After a migration (test) run, analyze occurred runtimes and try to identify bottlenecks and further optimization options (such as number of R3load jobs and table splitting)
• Especially for SAP Business Warehouse (SAP BW), you can complement the migration procedures by a downtime-minimized approach:
  • Idea is to create a parallel shadow system of your SAP BW system via homogeneous system copy, on which all required changes (upgrade, migration, ...) are performed
  • This is supported by automated post-copy configuration and an automated cloning of the delta queues in the SAP BW source systems, making sure that the copied system results in a consistent state, although the production SAP BW system can continue to work
  • This way, the production SAP BW system only faces a reduced downtime (for the export of the homogeneous system copy), while there is no technical downtime for the SAP BW source systems
  • For more information, see the document Easier Migration to SAP BW powered by SAP HANA
• If classical approaches outlined above should not suffice to achieve your downtime requirements or if you should face special requirements, consider SAP consulting offerings (available on request), as described in:
  • Near Zero Downtime - Reduction of Business Downtime
  • SAP Note 693168

The purpose of this document is to explain the concept of DGP for CTS and the various Clenaup / Update reports available.

The downgrade protection function tracks objects in transport requests, and reports conflicts in five scenarios when an object that is saved in two or more transport requests, is released, reassigned, or imported.

Downgrade protection is available only for ABAP systems. Downgrade protection can be used in Change Request Management and in Quality Gate Management. The function is identical, however, the user interfaces and the related terminology can be different.

In Change Request Management, the Downgrade Protection assignment block in the WebClient UI is available for project and maintenance cycles and for change documents. Whenever the system detects a conflict, it is displayed in the assignment block.

In Quality Gate Management, information related to downgrade protection is displayed on the Downgrade Protection Tab.

There are two ways to trigger downgrade checks:

Manually In Change Request Management, you can trigger downgrade checks from the Downgrade Protection assignment block. In Quality Gate Management, you can trigger the check from the Project Overview and the Changes tab. The system analyses potential release check conflicts for all open transport requests in the development system, and import check conflicts for all released transport requests in all systems into which they can be imported. This helps you to handle the conflicts before triggering the transport. The check is performed asynchronously. Refresh the assignment block or tab page to display up-to-date check results.

Automatically Downgrade checks are triggered automatically when releasing transport requests, importing, decoupling, assigning transport requests or when reassigning a change document. In case of a conflict, the operation (release or import) is cancelled, unless you have ignored the conflict. You can set the system to automatically ignore conflicts in specific project and/or in logical systems. To do so, refer to the downgrade protection Customizing for more information.

You can also trigger a downgrade check from a task list. In case of a conflict, the system displays a dialog box notifying the user about the conflict and the cancellation of the operation. A link to the change cycle document in the WebClient UI, where the conflicts can be checked and handled, is provided.

Downgrade Check Types :

The following downgrade checks can be performed by the system:

Cross-system object lock : The cross-system object lock (CSOL) ensures that when an object is changed in a managed system, it is locked in the central SAP Solution Manager system. Depending on the conflict scenario, this prevents changes being made to this object in any other transport request.

Release check : When you release a transport request, downgrade protection can detect conflicts for objects in transport requests. The conflicts are the same as those displayed by the cross-system object lock when saving the objects to the transport requests.

Reassign check : The system performs this check when you reassign a change document or assign or decouple transport requests in a change document.

Predecessor check : The system can detect conflicting predecessors, that is, preceding transport requests containing conflicts, at the time of importing transport requests or transports of copies to the production or quality assurance system.

Imminent check : The system can detect impending (imminent) downgrade conflicts when transport requests are imported. This kind of conflict would become an actual downgrade if you ignore the conflict.

The following graphic shows the user and system activities during the downgrade protection process.

Downgrade Protection Process

DGP Housekeeping :

If DGP feature is switched on (you have configured downgrade protection and the cross-system object lock, in Customizing, under SAP > Solution Manager > Capabilities > Change Control Management > Cross-System Object Lock and Downgrade Protection) those tables will be filled constantly with new tracking information. In order to ensure those tables are not growing indefinitely, do not contain outdated or wrong information, and changes in the CTS landscape are handled correctly (eg removing or adding a system) housekeeper is required.

Clean-up reports :

RSCTS_OBJ_TRACK_CLEANING
RSCTS_OBJ_TRACK_CLEANING_2
RSCTS_OBJ_TRACK_CLEANING_0

SAP recommends to use RSCTS_OBJ_TRACK_CLEANING_0 in all cases, its a more efficient version of _2 and the core report.

Update reports :

RSCTS_OBJ_TRACK_RUN_QUEUE
RSCTS_OBJ_TRACK_RUN_QUEUE_ALT
RSCTS_OBJ_TRACK_RUN_QUEUE_MAX

The update reports basically query for the import status of all requests (in the respective target systems), where the tracking framework did not yet receive a  final import status (e.g. because transport was not imported yet, or no update was done since import). Currently, DGP is based on a pull-mechanism - we don't get any notifications of an import. Hence, we query for that data. Each line in SCTS_TRACK_UPQUE represents one request in one logical system, where we don't have the 'final import' status persisted in the SolMan. If we retrieved this exact status, the line is deleted from SCTS_TRACK_UPQUE and the STATUS field in SCTS_TRACK_MAIN is adjusted. The different reports now leverage different query mechanisms - the best way is to ask tp in the target system. However, this is super slow (tp takes 500ms per request, plus remoting, plus persistence). For large SCTS_TRACK_UPQUE tables, this simply does not work. RSCTS_OBJ_TRACK_RUN_QUEUE_ALT uses SolMan tracking tables instead - so no tp, no remoting and optimal queries, its not as 100% as the tp version, but gets the job done much faster.

If the downgrade protection feature is switched on in SAP Change Request Management or SAP Quality Gate Management, the following reports should be executed on a regular basis in your SAP Solution Manager system:

1. Report RSCTS_OBJ_TRACK_CLEANING and
2. Report RSCTS_OBJ_TRACK_CLEANING_2 and
3. Report RSCTS_OBJ_TRACK_RUN_QUEUE

All three reports can be triggered manually (e.g. using transaction SE38) or can be scheduled as batch jobs (using transaction SM36). Depending on the average transport volume, we recommend to execute the reports at least weekly. In very agile environments, with several hundred requests a day, a daily execution is recommended.

This is how SAP recommends the reports be utilised and in this order :

1. RSCTS_OBJ_TRACK_RUN_QUEUE_MAX

2. RSCTS_OBJ_TRACK_CLEANING_0

3. RSCTS_OBJ_TRACK_CLEANING

4. RSCTS_OBJ_TRACK_CLEANING_2

The queue-reports basically update information which is needed for the clean-ups. However, if those reports are scheduled daily, the core sequence is not that relevant, as the clean-ups on the next day will leverage the information retrieved before. But as a simple rule of thumb, running the queue-related reports before the clean-up ones is recommended.

SCTS_TRACK_UPQUE contains all transport request/system combinations, where SCTS_TRACK_MAIN still has STATUS = WAITING | REWAITING. Since we don’t get synchronous updates, when a transport request was imported, we have to query for it. The basis for those queries is the information in SCTS_TRACK_UPQUE.  Once we detect a transport being successfully imported in a given system, we remove the corresponding entry in SCTS_TRACK_UPQUE.

Report RSCTS_OBJ_TRACK_REMOVE_SYSTEM can be used to remove obsolete / decommissioned SAP systems as DGP clean-up reports RSCTS_OBJ_TRACK_CLEANING and RSCTS_OBJ_TRACK_CLEANING_2 will not removed these (per standard) from SCTS_TRACK_MAIN.

Report RSCTS_OBJ_TRACK_REMOVE_SYSTEM can be used as per Step 2 of SAP Note  # 2077091.

Report RSCTS_OBJ_TRACK_REMOVE can be used to remove obsolete requests. Simply execute the report in the SAP Solution Manager system and supply the requests in question and execute it. You can find more information in SAP note # 2108353.

Report RSCTS_OBJ_TRACK_ADD can be used to add transport requests that were created before SAP Solution Manager 7.1 Support Package 05.

List of relevant and important notes :

1897459 CTS DGP: Fixing performance issue for large repositories

1957898 DGP: Conflicts occur with already imported objects

1970273 DGP: Incorrect results for already imported objects

1972808 DGP: Cleanup Report for invalid or finished entries

2011014 DGP: Improvement of RSCTS_OBJ_TRACK_CLEANING

2077091 DGP: Refresh DGP-data after system copy/refresh

2196868 DGP - Cleanup Decommissioned SAP Systems

2097533 DGP: Manual update of tracking data for requests

2108353 DGP: Report to remove obsolete requests

2118375 DGP: False conflicts are reported for PFCG transports

2138047 DGP: Recommended Housekeeping

2164852 DGP: Roles are not always tracked

2173173 DGP: Details on how to use report RSCTS_OBJ_TRACK_CONF

2187926 DGP: Query optimization for update mechanism

2189071 DGP: Improved clean up for waiting export entries

2202616 DGP: Option for report RSCTS_OBJ_TRACK_RUN_QUEUE

2209499 DGP: Update report for large queues

2209856 DGP: Parameter 'cache expiration' not working

2216849 DGP: Performance improvements for long running clean-up/queue runs

2231112 cCTS DGP: Update of report RSCTS_OBJ_TRACK_CLEANING

2073071 DGP: performance issues and resolution

Frontend Setup

For the installation and distribution of frontend software, SAPSetup offers easy and reliable functionality for installations ranging from single PCs to distributions on a large scale - including the option to run installation servers that support you in distributing and updating frontends in your landscape.

System Installation

In your system landscape, you regularly face the requirement to realize new functionality, such as in the form of adding new systems to an existing landscape or even building up a totally new landscape. Here, it is important that you can perform the installation reliable according to your needs - be it the installation on your preferred operating system/database combination, the installation of a system distributed to several hosts or the installation of a high-availability system.

System Installation Tools

For this, SAP is offering the software provisioning manager 1.0 (providing the latest version of our software provisioning tool SAPinst) that enables software provisioning processes for several product versions, covering all supported platforms. Instead of searching for the right media containing the software provisioning tool and potentially having to consider a long list of issues and fixes described in SAP Notes that have to be applied manually, just download the latest version of the software provisioning manager and automatically get support of the latest product versions and platforms – including latest fixes in SAPinst and supported processes, powered by a reliable tool available and used for years.

Whether you are going to copy an SAP NetWeaver system, rename an SAP Business Suite system or install a standalone engine, you can handle all these installations flexible and reliable on all supported platforms. In addition, many other procedures are offered in the context of software provisioning, such as the system copy, system migration, system rename, and dual-stack split of SAP systems.

Further Information

For more information on system installation, see the following presentations:

• Short overview presentation of installation with software provisioning manager 1.0
• Quick overview how the installation process with software provisioning manager 1.0 looks like
• For troubleshooting information, see the list of Troubleshooting documents for Software Provisioning Manager

Integration

• To plan your installation, use the Master Guide (SMP login required) available for each SAP application.
• With the up-to-date installation, you can ease the installation process of a system with selected Support Package level. For this, by using the Maintenance Planner, you can directly generate a stack.xml file for planned landscape changes without first having to register the system in SAP Solution Manager. The information about planned activities can then be directly propagated to the tools that consume it (software provisioning manager and Software Update Manager). That is, software provisioning manager can now consume the generated stack.xml file and use the information provided in there for execution (including further enhancements in the installation process as part of the up-to-date installation, such as inclusion of language installation and the preparation for the execution of Software Update Manager).
• After the successful installation of a new SAP system with software provisioning manager 1.0, you can use the Technical Configuration for the automated configuration of SAP NetWeaver. Especially for SAP NetWeaver ABAP 7.4, we offer the automated initial setup with the ABAP task manager.
• To build up a three-system landscape with development, test and production system, use the System Copy tools provided by SAP.
• Instead of installing an evaluation, demo, or training system, you can also profit from a preconfigured SAP system delivered via the cloud. For more information, see the SAP Cloud Appliance Library space.

This article gives you an overview of the tools, features and services that SAP offers to minimize your planned downtime when you for example execute an update on your SAP system.
Planned downtime is related to maintenance events for OS, databases, applications and hardware.
The planned outages related to applications are

• Patches
• SPS
• EHP implementations
• Release upgrades
• Customer transports & add ons

All tools and features for updates offered by SAP are focused on outages related to application. However some of them can even cover all planned outages.
The tools and features that are offered by the SAP standard are available for download in the SL Toolset on the SAP Service Marketplace:

     /sltoolset

Overview of downtime minimization tools and features of SL Toolset

The Software Update Manager (SUM) is the tool for planned updates and upgrades of SAP systems for all software stacks, ABAP stack or Java stack.
But the downtime minimization tools for the stacks are different. In principle two approaches are used:

• Clone
• In place

The clone approach needs a full copy of the productive system but it is very flexible regarding maintenance activities. On a separate clone system also DB or OS updates or migrations are possible.

Considering the applications related to Java stack the downtime minimization tool near-zero downtime maintenance for SAP NetWeaver Java (nZDM Java)  uses a clone based approach. The downtime is reduced mainly to a restart and subsequent manual steps.

The downtime minimization tool for Dual-stack only considers the PI dual-stack and uses a lean clone-based concept with copy-back technique..

ABAP applications, especially the ERP system with DB sizes in range of several terabytes. Therefore the SAP standard tools use the in place approach for ABAP systems in general to minimize the planned downtime. The in place approach uses the DB and needs a minimum of additional Hardware. The downtime minimization capabilities of SUM, e.g. nZDM, use a separate DB schema (shadow).

The in-place approach is very comfortable and effective for regular updates. But when you have extended maintenance projects, e.g. an update combined with Unicode conversion or DB migration, a clone approach is needed. SAP offers a so called nZDT service (near zero downtime service) that covers additional outages which can be combined.

The next level of downtime minimization is to get rid of the “n” and talk about zero downtime maintenance (ZDM).  And so the latest development for applications based on ABAP is the zero downtime approach of SUM. This approach is called zero downtime option of SUM (ZDO). The zero downtime option works “in-place”, all actions are performed within the same database. This new architecture is based on a sub-system interaction between production sub-system and update sub-system.

nZDM for SAP NetWeaver Java (nZDM Java)

The nZDM Java procedure supports SAP Enterprise Portal (EP) and SAP Process Orchestration (PO) incl. SAP PI Java only and SAP BPM or SAP BPM (BPM).
nZDM Java is a clone based approach. It offers two main procedures:

• System switch
• Database switch

The system switch enables OS updates or database updates in addition to your SAP Process Orchestration or SAP BPM update. The nZDM Java procedure also supports your HA system.

nZDM Java is general available and supports patches, SPS, EHP and upgrades. When you want to use nZDM Java for your system red the SAP note 2157294 for details. To get further info about nZDM Java, read the following blogs:

nZDM Java: minimize the business downtime of your SAP Enterprise Portal update

nZDM Java: minimize the business downtime of your SAP Process Orchestration maintenance activity

Downtime Minimization Capabilities of SUM (nZDM)

The downtime minimization capabilities of SUM are features which can be used in the advanced mode. The following features in advanced mode are possible:

• SGEN in uptime
• nZDM (near Zero Downtime Maintenance of SUM)
• customer transport requests import

These features support the ABAP stack and can be used for SPS, EHP and Upgrades.
The capabilities in the SUM advanced mode support the ABAP stack products in general, e.g. SAP ERP, SAP SCM, SAP EWM, SAP CRM or SAP BW. 
It is available for all common DB. The main SAP Note is 1678565  – “Prerequisites, Terms and Conditions for nZDM/SUM”.
The nZDM feature in SUM is permanently being improved, e.g. regarding the CRR transaction which controls the record and replication functionality of nZDM.
With nZDM in SUM you reduce the overall technical downtime significantly. However, this is not the overall upgrade procedure. The customer specific activities have to be considered as well if you want to minimize the downtime of the whole upgrade process. A main step for reducing the overall business downtime is to integrate customer transports in the SUM procedure. When you activate this feature in the advanced mode of SUM you will be able to import and activate  objects in uptime related to your repository transports. The SUM includes your transports and it can be easily combined with a normal SAP stack implementation. But you can also use this powerful feature for your big customer releases exclusively. With SUM 1.0 SP14 the SUM asks if you want to perform the tool with a stack.xml (SAP stack) or only for customer transport requests. In 2014 and 2015 the import of customer transports was tested in many customer projects. The import of customer transports is fully integrated into Transport Management System, SPAU, SPDD and even Change Request Management system (ChaRM). Since SL Toolset SP14 this feature is available for customers without any restrictions.

Related blogs in SCN are:
Near-Zero Downtime Maintenance for SAP Business Suite Systems

Import of customer transports for upgrades and customer releases available in SUM
Settings to activate downtime minimization capabilities in SUM

Zero Downtime Option of SUM (ZDO)

The next level of downtime minimization is the zero downtime maintenance (ZDM). The zero downtime procedure in SUM is called Zero Downtime Option of SUM (ZDO).
ZDO enables upgrades of the ABAP applications without technical downtime and almost no business downtime. ZDO is simply activated through a switch in the existing SUM. Administrators who are familiar with SUM can easily run the zero downtime in SUM after an initial guidance and knowldege transfer.
The ZDO uses an in-place approach, this means minimal DB footprint on the database. This new architecture is based on a sub-system interaction between production sub-system and update sub-system. During the maintenance phase, the upgrade including the import of customer transports is run on the upgrade sub-system. In parallel, end users can continue working on their dialog instances on the start version running on the production sub-system.     
In 2015 ZDO was rolled out for pilot projects. The projects were guided by SAP Consulting / Max Attention and supported by SAP development.

With SUM 1.0 SP16 (February 2016) the ZDO procedure is also available for customers on request. For further details see blog: Zero Downtime Option of SUM (ZDO) is “available on request”

The ZDO approach supports Customer Releases, SAP SPS, EHPs and also Upgrades. The main focus is on SAP ERP, SAP CRM and other main Add Ons like SAP EWM or SAP GTS.  As of now ERP and EWM (on SAP NetWeaver) are available on request.

Related blog:
Zero Downtime Option of Software Update Manager

nZDT (near Zero Downtime Service)

The nZDT is a service offered bySAP. It is a customer specific procedure that is technically a clone approach.
When using the nZDT service, the maintenance is performed on the clone of the production system. All changes are recorded and tran     sferred to the clone afterthe maintenance tasks are completed. During the final downtime, only a few activities are executed, including a switch of the production to the new system (clone).
The nZDT is very flexible regarding planned downtime activities. Database upgrades or migrations, OS migrations or Unicode migrations can be done on the clone in parallel to SAP upgrades as well.
The nZDT is a bigger project and not a tool that is available in the SL Toolset on the SAP Marketplace. In order to get further info, please get in contact with your main SAP contact.

DMO (Database Migration Option)

The database migration option (DMO) of SUM offers the combination of system update with the migration to SAP HANA database, making the overall migration process easier and reducing the downtime.

DMO is available           as of SUM SP09, and may even include the Unicode conversion for non-unicode source systems.

It supports:

• SAP Business Warehouse (BW)
• SAP Business Suite (BS)

Check SAP Note 1813548 and the SCN blog

Database Migration Option (DMO) of SUM - Introduction

The downtime optimized DMO is currently available on request and will further reduce the downtime, see SCN blog

DMO: downtime optimization by migrating app tables during uptime (preview)

Summary

Here is a summary of the tools and features that SAP offers to reduce your planned downtime. The key figures about the downtime are based on  experiences are subject to change.

You perform an IMPORT ALL in STMS but transports are imported in the wrong sequence.

Prior to the import all taking place the sequence was correct in the buffer / import queue, but afterwards according to the import history the sequence is not as expected.

You have a 3 system landscape (or more) and you import to the consolidation system (system that delivers to at least one system - ECQ in transport routes below) with U0 ("Leave Transport Request in Queue for Later Import").

Using our transport routes above as an example, after you import  to your consolidation system (ECQ) this delivers the transport(s) to the buffer of the delivery system (ECP in transport routes above) with "F" (False Position) in the umode column of the buffer.

For a definition of 'F' in the buffer please see the description below :

F (in buffer only): buffer entry is at a wrong position. A subsequent (implicit) addtobuffer will correct that later. This umode normally only

appears in the buffer of delivery systems when umode 0 has been used.

In the buffer above we see 'IF in the umode column. The 'I' means repeat the import of the transport request from the beginning and is the result of importing with U0. This will be resolved by importing without U0 ("Leave Transport Request in Queue for Later Import").

For transports that are initial and yet to be imported the 'I' comes from an import to the previous system with U0 and will accompany the 'F' (in our example an import to ECQ with U0 will deliver to ECP with 'IF').

Up to now the sequence of transport(s) in the buffer (ECP in this example) are correct and match the import sequence of the previous system in the transport routes (ECQ in this example).

Remember the sequence of transports in the consolidation system (ECQ) is based on the export sequence (from ECD) and in the delivery system (ECP) is based on the import sequence to the consolidation system (ECQ).

If one checks the sequence of transports prior to the IMPORT ALL you will be under the false impression they are correct. It is only when you check
the import history that you see the sequence was not the sequence you expected.

This is due to the fact that when tp starts the import (after you trigger IMPORT ALL) of transports in the buffer, those transports with 'F' in the umode column are all pushed to the bottom of the buffer. This is because those that are without 'F' are known to be in the correct sequence and are imported first.

The 'F' (in the umode column of the buffer) can ripple from one buffer to the next if not resolved. In our example if there was a fourth system in the landscape and ECP delivered to that system, if you import to ECP (whilst 'F' is still in the buffer column) even without the U0 ("Leave Transport Request in Import Queue for Later Import") it will still deliver to next system with 'F' in the umode column.

In order to resolve this situation you should always check the buffer before you make an import all, especially if you are in the habit of importing to any system(s) with the option "Leave Transport Request in Queue for Later Import".

If you see any transports with 'F' then you should resolve this before you make the import all.

In order to resolve the 'F' you must follow the steps below :

• Import to the system that delivered the transport(s) with 'F' in the umode column without U0 ("Leave Transport Request in Queue for Later Import"). In our example that means importing to ECQ without U0 since that is responsible for delivering the transport to ECP with 'F'.
• If mass transports is your transport strategy then best practice is to perform an IMPORT ALL into ECQ so as to correct the transports in ECP with 'F', but also a single transport without U0 will resolve the 'F' too.

• This will leave the transport with just 'I' in the umode column and as soon as you import that transport as part of the IMPORT ALL (without Leave Transport Request in Queue for Later Import) it will be cleaned from the buffer.
• If you imported the transport(s) to ECP without U0 ("Leave Transport Request in Queue for Later Import") without first resolving the 'F' then instead of 'IF' you would have just 'F'.

Please remember the point about the 'F' in the umode column being able to ripple. If there is a 4 system landscape (a system that ECP delivers to) and you find that you did not import to ECP with U0 ("Leave Transport Request in Queue for Later Import"), but there is still an 'F' in the umode column (of delivery system of ECP) then you will most likely trace it back that you imported to ECQ with U0 and that delivered to ECP with 'F'. You then imported to ECP (without U0), but that still delivered to the next (delivery) system with 'F' because the 'F' was not resolved (in ECP). So it is very imported that you do not perform the import whilst the are transports in the buffer with 'F' or you will have a rippled affect.

In this wiki we talk about IMPORT ALL, but it should be noted the same can happen for an import subset if the subset contains transports with 'F' in the umode column.

Finally it should be noted before the IMPORT ALL (starts) the import queue is automatically closed. If you manually close the import queue via
Queue > Close

then the result will be the same and those transports with 'F' in the umode column of the buffer will be pushed to the bottom.