Get technical details about the dual-stack split procedure of software provisioning manager 1.0.
Technical Details - Dual-Stack Split Procedure of Software Provisioning Manager 1.0
Overview - Dual-Stack Split Procedure of Software Provisioning Manager 1.0
Get an overview of SAP's approach for dual-stack systems and the dual-stack split procedure of software provisioning manager 1.0.
Migration of SAP Systems to SAP HANA
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:
- 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.
- 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.
- 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.
Database Migration Option (DMO) of SUM - Introduction
Scenario:
- You want to migrate your existing SAP ABAP system to the SAP HANA database
- Your SAP release needs to be upgraded prior to migration
Use the database migration option (DMO) of the Software Update Manager (SUM):
it combines SAP upgrade and database migration to SAP HANA in one tool!
Benefits:
- Migration steps are simplified
- System update, Unicode Conversion, and database migration are combined in one tool
- Business downtime is reduced
- The source database remains consistent, so a fast fallback is possible
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
Classical Migration to SAP HANA
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:
- 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).
- You perform an export of your traditional source database in a database-independent format.
- You create your target system on SAP HANA by using the database load exported in the previous step.
- 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:
- 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
Short history of DMO
This blog offers a chronological list of features for database migration option (DMO) with Software Update Manager (SUM) 1.0, starting with SP09 up to the latest release. As a prerequisite, you should read the introductionary document about DMO: Database Migration Option (DMO) of SUM - Introduction
Check this page once in a while for updates with new SUM SPs.
Always check the restrictions and conditions for a specific feature in the respective SAP Note for DMO.
SP 15 | Details | More information |
---|---|---|
7.50 support | SUM SP 15 is exclusively for scenarios targeting SAP NetWeaver 7.50 based systems, and is available parallel to SUM SP 14. SAP Note 2161396 is relevant for DMO with SUM SP 15. | SUM 1.0 SP 14 gets a buddy called SP 15 |
SP 14 | Details | More information |
MS SQL as target | The list of target database types is extended to MS SQL. Like with SAP ASE as target database, this is only available on request. (For a request, create an incident on BC-UPG-TLS-TLA). | SAP Note 2161397 |
MDC support | Support for Multi Database Containers (MDC) on SAP HANA DB | DMO guide section 4.5.5 |
non-UC SCM | Support for non-Unicode SAP SCM systems | SAP Note 2161397 |
Monitoring | Improved monitoring for R3load usage | DMO guide section 4.2 |
Test cycle | Test cycle option for quick migration repeat | DMO guide section 4.5.2 |
DMO notes | The SAP Notes on DMO are now SP-specific: SAP Note 2161397 is specific for DMO with SUM SP 14 (SAP Note 1813548 was for DMO with SUM up to SP 13). | - |
SP 13 | Details | More information |
Benchmarking | Benchmarking tool for testing migration performance | DMO: introducing the benchmarking tool |
R/3 as start | Start release SAP R/3 4.6C is now supported. | SAP Note 2161397 |
ROWID export | ROWID-based export for Oracle source database. | - |
Win: pipe mode | Pipe mode for R3load is now also used for SUM on Windows OS | DMO: comparing pipe and file mode for R3load. |
SUM on AAS | It is possible to run SUM (and DMO of SUM) on an Additional Application Server (AAS, fka DI).![]() | SAP Note 2161397 |
New SL UI | The "DMO UI" is replaced by the "Software Logistics User Interface" (SL UI). Note that the URL suffix has changed from /doc/gui to /doc/sluigui. | DMO guide section 6.1 |
Duration files | Table duration files can now simply be put into the download folder to be considered for the next DMO run. | DMO guide section 2.3 |
SP 12 | Details | More information |
SAP ASE as target | SAP ASE is a possible target database type for DMO, apart from SAP HANA - this is available on request. Check the SAP Note on DMO for details and restrictions, e.g. it is only supported if you have a separate ASCS instance. | SAP Note 2161397 |
SP 11 | Details | More information |
Table comparison | With table comparison, it is possible to optionally compare not only the number of rows for the migrated tables, but also the content of tables during a DMO run. It should not be used for the DMO run on a productive system as it increases the downtime. | DMO guide section 4.5.1 |
SP 10 | Details | More information |
Unicode Conversion | It is now possible to include the Unicode Conversion (for single code page systems only) as part of the DMO procedure. The manual activities required before the actual technical conversion remain the same. | SAP Note 2108396 |
Reset button | The reset button is now shown on all dialogs. Previously, it was only available on a roadmap switch dialog, like from Preprocessing to Execution. | - |
SP 09 | Details | More information |
DMO available | Database Migration Option (DMO) is available as a new scenario for Software Update Manager (SUM). It offers the combined update/upgrade of the SAP software with the database migration to SAP HANA DB. DMO is available for SAP Business Suite systems, SAP NetWeaver systems, and for SAP BW systems. | Database Migration Option (DMO) of SUM - Introduction |
Software Provisioning Manager 1.0
Introduction
Concept of Software Provisioning Manager 1.0
Easier and More Reliable Software Provisioning
Always the Latest Features, Coverage and Fixes of Reliable Procedures
- Get the right tool for your product and platform
- Apply required fixes:
- Check what issues have to be considered before using the tool (by scanning through a long list of issues provided in the corresponding SAP Notes) - including possible adaptions of the installation media due to new operating system and database versions not supported by the old versions
- Apply fixes to relevant issues (for example, by adapting or replacing files or considering special procedures)
SAP recommends that you always download the latest Support Package of the software provisioning manager 1.0, as it contains latest corrections and is updated regularly – even if you have installation media available!
Covered Use Cases
Software provisioning manager covers the following use cases:
*) Both the dual-stack split and the sytem rename procedure got integrated into software provisioning manager 1.0 SP04 with Software Logistics Toolset 1.0 SPS09 - latest improvements of these procedures are no longer available as standalone tool
Further Information
- For more general information about the concept, see the overview presentation and this blog.
- For more information about how to use the software provisioning manager 1.0 and further technical details, see:
- See this document for features of the software provisioning process
- For frequently asked questions, see the document FAQ - System Installation
- Best Practices for SAP System Installation and Transformation
- For troubleshooting information, see the list of Troubleshooting documents for Software Provisioning Manager
- For information how to accelerate the restart time of software provisioning manager 1.0 after an issue during the execution phase, see this blog from Stefan Seemann.
- The following video shows a demo of the dialog phase of an installation procedure with software provisioning manager 1.0 (duration 6 minutes):
Feature Requests
Availability
Zero Downtime Option of SUM (ZDO) is “available on request”
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
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%!
Additionally you see that the overall project time is increased to approximately 20-30%. This additional time is used during the phases which are running in uptime. This has to be considered in the cutover plan.
Functionality
How does nZDM for SUM work?
The nZDM capability of SUM uses the shadow instance for the main import.
Quick facts about nZDM for SUM:
- Introduces the "Record & Replay" technique for business transactions based on database trigger technology
- Minimizes manual effort: all steps run automatically in background
- Minimal additional hardware requirements due to shadow-technique, only additional DB space needed (80 – 350 GB)
- The additional DB space is needed for the transferred tables to the shadow (30 – 150 GB) and for logging tables (50 – 200 GB).
- When you want to use nZDM in combination with customer transport requests import you have to consider z-tables for table conversions in addition
- Available for all ABAP-based Business Suite products
Record & Replay means that the database changes during uptime of the maintenance process create triggers, which records the changes. The recordings are only needed for tables which are used for the update / upgrade in the shadow. With the help of the recording the shadow tables will be updated after the upgrade/update phases in the uptime. The majority of the recording updates are run in the uptime. Only the delta (last 10%) has to run just before the switch in the downtime.
What are the consequences for CPU and memory consumption?
You maintain the amount of process which are used by the Record & Replay technique (CRR). The default value for the amount of processes is three. This is the value which is recommended from our side based on the experiences we made with our customers. I am not aware of an impact on pereformance for the enduser.
nZDM can be used for common used databases with the following minimal versions:
- IBM DB2 LUW 9.7 FP4
- Oracle 10g
- MS SQL 2005
- IBM DB2 for z/OS 10.1
- SAP Max DB 7.9
- SAP HANA 1.00.52
- SAP Adaptive Server Enterprise (ASE)
- DB2 for IBMi 7.1
SUM allows using the nZDM capabilities for the following standard software maintenance activities:
- Applying a Support Package on any ABAP-System with a target release based on SAP NetWeaver 7.0 EHP 2, SP8 or higher
- Installing an EHP on top of any ABAP system with a target release based on SAP NetWeaver 7.0 EHP 2, SP8 or higher
- Upgrading your system to any ABAP system with a target release based on SAP NetWeaver 7.0 EHP 3 or higher
For further operational details please see SAP Note https://css.wdf.sap.corp/sap/support/notes/1678564.
nZDM is described in the official user guide of SUM as well.
When you are looking for additional support please also check the frequent asked question document:
http://scn.sap.com/docs/DOC-40355
What is new with SUM 1.0 SP14 - SP16?
In the past you probably got issues with nZDM that for example the replication rate showed 95% but the SUM didn't accept this.Or you got issues due to very big tables to be copied.
With the latest SUM SPs we optimized nZDM:
- excluding big tables (sapup parameter)
- copying improvements to optimize the runtime for "copy to shadow" phase
- optimizing of CRR handlingfor transaction CRR_CONTROL
- optimizing of nZDM runtime
When you need to copy big tables (SAPor custom tables) to the shadow instance you should be aware of a parameter explained in the SAP note 1678564.
The default exclusion value is 50 GB.
If you want to mainly run conversions you probably didn't need this feature. You disable the the maximum table size feature using the SAPuppar parameter set_max_tab_size = OFF.
In older SUM versions it sometimes happened that the refresh of the CRR_CONTROL was very time consuming due to high load of CR entries. The threshold was not accurate. This has been changed with the new SUM 1.0 SP. For this a "Cut-Off" Limit ("Maximum Logtable Row Count") is introduced. This threshold ensures that the calculation is not such time consuming.
With the next SUM SP17 we plan to improve the start / stop procedure to avoid conflicts.
FAQ of near-Zero Downtime Maintenance for SAP Business Suite Systems
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
System Rename
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).
Information
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
FAQ - System Installation
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.
FAQ - System Copy and Migration
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):
- Preparation steps on the source system
- Export of the source system data into database-independent format
- Transfer of the exported files to the target host
- New system installation together with data import
- 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:
- Tools used at the export on the source system must have the same version as on the target system.
- 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).
- 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.
System Copy and Migration
Introduction
Getting Started
- In this shortoverview presentation, get a quick overview of the system copy and migration with software provisioning manager 1.0.
- In this short technical details presentation, get technical details and a quick overview how the system copy and migration process looks like with software provisioning manager 1.0.
- Explanation of Terms provides a quick overview of the terminology used for SAP system copies.
- Heterogeneous ABAP System Copy - Technical Overview: If you are involved in a migration process (be it as administrator, technical consultant or other project member) or just want to learn more about heterogeneous copies of ABAP systems, see this presentation to get a technical overview including involved tools and created files.
- SAP Note 784118 (System Copy Tools for ABAP Systems)
- FAQ - System Copy and Migration: frequently asked questions about the system copy and migration of SAP systems.
- SAP Note 547314 (FAQ: System Copy procedure)
- For troubleshooting information, see the list of Troubleshooting documents for Software Provisioning Manager
- The videoHow to Perform a System Copy Export (demo from Stefanie Gerbig) guides you through the export phase of an SAP system copy.
- The video How to Perform a System Copy Import (demo from Stefanie Gerbig) guides you through the import phase of an SAP system copy.
Migration to SAP HANA
For the migration to SAP HANA, several migration path options are offered - see the Migration of SAP Systems to SAP HANA page for an overview.
Especially for the classical migration to SAP HANA, see the corresponding Classical Migration to SAP HANA page that provides further information about the procedure and lists several best practices for this use case.
Further Information
- System copy and migration guides, available at http://help.sap.com/sltoolset→ System Provisioning→ System Copy Option.
- Best Practice Guide - Classical Migration of SAP NetWeaver AS ABAP to SAP HANA
- In addition to standard system copy and database-specific procedures, the split-mirror solution (SMP login required) uses storage technology to create a split-mirror image of a single system or a system landscape. For more information, navigate to Storage - Split Mirror Solutions.
- SAP Note 954268 (Optimization of export: Unsorted unloading)
- SAP Note 1918774 (Performance issues when running a SAP Installation / System Copy)
- For information about how to handle landscape data in the system landscape directory (SLD) in the course of a system copy, see the blog How to Deal with Landscape Data Created during System Copy and the Landscape Management page.
Possible Alternatives
- 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. For more information about our offering for the automation of post-copy activities, see also this overview presentation.
- For certain use cases, the system rename procedure might be a faster alternative to the classical homogeneous system copy procedure, as it allows to quickly adapt key characteristics - such as hostname, instance number, or system ID (SAP system ID or database system ID) - of an existing SAP system or to make cloned systems operational (for example, by using 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).
How to Get It?
Get the latest version of both the tool and the guide valid for several product versions and containing latest features and fixes at: http://help.sap.com/sltoolset→ System Provisioning.
The guides describe the export procedure of the source system as well as the import procedure on the target system based on software provisioning manager 1.0. Post-copy activities required for systems based on SAP NetWeaver are also covered. SAP Support can only provide optimal support for copied systems that have been copied using one of the procedures described in the guide
Feature Requests
SAP Add-On Assembly Kit
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
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!
Classical Migration to SAP HANA
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:
- 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.
- You perform an export of your traditional source database in a database-independent format.
- You create your target system on SAP HANA by using the database load exported in the previous step.
- 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:
- 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:
DGP - Downgrade Protection for CTS
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
Installation
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.
Minimize your downtime of an update
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.
Transport buffer with wrong sequence of transports
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.