ORACLE DG Topic 6-Redo Transmission Service

Preface

         The redo transfer service is used to automatically transfer redo data between DG configurations. The possible transmission destinations are:

  • DG standby database

The deployment of physical standby database and logical standby database as described above ;

  • Archive log warehouse

This destination is used to temporarily unload the storage of archive logs;

  • oracle flow capture database
  • far sync example

    All of the above transmission destinations can be individually configured to receive redo data synchronously or asynchronously. This article will describe the relevant principles and configuration of redo transmission services, supplemented by basic operation and maintenance methods;

Configure redo transfer

Security of redo transmission

The redo transmission between DG configurations is realized through the ORACLE network session. To ensure the establishment of the session, the following two methods can be used for authentication:

  1. SSL-- Secure Sockets Layer, secure socket protocol
  2. Password file

This method uses remote password login for redo data transmission , such as the synchronization of the password file when deploying the physical backup database; Oracle uses the SYS user for authentication by default, or you can specify a non-default user for authentication through the redo_transport_user parameter;

SQL> show parameter redo_transport_user

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
redo_transport_user                  string

Configure Oracle to send redo data

         The configuration of redo sending is mainly to configure the LOG_ARCHIVE_DEST_n parameter of ORACLE. 12c supports a total of 31 redo destination configurations from 1 to 31. Because one of them needs to be configured with a local archive path, it can support a maximum of 30 backup databases. This parameter has many attributes as follows:

AFFIRM and NOAFFIRM--------------指定目的是在写入standby redo log之前还是之后进行确认;
ALTERNATE -------------指定当源目的失败时的备选目的;
COMPRESSION ------指定是否进行压缩;
DB_UNIQUE_NAME -----指定目的地的unique名;
DELAY -----指定重做延时;
ENCRYPTION -----指定是否加密传输(只对Recovery Appliance可用)
LOCATION and SERVICE ----指定是否是归档至本地或通过服务传输传输至远程;
MANDATORY -----指定已填满的redo log必须先归档才能被重用;
MAX_CONNECTIONS ------配置重做传输的最大连接数,相当于多路复用,可提高传输效率;
MAX_FAILURE ------配置容忍的最大连续失败次数;
NET_TIMEOUT -----指定重做确认的超时时间;
NOREGISTER -----指定目的端无需记录归档重做日志的路径;
REOPEN -----指定一个失败的目的重新打开的最小时间s;
SYNC and ASYNC -----指定同步或异步传输
TEMPLATE --------指定归档目的文件的格式模版;
VALID_FOR --------指定重做传输配置在哪些条件下有效;

The LOG_ARCHIVE_DEST_STATE_N parameter configures whether the corresponding transmission destination is enabled or alternative, the optional values ​​are: enable, defer, alternate;

         View V$ARCHIVE_DEST to view the redo destination configuration status;

SQL> select * from V$ARCHIVE_DEST;

Configure Oracle to receive redo data

         The redo receiver needs to configure the standby redo log, and the structure of the standby redo log is the same as that of the online redo log. You can use the v$log and v$logfile views to view standby redo logs;

         Principles for creating backup redo logs:

  • Each standby redo log file must be at least as large as the largest redo log file in the redo log of the redo source database.

Each standby redo log is at least as large as the online redo log;

  • The standby redo log must have at least one more redo log group than the redo log at the redo source database, for each redo thread at the redo source database.

The number of standby redo logs is at least one more than that of online redo logs. In this way, in order to prevent the redo log of the main database from being written too quickly, the standby redo of the standby database is full and it is too late to apply.

         Create a new standby redo log:

SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 500M;

or:

SQL> alter database add standby logfile '/odata/datafile/standby_01.log' size 500m;

Verify/monitor redo configuration

         After configuring the redo service, you can check whether the relevant configuration is correct through the V$DATAGUARD_CONFIG view ;

SQL> select DEST_ID,DEST_NAME,DESTINATION,TRANSMIT_MODE,DB_UNIQUE_NAME from V$ARCHIVE_DEST where status='VALID';

         Specifically, you can view the information of each column of V$ARCHIVE_DEST ;

SQL> desc V$ARCHIVE_DEST

         Check if there is a redo gap:

SQL> SELECT * FROM V$ARCHIVE_GAP;

to sum up

         Redo transmission service is used to transmit redo data between DG configurations. This article mainly explains the basic configuration of redo sending and redo receiving. Redo sending is realized through LOG_ARCHIVE_DEST_N configuration, and redo receiving is realized by adding standby redo logs at the destination. . In-depth understanding of Oracle's redo transmission service can configure high-standard, high-reliability, and high-performance data protection solutions for specific use scenarios ;

Guess you like

Origin blog.csdn.net/zhaogang1993/article/details/101067838