Data Guard Physical Standby Database Best Practices – Part II

Comments 0

Share to social media

Read Data Guard Physical Standby Database Best Practices – Part I

In this second part we will setup the standby database and enable Fast Start Fail Over.

Standby Database Creation

Start the standby database instance in NOMOUNT start up mode:

Now that the configuration of the standby server is complete, let’s perform the duplication from the primary site.

Primary Server

Use the Recovery Manager (RMAN) to duplicate the primary database to the standby database.
Invoke RMAN; connect to the primary database as the sys user. Make an auxiliary connection to the standby instance:

The RMAN duplication process is finished without errors. After the database duplication, we will force the log switch on the primary database to archive the current redo log group.

Standby Server

On the standby database, run the ALTER DATABASE RECOVER MANAGED STANDBY DATABASE command to start redo apply.The USING CURRENT LOGFILE means the redo is applied as soon as it is received on the standby.The DISCONNECT option means the redo apply will run in background session.

Note that the current log sequence number on the standby is 10.

Primary Server

Let’s perform 3 additional log switches on the primary database. Then we will query the standby database to verify that the log files are applied to the standby.

Standby Server

We query the standby database. The logs were successfully transported and applied.

Broker Configuration

Configuring the broker is recommended because it simplifies data guard operations.

The DG_BROKER_START parameter must be set to TRUE.

Standby Server

The Oracle Net listener must be also configured with an additional static service identifier. The value of the GLOBAL_DBNAME attribute must be set to a concatenation of _DGMGRL.

Primary Server

The Oracle Net listener on the primary database should have static service definitions:

Let’s create a broker configuration and identify the primary database.

Perform a switchover test:

Standby Server

Confirm of the role switch:

Primary Server

The former primary database is now the new physical standby database:

Switch over to the former primary database:

Enable Fast Start Fail Over

The actual configuration is running in Max Performance mode and Fast Start Fail Over is currently disabled.

Primary Server

To configure FSFO, you must first enable flashback database on both the primary and standby databases. (Further reading: Introduction to Oracle Flashback Technology)

Redo apply must be stopped to enable flashback database on the standby database:

Standby Server

Primary Server

Restart the Redo apply:

The Observer

The server dg3 will act as the observer in the Fast-Start Fail Over configuration. The Oracle client binaries have been installed with administrator option. Confirm the connectivity with both the primary and the standby databases:

The prerequisites for FSFO have been met. So FSFO can be configured, enabled and started. The FSFO observer process will be started using the DGMGRL session and will be logged to a file named observer.log:

Primary Server

Create a shell script and run the shell script in the background; create observer.sh (MOS ID: 1084681.1)

Where do you place the Observer?

That all depends on your requirements, the observer can be placed in a third site separated from primary and standby sites with a HA observer; this means 2 hosts; one observer process running on the first host and the other on standby (not running) on the second host. Only one observer can run at any one time.

References

https://docs.oracle.com/cd/E11882_01/server.112/e41134/toc.htm