Upgrades (AS-ABAP) invariably lead to changes in the structure of database tables. Sometimes, this means that a complete restructure is necessary, with the conversion of each row in the table. In previous SAP Releases, this conversion occurred during upgrade downtime, so increasing that downtime. Incremental table conversion with transaction ICNV now lets you perform conversions before the upgrade, that is, during production operation.
The benefits of incremental table conversion are:
· Reduced downtime during upgrade
· Simpler conversion back to SAP standard for modified tables
· Conversion of large tables during production operation
· During the "prepare" phase of the upgrade, the system checks whether transaction ICNV can run with your database.
· If so, the system identifies all tables that might benefit from incremental conversion. For example, this includes tables containing large amounts of data, which would considerably extend the downtime of the upgrade.
· This all takes places automatically without any extra work.
If you have tables that might benefit from incremental conversion, then the system asks you in phase ICNVREQ to start transaction ICNV, leading to the following:
1. The system asks you:
a. Which modified tables you want to incrementally convert back to the standard SAP table definition
b. Which non-modified tables you want to incrementally convert
2. You start the incremental conversion.
3. You watch its progress.
4. The system estimates the time taken for the conversion, so helping you to plan the start of the upgrade.
The conversion is completed during upgrade downtime in phase PARCONV_UPG. Since most of the conversion has already been done, the downtime is significantly reduced.
Be sure to use the extensive online help with the ICNV transaction.
SAP recommends that you:
· Do not archive tables that are being incrementally converted. Instead, archive before the conversion.
· Do not attempt to modify tables that are being incrementally converted. These tables are locked until the end of the upgrade, so updates (including transaction SE11) are not possible.
· Observe the resource usage of the database so that you can spot bottlenecks early on. You might have problems because:
– Extra space is required, as each converted table has to be replicated before conversion
– Extra transactions are produced, leading to increased logging activity
· Make sure that enough batch work processes are available, preferably one batch work process for each table to be converted. If you are converting a large number of tables, transaction ICNV distributes the tables to the available batch work processes.
· Only start the upgrade when at least 95% of tables have been converted. This means that you have the greatest possible advantage in reducing downtime. You can easily observe the progress of the conversion using transaction ICNV.