Data Guard ----理论详解(二)

1.Data Guard

第一章详细部分阅读–传送门

2 DG Services 详解 – Redo Transport Services

2.1 Redo Transport Services

Redo transport services 在不同Oracle 数据库之间自动传送

redo data

。注意这里强调的是redo data不是redo log。
Redo transport services 可以将Redo data传送到如下位置：

Oracle Data Guard standby databases
Archive Log repository –Archive log 仓库
Oracle Streams downstream capture databases（废弃）

Synchronous —同步传送
同步日志传送模式会与事务提交保持一致。只有当所有的日志都被成功的传送到了目标后，本地的事务才能commit。

Asynchronous — 异步传送
异步传送日志采用异步的传送事务信息。主库的事务可以提交，不用等待日志同时成功写入目标库。而是采用异步的方式来传送归档。这种方式灵活性就增加很多。
🔔异步传送在Maximum Performance模式下使用。

2.2 配置 Redo Transport Services

2.2.1 Redo Transport 的安全性

Redo transport 使用Oracle Net sessions来传送redo data。这些redo 传送session 使用Secure Socket Layer (

SSL

) 协议或者远程密码文件来进行验证。

2.2.1.1 使用SSL 认证Redo Transport

SSL 是一个产业标准的网络连接协议。 SSL 使用RSA 公用密码或者对称密码来提供验证，加密和数据完整性功能。
当Oracle Net能够匹配到LOG_ARCHIVE_DEST_n 和FAL_SERVER 初始化参数的值，那么就会使用SSL。

2.2.1.2 使用口令文件认证Redo Transport

Oracle的口令文件的作用是存放所有以sysdba或者sysoper权限连接数据库的用户的口令。

2.2.2 配置数据库发送Redo Data

初始化参数LOG_ARCHIVE_DEST_n用来指定redo log的存放位置，可以存放在本地，也可以指定redo transport的位置。在oracle 11g中，该参数的n的值从1到31.
有另外一个初始化参数：LOG_ARCHIVE_DEST_STATE_n ，其与LOG_ARCHIVE_DEST_n 参数相对应。

DB_UNIQUE_NAME=BOSTON 
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_CONFIG='DG_CONFIG=(BOSTON,CHICAGO,HARTFORD)'
LOG_ARCHIVE_DEST_2='SERVICE=CHICAGO ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) REOPEN=60 COMPRESSION=ENABLE DB_UNIQUE_NAME=CHICAGO'
LOG_ARCHIVE_DEST_STATE_2='ENABLE'
LOG_ARCHIVE_DEST_3='SERVICE=HARTFORD SYNC AFFIRM NET_TIMEOUT=30 VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) REOPEN=60 COMPRESSION=ENABLE DB_UNIQUE_NAME=HARTFORD'
LOG_ARCHIVE_DEST_STATE_3='ENABLE'

SERVICE: 这个是一个强制的属性，而且也必须是第一个属性值。SERVICE 指定Oracle Net Service Name。就是tnsnames.ora 里面配置的名称。
SYNC: 该属性用来指定使用同步redo transport mode来传送redo data 到destination。
ASYNC: 该属性来用指定使用异步的方式来传送redo data。在没有指定SYNC 或ASYNC的情况下，默认使用ASYNC.
NET_TIMEOUT：该属性控制LGWR进程在中断网络连接之前等待网络服务进程状态的时间长短。如果在NET_TIMEOUT参数设置的值内还没有响应，LGWR进程就会返回错误信息。在SYNC的模式下，Oracle 建议设置该值，这样就可以控制redo 同步的最大持续时间，减少对事务的影响。
AFFIRM：确保备库从主库接受到的redo log由LGWR进程完全写入磁盘之后进行提交，
NOFFIRM：在主库的日志写进程不等所有磁盘IO完成。缺省的是NOFFIRM
DB_UNIQUE_NAME：该属性用来指定redo transport destination。如果LOG_ARCHIVE_CONFIG 参数和DG_CONFIG属性已经配置，那么该属性必须指定，并且该值也必须匹配DG_CONFIG中的一个值。如果匹配失败，就不会传送日志。
VALID_FOR: 该属性用来控制日志传输的，即角色转换方面。VALID_FOR允许同时为主备库数据库角色配置目的地属性，使DG切换后能正常工作。简化切换和故障转移。默认valid_for＝(all_logfiles,all_roles) 格式：VALID_FOR=(redo_log_type,database_role) redo_log_type包括：online_logfile、standby_logfile、all_logfiles database_role包括：primary_role、standby_role、all_roles
REOPEN：该属性来用指定在之前ARCn 进程或LGWR 进程在错误过后多少秒之后重新连接并传送日志。
COMPRESSION：该属性指定是否已压缩的形式传送日志。压缩传送可以提高性能，降低对带宽的影响。

