【IT168 技术文章】

    当用户修改表结构时，SAP会自动创建临时表，临时表的名称为:'QCM' +表名。这个临时表用于先将需要改变结构的表数据保存下来，当新表结构完成后，系统会将临时表的数据拷贝回数据表。

    临时表在SAP3.0版本前始终保存在数据库中，3.0以后版本只有在数据拷贝不成功时才保存在数据库中，否则会自动删除。

    如果要删除这些临时表，用户可以执行Tcode：se14->Extras ? Invalid temp. table 进行查询和删除。

    注意：当你要进行系统拷贝时，你必须在"export", 必须从系统中删除这些QCM表，否则导入会出错.

    SAP关于修改表结构时发生的操作说明如下：

    Conversion Process

    Table TAB was changed in the ABAP Dictionary. At this time the length of a field (Field 3) was reduced from 60 to 30 places. The ABAP Dictionary therefore contains an active version (where the field has a length of 60 places) and a revised version (where the field only has a length of 30 places) of the table.

    The active version of the table is created in the database, that is Field 3 currently has 60 places in the database. Two secondary indexes that were also created in the database are defined in the ABAP Dictionary for the table. The table already contains data.

    Reducing the length of a field results in a table conversion. The table is converted in a series of 7 steps.

    Step 1: Set Lock

    The table is locked against further structural changes. This lock mechanism prevents a new structural change from being made before the conversion has finished correctly.

    All the views that use the table are deleted from the database.

    Step 2: Rename Table

    The table is renamed in the database. All indexes on the table are deleted. The name of the new table consists of the prefix QCM and the table name. The name of the temporary table for table TAB is thus QCMTAB. If in the database a table named QCMTAB already exists (for example, from a previous conversion attempt), this table is deleted before renaming the table.

    Step 3: Activating Tables

    The revised version of the table is activated in the ABAP Dictionary. Thus the ABAP Dictionary contains only one active version of table TAB, in which field 3 has a length of 30.

    The table TAB is created in the database with its new structure under the name QCM8TAB. In addition, the primary index of the table is created in the database. The structure of database table QCM8TAB thus corresponds to the structure of table TAB in the ABAP Dictionary after this step. The database table does not, however, contain any data.

    Step 4: Reload Data

    The data is copied from table QCMTAB to table QCM8TAB (with the ABAP command MOVE-CORRESPONDING). After this step, the data is present in both tables, requiring additional space. Before converting large tables, you should therefore check whether the relevant tablespace has enough space left.

    You can find information about how existing entries are handled in a field when the field type changes in the ABAP documentation about the MOVE-CORRESPONDING statement.

    When you copy data from table QCMTAB into table QCM8TAB, a database commit is stored after 16 MB. The conversion process therefore needs 16 MB of resources in the rollback segment.

    When the length of a field is reduced, the extra places are truncated when the field is reloaded. When the length of a key is reduced and there are several records whose new key cannot be distinguished, only one of these records can be reloaded. In general it is not possible to determine in advance which record this will be. In such a case, you should clean up the data of the table before conversion.

    Step 5: Delete the QCM Table

    The data in table QCMTAB is no longer required at the end of the conversion. The table is therefore deleted, provided that all records could be copied from table QCMTAB into table QCM8TAB. If duplicate records appeared in table QCM8TAB, for example, because the key of table TAB was shortened, table QCMTAB is kept for safety reasons.

    Step 6: Rename Table and Create Secondary Indexes

    Table QCM8TAB is renamed to TAB. The secondary indexes on the table defined in the ABAP Dictionary are newly created in the database. The views on the table that were deleted in the first step are also newly created in the database.

    Step 7: Remove the Lock

    The lock set at the beginning of the conversion is removed.

    The table data is only consistent again once Step 4 has been completed. For this reason, programs must not access the table while the conversion is running. Otherwise a program could behave incorrectly when reading the table since some of the records were not yet copied back from the temporary table. For this reason conversions may not be running during production. At least all the applications that use the table to be converted must be deactivated.

    If the conversion terminates, the table stays locked is a reset log is written. Each successful step of the conversion is recorded in this reset log. The restart log is deleted together with the lock when the conversion has been completed. If the conversion terminates (see

    You must clean up terminated conversions!

    Programs that access tables might otherwise not execute correctly. You must find out why the conversion terminated (for example overflow of the corresponding tablespace) and correct it. You must then continue the terminated conversion (see Conversion Problems), you can find the place where the conversion terminated in the reset log (last step to be executed).Continuing Terminated Conversions).

    The following example shows the steps necessary for a conversion

    Initial Situation