cancel
Showing results for 
Search instead for 
Did you mean: 

Async recovery - Hana DB

0 Kudos

Dear Experts,

We recently migrated from Oracle to HANA. We have a DR site which is on prem and connectivity between DC and DR is not stable. We configured system replication using HANA studio but due to bad connectivity, the log area got full and our primary system started giving issues. we then had to stop the system replication. As a result, we are not able to use our DR site.

In oracle, what we used to do was keep the DR db in mount state and manually transfer all logs during night to DR site and apply them manually to keep the DB in sync. For this, we didnt had to perform complete recovery. just keep the logs synced and in case of switchover, manually take the DR site up. Now, this method is certainly not recommended and chances of data loss is very high but it is acceptable by us.

Is there any way by which we can do similar thing in HANA DB. like keeping the DB in mount state and keep applying logs manually without have to do restore activity afresh...??

Thanks in advance.

Wasi

Accepted Solutions (1)

Accepted Solutions (1)

dennispadia
Active Contributor

Hello Wasi,

First and foremost you cannot use "Synchronous" replication when you are setting up replication with DR site. If are setting up system replication between HANA system in two different region, you should always use "Asynchronous" system replication mode.

Given ~ 250 GB of data

Let us assume that if you perform initial data load of 250 GB to DR site, what should it be throughput

Throughput ~ 250 GB/day = 250 * 1024MB / 86400s = 3 MB/s ~ 24 Mbps

I assume, how long it takes for you to perform initial data load with the speed you have mentioned? In "synchronous in memory" and "synchronous" replication mode, primary system waits until secondary system has received data.

With this speed and the distance between two data center, I think you system replication could not work. Try to establish system replication using asynchronous system replication.

You can always take daily incremental backup and copy that instead of copying all log backup. So if you are recovering your database on sunday, just restore it using last complete data backup and all incremental backup that way you can eliminate of using log backup.

But your network connectivity is really bad between two data center. This days normal WiFi connection is of 100 Mbps i.e. 12 MB/s, if possible try to increase internet bandwidth as well.

Regards,

Dennis Padia

Answers (3)

Answers (3)

dennispadia
Active Contributor

Hello Wasi,

The task you were performing on Oracle database is not possible on HANA database i.e. manually performing roll forward logs on DR site to keep HANA database in sync with primary.

As you have DR scenario, I assume that the HANA System Replication is happening over the internet. Can you please let us know which replication mode you are using for HANA System Replication? Also what is the size of your database? What is your HANA Database version? When you say bad connectivity, can you please tell us what is your Internet bandwidth?

Regards,

Dennis Padia

0 Kudos

Dear Dennis,

Thanks so much for your suggestion. I can try incremental backup / recovery approach. this should be doable and my restoration time should also decrease.

Unfortunately, we cant increase the bandwidth between DC and DR immediately. Its surely planned for near future though.

Thanks once again.

regards,

Wasi

0 Kudos

Dear Dennis,

Thanks so much for your reply. The details you asked are mentioned below.

Replication mode: Synchronous
DB Size: 250 GB
HDB version: HANA2 SP03
Connectivity: 2MBPS P2P (Dedicated)

Bad connectivity means higher latency, packet drops, rto etc...for instance, once the connectivity was down for almost 24 hrs due to technical reasons and log space on primary started to fill up. We dont have a dedicated Basis resource monitoring the system continuously. In such a scenario, if the DR downtime goes unnoticed for more time, DC may get into major issues. Hence, I need to have DR but its existence should not hamper our DC.

Right now, I am copying the logs manually to DR site and lets say, I have a full backup which was taken 15 days back lying on DR. Every week on a set day, we perform full recovery with logs and DR system starts. Only problem with this approach is that we have to perform full recovery every-time and as logs increase, the recovery time is increasing substantially. And to copy full data backup on DR site is too cumbersome and time consuming. Also, while copying if there is a glitch in the connectivity, the backup gets corrupted and rendered unusable for restore.

In crux, this is the issue and hence I asked the question in the first post.

Any suggestions will be highly appreciated.

Thanks and regards,

Wasi