Blo Title : step by step SAP BW UPGRADE 3.x to 7.x or 7.0 to 7.

3 activities -- pre upgrade post

upgrade( Must Read once )

step by step SAP BW UPGRADE 3.x to 7.x or 7.0 to 7.3 activities -- pre upgrade post upgrade

Share
BW Upgrade involves, upgrade of BW system from a previous version to a newer version.

Clients generally go for upgrade primarily for the reason that SAP stops supporting the
previous version after a time frame to encourage clients to enhance their system and use new
functionalities in the newer version.

This document covers the steps involved in the BW technical upgrade. Upgrade activity is
generally split into three different set of activities.

1. Pre Upgrade activities

2. Actual system upgrade which is usually carried out by basis team experts.
3. Post Upgrade activities

Approachwise there are two ways which normally followed during the upgrade

1. Upgrading the complete landscape as is without copying production landscape, so that all the
systems sandbox, development, quality and production will be upgraded simultaneously.
2. Production landscape is copied on fresh landscape say sandbox/Development/Test/quality
servers and upgrade those servers.

During Pre Upgrade activities following steps could be followed

1. Check the source system connectivity and activate/replicate it in case it is necessary.

2. Post refresh of the system we need to verify whether all the objects are refreshed correctly or
not. If anything is inactive, we need to manually activate same and save it in the transport
request.
3. Run program RSUPGRCHECK to find inconsistent Info cubes, ODS, Info objects,
Multiproviders, Update and Transfer Rules and then activate the relevant objects.
4. Checking consistency of master data:- Run program RSDMD_CHECKPRG_ALL
for consistency test.
5. Check DDIC Database Consistency: - Run report RUTMSJOB to ensure DDIC
databaseconsistency.
6. Check M status for ODS - Check whether M tables of ODS are empty or not. Loading and
activation status should be shown green.
7. Check for invalid temp tables - This can be done through SE14 transaction and in extras
option.
8. Checking double entries in the table - Execute program ANALYZE_RSZ_TABLES in SE38
to find double entries.
9. Activation of Infocubes - We can ensure all the infocubes are activated through transaction
RSDG_CUBE_ACTIVATE.
10. Right code page setting - Execute program RSCPINST for Right Code Page Setting.
11. DSO Activation - Can be carried out through RSDG_ODSO_ACTIVATE transaction.
12. Repairing of any Info object can be carried out through RSD1 transaction.
13. Activate all Transfer Structures: - Run program RS_TRANSTRU_ACTIVATE_ALL in SE38 to
activate all Transfer Structures.
14. Activate all Communication Structure: - Run program RS_COMSTRU_ACTIVATE_ALL in SE38
to activate all Communication Structures.
15. Multiprovider activation: - Run program RSDG_MPRO_ACTIVATE to activate all
Multiproviders.
16. Conversion of Inconsistent Characteristic Values with a Conversion Routine: - Run
program RSMDCNVEXIT for converting inconsistent characteristic values with a conversion
routine.
17. Convert Data Classes of Info Cubes: - Run program RSDG_DATCLS_ASSIGN for the
BI: Converting Data Classes of Info Cubes. Check whether everything is available with
DDIM, DFACT and for ODS it is DODS (*table DD09L).

Above all the activities will ensure normally smooth upgrade during the actual upgrade
activities which is normally carried out by basis experts.

Upgrade of BW server:

This is activity mainly carried out by basis team. During actual upgrade activities are again
classified into two different sets. One set of activity can be carried out during the system
Uptime and for second set of activity system downtime will be required. SPAU-SPDD needs to
be carried out during and post upgrade of the server. Time required for this phase will vary
depending upon the severity of the issues appearing during the SPAU-SPDD phase.

Once upgrade is carried out we normally need to carry out post upgrade activities which most
of them are similar to pre-upgrade checks only.

Post Upgrade activities :

1. When we will start with rsa1 for the first time BI content gets activated in the background
initially.
2. We need to check the source system connections.