2.2.3配置数据库接收Redo Data

2.2.3.1 创建和管理Standby Redo Log

同步传送和异步传送REDO 都需要standby redo log，用来存储从其他database 接受来的redo data。通过redo transport 传送到Standby database 的redo数据由RFS 的前台进程写入到当前的standby redo log group。

当primay database 发生日志切换时，对应的redo 数据写入到standby的下一组standby redo log group，然后standby 的ARCn 进程对standby redo log group 进行归档操作RFS（Remote File Server ）和ARCn。RFS 进程是专门用来接受并将日志写入standby的current standby redo log的。

每个standby redo log file 至少要和primary database的redo log 一样大，为了方便管理，Oracle 建议主备库的redo log 设置成一样的大小。
Standby redo log group 至少要比primary database的redo log group 多一组

在primary 库执行如下SQL，确定每个redo log file的大小和每个log groups的成员数量：

SQL>SELECTGROUP#,BYTES/1024/1024 MB FROM V$LOG;

–在standby 库执行执行如下SQL 查询每个standby redo log 大小和每组的成员：

SQL>SELECTGROUP#,BYTES/1024/1024 MB FROM V$STANDBY_LOG;

2.2.3.2 Standby Redo Log 的归档配置

启用归档

SQL>SHUTDOWN IMMEDIATE;SQL> STARTUP MOUNT;SQL>ALTERDATABASE ARCHIVELOG;

📢DG 环境下的主库必须是归档的

设置Standby Redo Log 归档

设置LOG_ARCHIVE_DEST_n 参数的LOCATION 属性
设置LOG_ARCHIVE_DEST_n 参数的VALID_FOR 属性允许进行归档。

LOG_ARCHIVE_DEST_1=‘LOCATION=/u01/app/oracle/arch VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=orcl’
LOG_ARCHIVE_DEST_2=‘SERVICE=orcls LGWR ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcls’

❓为什么LOG_ARCHIVE_DEST_1和LOG_ARCHIVE_DEST_2的VALID_FOR设置不一样呢
❓Standby Redo Log到底是通过dest_1还是dest_2来归档的呢
👉撮这里

2.2.3.3 Redo 直接写入归档文件

如果我们的standby redo log不可用，或者我们接收的redo 是为了解决redo gap的时候，那么这时候我们接收的redo data就会直接写入archived redo log。
具体写归档文件的位置就是LOG_ARCHIVE_DEST_n参数的LOCATION属性指定的。

2.3 Cascaded Redo Transport Destinations (级联Redo 传送)

比如有1个主库A，2个备库：B，C。
那么日志传送A—>B—>C。这个就是Cascaded Redo Transport。
Cascading 有如下2个限制：

只有物理standby database 才可以做cascading standby。
Data Guard broker不支持cascaded destinations。

2.3.1 配置 Cascaded Destination

配置cascaded destination的步骤如下：

选择一个physical standby database 做为cascading standby database
在cascading standby database设置FAL_SERVER 参数为primary database或者其他直接从primary database接收redo的standby database
在cascading standby database设置LOG_ARCHIVE_DEST_n 参数指定cascaded destination，并指定其他有效参数
在cascaded destination database 设置FAL_SERVER参数为cascading standby database或者其他直接从primary database接收redo的standby database。

– Primary Database：

DB_UNIQUE_NAME=boston
FAL_SERVER=boston2
LOG_ARCHIVE_CONFIG='DG_CONFIG=(boston,boston2,denver)'
LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2='SERVICE=boston2 SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston2'

–Cascading Physical Standby Database：

