Migration to HANA

[Former Member]

Hi ,

I am not sure if it is the right forum to place this but let me try.

We want to migrate from oracle to HANA DB. Current oracle size is 1 TB. We want to know what could be the options to reduce database size before we migrate to HANA DB. Thanks.

Regards,

Arpit.

[lucas_oliveira · Accepted solution]

Hello Arpit,

Not sure which kind of application lies beneath your current Oracle DB nowadays but I'm assuming it's an SAP application like BW or Business Suite. If I got it right I must say taht there are many resources available here (yes, in scn) and actually this sort of question has been answered in quite a few discussions/blog posts as well. A quick search lead me to:

SAP BW on HANA Cookbook

And of course, SAP Note 706478 - Preventing Basis tables from increasing considerably - it's a classic and touches a subject that needs attention, specially in migrations.

Best Regards,

Lucas

[Former Member · Accepted solution]

Hi Lucas,

Thanks for your reply. Note 706478 is really helpful .

We are running ECC 6.0 SR3 on oracle. and We want to move to HANA DB.

Due to 1.8 TB size we are little worried.

We are thinking of archiving but if we do archiving at ECC 6.0 / oracle DB then after migration will ECC be able to access archived files with ECC 6.0 / HANA DB?

This question is because when we archive, those files will not be migrated to HANA DB by DMO if I am not wroong?

I have the same question as mentioned in the below link

Best Regards,

Arpit.

[lucas_oliveira · Accepted solution]

Hello Arpit,

Well, first of all, there are HANA appliances out there that can handle 1.8TB of data. Please check the availability of the Business Suite on HANA appliances here.

Secondly, I'm no archiving expert but I understand that one of the objectives of archiving data is to release load from the database moving data to archive files. Later on, archived data can be read from the ABAP application server bypassing database (ok, only the archive indexes will be read from db, but not the actual data).

With that said, I can only imagine that the archiving system is (or at least should be) database agnostic. Thus, switching to HANA or any other db would bring this question anyway. That makes me think that indeed this forum is not really the best place for this sort of question. Unless someone point a specific issue related to reading archived data in SAP systems with HANA as db. The only issues I could find up until now are related to the replication of archived data into HANA using SLT. Clearly not your scenario.

Maybe the best place to address this specific question is the

[]'s,

Lucas de Oliveira

[Former Member · Accepted solution]

Hello Aprit,

Housekeeping as described in the Note 706478 is my first recommendation. In addition you should consider data archiving in ADK files.

ADK files stored outside of the primary database and can be stored in the file system. The recommended storage option would be an SAP certified repository. With this you reduce the DB size, but can still access the Data for reporting purposes.

After the migration the ADK files are still accessible from suite on HANA. ADK ever supported the upgrade to the next version. I started archiving in R/3 3.0F and this is still valid for Suite on HANA.

Best Regards

Stefan Netzer

Practice Engineer ILM

[Former Member]

Hi Arpit,

For sizing for ECC you can look at SAP Note 182170 - http://service.sap.com/sap/support/notes/1872170 . It contains a report /SDF/HDBSIZING which can be run to give you an estimate of your memory requirements when migrating to HANA. A rough estimate is can be gathered form the calculation (DB Size/2 * 1.2 + 50GB). Please remember HANA has a high compression factor so your 1.8TB system should go down to approx. 1.1TB without archiving.

Concerning your archiving question - There are some customers who have archived data before a migration using Near-Line Storage technology, after the migration the NLS is configured and the archiving links/locks are still in place and can be read from the same archiving storage.

Thanks

Paul