Procedure for BW on HANA migration - Export Preparations

 Below are listed some of the important Information material on BW on HANA migration-

After you have prepared your BW system for migration, it is time now to perform actual migration. The post will focus on manual migration in parts as this is the most used method in real scenarios.

We will take SAP BW 7.4 (ABAP stack) based on Oracle 11.2 as sample for describing migration steps. SAP BW application server is operated on separate hardware which is Windows 2008 R2. A certified HANA appliance is used (single node system). The migration is done using SWPM (Software Provisioning Manager). If the system to be migrated is a sandbox system, the optional step for creating homogeneous system copy can be skipped.

Also, it is assumed that the system ID (SID) of the SAP BW system remains unchanged during migration.

migration.png

As shown in above figure, the migration of SAP BW starts with the export of all data. Start the SWPM and connect it with present SAP BW application server. Using this server, the SWPM can access the database and exports all data to a file system.

The SWPM is then started in target environment to built the new SAP BW on SAP HANA system. Initially, the SAP BW application server that uses SAP HANA as the primary database is installed. The SWPM then imports the previously exported data to the new SAP BW on SAP HANA system.

Export Preparations-

Before starting export of BW system, some preparation steps are needed. This ensures that the BW system is in consistent phase and there are no data losses during export. Below are some of the essential steps. Depending on your system version, you should refer the SAP documents to determine if you should carry out any supplementary steps (Check the link given before under Information Material on SAP BW on SAP HANA Migration)

Step 1: Lock Users

All users must be temporarily locked out of the BW system to bring the system in consistent state. You need to exclude the administrators that are involved in migration, emergency users and the DDIC users from the locks. Use tcode SU01 to lock individual users in SAP BW and tcode SU10 to lock multiple users at a time. First, choose all users for which there is no lock. To do so, click LOGON DATA button in tcode SU10, and choose USERS WITHOUT LOCKS ONLY option under SELECTION BY LOCKS. Initially, select all users, and then remove the previously described administration users from the selection. Save this list so that you can undo the lock process later on without releasing IDs that have been locked before. Then click the 'lock' icon. Before continuing, check if any users are still logged in the system using tcode SM04. Go to the next step after all the users are logged off from the SAP BW system.

Step 2: Stop the Process Chains

To stop the internal processing operations in the SAP BW system, you must stop the process chains and the real time data acquisition (RDA) daemons using the RS_SYSTEM_SHUTDOWN report in tcode SE38. Choose the SHUT DOWN PROCESS, and select the PROCESS CHAINS and DAEMONS options. Then, click EXECUTE or press F8.

Step 3: Clear Delta Queues

To lower the risk of a possible data loss, SAP advises you to clear the delta queues of connected source systems prior to the export of SAP BW system. Log on to the connected systems and go to tcode RSA7. Check if any delta queues for the datasources of your BW system have non zero number of entries. If yes, you should run the infopackage in your SAP BW system for the relevant Datasource to transfer the data to the SAP BW system. Of technical connection problems occur, the background users that are required for this operation may already be locked. Unlock them temporarily for the data transfer.

Step 4: Stop Job Processing

You must also temporarily stop the background processing so that the data in the SAP BW system remains unchanged during export. This also ensures that the job is not executed uncontrolled in the migrated SAP BW on HANA system. In tcode SE38, start report BTCTRNS1 for stopping the background processing.

Step 5: Clear Temporary SAP Tables

Even if you have cleared the temporary tables in cleanup activites, you must now rerun this step after all activities are discontinued in the SAP BW system. Call the report SAP_DROP_TMPTABLES report for this purpose.

Step 6: Update Table DBDIFF

Table DBDIFF contains information about deviations between corresponding objects of the Data Dictionary (DDIC) and the database. For example, if objects in DDIC have another type than in the database, this entry will be recorded in the DBDIFF table. All differences that are not recorded correctly in this table prior to running export, can result in technical problems later on. For this reason, you should call the report SAP_UPDATE_DBDIFF in tcode SE38 to update these entries.

Step 7: Export Native Database Objects

The SMIGR_CREATE_DDL ABAP report generates SQL statements that you can use to transfer native database objects of the current SAP BW system to the SAP BW on SAP HANA system. The report creates several SQL scripts that are all listed in the SQLFiles.LST file. All files generated by the report are  imported later on. Read SAP note 1921023 and then execute the report in SE38. Choose SAP HANA as the target database. Enter the appropriate path on the SAP BW application server under the INSTALLATION DIRECTORY.

Step 8: Check the DDIC Password

Before starting export, you should check the DDIC password in the SAP BW system as the last step. Logon to Client 000 as the DDIC user. You must enter this password later on to complete the migration. If you can't determine the password, you must reset it before export.

Comments

Post a Comment

Popular posts from this blog

Sample ABAP program for Updating notepad file data to Internal table and Sending it to Application server

 *--Structure type TYPES: BEGIN OF TY_STD, RONO TYPE C LENGTH 4, NAME1 TYPE C LENGTH 20, GEN TYPE C LENGTH 6, FEES TYPE C LENGTH 10. END OF TY_STD. *--Header line and internal table DATA WKA TYPE TY_STD. DATA INT_TAB TYPE TABLE OF TY_STD. *--Application server files are known as "Datasets" *--here "fname" is the Dataset DATA FNAME TYPE C LENGTH 40 VALUE "StudentsInfo.txt". *--Convert notepad file data into internal table CALL FUNCTION 'GUI_UPLOAD' EXPORTING FILENAME = 'C:Documents and SettingsAdministratorDesktopstudents.txt' HAS FIELD_SEPARATOR = 'X' TABLES DATA_TAB = INT_TAB. *--Sending data to Application Server OPEN DATASET FNAME FOR OUTPUT IN TEXT MODE ENCODING DEFAULT. LOOP AT INT_TAB INTO WKA. TRANSFER WKA TO FNAME. ENDLOOP. CLOSE DATASET FNAME.
Read more

OPEN SQL EXAMPLES IN ABAP – PART 2

 ******************************************* **displaying Raw Materials and Finished products **only from MARA table. DATA WA TYPE MARA. * **--WHERE clause is for filtering the records SELECT * FROM MARA INTO WA WHERE MTART = 'ROH' OR MTART = 'FERT'. WRITE: / WA-MATNR, WA-MBRSH, WA-MTART, WA-MEINS. ENDSELECT. * **************************************************
Read more

Domains and Data Elements

  Domains A domain provided Technical attributes (type, length and possible values) for a field. The definition of domain in ABAP is same as that in Mathematics. In the world of Mathematics, a domain is defined as the set of input values that are valid for a given function. The same holds true for domains in ABAP. To understand this, let us first see what is the role of domains in ABAP data dictionary. Domains -> Data Elements -> (Structures, DB tables, program references etc.)
Read more