DB_UNIQUE_NAME=boston2
FAL_SERVER=boston
LOG_ARCHIVE_CONFIG='DG_CONFIG=(boston,boston2,denver)'
LOG_ARCHIVE_DEST_1='LOCATION= USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston2'
LOG_ARCHIVE_DEST_2='SERVICE=denver VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=denver'

–Cascaded Physical Standby Database：

DB_UNIQUE_NAME=denver
FAL_SERVER=boston2
LOG_ARCHIVE_CONFIG='DG_CONFIG=(boston,boston2,denver)'
LOG_ARCHIVE_DEST_1='LOCATION= USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=denver'

2.4 监控 Redo Transport Services

2.4.1 监控Redo Transport Status

检查最近的归档日志文件：

SQL>SELECTMAX(SEQUENCE#), THREAD# FROM V$ARCHIVED_LOG GROUP BY THREAD#;

检查传输目的地路径及最近的归档情况：

SELECT DESTINATION,STATUS,ARCHIVED_THREAD#,ARCHIVED_SEQ# FROM V$ARCHIVE_DEST_STATUS WHERE STATUS <> 'DEFERRED' AND STATUS <> 'INACTIVE';
DESTINATION         STATUS  ARCHIVED_THREAD#  ARCHIVED_SEQ#------------------  ------  ----------------  -------------/private1/prmy/lad   VALID                 1947
standby1             VALID                 1947

检查归档目的地已经接收到的归档日志情况：

SELECTLOCAL.THREAD#, LOCAL.SEQUENCE#FROM(SELECT THREAD#, SEQUENCE#FROM V$ARCHIVED_LOG
         WHERE DEST_ID =1)LOCALWHERELOCAL.SEQUENCE# NOT IN(SELECT SEQUENCE#FROM V$ARCHIVED_LOG
            WHERE DEST_ID =2AND THREAD# = LOCAL.THREAD#);#DEST_ID=2要根据自己的配置改

2.4.2 监控同步传送Redo Transport的响应时间

V$REDO_DEST_RESP_HISTOGRAM

视图包含了每个redo transport destination的response time。
Response time 数据对同步传送数据实时传输时有帮助。也可以用来做NET_TIMEOUT的值调整时的参考。
V$REDO_DEST_RESP_HISTOGRAM 视图有4列：FREQUENCY, DURATION, DEST_ID, 和 TIME.

FREQUENCY：A non-negative integer that shows the number of times a particular bucket was hit by the SYNC LNS process
DEST_ID：A non-negative integer value from 1 - 10 for each possible LGWR SYNC standby destination
The TIME：A text string that shows the last wall-clock time that a bucket was hit
DURATION：A positive integer value that represents a bucket of seconds, 1, 2, 3, up to 300 seconds, followed by 5 additional buckets that represent 600, 1200, 2400, 4800, and 9600 ( >= 4801) seconds

每个destination 都会包含一系列的记录。每个记录都会有response time。为了便于记录，当response time 会计算到实际值，如果超过300秒，就会用最接近600，1200，2400，4800，9600的值来代替。

–在主库查询destination=2 的response time 信息：

SQL>SELECT FREQUENCY, DURATION FROM V$REDO_DEST_RESP_HISTOGRAM WHERE DEST_ID=2AND FREQUENCY>1;

–在主库查询destionation=2 最慢的响应时间：

SQL>SELECTmax(DURATION)FROM V\$REDO_DEST_RESP_HISTOGRAM WHERE DEST_ID=2AND FREQUENCY>1;

–在主库查询destionation=2最快的响应时间：

SQL>SELECTmin( DURATION)FROM V$REDO_DEST_RESP_HISTOGRAM WHERE DEST_ID=2AND FREQUENCY>1;

2.4.3 手工解决 Gap 问题

2.4.3.1 解决物理standby Gap问题

在物理standby 库上执行如下SQL，判断是否存在gap：

SQL>SELECT*FROM V$ARCHIVE_GAP;

把这些归档copy到物理standby，并使用ALTER DATABASE REGISTER LOGFILE应用这些归档：

