SAP on Oracle Data Guard on Google Cloud GCE - Part 2 - Implementation Steps

Technical Blog

This second part will take you on a deep dive into the implementation steps, following the first part of this blog, "SAP on Oracle Data Guard  on Google Cloud GCE - Part 1 - System Requirements".

Before we start, there are a few more details about Oracle Data Guard we need to know.    

The Oracle Data Guard observer monitors the synchronization of primary and standby Oracle databases. There are several options for setting up Oracle Data Guard, as shown in the table below.

The Fast-Start Failover feature enables an automated process to restart an old primary server as the secondary database.  These two features are included in Oracle Enterprise Edition.   

Process flow of FSFO (Fast-Start Failover).

In this proof of concept (POC) system, the components included are:    

• Oracle Primary GCE instance with SAP Netweaver 7.5 installed
• Oracle Secondary GCE instance
• Observer instance instance for Oracle Data Guard Fast-Start Failover

In this blog, we will focus only on the Oracle Data Guard implementation process. I will skip the SAP application server HA installation process; for more details, you can refer to High-availability planning guide for SAP NetWeaver on Google Cloud.

Regarding storage, this setting may be slightly different from on-premise Oracle databases in terms of storage for HA.  Traditionally, we use shared storage for Oracle Data Guard, while in GCE, we use a separate persistent disk for each GCE instance and use log shipping to synchronize them.

System Diagram

My POC system detail

This configuration is moderately complex and requires experienced SAP Basis and Oracle DBAs.

The main steps include:

1. Provisioning a GCP landing zone, project, and VPC.
2. Installing the primary Oracle server in ARCHIVELOG mode, downloading required files, and disabling SELinux.
3. Cloning this server to the secondary and observer servers to avoid repeating the previous steps.
4. On the primary server, installing SAP ASCS, DB, and PAS. (Ref: 2660017 - Oracle Database Software Installation on Unix)
5. Installing the secondary Oracle server using the cloned server from step 3.
6. Installing the Observer, adding the primary and secondary servers to the failover configuration, and enabling monitoring. You can refer to the Oracle manual in SAP note : 3569811 - Oracle Data Guard Guide for SAP customers for more detail and example code. Follow the topic “Configuring Data Guard Broker”
7. Also, adding the Oracle wallet to enable passwordless connections between these servers.
8. Create database trigger ex. POC_PRI when DB role changes. Follow topic “Switching database service at database role event” in the manual.
9. Adjust NW 7.5 AS server to use failover TNS name. Follow topic “Reconnect SAP instance to database”

Switchover Testing

After the lengthy configuration process, let's check the current system and attempt a failover.

• Start SAP POC and check the system status; we are currently on database server ora-1-game. I tried adding some transaction data to verify its persistence after the switchover.  

• Switch over to poc_ora2. This process is similar to a soft failover while both servers are available. This process automatically restarts poc_ora1 as the secondary database, eliminating the need to reinstate it.

• If you are running a transaction during the switchover, a “dbif_repo_sql_error” error will occur. In this test, the system came back up in less than 2 minutes. If you open the SAP GUI and leave it idle during the switchover, you will not notice any errors and can continue using the system as normal.

• Now, if you check the system status again, the database host will be the previous secondary server.

• In a real-world scenario, if the primary server becomes unavailable, we need to fail over to the secondary server. In this POC scenario, this takes less than 3 minutes to complete.

• After the failover, we need to start and mount the secondary server using SQL*Plus, and then use DGMGRL to reinstate it back to operation.

Conclusion

In this POC system, we demonstrated how to set up the Oracle Database native tool for a Data Guard HA solution in Google Cloud, with references provided. This process requires a skilled team from the infrastructure, SAP, and Oracle areas. 

I hope that Google Cloud will soon provide central documentation to simplify this process for customers, similar to “Deploy Oracle Data Guard on Bare Metal Solution“

Please feel free to comment if you have any suggestions.    

Thank you.

Chankitti Srisawat