Lesson 1
Identifying the Goals of ICNV
Lesson 2
Performing ICNV
UNIT OBJECTIVES
• Identify the goals of ICNV
• Perform ICNV
© Copyright . All rights reserved.
118
123
117
�
Unit 8 Lesson
1Identifying the Goals of ICNV
LESSON OVERVIEW
This lesson covers the goals of ICNV.
LESSON OBJECTIVES
After completing this lesson, you will be able to:
• Identify the goals of ICNV
Goals of ICNV
Early ICNV is not available when using resource minimized!
Reduction of update/upgrade downtime
• Large tables are now converted during uptime
• Only switch to new structure during downtime
(in PARCONV)
Easy handling
• Fully integrated into update/upgrade process
Configurable conversion process
• Exclusion times
• Progress prediction
Figure 98: Goals of Early ICNV
• The main goal of the ICNV is to reduce the downtime during an update/upgrade.
• The procedure should not be too complicated and it should be fully integrated into the update/upgrade process.
• The conversion process is executed during uptime. The database load is expected to be higher during this process; therefore. it is possible to define exclusion times during which no ICNV processes are running.
Lesson: Identifying the Goals of ICNV
View T1
Table QCM1T1 Table QCMT1
Table T1 (New structure)
Figure 99: Overview
Add Field (3)
Rename(2)
• Here is the sequence of steps during an incremental table conversion:
The conversion table candidates are selected.
(1) A QCM table with a new structure is created.
\(2) The table Tl is renamed to QCMlTl.
(3) An additional status field is added to QCMlTl.
Create (1)
( 4) A view on the old table structure is created. The applications access the view from now on. To log these changes the update (5) and the delete (6) trigger is needed
The table content is copied (low priority copy) to the shadow table QCMTl.
QCMTl is filled by periodic runs
• At beginning of downtime. only a few conversions should remain. The downtime due to table conversion is significantly reduced.
© Copyright . All rights reserved. 119
�
Unit 8: Incremental Table Conversion
Production
operation Active table (QCM1T1) Shadow table {QCMT1) Update
Delete
Insert
Missin Copy
1
MissingFigure 100: Need for Logging Mechanism
• A shadow table named QCMTl with is created the new structure.
• The data from the original table QCMlTl is copied using a background process during uptime to the shadow table QCMTl.
• QCMlTl is still accessible by the applications. Therefore the changes during the data transfer must be logged and also be executed on the shadow table.
• QC Ml Tl is modified by creating a flag field. This field indicates if this entry was already copied to the corresponding fields in QCMTL
• Programs can perform updates, deletes and inserts on QCMlTl.
Update of already converted entry: The "x" in the flag field is erased by the update trigger.
Deletion of already converted entry: The corresponding entry in the new table is directly deleted by the delete trigger.
Insert: The flag field for this entry is left empty.
• Every entry in table QCMlTl with an empty flag field is copied to QCMTl
• Periodically, the copy is repeated for all new rows since the last copy
Lesson: Identifying the Goals of ICNV
QCM1T1 Update
Delete
Delete trigger Insert
Copy
Figure 101: Logging Mechanism
• This could be the situation right after beginning of downtime:
QCMT1
Needs u date
Still missing
Some rows are updated or inserted but not copied yet (empty flag field).
There can be a part of the old table which has not been transferred to QCMTl (empty flag field).
• The latest insert/update operations and the remaining conversion will be processed during downtime.
• Inserting rows is possible without an additional load at that point in time, because no insert trigger is used.
• The update trigger is very efficient, because the additional load just consists of filling the flag field.
• Delete operations must be executed in both tables and are therefore inefficient.
• After the incremental conversion starts, dictionary definitions for the relevant tables cannot be changed until the upgrade ends. This affects changing, deleting or adding field definitions.
Transaction SEll is locked for these tables.
• If you use incremental table conversion, do not start an SAP archiving program for these tables in parallel, since this can lead to performance bottlenecks. Therefore, archive as much as possible before starting the conversion.
• Incremental conversion requires sufficient background work processes. Ideally, there should be one process for each table to be converted. If you cannot have one process for each table due to a large number of tables, you can still convert the tables since transaction ICNV
distributes the tables by itself to the available background processes. However, completing the incremental conversion takes longer. and therefore more time is needed before beginning the upgrade downtime.
© Copyright . All rights reserved. 121
�
Unit 8: Incremental Table Conversion
•Conversion of large tables during SAP system uptime Conversion process can be stopped and restarted
• Possible error situations during uptime
• ICNV especially suited for WORM tables
• ICNV is fully integrated into the update/upgrade
•Tables to be processed by ICNV can be selected
•Conversion process is configurable
• Additional resource usage of DBMS
• Sufficient number of background work processes
• Execute ICNV as early as possible Figure 102: Aspects of ICNV
• Because most data is converted before the beginning of downtime, downtime can be reduced by several hours. The actual reduction depends on the table size. The dependence of
downtime on the database size is also strongly reduced. The downtime can be predicted more accurately.
• The conversion process can be stopped and restarted at any time without loss of converted data.
• Error situations like table space overflow or reaching of maxextends due to the incremental conversion occur during uptime.
• ICNV is especially suited for large Write Once Read Many (WORM) tables Pay special attention to the resource usage of your database management system to detect bottlenecks early.
Incremental conversion requires double the space in the relevant database container (tablespace, dbspace, and so on) for each affected table during the conversion.
Due to the continuous data transfer, there are more transactions. Therefore, you should also monitor the space for the rollback information.
• Incremental conversion eventually requires more background work processes.
• Make sure, that at beginning of downtime most data is converted.
LESSON SUMMARY
You should now be able to:
• Identify the goals of ICNV