Oracle 11GR2 DataGuard (DG) installation and configuration (physical standby)

Reference document https://oracle-base.com/articles/11g/data-guard-setup-11gr2 Oracle 11GR2   

DataGuard (DG) installation and configuration (physical standby)

 

Master database

Precondition

  • You have two servers (physical servers or vm) with operating systems and Oracle is installed on them. In this example, I used Oracle Linux 5.6 and Oracle Database 11.2.0.2
  • The main server has a running instance
  • The standby server only installs database software

Main server settings

logging

Check whether the main database is in archive mode.

SELECT log_mode FROM v$database;

LOG_MODE
------------
NOARCHIVELOG

SQL>

If it is no archive mode, switch to archive mode.

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

Force Oracle to log all operations

ALTER DATABASE FORCE LOGGING;

Initialization parameters

Check the settings of the dbname and dbunique name parameters. In the current example (the main database), they are all set to "DB11G".

SQL> show parameter db_name

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
db_name 			     string	 DB11G

SQL> show parameter db_unique_name

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
db_unique_name			     string	 DB11G

SQL>

The dbname of the standby database will be the same as the dbname of the primary database, but the primary and standby databases must have different dbunique name values. The dbunique name values ​​of the primary and standby databases should be used in the DG config setting of the LOG_ARCHIVE_CONFIG parameter. For this example, the value of the standby database is "DB11G_STBY"

ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(DB11G,DB11G_STBY)

Set the appropriate remote archive log destination. In this example, I use the fast recovery area as the local location. Note that the SERVICE and DB_UNIQUE_NAME of the following parameters use the value of the standby database (STANDBY).

ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=db11g_stby NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DB11G_STBY';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

 LOG_ARCHIVE_FORMAT And the LOG_ARCHIVE_MAX_PROCESSES parameters must be set to appropriate values, and the REMOTE_LOGIN_PASSWORDFILE parameter must be set to exclusive.

ALTER SYSTEM SET LOG_ARCHIVE_FORMAT='%t_%s_%r.arc' SCOPE=SPFILE;
ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=30;
ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE SCOPE=SPFILE;

In addition to the previous settings, in order to ensure that the main and standby servers can be switched at any time. The following parameters need to be set. Adjust the *_CONVERT parameter to adapt to the difference between the file name and file path of the active and standby servers.

ALTER SYSTEM SET FAL_SERVER=DB11G_STBY;
--ALTER SYSTEM SET DB_FILE_NAME_CONVERT='DB11G_STBY','DB11G' SCOPE=SPFILE;
--ALTER SYSTEM SET LOG_FILE_NAME_CONVERT='DB11G_STBY','DB11G'  SCOPE=SPFILE;
ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;

Because some parameters take effect only after restarting the database (scope=spfile), please restart the database after changing the above parameters.

Service settings

Fill in the following information for the primary and secondary databases of the $ORACLE_HOME/network/admin/tnsnames.ora file.

DB11G =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = ol5-112-dga1)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = DB11G.WORLD)
    )
  )

DB11G_STBY =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = ol5-112-dga2)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = DB11G.WORLD)
    )
  )

Backup the main database

Perform a full backup of the main database.

$ rman target=/

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

Create backup control file and PFILE

Create a control file for the standby database on the primary database.

ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/db11g_stby.ctl';

Create a parameter file for the standby database on the primary database.

CREATE PFILE='/tmp/initDB11G_stby.ora' FROM SPFILE;

Modify the newly created parameter file /tmp/initDB11G_stby.ora so that it can be used by the standby database (the parameter value writes the relevant value of the standby database)

*.db_unique_name='DB11G_STBY'
*.fal_server='DB11G'
*.log_archive_dest_2='SERVICE=db11g ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DB11G'

Standby server installation and configuration (manual)

Copy files

Create the necessary directories on the standby server.

