This action might not be possible to undo. Are you sure you want to continue?
Before you Begin 1. If you have never yet worked with Transaction IMIG, please first read the 'Short Instructions' to become familiar with the most important functions. 2. Also read Note 353558 in the Online Service System (OSS), which describes the entire incremental migration process. Also read the notes referred to in Note 353558. 3. Use the F1 help for the displayed information. For example, place the cursor on the column 'Status' in the status overview and press F1. This gives you a detailed explanation of the displayed information.
Short Instructions To reduce the downtime during a migration, you can migrate tables incrementally. You can work productively with the table during the migration. The following steps are necessary for an incremental migration of a table: 1. Make general preparations: a) Choose Migration -> Setup Parameters to specify the R3SETUP and export directory. You have to do this in the source system and in the temporary target system. In the source system you also have to enter the RFC destination of the temporary target system. b) Choose Migration -> Generate R3S Files to generate the IMIG- specific R3SETUP templates (EXPREST.R3S, EXPTAB01.R3S, and so on). 2. Enter the table for migration you can add a transparent table, a physical table cluster or a physical table pool to the worklist with Edit -> Add table. [Details] [Details] Enter Tables for Migration Background If you enter a table for incremental migration, the table can still be migrated to the target database when the migrating system is being used for production. This table is no longer migrated with R3SETUP/R3load, so that the time span for migrating the rest of the table is proportionally shorter. Procedure With Edit->Add table you can mark a table for migration. In addition to transparent tables, physical cluster and physcial pooled tables can also be migrated incrementally, that is the incremental migration of a physical cluster or pooled table also causes the logical tables it contains to be migrated. The target for the migration must be specified as well as the table name. The target is the RFC destination of the target system, which must first be created with Transaction SM59. When you enter a table, the maintenance routine for the storage parameters for this table are called in the target system by RFC. You may and should now maintain the storage parameters of the table, taking the storage parameters in the starting system into consideration. This prevents problems during the data transfer of the migration.
3. Initialize The table must be prepared for the data transfer. You can do this with Control->Initialization. [Details] [Details] Initialization Background
Initialization prepares the table for the upcoming incremental migration. The following objects are created: 1. Table in the target system for holding the data. 2. Database trigger with 'Logging' table in the original system for recording all the changes to the original table. [Details] Technique of Incremental Table Migration Overall Procedure Incremental table migration is part of the overall migration and permits some larger tables to be migrated during production. The overall flow is described in detail in Note 353558 and basically comprises the following steps: 1. Installation of a SAP Basis System on the target database This system is only required temporarily and provides the infrastructure needed for an incremental table migration. 2. Import the IMIG package into the initial system and the temporary target system 3. Incremental migration of the largest tables to the target database (transaction IMIG and R3SETUP) 4. Reduced DROP of the temporary target system The tables that were migrated incrementally are retained. 5. Standard migration of the reamining initial system The tables that were already migrated are not taken into consideration. Since the large tables normally make up about 2/3 of the total size of a system, the downtime necessary for the final standard migration is substantially reduced by this procedure. Method A table with the same structure as the original table is created in the target system for the copied data. Transaction IMIG also creates database triggers in the initial system in connection with an additional 'Logging' table to record changes to the dataset of the original table. The 'Logging' table consists of the key fields of the original table and an additional field. This additional field contains information as to whether the original data was already copied to the target system or needs to be deleted (again) or modified there, so that the data transfer process can use these values to decide what should happen with the original data. Changed or deleted data records are marked in the 'Logging' table with an update or delete trigger. New data records are inserted in the 'Logging' table with an insert trigger. The original table to be migrated can be accessed for reading and writing by any application programs during the whole time. The beginning of downtime for a table only starts with the 'Switch' phase and can be controlled individually. Performance It is logical that the runtime of database operations that write to the original tables can be slowed down considerably by the additional update, delete and insert triggers. The effect on the overall performance, however, is not so serious because the access to the tables to be migrated normally makes up only a small part of an application transaction.
3. Procedure Choose Control->Initialization. All the tables that can be initialized are offered here. After selecting the required table(s) you can define when initialization should take place. The table can still be used productively during this phase. 4. Initial migration Use R3SETUP -f EXPTAB01.R3S to export all initialized tables. In the target system, the data is imported using R3SETUP -f IMPTAB01.R3S.
5. Start data transfer Start the data transfer with Control -> Data transfer -> Start. [Details] [Details] Data Transfer Background During the data transfer, the data records of the orignal table are read, compressed, copied to the target system of the migration by RFC and entered in the target tables. The information is taken from the 'Logging' table to ensure that the target data is consistent. Procedure The number and type of necessary background processes as well as the tables to be processed at the moment are defined automatically by the incremental migration process. You have the following options: 1.Start with Control->Data transfer->Start. A number of background processes are scheduled for the data transfer. If there are restrictions concerning the server or the number of processes, this is taken into consideration. Please read how to define such restrictions in point 4 'Restricting the Use of Resources'. 2.Stop with Control->Stop all. The data transfer is stopped and scheduling for all the background jobs is canceled. Processes that are running at the moment get a termination signal. If the processes are just executing a complicated database operation, you cannot apply this signal immediately, and the process is terminated after a delay. You therefore should execute the function repeatedly until all the processes have stopped. 3.Optimize with Control->Data transfer->Optimize. There is a check to find out how many background processes are available on the allowed servers and whether the number of background processes is restricted. The number of processes needed for the IMIG requirements is also determined. If necessary, other background processes are scheduled or existing processes are unscheduled. 4.Restricting the Use of Resources: To set the list of the application servers on which IMIG processes may run, choose Edit -> Options -> Server Selection. If nothing is set, any number of background application servers is used. You can set the maximum number of background processes that may be reserved by IMIG by choosing Edit -> Options -> Process Selection. You can set the time interval in which data transfer processes can be started by choosing Edit -> Options -> Scheduler Interval. 5.Define Exclusion Times In addition to restricting the resource requirements as described above, you can define when the data transfer should be stopped for each individual table with Control->Exclusion times. If you do not define any value here, the data transfer is always possible as long as the relevant table is in state 'Migration'. 6. Monitor and analyze Themgration will take some time, depending on the size of the tables. a) Choose View -> Performance Analysis to get detailed statistics about the progress. Since application transactions can insert, change, and delete data records during production operation, these numbers eventually become imprecise. b) You can therefore update the statistics at any time with Utilities -> Compute progress. Note that this is a time- consuming operation depending on the data volume. c) Execute Control -> Data Transfer -> Optimize occasionally so that there are always enough jobs scheduled.
7. Switch to the new table Choose Control -> Switch to display a selection screen that offers the tables that can be switched. [Details] [Details]
Switch Background The switch marks the beginning of downtime for the table to be migrated. Once you have started the switch, you can no longer access the table for production. During switching, the data that was not yet migrated is copied from the original table to the target table (last data transfer). The system makes sure that no more changes can be made to the original data. The original table is then renamed on the database and is no longer visible to the SAP System. To keep the non-productive switch as short as possible, the data transfer should be nearly complete (at least 95% for each individual table). The renamed table is given its old name when the rest of the system is exported with R3SETUP, so that it is again available for production after completion of the export. Procedure The switch is made with Control->Switch. All the tables that can be switched are displayed. After selecting the required table(s), you can define when they should be switched. Note that the start of the switch (for the first table) marks the beginning of downtime for this table. You therefore should only start the switch shortly before the migration of the rest of the system.
8. Prepare remaining export You can start the remaining export by choosing Migration -> Prepare Remaining Export. This also generates control files for the reduced drop of the temporary target system. [Details] [Details]
Prepare Remaining Export Background This action makes some final consistency checks and then generates the R3S file DRPBASIS.R3S for the reduced drop of this system. The incrementally migrated tables are renamed in the source system to ensure data consistency. Procedure Perform the following actions shortly before you want to start the export of the original system by using R3SETUP control. 1. To ensure data consistency, lock the system and reboot all application servers. 2. For all tables that you want to incrementally migrate, perform the Switch step. 3. Choose Migration -> Prepare Remaining Export.
9. Perform remaining export Use R3SETUP -f EXPREST.R3S (source system) and R3SETUP -f IMPREST.R3S (target system) to migrate the remaining system. You can also perform the following special actions: Reset Choose Control -> Reset to remove the tables from the worklist of the incremental migration. [Details]
[Details] Reset Background When you reset the incremental migration of a table, the entire migration work done for this table is lost. This function can be used for all the table types (transparent, cluster, pooled) edited with
Transaction IMIG. Resetting could be necessary if the data transfer to the target system was not fast enough, for example the percentage of migrated data for this table grows too slowly or not at all, so that the scheduled starting time for the downtime for the rest of the migration is endangered. If a table was reset, it is copied to the target system later on with the remaining export. The table can still be used productively in the original system while and after being reset. Procedure If necessary, choose Control -> Reset. You can then delete the table from the IMIG worklist by choosing Control -> Delete Entry.
Delete entries Choose Control -> Delete Entry to display a selection screen of the tables that may be removed from the worklist. [Details]
[Details] Delete Entries Background When you remove a table, it can be used again for production in the original system of the migration. The locks on the table in the R/3 Dictionary are removed and the logs of the migration are deleted. Please note that the changes to the data of this table are NOT copied to the target system of the migration! Procedure Remove the table with Control->Delete entry.
Procedure in Case of Problems Read the Notes about incremental migration (especially Note 353558) in the Online Service System (OSS). You can correct a number of problems yourself by noting the following: 1. Detecting the problem If Transaction IMIG does not work as you expected, try to detect the problem before performing other functions. The most important errors are displayed by Transaction IMIG itself. If the table is marked as incorrect in the 'Process' column, there is definitely a problem. In this case an error occurred during initialization or when switching the table. Please analyze this error in both the source and target systems with Utilities->Logs (place the cursor on the appropriate table). Also read the log texts for the error messages. 2. Not all of the problems are so easy to detect. You should therefore read the list of typical error situations and also use the error analysis tools. 3. Correcting the error Once you have detected the error and found a relevant Note, you can go about correcting the error. If necessary ask your system or database administrator to help you. 4. Repeating the incorrect process
Fundamentals Technique of Incremental Table Migration Overall Procedure
Incremental table migration is part of the overall migration and permits some larger tables to be migrated during production. The overall flow is described in detail in Note 353558 and basically comprises the following steps: 1.Installation of a SAP Basis System on the target database this system is only required temporarily and provides the infrastructure needed for an incremental table migration. 2.Import the IMIG package into the initial system and the temporary target system 3.Incremental migration of the largest tables to the target database (transaction IMIG and R3SETUP) 4.Reduced DROP of the temporary target system ,the tables that were migrated incrementally are retained. 5.Standard migration of the remaining initial system the tables that were already migrated are not taken into consideration. Since the large tables normally make up about 2/3 of the total size of a system, the downtime necessary for the final standard migration is substantially reduced by this procedure. Method A table with the same structure as the original table is created in the target system for the copied data. Transaction IMIG also creates database triggers in the initial system in connection with an additional 'Logging' table to record changes to the dataset of the original table. The 'Logging' table consists of the key fields of the original table and an additional field. This additional field contains information as to whether the original data was already copied to the target system or needs to be deleted (again) or modified there, so that the data transfer process can use these values to decide what should happen with the original data. Changed or deleted data records are marked in the 'Logging' table with an update or delete trigger. New data records are inserted in the 'Logging' table with an insert trigger. The original table to be migrated can be accessed for reading and writing by any application programs during the whole time. The beginning of downtime for a table only starts with the 'Switch' phase and can be controlled individually. Performance It is logical that the runtime of database operations that write to the original tables can be slowed down considerably by the additional update, delete and insert triggers. The effect on the overall performance, however, is not so serious because the access to the tables to be migrated normally makes up only a small part of an application transaction.
Resource Requirements Meaning of the Background Work Proccesses Transaction IMIG executes nearly all the processes in background jobs. This includes initializing the tables, data transfer, switching and also calculation of the progress of the migration. All these processes are automatically distributed on jobs. The user of Transaction IMIG simply triggers the processes by pressing the appropriate buttons. The transaction then makes sure that there are enough jobs scheduled. These jobs can only be executed if there are enough background work processes available in the system.
If you notice that operations triggered in IMIG only execute after a long delay, the background work processes are probably busy with other programs. In this case you should increase the number of processes to improve the runtime behavior of the transaction. This number is defined with the profile parameter 'rdisp/wp_no_btc' for each application server. You can use Report 'RSPARAM' to get the current setting. If you want to change this parameter, please contact your system administrator. Restricting IMIG to Certain Application Servers: With Edit->Options->Server selectionyou can restrict IMIG to certain application servers. In this way you can make sure that certain servers are not used by Transaction IMIG. Restricting the Number of Background Processes Used: With Edit->Options->Process numberyou can define the maximum number of background work processes that may be used by Transaction IMIG. This prevents a too heavy load on the system. Space on the Database A temporary table (for recording changes) including an index is created for each table to be migrated incrementally. This table is normally considerably smaller than the original table since it contains only the key fields of the original table plus a field of length 1. To create this table, however, the storage parameters of the original table and your indexes are used. The table that is to contain the migrated data is also created in the target system. During migration the space requirements for the target table increase to the size of the original table. You therefore should regularaly check if the database (in the target system) still has sufficient storage resources and if necessary supply more resources. Use for example program SAPDBA here or tools provided by the relevant database vendor. The original storage parameters of the target table can (and should) be maintained directly when you enter the table for the IMIG. If you nevertheless have to terminate a job due to lack of space, no damage will be done to the migration and work already done by the migration process is lost. In this case correct the shortage of resources and then execute Control->Data transfer->Optimize in Transaction IMIG.