Incremental Migration (IMIG)

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

The mgration 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 selection you 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 number you 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.