Data Guard组件等相关介绍

来源：互联网发布：eviews导入数据教程编辑：程序博客网时间：2024/06/08 12:39

1、Data Guard组件介绍

Data Guard架构归类为3个主要的组件。

Data Guard 重做传输服务 重做传输服务用来将主数据库生成的重做数据传输给备用数据库。
Data Guard 应用服务 应用服务接受和应用由重做传输服务发给备用数据库的重做数据。
Data Guard 角色管理服务 角色管理服务在切换和故障转移场景中协助更改数据库角色。

如下图配置中都存在这些服务。

2、Data Guard 进程介绍

传输服务和应用服务结合使用，以同步主数据库与其备用数据库。几个Oracle 后台进程在物理备用Data Guard框架中扮演了重要角色。

主数据库上的几个重要的进程：

LGWR ：日志写入进场将SGA中的日志缓冲区转存到ORL文件。
LNS ：日志写入网络服务（Log Writer Network Service，LNS）从重做缓冲区读取重做（LGWR则将这些信息转储到ORL），然后将重做数据经由网络传给备用站点。LNS进程的主要目的是使LGWR进程不必再担当重做传输角色。
ARCH ：归档进程将ORL文件归档到归档日志文件。ARCH进程多达30个之多，这些ARCH进程也用来满足间隔处理请求。注意，一个ARCH进程担当特殊角色，专用于本地重做日志归档，从来不与备用数据库通信。

以下为主数据库中一段alert日志，完整的记录了三个进程的运转过程：

Fri Jun 28 13:09:43 2013    Thread 1 advanced to log sequence 146 (LGWR switch)    Current log# 1 seq# 146 mem# 0: +DATA/bdspoc/onlinelog/redo_group0101.dbf   Fri Jun 28 13:09:44 2013    LNS: Standby redo logfile selected for thread 1 sequence 146 for destination LOG_ARCHIVE_DEST_2   Fri Jun 28 13:09:46 2013    Archived Log entry 445 added for thread 1 sequence 145 ID 0xaed5d29c dest 1:

备用数据库上的几个重要的进程：

