-
8/8/2019 IMIG
1/7
Incremental Migration (IMIG)
Before you Begin1. If you have never yet worked with Transaction
IMIG, please first read the'Short Instructions' tobecome familiar
with the most important functions.
2. Also read Note 353558 in the Online Service System (OSS),
which describes the entire incrementalmigration 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' inthe 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 databasewhen 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 thedata 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
-
8/8/2019 IMIG
2/7
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 happenwith 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.
-
8/8/2019 IMIG
3/7
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 choosingEdit ->
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.
-
8/8/2019 IMIG
4/7
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 theswitch, 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 targettable
(last data transfer). The system makes sure that no more changes
can be made to the originaldata. 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, sothat it is again available for
production after completion of the export.ProcedureThe 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 ExportBackground
This action makes some final consistency checks and then
generates the R3S file DRPBASIS.R3S forthe reduced drop of this
system. The incrementally migrated tables are renamed in the source
systemto ensure data consistency.
ProcedurePerform the following actions shortly before you want
to start the export of the original system byusing 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 migratethe 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]ResetBackgroundWhen you reset the incremental migration
of a table, the entire migration work done for this table islost.
This function can be used for all the table types (transparent,
cluster, pooled) edited with
-
8/8/2019 IMIG
5/7
Transaction IMIG. Resetting could be necessary if the data
transfer to the target system was not fastenough, for example the
percentage of migrated data for this table grows too slowly or not
at all, sothat the scheduled starting time for the downtime for the
rest of the migration is endangered. If atable 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 bychoosing 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 EntriesBackgroundWhen 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 themigration!
ProcedureRemove the table with Control->Delete entry.
Procedure in Case ofProblems
Read the Notes about incremental migration (especially Note
353558) in the Online ServiceSystem (OSS).
You can correct a number of problems yourself by noting the
following:
1. Detecting the problemIf Transaction IMIG does not work as you
expected, try to detect the problem before performingother
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 thiscase an error
occurred during initialization or when switching the table.Please
analyze this errorin both the source and target systems
withUtilities->Logs (place the cursor on the appropriatetable).
Also read the log texts for the error messages.
2. Not all of the problems are so easy to detect. You should
therefore read thelist of typical errorsituations and also use the
error analysis tools.
3. Correcting the errorOnce 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
-
8/8/2019 IMIG
6/7
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 andcan 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 includesinitializing the tables, data transfer,
switching and also calculation of the progress of themigration. All
these processes are automatically distributed on jobs. The user of
TransactionIMIG simply triggers the processes by pressing the
appropriate buttons. The transactionthen makes sure that there are
enough jobs scheduled.
These jobs can only be executed if there are enough background
work processes availablein the system.
-
8/8/2019 IMIG
7/7
If you notice that operations triggered in IMIG only execute
after a long delay, thebackground work processes are probably busy
with other programs. In this case you shouldincrease 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 applicationserver. 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 applicationservers. In this way you can make sure that
certain servers are not used by TransactionIMIG.
Restricting the Number of Background Processes Used:With
Edit->Options->Process numberyou can define the maximum
number ofbackground work processes that may be used by Transaction
IMIG. This prevents a tooheavy load on the system.
Space on the DatabaseA temporary table (for recording changes)
including an index is created for each table to bemigrated
incrementally. This table is normally considerably smaller than the
original tablesince it contains only the key fields of the original
table plus a field of length 1. To createthis 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 theoriginal 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 forexample program SAPDBA here or tools
provided by the relevant database vendor. Theoriginal storage
parameters of the target table can (and should) be maintained
directlywhen 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 correctthe shortage of resources and then
execute Control->Data transfer->Optimize inTransaction
IMIG.
