FAQ - ALPHA Conversion

Frequently Asked Questions - ALPHA Conversion

What is the "ALPHA conversion" about?
A characteristic in BW can use a conversion routine like the conversion routine called ALPHA. A conversion routine converts data that a user enters (in so called external format) to an internal format before it is stored on the data base.
The most important conversion routine - due to its common use - is the ALPHA routine that converts purely numeric user input like '4711' into '004711' (assuming that the characteristic value is 6 characters long). If a value is not purely numeric like '4711A' it is left unchanged.
We have found out that in customers systems there are quite often characteristics using a conversion routine like ALPHA that have values on the data base which are not in internal format, e.g. one might find '4711' instead of '004711' on the data base.
It could even happen that there is also a value '04711', or ' 4711' (leading space).
This possibly results in data inconsistencies, also for query selection; i.e. if you select '4711', this is converted into '004711', so '04711' won't be selected.

Why is the "ALPHA conversion" necessary?
In such a case, a number of problems can arise in reporting like wrong values of key figures, no data found for certain filter values...
The "conversion of internal characteristic values", in short term: "ALPHA conversion", is a transaction (transaction code RSMDCNVEXIT) that checks the format of all values of characteristics that use one of the conversion routines ALPHA, GJAHR and NUMCV.
If values are found that do not have the correct internal format it can replace them by correct value and update all dependant BW objects (like InfoCubes, Hierarchies, master data of other characteristics...).
This transaction potentially has to touch a very significant part of all the data in BW. While running the check or conversion phase of RSMDCNVEXIT no data loads of any kind are possible; the conversion part of it cannot be interrupted. Therefore you should never start the conversion part without having thoroughly read the documentation.
We recommend to run the conversion as soon as possible.

Where do I find detailed information?
The "ALPHA conversion" transaction RSMDCNVEXIT has online documentation which you reach via its "Help" button.
OSS note 447341 is about the ALPHA conversion in general and has attached to it a number of other OSS notes describing solutions to known problems.

What are the prerequisites for the "ALPHA conversion"?
Before running ALPHA conversion, apply SP 26 (2.0B) resp. SP 18 (2.1C) resp. SP 11 (BW 3.0A).
If you have large ODS Objects (> 50 mio records in all) we recommend to apply Support Package 27 (2.0B) resp. 19 (2.1C) or the coding correction of OSS note 548122.
If you are unsure if the conversion has already been executed in your system (in a BW 3.0A system it probably has already been done during the upgrade to BW 3.0A) start transaction RSMDCNVEXIT and look at the system status: if it says "All characteristic only have correct internal values" you do not need to run it.
We recommend a database backup before you run the transaction.
If you have strong reasons not to apply the named support packages, please note that you can run the ALPHA conversion starting from SP 22 (BW2.0B) resp. SP 14(BW2.1C). If your support package level is strictly smaller than 25 (BW 2.0B) resp. 17 (BW 2.1C) you have to apply the coding correction of OSS note 528381. If you have SID tables with more than several millions of records you have to be on SP 25 (BW 2.0B) resp. 17 (BW 2.1C) and also apply a correction described in OSS note 543482.

What effects does the "ALPHA conversion" have on my BW system?
No data loads are possible while the transaction is checking or converting.
Once the conversion part has been started the conversion has to be completed. The system is in an inconsistent state in the mean time!

How long does the conversion take?
Usually, the alpha conversion requires between 3 and 20 hours for production systems. For very big systems (>1TB) , it could also take up several days.
From our experience, the most decisive factor for the duration is the size of the ODS objects. As a rough rule of thumb, approximately 2.5 mio. Records per hour can be converted within ODS objects (status BW 2.0B SP 27 resp. BW 2.1C SP 19). To improve the conversion for ODS objects, keep the change log small (i.e. delete old entries) because all change log records will be converted, too. Furthermore, the size of the master data tables (which include characters with one of the ALPHA, NUMCV or GJAHR conversions) has impact on the runtime of the upgrade.
As of BW 2.0B SP 29 resp. BW 2.1C SP 21, ODS objects can be converted in parallel. Please see note 559524 for details how to set up this parallelism.
As of BW 2.0B SP 29 resp. BW 2.1C SP 21, transaction RSMDCNVEXIT is enhanced by a workload estimate. This preliminary check lists all characteristics, database tables and the size of the tables that will be converted during the alpha conversion. Furthermore, possible meta data inconsistencies are found and the possibility of aborts during the conversion is reduced.
During the conversion process, you can check the state of the conversion in the log.
This estimate can be executed without locking the system. We recommend to run it before starting the conversion.
Please see the enhanced online help in transaction RSMDCNVEXIT for more details.

What is the interrelation between a BW upgrade and the "ALPHA conversion"?
During the prepare phase of an upgrade to BW 3.0B it is checked that the "conversion of internal characteristic values", also called "ALPHA conversion", has been successfully completed. This "ALPHA conversion" is time-consuming. Therefore we strongly recommend to separate this conversion from the actual upgrade process.