$ mkdir -p /u01/app/oracle/oradata/DB11G
$ mkdir -p /u01/app/oracle/fast_recovery_area/DB11G
$ mkdir -p /u01/app/oracle/admin/DB11G/adump

Copy files from the primary server to the standby server.

$ # Standby controlfile to all locations.
$ scp oracle@ol5-112-dga1:/tmp/db11g_stby.ctl /u01/app/oracle/oradata/DB11G/control01.ctl
$ cp /u01/app/oracle/oradata/DB11G/control01.ctl /u01/app/oracle/fast_recovery_area/DB11G/control02.ctl

$ # Archivelogs and backups
$ scp -r oracle@ol5-112-dga1:/u01/app/oracle/fast_recovery_area/DB11G/archivelog /u01/app/oracle/fast_recovery_area/DB11G
$ scp -r oracle@ol5-112-dga1:/u01/app/oracle/fast_recovery_area/DB11G/backupset /u01/app/oracle/fast_recovery_area/DB11G

$ # Parameter file.
$ scp oracle@ol5-112-dga1:/tmp/initDB11G_stby.ora /tmp/initDB11G_stby.ora

$ # Remote login password file.
$ scp oracle@ol5-112-dga1:$ORACLE_HOME/dbs/orapwDB11G $ORACLE_HOME/dbs

Note that the backup is copied to the standby server as part of the FRA copy. If the backups are not saved in FRA, you must make sure to copy them to the standby server and make them the same path used on the primary server.

Start listening

Make sure to start monitoring on the standby server.

$ lsnrctl start

Restore backup

Create SPFILE from the modified PFILE.

$ export ORACLE_SID=DB11G
$ sqlplus / as sysdba

SQL> CREATE SPFILE FROM PFILE='/tmp/initDB11G_stby.ora';

Restore control files and data files

$ export ORACLE_SID=DB11G
$ rman target=/

RMAN> STARTUP MOUNT;
RMAN> RESTORE DATABASE;

Create redo log

Create online redo logs for the standby server.

ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL;
ALTER DATABASE ADD LOGFILE ('/u01/app/oracle/oradata/DB11G/online_redo01.log') SIZE 50M;
ALTER DATABASE ADD LOGFILE ('/u01/app/oracle/oradata/DB11G/online_redo02.log') SIZE 50M;
ALTER DATABASE ADD LOGFILE ('/u01/app/oracle/oradata/DB11G/online_redo03.log') SIZE 50M;
ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;

In addition to online redo logs, standby redo logs should be created on the standby database and the primary database (used by the primary/standby switch). The standby redo log should be at least as large as the largest online redo log, and one more set than the online log. As shown below, it must be created on both the primary server and the standby server.

ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 10 ('/u01/app/oracle/oradata/DB11G/standby_redo01.log') SIZE 50M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 11 ('/u01/app/oracle/oradata/DB11G/standby_redo02.log') SIZE 50M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 12 ('/u01/app/oracle/oradata/DB11G/standby_redo03.log') SIZE 50M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 13 ('/u01/app/oracle/oradata/DB11G/standby_redo04.log') SIZE 50M;

After the above operations are completed, the primary database can transmit logs to the standby database.

Start log application

Start the log receiving application on the standby server.

# Foreground redo apply. Session never returns until cancel. (这个是不会停止会话)
#ALTER DATABASE RECOVER MANAGED STANDBY DATABASE; 

# Background redo apply. Control is returned to the session once the apply process is started.
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

If you need to cancel the log application.

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

If you want, you can use the following command to delay the application.

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DELAY 30 DISCONNECT FROM SESSION;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY DISCONNECT FROM SESSION;

If you have configured a standby redo log, you can use the following command to start the real-time log application.

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;

Test log transfer

On the primary server, check the latest archived redo logs and force log switching.

ALTER SESSION SET nls_date_format='DD-MON-YYYY HH24:MI:SS';