3. Info package Group and process chain comparison: - Info packages are available with
RSA1OLD transaction and under tab ‘Administration’ all Loading things can be seen. Process
chains can be verified through RSPC transaction. Post refresh need to verify by carrying out
some sample data loading through process chains and Info package group.
4. There are some additional authorizations which need to be provided to access PSA or to
carry out any new developments.
5. Activation of Bex History: -Run program RS_PERS_ACTIVATE to activate Bex history.

6. Update rule activation: -Run transaction RSAU_UPDR_REACTIVATE_ALL to reactivate

all update rules.
7. Program RSR_VARIANT_XPRA:- Run report RSR_VARIANT_XPRA in se38 for the query
variants.
8. Activate all BI Business Content Statistics Cube. Again this is project specific and not the
mandatory step.
BI Cockpit Activation:- Run program RSTCC_ACTIVATEADMINCOCKPIT_NEW

9. Bex setting - We can run RRMX_CUST transaction and carry out relevant setting.
BI content activation various authorization issues can be solved by referring to SAP notes
1159976,965386,161292

10. Infoset activation - You can refer to SAP notes 1161444, 1010566 in case there are any
activation issues.

Security aspect post upgrade -

BI7 demands many new authorisations to be provided for BW object development. You need to
ensure that all such authorisations are provided in the Build server itself and need to be carried
forward to Production/Quality server whichever are required. Old authorisations can be still
used by switching to 3.x authorisation concept. New analysis authorisation concept also can be
used. It all depends on the scope of the project. But for day to day normal working in BI7.x you
need to have more authorization compared to 3.x version.

Transport Layer –

SE21 is Package builder for Transports. As per Technical naming convention of the new system
transport layer needs to be renamed. Also all the objects needs to be changed as per new naming
convention else during the actual development correction all the objects will be repaired which
should be avoided. Similar set up needs to be done for Security transport layer as well. There are
certain authorisation needs to be provided during the transport movement for eg Administration
of RFC destination S_RFC_ADM needs to be provided.

Other Important points –

1. Before actual upgrade of ECC and BW, delta queue should be made empty.
SMQ1, LBWQ, RSA7 entries should be made blank by executing the data loads multiple times.
LO Cockpit jobs to be run multiple times to push the queue to RSA7 from LBWQ. This will
ensure that there is no data loss incurring during the upgrade activity as well as upgrade is not
stopping/interrupting due to this data. This is important when R/3 and BW server both are
getting upgraded at the same time.

2. BW Threshold value for data loading should be maintained through RSCUSTV6.

3. Mapping of logical system should be carried out in RSLOGSYSMAP. Without these mapping
all the transport movement will fail.

4. Data packet size needs to be redefined in table ROIDOCPRMS in BI7 and ECC as per
Data loading performance in the BW system. This table mainly contains following
information
MAXSIZE - Maximum size of a data package in KB
STATFRQU - Number of packages that are transferred before statistical information is sent
MAXLINES - Maximum number of records sent in one data package
MAXPROCS - Maximum number of dialog work processes for each upload request used to send
the data to the BW system. To ensure the performance and stability of the upload process, it is
important that this table is set up correctly.

Comments

Adding a few points on the BW upgrade activities :

1) If BW system is connected to any other system as well for e.g., Planning box. So RSA7 should be empty and data
loading must be stopped during downtime for Upgrade.

2) If any Non SAP R/3 system for e.g., MDM, JDE systems are connected to BW system to provide data to BW. In
that case, Daemons should be stopped prior to Upgrade, which can be done via RSDDA. Proxy settings should be
checked for the same.

3) If RSA7 contains more than 20 data sources, in that case, create a process chain with only 6 process types in
parallel as creating more than 6 process types may affect system performance. Once the delta queue is clear, create
next set of process chain with atleats 10 process types in parallel which will speed up the clearing of delta queue.

4) After upgrade if you find DTP as inactive then, activate respective transformations via RSDG_TRFN_ACTIVATE.

Showing 1 to 1 of 1 results