Skip to Content
avatar image
Former Member

Regarding OSS notes

Hai

Can anyone put OSS 447341 . OSS 510835 notes to me urgently please .Becz I dont have authorization

I will assign the points

bye

mohammed

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • avatar image
    Former Member
    Apr 15, 2006 at 09:34 AM

    Hello Chakri,

    you can check your other post.

    i have uploaded both the notes...

    Hope they help..

    thanks,

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Apr 15, 2006 at 09:51 AM

    Hi,

    OSS NOTES 510835

    Additional information on upgrading to BW 3.0B

    Symptom

    This note discusses errors in the upgrade procedure or in the upgrade guide, as well as how to prepare for the upgrade.

    Other terms

    Upgrade, migration, release upgrade, release, maintenance level, R3up, PREPARE

    Reason and Prerequisites

    .

    Solution

    CAUTION:Thisnote isupdated continually!

    Therefore make sure you read it again immediately before the upgrade.

    Depending on the functions used, you also require one or more of the following notes:

    Contents

    I/......R3upkey word (not in thissupplementary note)

    II/.....Important general remarks

    III/....Correctionsto the guides

    IV/.....Errorsonthe CD-ROM

    V/......Preventing data loss, upgrade shutdownsand long runtimes

    VI/.....Problemswith the Upgrade Assistant

    VII/....Problemsduring the PREPARE and upgrade phases

    VIII/...Problems after the upgrade

    IX/.....Chronological summary

    II/ Important general information

    -


    < D033327 NOV/19/02 >----


    SAP BW 3.0B on AIX: SAP BW 3.0B on AIX 5.1with Oracle 9.2 will be available from the beginning of December 2002. You must perform the upgrade for the operating system and database before starting the upgrade.

    -


    < D035504 NOV/22/02 >----


    <Z1>

    The R3trans version on the source release must have a release date of October 01, 2002 or later.

    -


    < D019165 JUL/26/02 >----


    <Z1>

    Do not install the SAP J2EE Engine

    The SAP J2EE Engine is not requiredforthe application which is upgraded to a new release during this upgrade. Therefore, do not install SAP J2EE after the upgrade.

    You can easily add the SAP J2EE Engine to the system if it is required for later applications (for example, for add-ons).

    If you have already installed the SAP J2EE Engineor if you are installing additional dialog instances after the upgrade, you must deactivate the relevant SAP J2EE Engines by setting the rdisp/j2ee_start parameter to 0 in the instance profile.

    To do this, follow the steps below:

    For UNIX:

    Log on as user root and edit the file

    <sapmnt>/profile/<SAPSID_INSTANCENAME_HOSTNAME>.

    For Windows

    Edit the file

    <DRIVE>:\usr\sap\<SAPSID>\sys\profile

    SAPSID_INSTANCENAME_HOSTNAME>.

    For IBM eServer iSeries

    Edit the file

    /sapmnt<SID>/profile/<SID_INSTANCENAME_HOSTNAME>.

    -


    < D035504/D033271 AUG/13/02 >----


    BEFORE starting the upgrade (BEFORE starting the PREPARE), you MUST run the runtime-intensive ALPHA conversion to eliminate any possible inconsistentcharacteristic values (see note 447341).

    During the tool import of the PREPARE, the conversion program of theALPHA conversion version BW 2.0B Support Package 19 is imported (this corresponds to 2.1C Support Package 11). However, this version is incomplete.

    In addition, the information on the ALPHA conversion version is lost during the tool import.

    As describedin note 447341, the ALPHA conversion should onlytakeplace as of BW 2.0B Support Package 25 or BW 2.1C Support Package 17.

    For more detailed information, refer to note 447341.

    During the "General Checks" phase of the PREPARE,a checkis carried out to verify whether the ALPHA conversion was already performed as this is absolutely essential for the upgrade.

    We therefore recommend the following procedure:

    1. Execute the ALPHA conversion as described in note 447341.

    2. Immediately before you start the PREPARE, create a request as a transportof copies which contains the objects of the RSMD_ALPHA BOM. To do this, go to transaction SE09. Only select the "Transport of copies" checkbox. Select "Create". Select a description and save. Select the option for including objects and select RSMD_ALPHA for the object list of a request. Depending on the Support Package level, there should now be approximately 140 objects on the created transport request.

    Then release 'Transport of copies'.

    3. Execute the PREPARE up to at least successful completion of the IMPORT (tool import) module.

    4. Import the previously exported "Transport ofcopies" into your BW system with UMODE 1 and 2.

    An error indicating that the implementation of the RENAME method for the CL_RSMD_SEM class is missing may be displayed during the generation.

    You can ignore this error.

    5. Start the PREPARE and execute the IMPORT modules for the subsequent modules (IMPORT module must not be started again).

    -


    < D037179 MAY/21/03 >----


    Include the latest BW, Basis and ABA Support Packages into the upgrade.

    For information on dependencies relating to other Support Packages, see notes 510898 and 510838.

    Ifthemost current Support Package had already been imported in the source release, we urgently recommend that you read note 624769.

    Import the latest kernel patch after the upgrade.

    -


    <C5031836 JUL/07/02 >----


    You can only install the IGS for BW on Microsoft Windows.

    -


    < D001398 JUN/11/02 >----


    Unfortunately, 6.20 kernels with a patch level lower than 173 containan error in the IMPORT statement of the ABAP processor which, at worst, can change data in the database. Note 530576 describes the details. If in doubt, you should not use this type of kernel but should instead replace it immediately with a current kernel from the SAP Service Marketplace.

    -


    < D037179 OCT/25/01 >----


    You must have set up at least one client and activated a characteristic before upgrading an empty BW system.

    -


    < D035504 APR/12/02 >----


    The upgrade contains the BW Service API (SAPI) within the software component PI_BASIS.

    Before the upgrade, you should consider the points describedin note 506694 (reactivating the source system connections, DeltaQueue of the BW system should be empty before the upgrade).

    You can download the Support Packages for PI_BASIS from the SAP Service Marketplace and then use transaction SPAM to import them, see note 553527.

    -


    III/ Corrections to the guides

    -


    < D031901 JAN/10/04 >----


    LOCK_EU phase:

    Downtime-minimized strategy: If you decidetolock the Administrator Workbench, this is automatically locked by R3up. You must not lock the Admin Workbench manually in SE01.

    -


    IV/ Errors on the CD-ROM

    -


    V/ Avoid from loss of data, upgrade shutdown and long runtimes

    -


    <D020034 JUN/06/02 >----


    For BW Source Release 3.0A only

    Make sure that the Unicode syntax check is deactivated before you start the PREPARE. If this is not the case, set the ABAP/UNICODE_CHECKprofile parameter to OFF and restart the system.

    Otherwise PREPARE terminates during the extension module with syntax errors.

    -


    <D025974 JUN/03/02 >----


    Checkingequivalence level when importing BW Support Packages

    The equivalence level entry of some BW Support Packages is incorrect.Whenyou import Support Packages, make sure to check whether you have included sufficient BW Support Packages in the upgrade, bearing in mind the Support Package level of your source release.

    You will find information on Support Package dependencies in notes 510898 and 336259.

    -


    VI/ Problems with the Upgrade Assistant

    -


    VII/ Problems in the PREPARE and upgrade phases

    Problems in the PREPARE phases

    -


    < D035504 DEC/13/2002 >----


    If add-ons such as ST-PI and ST-A/PI, for example, are installedin your BW system, a CD for updating these add-ons may be requested during the PREPARE. Here you require an add-on-specific CD ('supplement CD') for the target release which will upgrade the add-on to the corresponding status during the upgrade. For further information, refer to notes 539977 and 557584 for the ST-PI add-on or note 69455 for the ST-A/PI add-on.

    -


    < I018654 SEP/13/2002 >----


    In data mining, the results are stored in generated database tables.Some of these objects do not have a TADIR entry. Data Mining Moulding results (training/evaluation/prediction) cannot be displayed.Importing note 550256 imports new objects. You must run the RS_DME_PGM_TADIR_CREATE_ENTRY report before carrying out an upgrade.

    -


    < D026714 JUL/31/02 >----


    Termination in the RSUPGRCHECK_PRE phase

    The phase terminateswith a CONNE_ILLEGAL_TRANSPORT_VERS ABAP runtime error.

    For troubleshooting purposes,placea current R3trans with a minimum date of October 01, 2002 in the /usr/SAP/upgrade/exe directory and repeat the import module.

    -


    <D026714 JUL/31/02 >----


    BEFORE starting the upgrade, that is, BEFORE starting the PREPARE phase,you must perform the ALPHA conversion to eliminate possible inconsistent characteristic values as already explained in Section "II/Important general information". The procedure is described in note 447341.

    If you have started the PREPARE (the IMPORT module, in particular,)without first creating the transport of copies described in Section "II/Important general information", you should start the upgrade immediately afterwards; otherwise problems may occur when you work in the system (query execution, for example). The solutions for this are described in note 537462.

    -


    <D020384 NOV/18/01 >----


    If the message "InfoObject <NAME> is inconsistent - please activate'(001)"or "Please reactivate InfoCube <NAME>" appears in the prepare phase, follow the steps described in note 458363.

    Before the upgrade, you must check the internal characteristic valuesin the system and correct them if necessary (provided you have not done so already). For details, see notes 447341 and 484558.

    -


    <D020384 AUG/01/02 >----


    The RSVERS function group is destroyed by the prepare phase if the SupportPackage level before the upgrade is smaller than Support Package 18 (2.0B) or Support Package 10 (2.1C). No objects can then be processed in BW and no data can be loaded. This is not a problem if you continue immediately with the upgrade. However, we nevertheless recommend that you go to at least the above-mentioned Support Package level before the upgrade.

    -


    <D020384 APR/08/03 >----


    BEFORE you start the upgrade, that is, BEFORE you start the PREPARE phase,you must check/repair the InfoObjects. This is described in more detail in the upgrade guide. In this case, error message R7B230 can occur for the following Support Package versions, indicating that the maximum ID of 2,000,000,200 has exceeded the upper limit of the BIM9999996 number range

    2.0B Support Packages 28 to 32

    2.1C Support Packages 20 to 24

    See note 589882 for information on this error and on how to solve the problem.

    -


    <D035504 JUL/11/02 >----


    Owing to an error shipped in the first delivery of the SPAM/SAINT updateversion 610/0008, the Support Package levels of the software components were not recognized during the prepare phase. This version was delivered from JUN/26/02 to JUN/27/02. If you have already imported this particular version, you should now also install the latest version. For more information, see note 400280.

    -


    Problems in the upgrade phases

    -


    < D035504 NOV/22/02 >----


    SHADOW_IMPORT_TRIG phase

    A termination may occur in the SHADOW_IMPORT_TRIG phase duringthe upgrade to SAP_BASIS 6.20. For troubleshooting, place a current R3trans with a minimum release date of October 01, 2002 in the /usr/sap/put/exe directory. See also note 545852.

    -


    < D037179 SEP/26/01 >----


    PARDIST_SHD phase

    Description:You can ignore both of the following messages:

    2WETG450XTable "RSRA_BC_LOG" is losing customer fields, although it did not appear in SPDD

    2WETG450XTable "RSRA_SETTING_BT" is losing customer fields, although it did not appear in SPDD.

    -


    < D037179 OCT/24/01 >----


    For additional information concerning tables that may lose fields, read note 73999.

    -


    < D030244 OCT/17/01 >----


    PARDIST_SHD phase

    You can ignore the message concerning the SCWBINDXVS table.

    -


    < D002553 NOV/15/02 D037179 MAY/21/03>----


    ACT_620 phase

    The following messagesmayoccur:

    1EEDO519 "Domain" "UC_DE_ACTION" could not be activated

    1EEDO519"Domain" "UC_DE_DATATYPE" could not be activated

    1EEDO519"Domain" "UG_DEDISPLAY_HIER" could not beactivated

    1EEDO519"Domain" "UG_DEPITERATED" could not beactivated

    1EEDO519"Domain" "UPX_YSD_SLC_AC" could not beactivated

    1EEDO519"Domain" "UPX_YSD_SLC_CT" could not beactivated

    1EEDO519"Domain" "UPX_YSD_SLC_PB" could not be activated

    1EEDO519"Domain" "UPX_YSD_SLC_VZ" could not be activated

    1EEDO519"Data element" "UCFT_TECHNAME" could not be activated

    1EEDO519"Data element" "UCU_DDN_TEXT" could not be activated

    1EEDO519"Data element" "UCU_DDN_VALUE" could not be activated

    1EEDO519"Data element" "UC_DEPITERATED" could not be activated

    1EEDO519"Data element" "UC_MSGID" could not be activated

    1EEDO519"Data element" "UPX_YSD_SLC_AC" could not be activated

    1EEDO519"Data element" "UPX_YSD_SLC_CT" could not be activated

    1EEDO519"Data element" "UPX_YSD_SLC_PB" could not be activated

    1EEDO519"Data element" "UPX_YSD_SLC_VZ" could not be activated

    1EEDO519 "Table" "UCFT_S_OVERVIEW_TREEDATA" could not be activated

    1EEDO519 "Table" "UCFT_SX_MANUAL" could not be activated

    1EEDO519 "Table" "UCFT_SX_UPL" could not be activated

    1EEDO519 "Table" "UCFT_SX_UPL_DETAIL" could not be activated

    1EEDO519 "Table" "UCFT_SX_UPL_DTL" could not be activated

    1EEDO519 "Table" "UCFT_S_ACTIVITY" could not be activated

    1EEDO519 "Table" "UCFT_S_BACK" could not be activated

    1EEDO519 "Table" "UCFT_S_DE_UNIT_HRY" could not be activated

    1EEDO519 "Table" "UCFT_S_DT_METHOD_DATATX" could not be activated

    1EEDO519 "Table" "UCFT_S_METHDATATX_EXT" could not be activated

    1EEDO519 "Table" "UCFT_S_METHDATATX_INT" could not be activated

    1EEDO519 "Table" "UCFT_S_METHODTX" could not be activated

    1EEDO519 "Table" "UCFT_S_METHODTX_DOC" could not be activated

    1EEDO519 "Table" "UCFV105" could not be activated

    1EEDO519 "Table" "UCF_S_DEP_TXDATA" could not be activated

    1EEDO519 "Table" "UCRX011" could not be activated

    1EEDO519 "Table" "UPX_YSD_SLC_ATTR1" could not be activated

    1EEDO519 "Table" "UPX_YSD_SLC_ATTR2" could not be activated

    1EEDO519 "Table" "UPX_YSD_SLC_PU" could not be activated

    1EEDO519"Table type" "UC0_TA_FIELD"could not be activated

    You can ignore all of the above messagesexcept the last one.

    Log on to the shadow instance.

    Save the UC0_TA_FIELD tabletypemanually in transaction SE11. Repeat the phase. Then select the "Ignore" option in the upgrade and then continue the upgrade.

    -


    -


    < D020384 APR/24/03 >----


    ACT_620 phase

    The following messages may occur in rare cases:

    1EDAD857 "<TABLE>"-"<FIELD>" (specify the reference table AND the reference field).

    These are tables generated for characteristics,InfoCubes, ODS objects or communication structures. Note 616361 describes the error and its cause in greater detail.

    First of all, you can ignore these errors and continue with the upgrade. However, you must repair the incorrect tables as described in note 616361 after the upgrade.

    Note 616361 also contains correction instructions for a check program.You can use this program to check your system before the upgrade. You can then execute the corrections described in note 616361 before the upgrade so that it no longer hangs.

    -


    VIII/ Problems after the upgrade

    -


    < D035504 NOV/08/02 >----


    BW Web Applications cause a relatively high network load if you areusing uncompressed transmission. It makes sense to use compressed transmission with large datasets. Activate compressed transmission after the upgrade as described in note 550669.

    -


    < I018654 SEP/13/2002 >----


    The generated dictionary table objects in the data mining are deleted afterthe upgrade to BW 3.0B. The installation of note 547179 imports new objects. To add the missing TADIR entries for existing data mining results, you must run the report DRS_DME_PGM_TADIR_CREATE_ENTRY.

    -


    < D030244 OCT/18/01 >----


    You can ignore the following message in the Longpost.log:

    "3PETG447 table and runtime object "RSRA_BC_BDS" exist without DDIC reference ("transp. table")"

    -


    < D030244 NOV/20/01 >----


    Information about the WAS configuration is available under SAPNet Alias BW Services & Implementation - HOW TO # Guides - Guide List BW 30 - How to customize BW 3.0 after an upgrade from 2.0B/2.1C

    -


    <D037179JUN/17/02 >----


    Use the latest BW front end. For problems with transactions RSPC or RSISET, see note 528392.

    -


    -


    < D020384 OCT/11/02 >----


    The texts for navigation attributes and dimensions may be inconsistentafter the upgrade if you have not included at least Support Package 3.0B Support Package 04 in the upgrade. You can find details and a repair option in note 562436.

    -


    IX/ Chronological Summary

    Date Topic Shortdescription

    -


    JAN/10/04...III...LOCKEU_PREphase: Locking the Administrator Workbench

    DEC/13/02...VII..Updating add-ons (such as ST-PI andST-A/PI)

    NOV/22/02...VII..Terminationin the SHADOW_IMPORT_TRIG phase

    NOV/19/02...II ...Availabilityof SAP BW 3.0B on AIX

    NOV/15/02...VII...ACT_620 phase

    SEP/13/02...VII...DataMining: Missing TADIR entries for DD objects

    AUG/21/02...VII...Terminationin phase RSUPGRCHECK_PRE

    AUG/13/02...II....Performingthe ALPHA conversionBEFOREPREPARE

    AUG/05/02...II....Additional informationon importing Support Package 2

    AUG/01/02...VII...RSVERS isdestroyed

    JUL/26/02...II....Donot install SAP J2EE Engine

    JUL/23/02...II....Donot include Support Package 2 in the upgrade

    JUL/17/02...II....Startupgrade directly after PREPAREphase

    JUL/16/02...II....IGSfor BW 3.X can only be installed on Windows

    JUL/11/02...II....Errorin 620 kernel lower than 173

    JUL/11/02...VII...Errorin SPAM/SAINT update 610/0008 before JUN/28/02

    JUN/06/02.....V...SourceRelease 3.0A: Syntax error in the PREPARE

    JUN/03/02.....V...Checkingequivalence level for BWSupportPackages

    MAR/25/02...II....Error in importing BW Support Packages

    SEP/27/01...III...Licensefor remote shadow instance

    SEP/26/01...VII...PhasePARDIST_SHD: Table RSRA_BC_LOG/RSRA_SETTING_BT

    SEP/19/01...III...PhaseSHDINST_HOST replaced with phase INITSHD

    AUG/15/01...III...WindowsXP only after release by Microsoft

    JUL/23/01...II....Including the latest Support Packages in theupgrade

    Importingthe latestkernelpatch after the upgrade

    MAR/08/01...II....Warnings '... DB versionis toohigh'

    FEB/15/01...V....Checking InfoObjects

    JAN/17/01...II....IncludingSupport Packages and theirdependentsin the upgrade

    DEC/05/00...VIII..Init-SimulationforDelta-InfoSources

    NOV/14/00...III...Windows NT: SAPDB version

    NOV/14/00...III...SAPRetail: Converting theterminology

    NOV/10/00...VIII..ScheduledInfoPackagescausetermination

    JUL/13/00...VII...Different CD- requestthrough R3up

    JUL/13/00...VII...Error/warning intheLongpost.log

    JUN/09/00...VIII..Error/warningin the Longpost.log

    MAY/25/00...III...Correctionin the guide for Windows NT

    APR/10/00...II....Checkingmemory parameters

    APR/08/03...VII.. Reference to note 589882

    APR/24/03...VII.. Reference to note 616361

    OSS NOTES 447341....

    Inconsistent char. values for ALPHA conversion routine

    Symptom

    Thisis the main note for problems with inconsistencies in conversion routines. See the current version of the note in each case.

    Caution: The conversion of non-consistent characteristicvaluesdescribed here must be executed before the PREPARE of the upgrade to BW 3.0. See part 2 of this note. See part 2 of the note.

    Other terms

    ALPHA, NUMCV, GJAHR, conversion exit, conversion routine, upgrade

    Reason and Prerequisites

    Contents

    Part 1 Inconsistencies with conversion routines

    1.1 General description of conversion routines

    1.2 Possible symptoms with inconsistencies

    1.3 Causes of inconsistencies

    1.4 Correcting inconsistencies (with RSMDCNVEXIT)

    1.5 Before conversion

    1.6 Possible problems and solutions

    1.7 Runtime of the correction

    1.8 Following successful conversion

    Part 2 Checks before the upgrade

    2.1 Upgrade from BW 2.X to BW 3.0

    2.2 Upgrade from BW 3.0A to BW 3.0B

    2.3 Upgrade from BW < 3.0 to BW >= 3.1 Content

    2.4 Upgrade from BW >= 3.0B to BW >= 3.1 Content

    Part 3 Special features for different Support Package levels

    Solution

    Part 1

    Inconsistency with conversion routines

    1.1 General description of conversion routines

    The conversion exits ALPHA,NUMCV and GJAHR for characteristic values convert a user-friendly external display into a system-internal display during input.

    Purely numeric left-aligned values are filled with zeros for anALPHA exit characteristic. The value '01' would not be a valid internal value for a four-digit characteristic - it would have to be converted into the value '0001'. However, the value ' 0A' would not be converted because it contains a non-numeric character ('A'). Conversely, leading zeros of purely numeric values are deleted when they are convertedinto the external format. Therefore, the internal value '00014' is displayed as '14'. A characteristic is only inconsistent ifthe internal tables contain values that do not correspond to the conversion rule. During output, the characteristic values are converted back again. If the master data table, the InfoCube or ODS object is inconsistent and contains several values that all have the same external display (for example, '0001', '001 ' and ' 1'), these are displayed in the query, for example, as the same rows (with '1). An inconsistent value (for example, '01 ' instead of '0001') cannot be selected. The value entered on the screen would be converted into the correct internal format ('0001). However, this value is not in the table and therefore cannot be found.

    The NUMCV conversion routine behaves in exactly the same way duringconversion into the internal format, only blank characters between numbers are still compressed at the beginning. With the NUMCV conversion routine, the system would convert the value '1 1' to '011' while the value would not be converted with the ALPHA conversion routine. When the system converts using the NUMCV conversion routine, conversion into the external format does not take place. The GJAHR conversion routine for entering year dates creates entries from 00 to 99 on the interval 1950 to 2049. There is also no backward conversion of the output.

    1.2 Possible symptoms with inconsistencies

    Problems with the upgrade are dealt with in part 2 of this note. The following symptoms can occur during normal operation:

    If a characteristic is in the drilldown, characteristic values can appear repeatedly.

    During the selection (also with variables),no datais found, even though the corresponding values do exist or are displayed without restrictions when a query is executed.

    In the case of hierarchies,some orall characteristic values appear under the "Not assigned" node, even though corresponding values exist in the hierarchy.

    1.3 Causes of inconsistencies

    Automatic conversion does not take place during data transfer if the fieldis transferred to a longer field. If, for example, the field has 4 characters in the transfer structure and the InfoObject has 6 characters, the system converts the transfer structure value '0001' to the characteristic value '0001 '. Here, a subsequent conversion to '000001' would still have to be executed again.

    Some Business Content InfoObjects were delivered with the ALPHA conversionroutine even though this is not necessary. However, the values are not checked for correct internal display during the R/3 system data transfer. On the other hand, conversion to the internal format takes place when a file is loaded.

    Before Support Package 19 for BW2.0B (or Support Package 11 forBW 2.1C), the above-mentioned conversion routines could be activated for characteristics. However, the values are not converted in compliance with the conversion routine during the database conversion of the master data tables.

    1.4 Correcting inconsistencies (with RSMDCNVEXIT)

    Using transaction RSMDCNVEXIT, you should check your system for correct characteristic values and repair it if necessary. Detaileddocumentation on the conversion or repair transaction is provided in the system when you start the transaction ('Help' button).

    Caution!During conversion, the data is locked against changes. You cannot load any data into the system during the conversion.

    Here are the most important steps:

    1. Checking the characteristics: All master data tables for characteristicswith the aforementioned conversion routines are checked for inconsistent values. The system also analyzes conflicts - that is, several values which are converted to the same correct internal value.

    2. For each characteristic with inconsistent values, you must decide whether to remove the conversion routine or whether the values should be converted. Caution! Neither of the two alternatives is preset for characteristics with conflicts. You must select one of the two alternatives, otherwise, the conversion cannot be fully executed.

    3. You can only exit this windowbyselecting "OK" if you have made a selection for all inconsistent characteristics. You cannot start the conversion before this.

    Note the following:

    When you remove the conversion routine, '000012' and '12 ', for example,are handled as completely different values. This has the disadvantage that the internal value now has to be entered exactly in the variable window. Therefore, you must enter the '000012' value in exactly the same way, that is, with 4 zeros. Before the ALPHA conversion routine was removed, you only needed to enter '12' - this was converted internally to '000012'. After the conversion, you can activate the conversion routine again for individual characteristics with a data conversion.

    When you convert the values in the case of conflicts, values that werepreviously different are now summarized. With the ALPHA conversion routine, the system converts the values '001', ' 01' and ' 1', for example, altogether to the same value '001'. This should only be done if the three values really describe the same object. During conversion, several records are then grouped together in internal tables, if necessary. The non-initial attributes are retained as far as possible. However, some attribute values may disappear during conversion, therefore, you may need to reload data. This is precisely the case if an attribute has different non-initial values in severalrecords that are combined. The conversion then randomly selects one of the values, which is copied to the converted record.

    1.Converting the characteristic values: First, checks are performed to see whether the following prerequisites are fulfilled:

    a) All meta objects (InfoObjects, InfoCubes, ODS objects, and so on) being edited must be active.

    b) The master data must have been activated (hierarchy/attribute realignment run)

    c) The ODS object data must have been activated and must have been updated into all data targets.

    Make sure that these prerequisites are fulfilled before conversion begins.If the system detects that the prerequisites are not fulfilled during conversion, the objects are already locked. Then proceed as described in note 484558 ("Object locked with (terminated) conversion").

    The characteristic values are then converted into the following objects:

    Characteristics (master data tables, SID tables and text tables)

    Hierarchies

    InfoCubes

    ODS objects

    Meta data (characteristic constants with characteristics and data targets)

    Aggregates

    Authorizations

    1.5 Before conversion

    Caution:As a precaution, we urgently recommend thatyou perform a database backup of the system before conversion. If, for some reason, the conversion is not successful, the system may hang in an unspecified status. When the error analysis is completed, you must import this database backup.

    A termination may occur during conversion if you loaded textsthat do not have any SID entries. (This did not pose a problem up to now.) Execute the RSDMD_CHECKPRG_ALL report to avoid a possible termination.

    Do not explicitly enter any characteristic name so the system can check all characteristics. Set the "Repair" indicator and then only set the indicator for characteristic values in SID,T.

    In very rare cases, the report can run for a few hours and this may resultin a timeout. If this occurs, simply restart the check because the program will continue from the termination point. (See also note 483330, for this case, however, the check is only suitable with RSDMD_CHECKPRG_ALL, and not RSRV.)

    Even if problems with texts do not occur, we wish to highlight measures here that you can use to avoid problems during the conversion:

    1. If at all possible, use the function available as of Support Package 29 for BW 2.0 (or Support Package 21 for BW 2.1C) "Precheck/Estimate runtime".This preliminary examination already finds many possible error causes in advance. You will also get an idea of the approximate runtime of the conversion. During the preliminary examination the system is not locked. See also notes 575814 and 588638.

    2. Use transaction RSRV to check the system. It is a good idea, for example,to check the five largest characteristics for inconsistencies. The check program RSDMD_CHECKPRG_ALL performs comparable checks. Depending on the available runtime, you can also use RSRV or RSDMD_CHECKPRG_ALL to perform more extensive checks.

    3. Perform checks with RSRV or RSDMD_CHECKPRG_ALL.

    4. See notes 584416 and 543482 for the optimal setting of the system and database parameters.

    5. You can create the security backup directly before the conversion, that is, after the check phase.

    6. The internal conversion tables are created in the check phase. Simultaneouslythe system is now locked against any data loading. If you delete these locks manually and then load data, the conversion tables lose their validity and the check must be performed again before a successful conversion can take place.

    1.6 Possible problems and solutions

    Ifthe conversion fails, the last option is to import the database backup - a measure which, though it is rather awkward, always works. Important: You must find the cause of the error before you import the backup! You must therefore examine the log of the converter (in RSMDCNVEXIT), then possible dumps (ST22) and also the syslog (SM21).

    It is not absolutely necessary to import the backup, ifyou can eliminate the cause of the termination (for instance, tablespaces that are too small or rollback segments). However, you can only restart the conversion if you have not

    loaded

    maintained or

    deleted

    any data in the meantime.

    Deleting data in particular can cause serious data loss/inconsistencies.

    If data has been loaded again nevertheless, the conversion tables must be set up again. (In the "Check" step.)

    If, however, master data may have been deleted and importing the backup is problematic for any given reason, it may be useful to first stop the conversion that has started (if possible). You must then execute the full conversion again.

    If this procedure is not possible, you must import the database backup to avoid a possible loss of data.

    If data was both deleted and loaded, the database backup must be imported.

    1.7 Runtime of the correction

    The entire correction process for a system can take a considerable amountof time. Note 589851 contains general guidelines for improving performance. Note 584416 lists the various options for optimizing an ORACLE database.

    You can roughly estimate the runtime of the two "check" and "conversion" steps as follows:

    Check:

    The relevant aspect here is the total of all entries of the SID tablesof all characteristics. This corresponds to the number of relevant characteristic values, for instance. Approximately 20 million data records are processed per hour.

    Conversion:

    Long runtimes here are usually created by large ODS objects. Before SupportPackage 27 for BW 2.0B (or Support Package 19 for BW 2.1C), approximately 2 million records could be processed per hour. This output is almost doubled as of this Support Package (or after you apply note 548122). (Parallel processing: see below).

    Note that the processing rates specified here only constitute averageguidelines. Depending on the performance of your individual system, the actual values can also be above or below the guidelines by a factor of 2.

    As of Support Package 26 for BW 2.0B (or Support Package 18 for BW 2.1C)

    A runtime estimate (new button "Preliminary check/Estimate runtime") is provided as of this Support Package level. This enhancement is containedin Support Package 29 for BW 2.0B (or Support Package 21 for BW 2.1C) For Support Packages 26-28 for BW 2.0B (or Support Packages 18-20 for BW 2.1C), you can load it as a transport. For more information, see note 575814.

    Parallel processing as of Support Package 29 for BW 2.0B (or Support Package 21 for BW 2.1C)

    As of this Support Package level,the conversion of the ODS tables can be processed in parallel. This can considerably improve performance. Refer to note 559524.

    1.8 Following successful conversion

    A system is consideredto be completely converted if the system status is "All characteristics only have correct internal values" in RSMDCNVEXIT.

    After the conversion, stricter checks and conversions are active in the system to avoid new inconsistent values reaching the system:

    With the transfer and update rules, fields are checked for conformity ifthey are transferred in a characteristic with a conversion routine. If errors occur when you load the data because the data is not delivered in the correct internal format, you have two options:

    Change the source data or extractor so that the data is delivered to BW in the correct internal format.

    Activate the execution of the conversion routine in the transfer rules. To do this, go tothe transfer rulestab in the transfer rules maintenance. The last column in the table is called conversion. Activate this checkbox.

    Iffieldsare transferred to a longer characteristic with a consistent conversion routine, this is executed on the target field.

    When you create new SIDs for a characteristic, the system checks to see whether the values agree.

    When you update directly into an InfoCube or an ODS object, the system also checks the characteristic values.

    When you enter the characteristic values, the system converts them automatically.

    Part 2

    Checks before the upgrade

    2.1 Upgrade from BW 2.X to BW 3.0

    It is an essential prerequisite for the upgrade to 3.0 that the system is consistent.

    More precisely, during the PREPARE phase of the upgrade, the system checks whetherthe system data is consistent with regard to the conversions. The conversion program with the upgrade tool import is providedfor this purpose. To avoid scheduling difficulties, we urgently recommend that you carry out the conversion some time before the upgrade.

    Known problems

    To allow an upgrade for as low a Support Package status as possible,the tool import step, which imports some data necessary for the upgrade, was incorporated into the PREPARE phase some time ago.

    Unfortunately, however, this is exactly what causes problems for systemswith a Support Package version higher than Support Package 19 for BW 2.0B (or Support Package 11 for BW 2.1C). The tool import then corresponds to a partial "downgrade".

    The results are:

    The conversion program in RSMDCNVEXIT is in an obsolete version, so you cannot carry out the conversion correctly.

    Other parts of the source code delivered are also incompatible withnewer Support Package levels. As a result, no queries can be executed after the tool import until the upgrade has been completed (or until the workaround has been implemented in accordance with note 510835).

    Unfortunately, the conversion status of the system also disappears,so you are forced to carry out the conversion with RSMDCNVEXIT in the "General Checks" phase of the PREPARE if you had already successfully executed this previously.

    Solution to these problems

    1.

    Execute the conversion using transaction RSMDCNVEXIT before the PREPARE of the upgrade. Make sure the systemstatusoutput in transaction RSMDCNVEXIT after the conversion states that all characteristics have only correct internal values.

    2.

    Immediately before starting the upgrade PREPARE, create a request asa transport of copies for the objects of BOM RSMD_ALPHA. To do this, go to transaction SE09. Only select the checkbox "Transport of Copies". Press "Create", select a description and save. Press the "IncludeObjects" pushbutton and then select RSMD_ALPHA as the object list of a request. RSMD_ALPHA. Release the created request.

    3.

    Execute the PREPARE up to and includingthe firsttool import. Stop after the tool import. Carry out point 4 in this list before moving on to the next step in the PREPARE.

    4.

    Importthe previously exported transport of copies with UMODE 1 and 2. The following errors may be reported during generation:

    Program CL_RSMD_SEM===================CP,

    Include CL_RSMD_SEM===================CI: syntax error row 000024

    The implementation of method 'RENAME_IOBJ' is missing.

    You can ignore this error.

    5.

    The errors mentioned above do not occur during query execution under theseconditions. You can therefore work with your system as usual or execute the PREPARE to the end. A check on the conversion status carried out during the "General Checks" phase of the PREPARE recognizes that your system is converted. If no other errors were reported, you can now start the actual upgrade. If, for any reason, you (have to) repeat the tool import, you must start the procedure above at point 3.

    This descriptionisalso contained in note 510835 "Additional information on upgrading to BW 3.0B", which you should always read before an upgrade.

    Other possible problems

    If you have to repair BW objects such as InfoCubes, InfoObjects or ODSobjects because they were recognized as inconsistent during the "General Checks" phase, there may be problems with the system change option. If you are in a non-changeable production system, you must switch the system to "changeable". If necessary, interrupt the upgrade for this purpose. For information on other problems (and solutions) related to an object's ability to change during the upgrade, see note 458024.

    2.2 Upgrade from BW 3.0A to BW 3.0B

    The system must also be in a consistent state for this upgrade to 3.0B. (That is, the system status in transaction RSMDCNVEXIT is "All Characteristics Have Correct Internal Values".)

    If you have already upgraded fromBW2.0B/BW 2.1C to BW 3.0A, you already had to convert your system during this upgrade and your system should now have this status.

    Exception:

    If you belong to the small group of customerswho participated in the First Customer Shipment Program for BW 3.0A, the upgrade from BW 2.X to BW 3.0A was not carried out.

    You must nowcarryout the check and, if necessary, the conversion before you upgrade to BW 3.0B. To do this, execute transaction RSMDCNVEXIT.

    Prerequisite: At least SupportPackage 7 for BW 3.0A plus the correction contained in note 528381. Alternatively, you can use Support Package 11 for BW 3.0A.

    To avoid scheduling difficulties, we recommend that you carry out the conversion some time before the upgrade.

    2.3 Upgrade from BW < 3.0 to BW >= 3.1 Content

    As with the upgrade to 3.0B, the consistency of the system is also an essential prerequisite for the upgrade to 3.1 Content!

    In the General Checks phase of the upgrade PREPARE, there is also a checkto determine whether the system data is consistent with regard to the conversions. The conversion program with the tool import of the upgrade is provided for this purpose.

    To avoid scheduling difficulties, we recommend that you carry out the conversion some time before the upgrade.

    The problemsthat occur with the tool import (as with the upgrade to 3.0B) do not occur with the upgrade to 3.1 Content. Therefore, do not implement the solution described under Section 2.1. In particular, it is not necessary to export a transport created from the RSMD_ALPHA BOM and this would in any case result in errors (unknown syntax "R3TR" "TABL" "RSMDCONTCONVEXIT" or "Object R3TR TABL RSMDCONTCONVEXIT requires a catalog entry") because some of the objects no longer exist.

    Note the prerequisite Support Package levels for the upgrade to 3.1Content: Support Package 26 for BW 2.0B, Support Package 18 for BW 2.1C, Support Package 10 for BW 3.0A and Support Package 3 for BW 3.0B.

    2.4 Upgrade from BW >= 3.0B to BW >= 3.1 Content

    In this case, the consistencyof the data should be already be ensured by a previous upgrade. As a precaution, a check is carried out in the upgrade PREPARE.

    Do not, therefore, implement the solution described under Section 2.1 in this case. In particular, it is not necessary to exporta transport created from the BOM RSMD_ALPHA and would in any case result in errors (unknown syntax "R3TR" "TABL" "RSMDCONTCONVEXIT" or "Object R3TR TABL RSMDCONTCONVEXIT requires a catalog entry") because some of the objects no longer exist.

    Part 3

    Special features for different Support Package levels

    For all Support Package levels

    The check terminates with the error EXSORT_NOT_ENOUGH_MEMORY

    See note 495428.

    Support Package 19 - 21 (BW 2.0B) or Support Package 11 - 13 (BW 2.1C)

    Transaction RSMDCNVEXIT is available, but incorrect and must not be executed.

    Support Package 22 - 24 (BW 2.0B) or Support Package 14 - 16 (BW 2.1C) or Support Package 8 - 10 (BW 3.0A)

    Import note 528381 before the conversion.

    If you have already upgraded to this status, you can then use note 525799. You must then perform another complete upgrade.

    As of SP 25 (BW 2.0B) or SP 17 (BW 2.1C) or SP 11 (BW 3.0A)

    The conversion program (transaction RSMDCNVEXIT) always works without any errors.

    Before SP 26 (BW 2.0B) or SP 18 (BW 2.1C) or SP 12 (BW 3.0A)

    The conversion can only be successful if you have selected one of thealternatives "Delete conversion routine" or "Convert characteristic" for all characteristics. If this is not the case, only green messages will appear in the conversion log. Despite this, the system is not set to "All characteristics only have correct internal values" because only some of characteristics were converted. Message RSMD 057 is displayed in the log instead: "The ALPHA conversion routine could not be set to consistent". In this case, you must execute the conversion once again after step 2 (but only with the characteristics that have not yet been converted). If you do not do this, the stricter checks and conversions described above do not become active, therefore, new incorrect values can arrive in your system which then, in all likelihood, cause conflicts with the values already converted. Note that the stricter checks and conversions (for successfully converted characteristics also) are only active if the system status is "All characteristics only have correct internal values".

    Termination with TSV_TNEW_PAGE_ALLOC_FAILED

    An enhancement was made with Support Package 26 that alsoallowsvery large SID tables to be converted on hosts with a 32-bit architecture. For more detailed information, see note 543482.

    On Support Package 26 (BW 2.0B) or Support Package 18 (BW 2.1C) or Support Package 12 (BW 3.0A)

    Performance is inadequate.

    If very large ODS tables are affectingthe performance of the conversion, see note 548122. This correction is also part of Support Package 27 or Support Package 19.

    As of Support Package 26 (BW 2.0B) or Support Package 18 (BW 2.1C) or Support Package 12 (BW 3.0A)

    It is no longer possibletostart the conversion after the check until you have selected one of the two repair-options for all inconsistent characteristics.

    A transport containing the new "Preliminary check/Estimateruntime"function is provided for Support Packages 26-28 (BW 2.0B) or Support Packages 18-20 (BW 2.1C). See notes 575814 and 588638.

    Before Support Package 27 (BW 2.0B) or Support Package 19 (BW 2.1C)

    The conversion terminates with SAPSQL_ARRAY_INSERT_DUPREC. See note 547307.

    Although you have activated the "Simulation (no DB change)" option, the system also executes the change on the database. See note 552547.

    As of Support Package 29 (BW 2.0B) or Support Package 21 (BW 2.1C)

    The Support Package contains the new "Preliminary check/Estimate runtime" function. See notes 575814 and 588638.

    The conversion of ODS tables can be processed in parallel. See note 559524.

    Theconversion terminates in test mode: The problem is eliminated with the next Support Package. See also note 585275.

    Before SP 34 (BW 2.0B) or SP 26 (BW 2.1C)

    Possible dump COMPUTE_INT_PLUS_OVERFLOW when ODS objects are converted. See note 658481.

    The following error may occur on the INFORMIX database: "Updateto <characteristic>leads to entries with identical keys", RSMD 313 (DUPL_RECORD). For more information, see note 632828.

    -SHREYA

    Add comment
    10|10000 characters needed characters exceeded