TENSIÓN ALTA
D. Teclas de funcionamiento y reinicio
5.4 Programación básica
The Migration Project
Unit Overview
Unit Objectives
After completing this unit, you will be able to:
• Describe the scope of services performed by the SAP OS/DB Migration Check • Estimate the effort involved in a migration
• Plan a migration project
Unit Contents
Lesson: The Migration Project ... 24 Exercise 2: The Migration Project ... 37
Lesson: The Migration Project
Lesson Overview
Contents
• Project Schedule of an OS/DB Migration
• Drawing Up a Project Schedule for the SAP OS/DB Migration Check
Lesson Objectives
After completing this lesson, you will be able to:
• Describe the scope of services performed by the SAP OS/DB Migration Check • Estimate the effort involved in a migration
• Plan a migration project
Business Example
You want to setup an OS/DB Migration project. You need to know which steps are required and what can be a reasonable time line to finish the tasks.
TADM70 Lesson: The Migration Project
Migration requests can be directed to the local SAP Support Organization or to the local customer SAP contact (i.e. Customer Interaction Center).
An introductory phase applies to new SAP products only. If mentioned in a system copy SAP Note, customers must register to the introductory phase before starting the OS/DB Migration. In such a case, it was decided that this particular product can only be migrated under SAP's control (providing direct support from SAP development in case of problems). Usually the introductory phase is limited to few months only. Customer projects with required SAP involvement can be i.e. “Pilot Projects” or a “Minimized Downtime Service” (MDS) for very large databases.
The standard OS/DB migration procedure applies also to heterogeneous system copies of ABAP Systems in “Introductory Phase Projects” or “Pilot Projects”. The project type specific activities can be seen as something over-and-above a standard migration procedure.
Figure 19: Project Schedule of an OS/DB Migration (2)
Prepare for the “SAP OS/DB Migration Check Analysis Session” as soon as possible. It runs on the productive SAP System (the source system) and must be performed before the final migration.
Migration test-runs are iterative processes that are used to find the optimal
configuration for the target system. In some cases, one test-run suffices, but several repeated runs are required in other cases.
The same project procedure applies to both the operating system migration and the database migration.
Test and final migrations are mandatory for productive SAP Systems only. Most other SAP Systems like development, test or quality assurance are less critical. If the first test-run for those systems shows positive results, an additional migration-run (final migration) is not necessary. Nevertheless, the schedule defined in the “SAP OS/DB Migration Check Project Audit questionnaire” must reflect test-runs and final migrations for all SAP Systems of the customer landscape.
The “SAP OS/DB Migration Check Analysis Session” will be performed on the production migration source system and the “SAP OS/DB Migration Check Verification Session” will run on the migrated production system after the final migration.
Figure 20: Time Schedule for Productive SAP Systems
You should begin planning a migration early. If you procure new hardware, there may be long delivery times.
The time which is necessary to do serious tests varies from system to system. Allow at least two weeks!
SAP recommends to wait with a SAP release upgrade on a migrated productive system for 6 weeks! First get the system stable and then do the upgrade!
SAP will schedule the “SAP OS/DB Migration Check Analysis Session” only if the “Remote Project Audit Session” was completed successfully.
TADM70 Lesson: The Migration Project
Figure 21: Migration Partners
The above requirements refer to the technical implementation of the migration. Application-specific tests require knowledge of the applications.
ABAP Dictionary knowledge is required for System copies based on R3LOAD. Understand consequences of missing objects on database and/or SAP ABAP Dictionary.
A method to verify, that all tables in the R3LOAD structure files can be exported without problem, would be a compare of the table names from the structure file against the ones from the database catalog. The more easy way is a test export.
Useful SAP Notes are:
• 9385 What to do with QCM tables (conversion tables)
• 33814 Warnings of inconsistencies between database & R/3 DDIC (DB02)
Figure 22: Contractual Arrangements
Database or operating system specific areas in the SAP Service Marketplace may not be visible to the customer unless the contractual agreement regarding the new configuration is finalized with SAP.
The “SAP OS/DB Migration Check” is mandatory for each productive system, but not for development, quality assurance, or test systems.
A productive system can be a stand-alone ABAP system, but it can also be an ABAP Web AS with an JAVA Add-in, or an ABAP Web AS with a JAVA Web AS, each using its own database. The services are checking the parameters for ABAP and JAVA-based systems.
A heterogeneous system copy of a stand-alone JAVA system means that no ABAP system is copied in the migration project.
Figure 23: Hardware Procurement
For safety reasons, an OS/DB migration of productive SAP Systems must always be performed in a separate system. For this reason, should serious problems occur, you can always switch back to the old system. Retaining the old system also simplifies error analysis.
When you change the database, consider the new disk layout. Each database has its own specific hardware requirement. From a performance point of view, it might not be sufficient to provide a duplicate of the current system.
TADM70 Lesson: The Migration Project
Figure 24: Migrating a SAP System Landscape
Each productive system must be migrated twice (test and final migration)!
Development, test und quality assurance systems are less critical and can often be migrated in a single step.
In many cases, the migration of a quality assurance system is not necessary, because it can be copied from the migrated production system.
Figure 25: SAP OS/DB Migration Check Project Audit
The “SAP OS/DB Migration Check Project Audit Questionnaire” will automatically be sent from SAP to the customer, as soon as the “SAP OS/DB Migration Check” was requested.
The migration project time schedule should be created in consultation with the migration partner.
For safety reasons, SAP cannot approve any migration of a production SAP System in which the source system is deleted after the data export in order to set up the target database.
Make sure to include the dates for test and final migration steps of every SAP System, not only for productive systems.
The migration project schedule must reflect correct estimates of the complexity of the conversion, its time schedule, and planned effort.
SAP checks for the following:
• Is the migration partner technology consultant SAP-certified for migrations? • Does the migration project schedule meet the migration requirements? • Technical feasibility. Are hardware, operating system, SAP System, and
database versions compatible with the migration tools, and is this combination supported for the target system?
The migration of an SAP System is a complex undertaking that can result in unexpected problems. For this reason, it is essential that SAP has remote access to the migrated system. Remote access is also a prerequisite for the “SAP OS/DB Migration Check”.
Figure 26: SAP Migration Tools
TADM70 Lesson: The Migration Project
Only for those SAP installations that are running old database or operating systems (which are no longer supported by current installation software 4.6D and below), it may be necessary to order the Migration CD set. Most questions regarding tool versions are answered in the SAP System copy notes and manuals. Also check the “Product Availability Matrix” (PAM) in the SAP Service Marketplace. Please open a call at the SAP Service Marketplace if in doubt about which tools to use in certain software combinations.
In some cases it is advisable to upgrade the operating system, database or SAP release first, before performing the migration. In rare cases if can be even necessary to use intermediate systems.
Figure 27: SAP OS/DB Migration Check Analysis
The “SAP OS/DB Migration Check Analysis Session” is focused on the special aspects involved in the platform or database change. It is performed on the production SAP System with regard to the target migration system environment.
The results of the “SAP OS/DB Migration Check” are recorded in detail and provided to the customer through the SAP Service Marketplace. They also include recommendations for the migration target system.
Figure 28: Required Source System Information (1)
It must be carefully checked that all software components can be migrated – in particular JAVA-based components!
The exact version information of each software component is necessary to be able to download/order and use the right installation software. It could be the case, that a certain Support Package Stack must be installed before a OS/DB migration can take place (i.e. certain target database features can be utilized only if the Support Packages are current). Updating Support Packages can be a serious problem in some customer environments, because of modifications, system interdependencies, or fixed update schedules.
The current system landscape must be known to have the big picture. There may be OS/DB related dependencies between certain systems which must be analyzed first. The number of productive systems indicates the number of test and final migrations Which systems should be migrated in which order? What is the customer time schedule (deadlines)?
When minimizing the downtime, the amount of tuning efforts that are necessary increases and much more time must be spend on it.
In case of a hosting environment, will the consultant have access to the source system (which limitations will apply)?
TADM70 Lesson: The Migration Project
Figure 29: Required Source System Information (2)
The number of CPUs and information about the I/O sub system can help in determining the best number of export processes.
The sizes of the source databases indicate how long the migration will take. Next to the database size itself, the size of the largest tables will influence the export significantly. For the first test migration 10% - 15% of the source database size should be available as export file system free space.
If large tables are stored in separate locations (i.e. table spaces), should this also be retained in the target database? On some databases it can increase performance or ease database administration.
MDMP or UNICODE system? In case of AS/400 R/3 4.6C and below: is it an EBCDIC or ASCII based system?
Case 1: Table exists in database but not in the ABAP Dictionary - table will not be exported.
Case 2: Table exists in ABAP Dictionary but not in database – export errors are to be expected.
How to handle external files (spool files, archives, logs, transport system files, interfaces, ) ? Which files must be copied to the target system?
The migration support tools like MIGMON and the PACKAGE SPLITTER used by SAPINST will need JAVA. The old Perl-based PACKAGE SPLITTER of R3SETUP needs Perl version 5. Because of strict software policies, customers might not allow the installation of additional software on productive systems.
If source and target system are not in the same location – which media will be available to transport the dump files?
Figure 30: Required Target System Information
Figure 31: Migration Test Run
Generating the target database:
• Make a generous sizing of the target database, or set it to an auto extensible mode (if possible), this will prevent load errors caused by insufficient space. An analysis of disk usage cannot be performed until after the data has been loaded. Configuring the test environment:
• RFC connections • External interfaces • Transport environment • Backup • Printer • Archiving • etc.
TADM70 Lesson: The Migration Project
Figure 32: Final Migration
A cut-over plan should be created, including an activity checklist and a time schedule. Include plenty of reserve time. The migration of a production system is often performed under intense time pressure. Checklists will help you to keep track of what is to be done, and when to do it. Not all the tests and checks which were done during previous test runs must be necessarily done again in the final migration.
In most cases it makes sense to have one cut-over-plan for the technical migration, and a separate one for application related tasks.
Figure 33: SAP OS/DB Migration Check Verification
The “SAP OS/DB Migration Check Verification Session” should be scheduled 4 weeks after the final migration of the productive SAP System. This is because several weeks are required to collect enough data for a performance analysis. The “old” production system should still be available.
TADM70 Lesson: The Migration Project
Exercise 2: The Migration Project
Exercise Objectives
After completing this exercise, you will be able to:
• Create a migration project plan and a time schedule that is compliant to SAP needs.
Business Example
To plan a system copy project, you must know about the proper timing and the required test phases. The database size will influence the expected downtime. You should know about the tasks of each OS/DB Migration Check service component and how many services are required in a specific customer project.
Task 1:
The SAP heterogeneous system copy procedure for productive systems requires a test phase between test and final migration, and also recommends not performing an upgrade to the next SAP System release until at least 6 weeks after the final migration. 1. What is the minimal duration recommended for the test phase?
2. What should be done in the test phase, and who should perform it?
3. What is the reason for the recommended time duration between final migration and the next upgrade?
Task 2:
A customer SAP System landscape is made up of several systems. All systems have to be migrated to a different database.
System set 1 (ERP): Development, Quality Assurance, Production. System set 2 (BW): Development, Production.
1. How many SAP OS/DB Migration Checks must be ordered?
2. How many system copies are involved? (More than one answer can be right)
Task 3:
The following facts as listed below are known in inspecting the source system of a migration (ABAP Web AS with JAVA Add-In). Please indicate for every item what the impact on the R3LOAD/JLOAD migration will be.
1. The to total size of the database is 500 GB (used space).
2. The sizes of the largest ABAP tables are 34 GB, 20 GB, 18 GB.
3. The sum of all tables and index sizes of the JAVA schema does not exceed 2 GB. 4. Transaction DB02 shows two tables belonging to the ABAP schema user that
only exist on the database, but not in the ABAP Dictionary.
Task 4:
The SAP OS/DB Migration Check sessions have three major topics. Please explain the main tasks of each session type.
1. Project Audit Session 2. Analysis Session 3. Verification Session
TADM70 Lesson: The Migration Project
Solution 2: The Migration Project
Task 1:
The SAP heterogeneous system copy procedure for productive systems requires a test phase between test and final migration, and also recommends not performing an upgrade to the next SAP System release until at least 6 weeks after the final migration. 1. What is the minimal duration recommended for the test phase?
a) Two weeks is the minimum amount of time to be considered between the test and final migration of a productive system.
2. What should be done in the test phase, and who should perform it?
a) The test phase should be utilized to check the migrated system regarding the most important customer tasks and business processes. End users who know their daily business very well should do the major part of the testing. Two weeks might be sufficient even in complex environments.
3. What is the reason for the recommended time duration between final migration and the next upgrade?
a) Every time a system has been copied to a different operating system and/or database, it takes some time to get familiar with it and to establish a smooth-running production environment. In the case that an upgrade immediately follows the migration, the direct cause of the problems may be hard to identify. First get the system stable and then do the upgrade!
Task 2:
A customer SAP System landscape is made up of several systems. All systems have to be migrated to a different database.
System set 1 (ERP): Development, Quality Assurance, Production. System set 2 (BW): Development, Production.
1. How many SAP OS/DB Migration Checks must be ordered?
a) System sets 1 and 2 contain productive systems. Because of this, two separate SAP OS/DB Migration Checks must be ordered.
2. How many system copies are involved? (More than one answer can be right) a)
System set 1:
1 x Development, 1 x Quality Assurance, 2 x Production. Alter-
nate:
1 x Development, 2 x Production, homogeneous system copy from Production to Quality Assurance.
System set 2:
1 x Development, 2 x Production.
Task 3:
The following facts as listed below are known in inspecting the source system of a migration (ABAP Web AS with JAVA Add-In). Please indicate for every item what the impact on the R3LOAD/JLOAD migration will be.
1. The to total size of the database is 500 GB (used space).
a) From a database size of 500 GB it can be expected, that the R3LOAD / JLOAD export will need about 10% - 15% (50 GB - 75 GB) of local disk storage.
2. The sizes of the largest ABAP tables are 34 GB, 20 GB, 18 GB.
a) The largest ABAP tables will significantly influence the amount of time necessary to export or import the database. A single R3LOAD process for each large table will improve the export and import time.
3. The sum of all tables and index sizes of the JAVA schema does not exceed 2 GB. a) Because the JAVA tables will only need a little bit of time to export, this
will not be critical for the overall export time.
4. Transaction DB02 shows two tables belonging to the ABAP schema user that only exist on the database, but not in the ABAP Dictionary.
a) R3LDCTL only reads the ABAP Dictionary. Tables that exist on the database, but not in the ABAP Dictionary, are ignored. As a consequence they are not inserted into any *.STR file. The same happens to tables belonging to the JAVA schema, but are not defined in the JAVA Dictionary. They will not be exported.
TADM70 Lesson: The Migration Project
Task 4:
The SAP OS/DB Migration Check sessions have three major topics. Please explain the main tasks of each session type.
1. Project Audit Session a) Project Audit Session:
Checks for technical feasibility, certified migration partner, and time schedule.
2. Analysis Session a) Analysis Session:
Performance analysis on source system. Returns configuration and parameter recommendations for the target system.
3. Verification Session a) Verification Session:
Performance verification on the target system after going live. Returns updated configuration and parameter recommendations.
Lesson Summary
You should now be able to:
• Describe the scope of services performed by the SAP OS/DB Migration Check • Estimate the effort involved in a migration
TADM70 Unit Summary
Unit Summary
You should now be able to:
• Describe the scope of services performed by the SAP OS/DB Migration Check