RFS ：RFS（远程文件服务器）进程的主要目标是接受主站点从网络传来的重做数据，然后将网络缓冲区（重做数据）写入备用重做日志（SRL）文件。
ARCH ：备用站点上的归档进程与主站点上的归档进程作用相同，只不过在备用站点上，ARCH进程从SRL文件生成归档日志文件。
MRP : 托管恢复进程协调管理介质恢复。物理备用始终处于恢复模式。
LSP : 逻辑备用进程协调SQL Apply。该进程仅运行于逻辑备份配置中。
PROx ：此恢复服务器进程从SRL(在实时应用时）或归档日志文件读取重做数据，然后将其应用于备用数据库。

以下为备用数据库中一段alert日志，记录这几个重要的进程：

RFS[36]: Selected log 12 for thread 2 sequence 117 dbid -1361714017 branch 816281825
Media Recovery Waiting for thread 2 sequence 117 (in transit)
Recovery of Online Redo Log: Thread 2 Group 12 Seq 117 Reading mem 0
Mem# 0: /u01/app/oracle/oradata/bdspoc/group_12.dbf
Fri Jun 28 07:04:30 2013
Archived Log entry 80 added for thread 2 sequence 116 ID 0xaed5d29c dest 1:
Fri Jun 28 08:45:24 2013

从主备库上查看相关服务：

备库：

SQL> select client_process,process,sequence#,status from v$managed_standby;

CLIENT_P PROCESS    SEQUENCE# STATUS
-------- --------- ---------- ------------
ARCH ARCH    128 CLOSING
ARCH ARCH    171 CLOSING
ARCH ARCH    174 CLOSING
ARCH ARCH      0 CONNECTED
ARCH ARCH    172 CLOSING
ARCH ARCH    127 CLOSING
ARCH ARCH    126 CLOSING
ARCH ARCH    175 CLOSING
LGWR RFS    176 IDLE
N/A MRP0    129 APPLYING_LOG
UNKNOWN RFS      0 IDLE

CLIENT_P PROCESS    SEQUENCE# STATUS
-------- --------- ---------- ------------
UNKNOWN RFS      0 IDLE
UNKNOWN RFS      0 IDLE
ARCH RFS      0 IDLE
UNKNOWN RFS      0 IDLE
ARCH RFS      0 IDLE
UNKNOWN RFS      0 IDLE
LGWR RFS    129 IDLE
UNKNOWN RFS      0 IDLE

19 rows selected.

主库节点1：

SQL> select client_process,process,sequence#,status from v$managed_standby;

CLIENT_P PROCESS    SEQUENCE# STATUS
-------- --------- ---------- ------------
ARCH ARCH    171 CLOSING
ARCH ARCH    172 CLOSING
ARCH ARCH      0 CONNECTED
ARCH ARCH    173 CLOSING
ARCH ARCH    167 CLOSING
ARCH ARCH    175 CLOSING
ARCH ARCH    169 CLOSING
ARCH ARCH    170 CLOSING
LNS    LNS    176 WRITING

主库节点2：

SQL> select client_process,process,sequence#,status from v$managed_standby;

CLIENT_P PROCESS    SEQUENCE# STATUS
-------- --------- ---------- ------------
ARCH ARCH    124 CLOSING
ARCH ARCH    125 CLOSING
ARCH ARCH    126 CLOSING
ARCH ARCH      0 CONNECTED
ARCH ARCH    120 CLOSING
ARCH ARCH    127 CLOSING
ARCH ARCH    128 CLOSING
ARCH ARCH    123 CLOSING
LNS    LNS    129 WRITING

9 rows selected.

可以看到备库LGWR正在等待主库线程1和2 的归档序列号为176和129.从主库可以看到LNS进程服务正在对176和129的归档日志进行写入状态，当然亦可以从V$LOG中查看日志归档的状况。

该方法将可以再重做间隔的时候查看间隔处理情况。

3、 SRL(standby redo log）文件介绍

引入SRL文件是为了解决以下两个主要问题：

数据保护： 如果没有使用SRL文件，而且与主数据库的连接中断，将无法保护留传入的重做数据---例如，如果主数据库出现故障，然后进行故障转移，那么连接中断时正在发送的数据就会丢失。如果将重做数据写入SRL，故障转移时已经永久保存了重做数据并可供使用。
性能目标：当LNS(或Oracle Database 10gR1 之后的ARCH进程）连接到备用数据库时，仅当在备用数据库上的RFS进程创建和初始化了归档日志，LNS/ARCH才能开始发送重做数据。如果日志文件很大（比当今典型的重做日志问价大小500MB或1GB),这会导致暂停时间过长。该时间在日志切换时发生，因而对主数据库的吞吐量影响很大，但在Oracle Database 10gR2和11g中，在ASYNC模式下的LNS不阻止LGWR日志切换，但可能影响备用数据库在日志切换后的落后幅度。

事实证明，随着配置SRL，实时应用（Real-Time Apply，RTA）成为一项与生俱来的优势。

SRL文件与ORL文件基本相同，但SLR文件的逻辑差别是包含仅在备用站点上活动的当前重做数据。虽然主数据库也定义了SRL文件，但他们在主数据库上不活动，而当管理角色更改时启用。需要SRL配置为与ORL文件大小相等，否则无法使用SRL。此外，建议在备用站点上为每个实例配置N+1个SRL文件，这里的N是主站点上的每个线程的重做日志总数。

通过查看备库的alert日志了解：

主库：

SQL> select group#,thread#,SEQUENCE#,ARCHIVED,STATUS FROM V$LOG;

GROUP# THREAD# SEQUENCE# ARCHIVED STATUS

---------- ---------- ---------- -------- ----------------

1 1 519 NO CURRENT

2 1 517 YES INACTIVE

3 1 518 YES INACTIVE

4 2 413 YES INACTIVE

5 2 414 NO CURRENT

6 2 412 YES INACTIVE

备库alert日志：

SQL> select group#,dbid,thread#,sequence#,archived from v$standby_log;

GROUP# DBID THREAD# SEQUENCE# ARC

---------- ---------------------------------------- ---------- ---------- ---

7 UNASSIGNED 1 0 NO

8 2933253279 1 519 YES

9 UNASSIGNED 1 0 YES

10 UNASSIGNED 1 0 YES

11 UNASSIGNED 2 0 NO

12 2933253279 2 414 YES

13 UNASSIGNED 2 0 YES

14 UNASSIGNED 2 0 YES

8 rows selected.

选择SRL 8 来实时恢复节点1来的redo data：

RFS[3]: Selected log 8 for thread 1 sequence 519 dbid -1361714017 branch 816281825

Fri Jul 12 09:44:29 2013

Media Recovery Waiting for thread 1 sequence 519 (in transit)

Recovery of Online Redo Log: Thread 1 Group 8 Seq 519 Reading mem 0

Mem# 0: /u01/app/oracle/oradata/bdspoc/group_8.dbf

选择SRL 12 来实时恢复节点2来的redo data：

RFS[6]: Selected log 12 for thread 2 sequence 414 dbid -1361714017 branch 816281825

Fri Jul 12 09:36:58 2013

Media Recovery Waiting for thread 2 sequence 414 (in transit)

Recovery of Online Redo Log: Thread 2 Group 12 Seq 414 Reading mem 0

Mem# 0: /u01/app/oracle/oradata/bdspoc/group_12.dbf