SELECT sequence#, first_time, next_time
FROM   v$archived_log
ORDER BY sequence#;

ALTER SYSTEM SWITCH LOGFILE;

Check that the new archived redo log has reached the standby server and has been applied.

ALTER SESSION SET nls_date_format='DD-MON-YYYY HH24:MI:SS';

SELECT sequence#, first_time, next_time, applied
FROM   v$archived_log
ORDER BY sequence#;

Dataguard's protection mode (Protection Mode)

The main database has three protection modes:

  • Maximum Availability: Before the redo information is written to the online redo log and the standby redo log of at least one standby location, the transaction on the primary service will not be committed. If no standby database is available, it will behave in the same manner as the maximum performance mode until the standby database is available again.
  • Maximum Performance: The transaction submitted on the primary database is executed immediately after the redo information is written into the online redo log. The transmission of redo information to the standby server is asynchronous, so it does not affect the performance of the primary server.
  • Maximum Protection: Before the redo information is written to the online redo log and the standby redo log in at least one alternate location, the transaction on the primary service is not committed. If there is no suitable alternate location, the primary database will be shut down

By default, for a newly created standby database, the primary database is in maximum performance mode.

SELECT protection_mode FROM v$database;

PROTECTION_MODE
--------------------
MAXIMUM PERFORMANCE

SQL>

You can use the following command to switch these three protection modes.

-- Maximum Availability.
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=db11g_stby AFFIRM SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DB11G_STBY';
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;

-- Maximum Performance.
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=db11g_stby NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DB11G_STBY';
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

-- Maximum Protection.
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=db11g_stby AFFIRM SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DB11G_STBY';
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
ALTER DATABASE OPEN;

Switchover between the primary and standby databases (switchover)

You can use the following statement to perform the role switching of the primary and standby databases, and no data will be lost during the entire switching process.

The primary database executes the following command to switch to the standby database

-- Convert primary database to standby
CONNECT / AS SYSDBA
ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY;

-- Shutdown primary database
SHUTDOWN IMMEDIATE;

-- Mount old primary database as standby database
STARTUP NOMOUNT;
ALTER DATABASE MOUNT STANDBY DATABASE;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

The standby server executes the following command to switch to the primary database

-- Convert standby database to primary
CONNECT / AS SYSDBA
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

-- Shutdown standby database
SHUTDOWN IMMEDIATE;

-- Open old standby database as primary
STARTUP;

After this is done, test the log transfer. If everything is normal, switch the primary database back to the original server through another switch.

Failover

If the primary database is not available, you can use the following statement to activate the standby database as the primary database.

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
ALTER DATABASE ACTIVATE STANDBY DATABASE;

Because the standby database is now the primary database, a full backup should be done immediately

Flashback Database

 Although switchover is safe for both the primary and standby databases, failover prevents the original primary database from being converted to a standby database. If Flashback Database is not enabled, you must discard the original primary database and recreate it as a standby database.

Another method is to enable flashback database on the primary database (if necessary, you can also enable the standby database), so that in the event of a failover, the primary database can flash back to the time before the failover, and quickly converted to a standby database.

For details, please refer to the official release document: https://docs.oracle.com/cd/E11882_01/server.112/e41134/scenarios.htm#SBYDB00910

 

Read-only standby database and (ADG) Active Data Guard

 When opened in read-only mode, archive log shipping will continue, but the application of the log in the standby database will stop, so the standby database will become more and more obsolete until log recovery is turned on.

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE OPEN READ ONLY;

To restore the log application, please execute

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

In 11g, Oracle introduced the Active Data Guard feature. This allows the standby database to be opened in read-only mode, but still apply redo information. This means that alternate service queries can be used, but they are still up to date. This feature requires the purchase of a license to use, the following command shows how to enable ADG.

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE OPEN READ ONLY;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

 

Guess you like

Origin blog.csdn.net/VoiceRoom/article/details/106803914