Planning Migration to SAP HANA, But Worried about Business Downtime...!!!

[surjit_singh3]

Everybody, who knows about In-memory databases (like SAP HANA DB), is aware about their enormous speed and throughput one can achieve from In-memory database engine. If I say only about SAP HANA in-memory database engine, it can process data 3600 times faster than any traditional RDBMS.

As a proof point it has been tested than HANA in-memory engine can process as maximum as 460 billion data line item in a second. (This is equivalent to calculating amount of taxes paid by everyone on this planet, since 1950, in one second.)

Looking at these proof points, C.I.O. or IT manager of any organization would definitely wish to switch from their traditional RDBMS to SAP HANA in-memory database, to add a significant value proposition to their business from technical standpoint.

Only point, that might bring saturnine expression on the face of an IT manager or technical administrator, is the BUSINESS DOWNTIME they may need to migrate their existing SAP solution to HANA database.

Now, speaking a bit more technically, complete migration cycle comprises of two main processes,

1. ) Exporting Source Database and 2.) Import into target HANA database

As target is an in-memory database, so processing time for import is a lot smaller than of what exporting source system would take. So here, I would put more emphasis on improving export time on source system.

There are many already proven ways, in which SWPM tool of SAP can improve on export process timings.

To have a quick look at those traditional ways:

1. ) Performing table splitting on source system
2. ) Doing export package splitting
3. ) Updating database statistics
4. ) Cleaning un-wanted monitoring logs, temp tables beforehand
5. ) Leveraging R3load parallel processing

Along with these traditional ways, migration to HANA can be optimized further by using another option “using additional hosts for export” that is available when you choose to export source system towards HANA DB as target in SWPM tool.

How it would effect positively:-

1. ) Any available additional application server can be used for export along with central system
2. ) Packages can be distributed to all available hosts for export
3. ) We can further sort packages and decides number of R3load processes for larger and small packages differently
4. ) Export sorting can be done By SIZE, By TIME (taken in previous system export or dry run), By Name or By any manually customized export sequence
5. ) A common export directory is mounted across all available hosts, so final export dumps files always remain intact
6. ) Export Logs are stored in installation directory on different location (like .../EXP directory for CI & in .../EXP-FILTER directory for additional host), so error analysis & issue handling of packages running on each host is easy

Using this you can reduce total export time by significant amount.

For example, say SWPM tool is taking 12hours to export 2Terbytes of your source database from a single Central Instance, then using another application instance host of similar configuration, would help to reduce this to half of it i.e. to 6hours. Adding more hosts & distributing packages evenly across all hosts, would contribute by equal proportion in reducing overall export time.

Therefore, if you are planning to move your existing SAP solution to HANA, the use of this option would definitely make a great contribution to reduce overall HANA migration timings.

If you are interested in knowing more technically or step-by-step procedure, you can check following technical document on SCN. http://scn.sap.com/docs/DOC-64433

Remember that proper preparation is always the key point that would decide your success or time taken to achieve that success.