下面我们讨论redo log的情况。
3、online redo log情况——Primary端
相对于data file,online redo log的情况就略有不同。我们在实际运维环境中可能进行online redo log的调整,调整的出发点常常是从性能和可用性两个出发点。注意:online redo log是当前数据库生成的操作,而且是数据库“自己”生成的。在standby端的online redo log,在redo apply过程中原则上是不会使用的。
从性能上,过小的日志和过少的日志组常常引起日志相关的性能问题。在高redo log生成的场景下,无论是dbwr还是arch,可能在日志切换覆盖过程中被多次强制启动,如果IO效率较差,可能还会引起数据库整体的等待现象。可用性方面主要体现在日志组成员上,控制文件和online redo log是Oracle中采用镜像冗余进行管理的两类文件。在相同的日志组中,我们创建多个member对象,目的是为了分散在多个存储位置(磁盘),来防止单一日志文件损坏造成的故障。
我们先在Primary上进行日志操作实验。创建一个新的日志组。
--以OMF方式创建文件
SQL> alter database add logfile group 7 size 10m;
Database altered
创建成功:
SQL> select group#, type, member from v$logfile;
GROUP# TYPE MEMBER
---------- ------- --------------------------------------------------------------------------------
3 ONLINE /u01/app/oradata/ORA11G/onlinelog/o1_mf_3_9mnjx4n0_.log
(篇幅原因,有省略……)
7 ONLINE /u01/app/oradata/ORA11G/onlinelog/o1_mf_7_9pclt1jy_.log
7 ONLINE /u01/app/fast_recovery_area/ORA11G/onlinelog/o1_mf_7_9pclt1lt_.log
14 rows selected
但是,在standby端,是不会和datafile一样创建出来的。standby端依然保持三个日志组。
SQL> select group#, sequence#, status from v$log;
GROUP# SEQUENCE# STATUS
---------- ---------- ----------------
1 25 CLEARING
2 26 CLEARING
3 27 CURRENT
注意:DG环境下,online redo log的状态和普通单实例有一些差异。由于online redo log在standby状态下是没有数据写入的。所以有current和clearing状态。
当前primary端,日志组数为4。
SQL> select group#, status from v$log;
GROUP# STATUS
---------- ----------------
1 INACTIVE
2 INACTIVE
3 CURRENT
7 UNUSED
对于非current、active的日志组,是可以删除的。这点和单实例没有区别。
SQL> alter database drop logfile group 1;
Database altered
SQL> select group#, status from v$log;
GROUP# STATUS
---------- ----------------
2 INACTIVE
3 CURRENT
7 UNUSED
重新添加回日志组1。
SQL> alter database add logfile group 1 size 100m;
Database altered
SQL> select group#, status from v$log;
GROUP# STATUS
---------- ----------------
1 UNUSED
2 INACTIVE
3 CURRENT
7 UNUSED
同样standby端是没有什么反映的。
4、online redo log——standby端
相对于Primary端而言,standby端online redo log管理相对比较复杂。具体可以划分为增加add、删除drop和同步sync三种。
注意:在standby进行redo apply的过程中,standby端对应的online redo log其实是没有用处的,也没有起到作用。进行调整的目的只在于切换成Primary之后的性能问题。
首先是添加redo log group。
确保参数standby_file_management状态,和当前日志状态。
SQL> show parameter standby_file_management
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string AUTO
SQL> select group#, sequence#, status from v$log;
GROUP# SEQUENCE# STATUS
---------- ---------- ----------------
1 25 CLEARING
2 26 CLEARING
3 27 CURRENT
直接添加是不允许的。
SQL> alter database add logfile group 7 size 10m;
alter database add logfile group 7 size 10m
ORA-01156: 进行中的恢复或闪回可能需要访问文件
首先要停止redo apply过程,解除standby_file_management参数限制。
--添加过程
SQL> alter database recover managed standby database cancel;
Database altered
SQL> alter system set standby_file_management=manual;
System altered
之后再进行添加,就可以成功。但是注意将参数置回。
SQL> alter database add logfile group 7 size 10m;
Database altered
SQL> alter system set standby_file_management=auto;
System altered
SQL> select group#, sequence#, status from v$log;
GROUP# SEQUENCE# STATUS
---------- ---------- ----------------
1 25 CLEARING
2 26 CLEARING
3 27 CURRENT
7 0 UNUSED
确认文件创建。
SQL> select group#, type, member from v$logfile;
GROUP# TYPE MEMBER
---------- ------- --------------------------------------------------------------------------------
(篇幅原因,有省略……)
6 STANDBY /u01/app/fast_recovery_area/ORA11GSY/onlinelog/o1_mf_6_9ndhpfvo_.log
7 ONLINE /u01/app/oradata/ORA11GSY/onlinelog/o1_mf_7_9pcnkosf_.log
7 ONLINE /u01/app/fast_recovery_area/ORA11GSY/onlinelog/o1_mf_7_9pcnkotx_.log
14 rows selected
最后启动apply过程。
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered
下面是drop redo log的实验。
SQL> select group#, sequence#, status from v$log;
GROUP# SEQUENCE# STATUS
---------- ---------- ----------------
1 25 CLEARING
2 26 CLEARING
3 27 CURRENT
7 0 UNUSED
删除日志情况比较复杂。和单实例的情况一样,需要取决于日志组当前状态。如果状态是current或者current_clearing状态,是不允许删除的。也不允许进行switch logfile操作。
SQL> alter system switch logfile;
alter system switch logfile
ORA-16000: 打开数据库以进行只读访问
我们进行的drop操作只能针对非current类型的日志,如果确实需要删除current日志,则需要参考sync同步步骤。
首先取消redo log apply过程,修改自动管理参数。
SQL> alter database recover managed standby database cancel;
Database altered
SQL> alter system set standby_file_management=manual;
System altered
清理删除数据库日志组。
SQL> alter database clear logfile group 7; --不可缺少步骤
Database altered
SQL> alter database drop logfile group 7;
Database altered
SQL> alter system set standby_file_management=auto;
System altered
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered
当前日志组:
SQL> select group#, sequence#, status from v$log;
GROUP# SEQUENCE# STATUS
---------- ---------- ----------------
1 25 CLEARING
2 26 CLEARING
3 27 CURRENT
最后我们聊聊sync同步日志组的问题。同步日志组就是模拟DG搭建步骤,将primary上的日志结构复制到standby端。此时Primary端日志组结构如下:
SQL> select group#, status from v$log;
GROUP# STATUS
---------- ----------------
1 UNUSED
2 INACTIVE
3 CURRENT
7 UNUSED
首先需要将standby完全关闭。
[oracle@SimpleLinux trace]$ export ORACLE_SID=ora11gsy
[oracle@SimpleLinux trace]$ sqlplus /nolog
SQL*Plus: Release 11.2.0.4.0 Production on Sun May 4 14:15:52 2014
Copyright (c) 1982, 2013, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
到primary上构建standby control file。传统DG搭建过程是需要手工进行standby controlfile构建的。最新的duplicate from active 方法这个步骤是省略的。
[oracle@SimpleLinux ~]$ env | grep ORACLE_SID
ORACLE_SID=ora11g
[oracle@SimpleLinux ~]$ sqlplus /nolog
SQL*Plus: Release 11.2.0.4.0 Production on Sun May 4 14:17:30 2014
Copyright (c) 1982, 2013, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected.
SQL> alter database create standby controlfile as '/tmp/stb.ctl';
Database altered.
对应目录中找到文件。
[oracle@SimpleLinux ~]$ cd /tmp
[oracle@SimpleLinux tmp]$ ls -l | grep ctl
-rw-r-----. 1 oracle oinstall 9781248 May 4 14:18 stb.ctl
将standby control file拷贝到standby端对应的目录中。目录位置和文件名称可以查看standby端的参数文件。
SQL> show parameter control
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
control_file_record_keep_time integer 7
control_files string /u01/app/oradata/ORA11GSY/controlfile/ora11gsby01.ctl
control_management_pack_access string DIAGNOSTIC+TUNING
[oracle@SimpleLinux tmp]$ cp stb.ctl /u01/app/oradata/ORA11GSY/controlfile/ora11gsby01.ctl
将standby数据库进入mount状态。
SQL> alter database mount;
Database altered.
判断日志情况:
SQL> select * from v$logfile;
GROUP# STATUS TYPE MEMBER IS_RECOVERY_DEST_FILE
---------- ------- ------- -------------------------------------------------------------------------------- ---------------------
3 ONLINE /u01/app/oradata/ORA11GSY/onlinelog/o1_mf_3_9mnjx4n0_.log NO
3 ONLINE /u01/app/fast_recovery_area/ORA11GSY/onlinelog/o1_mf_3_9mnjx54c_.log NO
2 ONLINE /u01/app/oradata/ORA11GSY/onlinelog/o1_mf_2_9mnjwzpq_.log NO
2 ONLINE /u01/app/fast_recovery_area/ORA11GSY/onlinelog/o1_mf_2_9mnjx15f_.log NO
1 ONLINE /u01/app/oradata/ORA11GSY/onlinelog/o1_mf_1_9pcn18bg_.log NO
1 ONLINE /u01/app/fast_recovery_area/ORA11GSY/onlinelog/o1_mf_1_9pcn19z4_.log NO
4 STANDBY /u01/app/oradata/ORA11GSY/onlinelog/o1_mf_4_9nd01b56_.log NO
4 STANDBY /u01/app/fast_recovery_area/ORA11GSY/onlinelog/o1_mf_4_9nd01cpl_.log NO
5 STANDBY /u01/app/oradata/ORA11GSY/onlinelog/o1_mf_5_9nd04pps_.log NO
5 STANDBY /u01/app/fast_recovery_area/ORA11GSY/onlinelog/o1_mf_5_9nd04rpd_.log NO
6 STANDBY /u01/app/oradata/ORA11GSY/onlinelog/o1_mf_6_9nd04xjo_.log NO
6 STANDBY /u01/app/fast_recovery_area/ORA11GSY/onlinelog/o1_mf_6_9nd04yv7_.log NO
7 ONLINE /u01/app/oradata/ORA11GSY/onlinelog/o1_mf_7_9pclt1jy_.log NO
7 ONLINE /u01/app/fast_recovery_area/ORA11GSY/onlinelog/o1_mf_7_9pclt1lt_.log NO
14 rows selected
SQL> show parameter convert;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert string ORA11G, ORA11GSY
log_file_name_convert string ORA11G, ORA11GSY
注意:如果是10.2.0.1版本下,在mount中还要对所有日志组进行手工的clear动作。
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1;
启动之后,open可以成功。
SQL> alter database open;
Database altered.
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered.
SQL> select group#, status from v$log;
GROUP# STATUS
---------- ----------------
1 CURRENT
2 UNUSED
3 UNUSED
7 UNUSED
实验成功,四个online日志组被同步。
5、结论
Oracle DG是目前比较常用的HA策略模式。在运维过程中,文件创建和日志维护是经常需要关注的问题。记录下来,以备不时之需。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/28211342/viewspace-2131243/ ,如需转载,请注明出处,否则将追究法律责任。