Restoring production HANA DB backup to a smaller hardware

[nanda_kumar21]

Hi Everyone,

We have a production HANA DB (SP07) of total memory 1TB out of which  512GB+ is being utilized currently.

We are running BW 7.31 on top of it.

We now have a requirement to restore the full backup of this system to a smaller hardware (about 350GB of memory).

I understand the restore may throw some errors and may not be successful because of the difference in memory. My question is

1. Is there a way to load only selective tables or better yet, blacklist certain tables before starting the restore from the compete data backup files?
2. Is there a way to bypass the memory check during the restore and then somehow not load certain tables during the HANA DB startup?
3. Has anyone came across this requirement/tried this before?
   1. If yes to the question above, can you please let me know how you solved this problem?
      

• We cannot unload tables in the source system because its production
• We cannot upgrade our systems

Let me know if you need more information.

Just wondering, shouldn't there be an option that the HANA DB will first just restore the DB and then load data, only based on whatever memory is available during startup, instead of failing at the beginning of the restore itself (so the customer doesn't have to shell out for bigger hardware for non-prod environments). This makes sense, if you just want to restore to your sandbox for simple testing purposes.

Thanks

Nanda

[former_member205280]

Hi Nanda,

Before answer you question, I want to point out that HANA by default load column-store table on demand, and will load all row-store tables when indexserver gets started.

The restore process won't "check" your target system's memory size to see if it's match your source system, you may have license limited memory size or global_allocation_limit size in global.ini profile.

Now to answer your question, it's possible to restore your production system database to a testing environment, however there're some prerequisite:

1. The target system release is the same or higher than your source system.

2. The target system has the same hosts (both worker and standby) as your source system, otherwise the name server will fail to start.

3. The target system has the required free disk space (don't forget to add the backup files size), you can use NFS to share the backup files to reduce some disk space.

4. I'm not if it's require you use the same OS release, but in our experience we also use the same OS release.

As long as you meet the above requirements, you can restore your production system into the testing system. But the performance will depend on your workload, it's hard to tell!

Regards,

Michael

[Former Member]

Hi Nanda,

Can you please check the data and log volumes of the source system(1 TB memory) and the destination system(350 GB memory)

Is this a Single container or Multitenant Database container?

Single Host or Multi Host?

We have had similar situation in the past and as long as you have the same

Amount of disk space for data and log volumes

Architecture(Single Container/MDC) on source and destination

Same or higher version on secondary

The same number of IndexServer files between source and destination

The restore will not fail, as far as the memory allocation is concerned depending on the usage of the secondary system after restore you can come up with a plan to keep only certain tables in memory

Our experience has been that a non prod system uses much less memory and the automatic unloads will be able to handle the user requests and you may not be required to take manual actions unless your non prod system is highly utilized

Hope this helps

Sunil

[nanda_kumar21]

This message was moderated.