Other DB to HANA Migration cycle, roles/responsibilities of basis,functional & technical resources

New thing? No! This(migration) is the ongoing journey to be embark upon, which all businesses today or tomorrow have to ride on.

As usual, whenever I complete any assignment/project, I blog it and share the insights, in and out of that on this platform in easiest way possible.

So lets begin with what all steps involved in moving business from e.g. Oracle DB to HANA DB. This is one of the used case.

Pre-checks:

◉ How many custom reports are there?

◉ We will be having one standard program, to check count of custom reports in the system.

Team involvement and work distribution:

◉ First in process, comes functional consultant. They verify, custom config done for each module.

◉ After verification of custom module, Basis team comes into picture.

◉ They will start the system copy, data/table/reports each and everything to HANA DB

◉ After migration to HANA DB, technical consultant roles come in.

Timelines:

◉ Basis team will take 2 to 3 days for migration based on the system constellation.

◉ Then functional team will work on their configuration, whether they have configured correctly or not.

Technical Consultants responsibilities:

There are three variants, FUNCTIONAL_DB, FUNCTIONAL_DB_ADDITION, PERFORMANCE_DB

• We go to ATC, enter these variants, it will show result in form of reports.
• These reports contain, everything we need to change in ABAP code.
• It will show, what all SQL syntaxes need to be changed to compile with HANA DB.
• These are standard variants provided by SAP itself.
• It will show error for all technical aspects, be it custom report, custom tables.

e.g. suppose we have one report, and after running ATC transaction, there are 10 lines highlighted in report, double click on every line will show what exactly the error is, what line the error is, what is the program and what is the solution to correct the error.

We can download ATC test result in excel/spreadsheet, there were almost 1lack 80k areas highlighted that we need to change and fix.

This further gets distributed among technical resources working on project.

Few glimpses of warnings/errors:

• For every SELECT query ORDER BY clause should be present
• SELECT * should be removed, it should be present only if all the fields are needed otherwise use the required column name only
• Native DB SQL HINT, we use to write native SQL in ABAP report sometime, it should be mandatorily removed.
• All native SQL command should be replaced completely with open SQL statement e.g. EXEC SQL… ENDEXEC. whatever codes written inside this block is native SQL, needs to be removed.
• We use secondary index for performance, this should also be removed. Oracle HINT %
• Bypass in Table buffer, used in DB select query, needs to be removed. We do not use buffer in HANA DB.

When it comes to PERFORMANCE_DB, it will show error like LOOP inside LOOP (use parallel cursor).

READ without BINARY SEARCH. Sorting internal table.

PERFORMANCE_DB variant: We need to improve performance of the code using new or old syntaxes.

80% of errors would be from these only.

Note: Bypassing buffer means, it would not allow buffering of the table.

• After completing every report, we need to test again whole thing. Because we are changing most of the functionality in the report.
• Our functional team will give some test data, which we need to run and compare the result.
• After our initial testing, it would go to functional team, they will test it further.

In our migration project, client had hired another company, only for testing purpose.

They performed the regression testing, and lastly changes moved to production environment.

Migration was completed in almost 3 months.

Note: Basis team only perform Oracle server to HANA server migration, it will take one day, if there are issues or anything missed, such fixings can take few more days based on system constellation.

Technical consultant’s role comes when data are migrated to HANA DB, from there we need to take care of each and everything.

From the book:

Variant FUNCTIONAL_DB

These are different checks would be performed:

• Finding Native SQL
• Database (DB) hints
• Finding ADBC (ABAP Database Connectivity) Usages
• Finding usages of special DDIC function modules that check or return the existence or technical properties of certain DB indexes.
• Finding accesses to technical pools/clusters of a pool/cluster table
• Finding non-robust ABAP code that relies on non-ensured/implicit sorting of certain SQL queries, although no ORDER BY clause is used. There are two different checks available for finding non-robust ABAP code:
• “Search problematic statement…w/o ORDER BY”
• “Depooling/Declustering: Search for…w/o ORDER BY ”

Variant FUNCTIONAL_DB_ADDITION

This check variant contains additional checks that are not directly linked with the SAP HANA migration. However, they can detect – as experience has shown – important, potential functional errors and low-performance SQL statements. Therefore, the checks of this check variant are not mandatory for the SAP HANA migration, but they are recommended.

• Checking SQL Operations without a WHERE Clause
• Checking SQL operations with the addition FOR ALL ENTRIES IN, whereby in the code itself it is not ensured that the internal table < itab> is always filled.
• Checking settings in DDIC tables for consistency. This check whether table buffer settings have been maintained in a consistent manner (influence on performance).

PERFORMANCE_DB

This check variant is recommended for performing a static performance check run for ABAP custom code. The variant contains all the essential static SQL performance checks.

Note: This check should only be used as additional hints when fixing the issues detected by the SQL monitor analysis. Do never fix the static findings without looking in the SQL monitor before.