Home > DGCA > 搭建physical standby时standby log的问题

搭建physical standby时standby log的问题

当时的情况是这样的。。在准备阶段,主库就添加好了4份standby log file,我起初认为这样的话在搭备库的时候就不需要再手动添加standby log file了,因为控制文件里面已经有了这些信息,只需要clear一下就可以使用了。但是结果却并非如此。

在备库mount之后:

SQL> set lines 180
SQL> select * from v$standby_log;

    GROUP# DBID                                        THREAD#  SEQUENCE#      BYTES       USED ARC STATUS     FIRST_CHANGE# FIRST_TIME   LAST_CHANGE# LAST_TIME
---------- ---------------------------------------- ---------- ---------- ---------- ---------- --- ---------- ------------- ------------ ------------ ------------
         4 UNASSIGNED                                        0          0   10485760        512 YES UNASSIGNED             0                         0
         5 UNASSIGNED                                        0          0   10485760        512 YES UNASSIGNED             0                         0
         6 UNASSIGNED                                        0          0   10485760        512 YES UNASSIGNED             0                         0
         7 UNASSIGNED                                        0          0   10485760        512 YES UNASSIGNED             0                         0

可以看到是有4份standby log file的,但是recover 一下,你会发现:

SQL> recover managed standby database using current logfile disconnect;
Media recovery complete.
SQL> select * from v$standby_log;
no rows selected

查看alert.log会发现类似如下错误:

  Errors in file /opt/ora10g/admin/johnnydb_dg/udump/johnnydb_dg_rfs_7498.trc:
  ORA-00313: open failed for members of log group 7 of thread 1
  ORA-00312: online log 7 thread 1: '/data/oradata/johnnydb_dg/STD_REDO04.LOG'
  ORA-27037: unable to obtain file status
  Linux Error: 2: No such file or directory

所以事实上,上面的real time apply虽然命令是敲成功了,其实背后的real time apply是失败的,主库commit的事务并不会马上应用到备库。

之后再恢复就会报standby log file不存在的错误了,

SQL> recover managed standby database using current logfile disconnect;
ORA-38500: USING CURRENT LOGFILE option not available without stand

而online redo logfile就不同了,我们知道,在创建备库的时候,是不需要将主库的online redo logfile给拷贝过来的,备库恢复的时候,会先根据控制文件里的redo信息去clear online redo logfile ,自动生成新的online redo logfile文件,所以开始会有这样的信息:

  ORA-00313: open failed for members of log group 1 of thread 1
  ORA-00312: online log 1 thread 1: '/data/oradata/johnnydb_dg/REDO01.LOG'
  ORA-27037: unable to obtain file status
  Linux Error: 2: No such file or directory
  Additional information: 3
  *** 2012-02-02 00:28:11.906 60679 kcrr.c
  Clearing online redo logfile 1 /data/oradata/johnnydb_dg/REDO01.LOG
  ORA-00313: open failed for members of log group 1 of thread 1
  ORA-00312: online log 1 thread 1: '/data/oradata/johnnydb_dg/REDO01.LOG'
  ORA-27037: unable to obtain file status
  Linux Error: 2: No such file or directory
  Additional information: 3
  *** 2012-02-02 00:28:12.806 60679 kcrr.c
  Clearing online redo logfile 1 complete

这些报错信息可以忽略。standby logfile却做不到这一点,备库搭完,如果想用real time apply的话,就需要我们去手动add standby logfile。
事实上,在主库创建standby controlfile的时候,alert里面就已经有提示让我们手动去创建standby logfile了:

alter database create standby controlfile as '/data/control.ctl'
Fri Feb  3 23:32:10 2012
Clearing standby activation ID 979550934 (0x3a62c2d6)
The primary database controlfile was created using the
'MAXLOGFILES 16' clause.
There is space for up to 13 standby redo logfiles
Use the following SQL commands on the standby database to create
standby redo logfiles that match the primary database:
ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 10485760;
ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 10485760;
ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 10485760;
ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 10485760;
Completed: alter database create standby controlfile as '/data/control.ctl'

又做了次试验,如果拷贝数据文件的时候也将standby logfile拷贝过来的话,就万事OK啦,standby logfile不会报错,同时,如果online redo也拷贝过来的话,也不会出现找不到文件的错误信息(这是明显的。。),直接clearing成功。

alert日志:

  Clearing online redo logfile 1 complete
  Clearing online redo logfile 2 /data/oradata/johnnydb_dg/REDO02.LOG
  Clearing online log 2 of thread 1 sequence number 5
  Clearing online redo logfile 2 complete
  Clearing online redo logfile 3 /data/oradata/johnnydb_dg/REDO03.LOG
  Clearing online log 3 of thread 1 sequence number 3
  Clearing online redo logfile 3 complete
  Media Recovery Waiting for thread 1 sequence 5
  …
  Thu Feb  2 01:44:55 2012
  RFS[1]: Successfully opened standby log 4: '/data/oradata/johnnydb_dg/STD_REDO01.LOG'
  Thu Feb  2 01:44:56 2012
  Media Recovery Log /data/arch/johnnydb_dg/1_9_767310934.dbf
  Thu Feb  2 01:44:56 2012
  Redo Shipping Client Connected as PUBLIC
  -- Connected User is Valid
  RFS[2]: Assigned to RFS process 7783
  RFS[2]: Identified database type as 'physical standby'
  Primary database is in MAXIMUM PERFORMANCE mode
  Primary database is in MAXIMUM PERFORMANCE mode
  RFS[2]: Successfully opened standby log 4: '/data/oradata/johnnydb_dg/STD_REDO01.LOG'
  Thu Feb  2 01:44:57 2012
  Media Recovery Waiting for thread 1 sequence 10 (in transit)
  Thu Feb  2 01:45:02 2012
  Recovery of Online Redo Log: Thread 1 Group 4 Seq 10 Reading mem 0   Mem# 0 errs 0: /data/oradata/johnnydb_dg/STD_REDO01.LOG

所以,在standby logfile跟logfile的处理上,oracle还是有区分的(虽然我觉得完全可以按照online redo的处理方式来),如果想省去在备库创建standby logfile的操作的话,建备库的时候只需需要将主库的standby logfile拷贝过来。

Categories: DGCA Tags:
  1. No comments yet.
  1. No trackbacks yet.