Oracle Dataguard Standby Redo Log的两个实验 --博主

最新推荐文章于 2021-04-16 00:19:30 发布

hoopfor

最新推荐文章于 2021-04-16 00:19:30 发布

阅读量686

点赞数

在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维护过程中的方法。

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相匹配的。

阅读(5776) | 评论(0) | 转发(1) |

上一篇：Oracle 11g Dataguard环境下数据文件、日志文件管理（下）

下一篇：聊聊Data Guard环境下Temp表空间和Temp文件管理

hoopfor

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
复制链接

分享到 QQ

分享到新浪微博

扫一扫