SQL>ALTERDATABASE REGISTER LOGFILE '/physical_standby1/thread1_dest/arcr_1_7.arc';```

重新手工注册归档的语法

#注册归档目录
rman> catalog startwith'/oracle/oraarch';#注册单个归档SQL>alterdatabase register logfile  ‘/oraarch/archivelog_1_101.arc’;

2.4.3.2 解决逻辑standby Gap问题

对于logical standby database，在logical standby database上查询DBA_LOGSTDBY_LOG视图。

SQL>SELECT THREAD#, SEQUENCE#, FILE_NAME FROM DBA_LOGSTDBY_LOG L WHERE NEXT_CHANGE# NOT IN (SELECT FIRST_CHANGE# FROM DBA_LOGSTDBY_LOG WHERE L.THREAD# = THREAD#) ORDER BY THREAD#, SEQUENCE#;

后续处理同物理standby

2.5 Redo Data 传送

2.5.1 使用 Archiver (ARCn) 进程传送归档文件

默认情况下，Redo transport Service 使用ARCn 进程来归档online redo log。
📢注意一点，ARCn 进程的归档只支持DG的maximum performance 模式。如果是最大保护和最高可用，就必须只用LGWR 进程来传送redo data 到standby 数据库。

2.5.1.1 控制ARCn的初始化参数

有2个初始化参数控制ARCn 进程的行为：LOG_ARCHIVE_DEST_n和LOG_ARCHIVE_MAX_PROCESSES。

启用ARCn 进程将日志归档到本地或者远程库
这个参数我们前面看过，就是LOG_ARCHIVE_DEST_n，它控制redo data的自动传送。默认情况下就是使用ARCn 进程来发送redo data。所以我们在LOG_ARCHIVE_DEST_n 参数中可以不用指定ARCH属性。但必须指定SERVICE 属性。

指定ARCn 进程的数量
LOG_ARCHIVE_MAX_PROCESSES 初始化参数指定

ARCn

进程的最大数量。该参数默认值是4. 即当我们primary instance 启动时，会创建4个ARCn 进程。然后根据4个进程的负载情况，动态的分配4个进程的工作。
LOG_ARCHIVE_MAX_PROCESSES 的最大值是30个。

ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES =8;

2.5.1.2 ARCn 进程处理归档的过程

在primary 数据库，当ARC0 进程完成online redo 的本地归档（LOG_ARCHIVE_DEST_1）动作之后， ARC1 进程就会把本地的归档文件传送到remote standby destination（LOG_ARCHIVE_DEST_2）。
在standby 数据库，RFS(remote file server) 会接收这些归档文件，并将接收的redo data写入standby redo log file。最后在从standby redo log file归档到standby 的归档文件中。 Standby 的apply service 使用Redo Apply（MRP）或者SQL apply（LSP）从standby 的归档文件中应用数据，实现同步。

2.5.2 使用 Log Writer (LGWR) 进程传送 Redo Data

LGWR 的LOG_ARCHIVE_DEST_n 属性

SYNC 属性会保证所有的数据都会同步，即每次写操作都会要求主备库同时完成。
ASYNC 属性会执行异步的的同步，先写本地的online redo log ，在由LNS进程从online redo log传送redo data，因此可以立即返回给用户状态，而不需要等待备库的操作也完成。

使用LGWR SYNC 同步的示例

LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago'
LOG_ARCHIVE_DEST_2='SERVICE=boston LGWR SYNC NET_TIMEOUT=30'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE

LOG_ARCHIVE_DEST_n参数的

SYNC

属性是可选的。因为LGWR 传送默认就是使用SYNC的方式，所以建议设置NET_TIMEOUT属性。从而控制LGWR 等待redo data写入standby的时间，如果在NET_TIMEOUT时间内没有反应，LGWR就会返回错误。

主库，LGWR 进程提交redo data 到一个或者多个LNSn 进程，然后初始这些进程并行的发送redo data到远程数据。主库的事务不会提交，直到所有的redo data 发送到所有的LGWR SYNC的目的地。从这点看，很依赖与网络。
备库，RFS接收LGWR发送过来的数据，然后写入standby redo log files。

LGWR ASYNC 传送

使用LGWR ASYNC 同步的示例：

LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago'
LOG_ARCHIVE_DEST_2='SERVICE=boston LGWR ASYNC'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE

今天的文章就先到这里，后面继续更新Data Guard–理论详解（三）

标签： dba oracle database

本文转载自: https://blog.csdn.net/easonhyj/article/details/122823555
版权归原作者 eason_hyj 所有，如有侵权，请联系我们删除。