SAP Note 24864 - No conversion of the table BSEG

Symptom:

The table BSEG is to be converted, for example, during the import of a Support Package or during an upgrade. In this case, the following problems may occur:

1. Extremely long runtimes (for example, upgrade phase PCON_).

2. Terminations due to a lack of memory space in the database.

3. In very old releases, the number of fields in the table BSEG exceeds the number of columns that can be processed by the database management system. For Oracle versions lower than Version 8.1024, for example, the following error occurs as a result:
'ORA-1792: maximum number of columns in a table or view is 254'

Other terms

BSEG, ORA-1792, conversion, SE14, SE11, extreme runtime, upgrade, SPDD

Reason and Prerequisites

The table BSEG is usually a very large SAP cluster table. Due to the volume of data, a conversion of this table is often completely impracticable. We do not deliver any changes that would result in a conversion of the table BSEG during which it would be completely unloaded and reimported.

During an upgrade, we only add new fields or change field attributes that are not relevant for the conversion.

• Up to and including SAP_BASIS 6.40, new fields had to be added to the end of the table to prevent a conversion from occurring.

• As of SAP_BASIS 7.00, new fields can also be inserted between existing fields without a conversion occurring. In addition, appends are supported.

Possible reasons for a conversion are:

• Fields are deleted. A typical scenario is as follows: In the upgrade or SPAM/SAINT activation phase, the default value generated by transaction SPDD is not accepted. Instead, the decision is made to return to the standard SAP system. As a result, customer-specific fields are removed.

• Up to and including SAP_BASIS 6.40: New fields are inserted between existing fields or the sequence of the fields is changed.

• The field type or the field length is changed. This may also happen indirectly due to modifications of domains or data elements.

• The table is to be made transparent.

• Activation errors lead to an unjustified conversion of cluster tables (for example, see Note 1283197).

For the conversion of cluster tables, a transparent interim table is required. However, it may not be possible to create it because the maximum number of fields is exceeded. The conversion requires an extremely large amount of space in the database because the temporary interim table must include all of the rows of the table BSEG. The space requirement for the table BSEG is higher by factors than the space requirement for the table RFBLG.

Solution

Do not convert the table BSEG.

If possible, avoid all of the modifications mentioned above and do NOT decide to return to the standard SAP system during the SPDD run. If you notice a conversion (for example, in the test system), determine the reason for the conversion before you make the relevant changes in the productive systems.

If the conversion has already started and terminated, the repair is difficult and time-consuming. In this case, you must first check how far the conversion has advanced. To do this, use the restart log of the database utility (call transaction SE14, enter BSEG, and analyze the adjustment).

1. Resetting the conversion and correcting the field list

If step 2 of the conversion has not yet been completed (that is, if this step has not yet been selected in the restart log), the source table has not yet been changed. Only reset the adjustment (unlock the conversion) in this case. The relevant function is available in transaction SE14. You must then correct the field list of the table BSEG and activate it. In this case, the following applies:
a) Insert all of the removed fields again.
b) During the upgrade, do not remove any new standard fields that were added.

Due to point b), you must not use version management to simply return to an older version of the table BSEG. Instead, you must manually create a field list that does not lead to a conversion.

As of SAP_BASIS 7.00 (for example, ECC 6), it is sufficient to include all fields with the same length and the same type in the inactive DDIC source again. The sequence is irrelevant. However, you must ensure that Note 1283197 is implemented in the system. If possible, customer fields should be stored in customer-specific appends.

For systems with SAP_BASIS lower than Release 7.00 (R/3 Enterprise, ECC 5), you must restore exactly the original field sequence. To do this, you can use the active runtime object (nametab), which you can display in transaction SE37 by testing the function module DD_SHOW_NAMETAB. This runtime object still displays the fields that may have been removed from the field list and their previous position. However, it is easier to look up the original structure in a second system. If you have set the field list to the correct status, a conversion request will no longer be displayed when you check the table BSEG in transaction SE11. Only continue an upgrade if you have reached this status.

2. Complete conversion or restore:

If step 2 has already been completed, however, you can continue the conversion after you provide a sufficient amount of space in the database. In some cases, the runtimes will be extremely long. Resetting the adjustment (unlocking the conversion) is not possible at this advanced stage. In each case, check whether the primary index of the underlying physical table (RFBLG) exists. A missing primary index increases the runtime problem. Use the database utility (transaction SE14 for pool tables or cluster tables) for the existence check.
It may also make sense to restore the system to the status before the conversion.