Sie sind auf Seite 1von 2

Before upgrading BI 7.0 to BI 7.

3, below steps need to be performed:


Pre & Post Upgrade Activities:
1)
Check for source system settings and global settings from source system
2)
Run all the BEx Queries and take screen shots of all the BEx Queries
3)
Check the data flows and take screen shots of all the dataflows
4)
After upgrade, check all the data flows objects are active or not
5)
If any data flow objects are inactive, then activate it manually (Note:
Sometimes code also get disappeared)
6)
After upgrade, need to run all the process chains
7)
If any process chain gets failed, need to go and check the transformatio
ns and data flows
8)
Validate the source system settings and global settings from source syst
em
9)
No need to check alpha conversion or anything like that which we used to
do before 3.5
We can transport the objects from BI 7.0 to BI 7.3. there is no issues in that,
as SAP confirmed that transports from lower version to higher version are possib
le.
Pre-Upgrade Activities: t-code: /n/ASU/UPGRADE
It involves two types of activities:
Manual
Automatic
a) Restore entries in DBDIFF table (Note 449891):
Restore the backup of different temporary objects (i.e. terminations of quer
ies, compression and data extraction,)
through the report : report SAP_UPDATE_DBDIFF in the DB catalog to table DBDI
FF. DB02 includes the table
when checking for inconsistencies.
b) Check the Master Data Consistency (NOTE 1033721):
If Master data cannot be activated (e.g. If in master data tables there are
modified records for the characteristic where the field OBJVERS (Version) has
the value M (Revised).)
Goto transaction SE38 and run the master data check program RSDMD_CHECKPRG_AL
L for the characteristic.
If the report returns errors run the report again with the 'Repair' option fl
agged.
To avoid the TIME OUT, run the process in background.
c) ALPHA Convertors
The conversion of non-consistent characteristic values must be executed before t
he PREPARE of the upgrade to BW 3.0.
Using transaction RSMDCNVEXIT, check your system for correct characteristic valu
es and repair it if necessary.
d) ODS tables disappear during upgrade:
Symptoms: Tables of ODS objects go missing during a BW upgrade. The activation q
ueue table, which contains the new data records before the activation of the ODS

data, is affected. This table has the technical name /BIC/A<ODS Name>40 or /BI0
/A<ODS Name>40.
The following upgrades are affected:
Solution Run program RSDG_ODSO_ACTIVATE.
e) Activate Trasformations & DTP's
Use Program: RSDG_TRFN_ACTIVATE
f) Activate Infocube :
USE Program RSDG_CUBE_ACTIVATE
g) Check status of InfoObjects
Use Program RSDG_IOBJ_REORG
h) Activate InfoObjects
Use Program RSDS_IOBJ_ACTIAVTE
NOTE These activities are mentioned as OPTIONAL, but some of them are mandatory
to perform.
Try to perform all exceptDELETION OF TEMP TABLES, as this may cause inconsistencie
s.
Before performing this activity, make sure , no temporary table is under use
(system should not have any active sm37 job, including BASIS related jobs).
Post Upgrade Activities: t-code: /n/ASU/UPGRADE
a)
b)
c)
d)

TADIR entries for factviews.


Activate the source systems again.
Activate Transfomations, DTP s, Infoobjects, DSOs and Infocubes
Activation of MultiProviders

Use Program: RSDS_MPRD_ACTIVATE


e) Problem with a hierarchy with remaining nodes
Activate the affected hierarchies once again.
Use program PRINCLTAB_REBUILD to repair all the hierarchies of characteristics .

Das könnte Ihnen auch gefallen