在Data Guard环境中，Standby Redo Log是一个比较特殊的日志类型。从最新的DG安装指导中，都推荐在Primary和Standby端，都配置Standby Redo Log。
简单的说，Standby Redo Log就是在Standby端应用传递Redo Log过程中，逐步执行的online redo log。Standby端虽然也有online redo log，但是在redo apply应用的过程中，是不使用online redo log的。即使是11g Active Data Guard支持apply中读取standby数据，这个操作也是read-only的，并不涉及当前实例redo log的生成（注意是生成）。所以，如果一直是在Standby角色，online redo log是不需要的。
Primary传递过来的redo log信息，是存放在standby redo log组内进行apply的。并且随着主库Primary日志的切换动作而切换。这也就是为什么推荐standby redo log的大小和Primary online redo log的大小保持一致的原因。
下面会从维护角度，讨论Standby Redo log维护过程中的方法。
--------------------------------------分割线 --------------------------------------
相关参考:
Oracle Data Guard 重要配置参数 http://www.linuxidc.com/Linux/2013-08/88784.htm
基于同一主机配置 Oracle 11g Data Guard http://www.linuxidc.com/Linux/2013-08/88848.htm
探索Oracle之11g DataGuard http://www.linuxidc.com/Linux/2013-08/88692.htm
Oracle Data Guard （RAC+DG) 归档删除策略及脚本 http://www.linuxidc.com/Linux/2013-07/87782.htm
Oracle Data Guard 的角色转换 http://www.linuxidc.com/Linux/2013-06/86190.htm
Oracle Data Guard的日志FAL gap问题 http://www.linuxidc.com/Linux/2013-04/82561.htm
Oracle 11g Data Guard Error 16143 Heartbeat failed to connect to standby 处理方法 http://www.linuxidc.com/Linux/2013-03/82009.htm
--------------------------------------分割线 --------------------------------------
1、环境介绍
数据库版本为11.2.0.4，已经构建好DG环境。Primary数据库实例名ora11g。
SQL> select name, DATABASE_ROLE from v$database;
NAME DATABASE_ROLE
--------- ----------------
ORA11G PRIMARY
Primary上也是需要配置standby redo log的。但是，这个redo log和Standby端的online redo log一样，都是在角色switch/failover之后，才会发挥作用。
SQL> col dbid for a20;
SQL> select group#, dbid, sequence#, archived, status from v$standby_log;
GROUP# DBID SEQUENCE# ARCHIVED STATUS
---------- -------------------- ---------- -------- ----------
4 UNASSIGNED 0 YES UNASSIGNED
5 UNASSIGNED 0 YES UNASSIGNED
6 UNASSIGNED 0 YES UNASSIGNED
文件自动管理参数设置为Auto。
SQL> show parameter standby_file
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string AUTO
2、Primary端Standby Redo Log配置
Primary角色下，Standby Redo Log是不使用的。原则上也没有什么特殊的用途。所以，我们查看v$standby_log视图时查看到的Primary端状态都是unsigned，也就是没有使用。
在Primary正常Read Write状态下，我们是可以添加standby log group的。
SQL> alter database add standby logfile group 8 size 100m;
Database altered
SQL> select group#, dbid, sequence#, archived, status from v$standby_log;
GROUP# DBID SEQUENCE# ARCHIVED STATUS
---------- -------------------- ---------- -------- ----------
4 UNASSIGNED 0 YES UNASSIGNED
5 UNASSIGNED 0 YES UNASSIGNED
6 UNASSIGNED 0 YES UNASSIGNED
8 UNASSIGNED 0 YES UNASSIGNED
在v$logfile中，可以看到对应的添加文件。由于使用的OMF特性，创建成员组为两个，在recovery area中有对应镜像。
SQL> select group#, type, member from v$logfile;
GROUP# TYPE MEMBER
---------- ------- --------------------------------------------------------------------------------
（篇幅原因，有省略……）
7 ONLINE /u01/app/fast_recovery_area/ORA11G/onlinelog/o1_mf_7_9pclt1lt_.log
8 STANDBY /u01/app/oradata/ORA11G/onlinelog/o1_mf_8_9pgqt9hg_.log
8 STANDBY /u01/app/fast_recovery_area/ORA11G/onlinelog/o1_mf_8_9pgqtcgj_.log
16 rows selected
在standby端，我们查看是否有对应standby redo log自动添加。
SQL> select group#, sequence#, dbid,status from v$standby_log;
GROUP# SEQUENCE# DBID STATUS
---------- ---------- -------------------- ----------
4 34 4239941846 ACTIVE
5 0 UNASSIGNED UNASSIGNED
6 0 UNASSIGNED UNASSIGNED
Primary端删除standby redo log。
SQL> alter database drop standby logfile group 8;
Database altered
SQL> select group#, dbid, sequence#, archived, status from v$standby_log;
GROUP# DBID SEQUENCE# ARCHIVED STATUS
---------- -------------------- ---------- -------- ----------
4 UNASSIGNED 0 YES UNASSIGNED
5 UNASSIGNED 0 YES UNASSIGNED
6 UNASSIGNED 0 YES UNASSIGNED
从实验情况看：在Primary端，我们进行standby redo log的管理是比较方便的。没有过多的限制。
3、Standby端Standby Redo Log维护
当前Primary端的Online Redo Log情况。
SQL> select group#, sequence#, bytes, status from v$log;
GROUP# SEQUENCE# BYTES STATUS
---------- ---------- ---------- ----------------
1 32 104857600 INACTIVE
2 34 52428800 INACTIVE
3 35 52428800 CURRENT
7 33 10485760 INACTIVE
此时，standby端的standby redo log情况如下：
SQL> select group#, sequence#, dbid,status from v$standby_log;
GROUP# SEQUENCE# DBID STATUS
---------- ---------- -------------------- ----------
4 35 4239941846 ACTIVE
5 0 UNASSIGNED UNASSIGNED
6 0 UNASSIGNED UNASSIGNED
standby redo log对应的是当前Primary的online current redo log。反映在sequence#相同。我们尝试直接添加standby日志。
SQL> alter database add standby logfile group 8 size 100m;
alter database add standby logfile group 8 size 100m
ORA-01156: 进行中的恢复或闪回可能需要访问文件
当前standby处在apply过程，终止apply动作。
SQL> alter database recover managed standby database cancel;
Database altered
SQL> alter database add standby logfile group 8 size 100m;
Database altered
standby redo log日志情况。
SQL> select group#, dbid, sequence#, archived, status from v$standby_log;
GROUP# DBID SEQUENCE# ARCHIVED STATUS
---------- -------------------- ---------- -------- ----------
4 4239941846 35 YES ACTIVE
5 UNASSIGNED 0 NO UNASSIGNED
6 UNASSIGNED 0 NO UNASSIGNED
8 UNASSIGNED 0 YES UNASSIGNED
之后可以启动redo apply过程。
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered
删除redo log的方法也比较简单，都是首先终止redo apply过程，之后删除。
SQL> alter database recover managed standby database cancel;
Database altered
SQL> alter database drop standby logfile group 8;
Database altered
SQL> select group#, dbid, sequence#, archived, status from v$standby_log;
GROUP# DBID SEQUENCE# ARCHIVED STATUS
---------- -------------------- ---------- -------- ----------
4 4239941846 35 YES ACTIVE
5 UNASSIGNED 0 NO UNASSIGNED
6 UNASSIGNED 0 NO UNASSIGNED
注意：这里面我们处理的是非active状态日志。如果是active状态，可能就需要与online redo log的策略相同，进行重建过程。
4、standby redo log usage实验
这里考虑一个问题。在primary和standby工作过程中，redo log entry从Primary的online redo log中传递，传递到standby端的standby redo log等待进行redo apply。
如果apply之后，redo log就进入归档状态了。那么，如果当前日志积压很多，甚至primary端多次进行切换。那么这些日志在哪儿呢？我们通过实验去证明。
在primary端，当前日志编号为38。
（primary）
SQL> select group#, sequence#, archived, status from v$log;
GROUP# SEQUENCE# ARCHIVED STATUS
---------- ---------- -------- ----------------
1 36 YES INACTIVE
2 38 NO CURRENT
3 35 YES INACTIVE
7 37 YES INACTIVE
前一个sequence#的编号日志已经传递到standby端。
SQL> select recid, name, sequence#, STANDBY_DEST, ARCHIVED, APPLIED from v$archived_log where sequence#=37;
RECID NAME SEQUENCE# STANDBY_DEST ARCHIVED APPLIED
---------- -------------------------------------------------------------------------------- ---------- ------------ -------- ---------
53 /u01/app/fast_recovery_area/ORA11G/archivelog/2014_05_06/o1_mf_1_37_9pjrr6jg_.ar 37 NO YES NO
54 ora11gsy 37 YES YES NO
注意：57号记录apply状态为NO。standby端，standby redo log的current为38，与Primary相匹配。
SQL> col dbid for a20;
SQL> select group#, dbid, sequence#, archived, status from v$standby_log;
GROUP# DBID SEQUENCE# ARCHIVED STATUS
---------- -------------------- ---------- -------- ----------
4 4239941846 38 YES ACTIVE
5 UNASSIGNED 0 NO UNASSIGNED
6 UNASSIGNED 0 NO UNASSIGNED
同样的37号日志已经在归档空间。
SQL> select recid, name, sequence#, STANDBY_DEST, ARCHIVED, APPLIED from v$archived_log where sequence#=37;
RECID NAME SEQUENCE# STANDBY_DEST ARCHIVED APPLIED
---------- -------------------------------------------------------------------------------- ---------- ------------ -------- ---------
11 /u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_05_06/o1_mf_1_37_9pjrr6y0_. 37 NO YES NO
在Primary端进行多次的switch动作。
SQL> alter system switch logfile;
System altered
（多次切换，篇幅原因，有省略……）
SQL> alter system switch logfile;
System altered
Primary日志情况如下，当前sequence为43。
SQL> select group#, sequence#, archived, status from v$log;
GROUP# SEQUENCE# ARCHIVED STATUS
---------- ---------- -------- ----------------
1 40 YES INACTIVE
2 42 YES INACTIVE
3 43 NO CURRENT
7 41 YES INACTIVE
当前为43，进入归档空间。
SQL> select recid, name, sequence#, STANDBY_DEST, ARCHIVED, APPLIED from v$archived_log where sequence#>=37;
RECID NAME SEQUENCE# STANDBY_DEST ARCHIVED APPLIED
---------- -------------------------------------------------------------------------------- ---------- ------------ -------- ---------
（篇幅原因，有省略……）
60 ora11gsy 40 YES YES NO
61 /u01/app/fast_recovery_area/ORA11G/archivelog/2014_05_06/o1_mf_1_41_9pjs7os5_.ar 41 NO YES NO
62 ora11gsy 41 YES YES NO
63 /u01/app/fast_recovery_area/ORA11G/archivelog/2014_05_06/o1_mf_1_42_9pjs7pvn_.ar 42 NO YES NO
64 ora11gsy 42 YES YES NO
12 rows selected
在standby端，standby redo log的切换到sequence#=43。
SQL> select group#, dbid, sequence#, archived, status from v$standby_log;
GROUP# DBID SEQUENCE# ARCHIVED STATUS
---------- -------------------- ---------- -------- ----------
4 4239941846 43 YES ACTIVE
5 UNASSIGNED 0 NO UNASSIGNED
6 UNASSIGNED 0 NO UNASSIGNED
没有被应用的日志，并没有积压在standby redo log中。而是进入archive空间。
SQL> select recid, name, STANDBY_DEST, ARCHIVED, APPLIED from v$archived_log where sequence#>=37;
RECID SEQUENCE# STANDBY_DEST ARCHIVED APPLIED
---------- ---------- ------------ -------- ---------
11 37 NO YES NO
12 38 NO YES NO
13 39 NO YES NO
14 40 NO YES NO
15 41 NO YES NO
16 42 NO YES NO
6 rows selected
注意，他们的apply状态都是NO。启动standby端的应用之后，查看效果。
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered
SQL> select recid, sequence#, STANDBY_DEST, ARCHIVED, APPLIED from v$archived_log where sequence#>=37;
RECID SEQUENCE# STANDBY_DEST ARCHIVED APPLIED
---------- -------------------------------------------------------------------------------- ---------- ------------ -------- ---------
11 37 NO YES YES
12 38 NO YES YES
13 39 NO YES YES
14 40 NO YES YES
15 41 NO YES YES
16 42 NO YES IN-MEMORY
6 rows selected
5、结论
对standby而言，standby redo log就是online redo log。Oracle推荐standby redo log大小要与Primary上redo log size相匹配的。
转载：本文永久更新链接地址：http://www.linuxidc.com/Linux/2014-05/101673.htm
1000
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
