This architecture shows an Oracle Data Guard configuration with a primary database that transmits redo data to a standby database. The standby database is remotely located from the primary database for disaster recovery and backup operations.

dataguard-dr_db-oracle.zip

Oracle Data Guard uses Redo Transport Services and Apply Services to manage the transmission of redo data, the application of redo data, and changes to the database roles.

This architecture supports the following Oracle Data Guard components:

• Redo Transport Services

  Redo transport services control the automated transfer of redo data from the production database to one or more archival destinations.

  Redo transport services perform the following tasks:

  • Transmit redo data from the primary system to the standby systems in the configuration.
  • Manage the process of resolving any gaps in the archived redo log files due to a network failure.
  • Automatically detect missing or corrupted archived redo log files on a standby system and automatically retrieve replacement archived redo log files from the primary database or another standby database.
• Apply Services

  Apply services automatically apply the redo data on the standby database to maintain consistency with the primary database.

  The redo data is transmitted from the primary database and written to the standby redo log on the standby database. Redo data is applied directly from standby redo log files, as they are filled using real-time apply. Apply services also allows read-only access to the data.

• Role Transitions
  Using Oracle Data Guard, you can change the role of a database from a standby database to a primary database, or from a primary database to a standby database using either a switchover or a failover operation. Oracle Data Guard simplifies role transitions and automates failovers.

  • A switchover is a role reversal between the primary database and one of its standby databases. A switchover ensures no data loss. This is typically done for planned maintenance of the primary system. During a switchover, the primary database transitions to a standby role, and the standby database transitions to the primary role.
  • A failover is when the primary database is unavailable. Failover is performed only in the event of a failure of the primary database, and the failover results in a transition of a standby database to the primary role. The database administrator can configure Oracle Data Guard to ensure no data loss.

Several manual steps are involved in configuring Oracle Data Guard, including, but not limited to, the following:

• Prepare the primary database with the recommended parameters
• Prepare the TNS aliases in the primary and standby environments
• Create the physical standby database as a duplication of the primary database
• Configure the Data Guard

These manual steps are widely documented in multiple Oracle documents. This playbook provides a set of scripts that you can use to automate most of these actions. These scripts help to configure Oracle Data Guard by setting up a standby database for an existing primary database. The scripts make use of the restore from service Oracle Recovery Manager (RMAN) feature and Oracle Data Guard Broker.

Before configuring Oracle Data Guard using the scripts provided in this document, review the following assumptions and requirements:

• The primary database already exists.

• The standby nodes already exist, with or without an existing database.

  Note:

  If there is already a database in the standby location, then the scripts will delete it before recreating the standby.

• There is mutual connectivity between the primary and standby using the database’s listener port.

  • For single instance databases, there must be a bidirectional connection between the primary db host and the standby database listener's IP and port.
  • For Oracle Real Application Clusters (Oracle RAC) databases, there must be a bidirectional connection between the primary db hosts and the standby database's scan and VIP IPs and ports.

  The scripts perform connectivity checks, but you can use the command nc -vw 5 -z IP PORT to verify remote connectivity.

• Oracle Automatic Storage Management (Oracle ASM) is used for datafiles, control files, online redo logs and archive redo logs.

  • For single instance databases, the password file and the spfile can be located in regular file systems or in Oracle ASM.
  • For Oracle RAC databases, the password file and the spfile must be located in Oracle ASM.
• The primary and standby databases are managed by Oracle Clusterware ( Oracle Grid Infrastructure must be installed, as both single and Oracle RAC topologies use srvctl).
• Because Oracle Managed Files are used, the database parameters db_create_file_dest, db_create_online_log_dest_1, and db_recovery_file_dest must already be defined in the primary database with the appropriate Oracle ASM diskgroup location (such as +DATA or +RECO).
• The relational database management system (RDBMS) software owner (for example, oracle user) sets the required Oracle environment variables (ORACLE_HOME, LD_LIBRARY_PATH, PATH, ORACLE_UNQNAME and ORACLE_SID) in its profile.
• It is assumed that a symmetric topology is used (that is, if the primary is single DB, then the standby is single DB; if primary is an Oracle RAC database, then the standby is an Oracle RAC database too).
• If the databases are Oracle RAC, then it is assumed that each Oracle RAC has 2 nodes.
• The scripts are valid for configuring a standby database for a primary database that does not already have a standby database.
• The scripts are also valid for adding a new additional standby database to an existing Oracle Data Guard. For this scenario, you must use the property ADDITIONAL_STANDBY=YES in the properties file. In this case, the new standby is added to the existing Data Guard Broker configuration.

The following are features of the scripts:

• The scripts are idempotent: they can be re-executed in case of errors.
• The operating system user names (such as oracle, and grid) and the folders (Database home and Grid home) are configurable.
• The Oracle and Grid OS users can be the same user or different users.
• Transparent Data Encryption (TDE) for the database files is optional: the scripts are valid for both cases (TDE and no TDE).

  Note:

  a symmetric configuration will be performed: if the primary database uses TDE, then the standby database will be configured with TDE; if the primary database does not use TDE, then the standby database will not use TDE.
• Read Only Oracle Home (ROOH) are supported. The scripts are prepared to automatically work in environments with ROOH and with "traditional" Oracle homes.
• The scripts are valid both for Oracle RAC and single instance environments (in a symmetric topology).
• The scripts are validated in 12c (12.2), 18c, 19c and 21c RDBMS versions.
• The scripts are validated in Oracle Cloud Infrastructure (DB Systems) and in on-premises environments.
• The scripts have been validated to configure a hybrid Oracle Data Guard, where the primary database is on-premises and the standby is a DB System in Oracle Cloud Infrastructure.

The following are descriptions of the script files used in this solution:

• 1_prepare_primary_maa_parameters.sh

  Connects to the primary database and configures it with the recommended Oracle Maximum Availability Architecture (MAA) parameters for Oracle Data Guard. It creates the standby redo log files, it sets the values for DB_BLOCK_CHECKSUM, DB_FLASHBACK_RETENTION_TARGET, and so on. This script is executed only once, whether the primary database is an Oracle Real Application Clusters (Oracle RAC) or a single instance database.

• 2_dataguardit_primary.sh

  Prepares the primary hosts for Oracle Data Guard. It adds the required TNS aliases to the tnsnames.ora file, it checks the connectivity with the remote standby, it configures net encryption if it is not already set, and generates the output tar files that contain the primary password file and the Transparent Data Encryption (TDE) wallet (if used).

• create_pw_tar_from_asm_root.sh

  This script is not always required. It is required only when the primary password file is stored in Oracle Automatic Storage Management (Oracle ASM). It creates an output tar file with the password file.

• 3_dataguardit_standby_root.sh

  Prepares the new standby hosts and creates the standby database using the restore from service Oracle Recovery Manager (RMAN) feature and Oracle Data Guard broker. If there is an existing database in these hosts (either a working database or as result of a previous script execution failed attempt), then the scripts will delete it before recreating the new database as the standby.

• DG_properties.ini

  This is the properties file that must be customized with the environment's specific values. It's used by all of the scripts, both in the primary and the standby.

This solution requires the following roles for the primary and standby database systems:

See Oracle Products, Solutions, and Services to get what you need.