Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
Oracle数据库数据恢复、性能优化»论坛 › Oracle › Oracle数据库管理 › dg+stream环境下备库无法启动到read only状态？ ...
发新帖
bj-jn

8

积分

1

好友

20

主题

[常规管理] dg+stream环境下备库无法启动到read only状态？

1#
发表于 2013-5-6 13:03:33 | 查看: 4844| 回复: 9
环境描述:DB/10.2.0.4 64bit
    我在测试环境中搭建了一套2节点的dg环境，然后在主库上配置表级别的stream replication以便能将变化数据同步到第三个节点，配置完成后在主库上的数据修改可以同步到第三个节点，但是在备库上执行alter database open命令时提示如下错误：
    ERROR at line 1:
ORA-16004: backup database requires recovery
ORA-01194: file 6 needs more recovery to be consistent
ORA-01110: data file 6: '+DATA/tldg/datafile/streams_tbs.294.814629283'
数据文件6就是stream管理用户所在的默认表空间的数据文件
此时查询备库的checkpoint信息如下
SQL> select file#,checkpoint_change# from v$datafile_header;
                  FILE#      CHECKPOINT_CHANGE#
----------------------- -----------------------
                      1           9979315587069
                      2           9979315587069
                      3           9979315587069
                      4           9979315587069
                      5           9979315587069
                      6           9979315587069
.
SQL> select file#,checkpoint_change# from v$datafile;
                  FILE#      CHECKPOINT_CHANGE#
----------------------- -----------------------
                      1           9979315585708
                      2           9979315585708
                      3           9979315585708
                      4           9979315585708
                      5           9979315585708
                      6           9979315584855

同时查询主库的checkpoint信息如下
SQL> select file#,checkpoint_change# from v$datafile;
               FILE#   CHECKPOINT_CHANGE#
-------------------- --------------------
                   1        9979315585714
                   2        9979315585714
                   3        9979315585714
                   4        9979315585714
                   5        9979315585714
                   6        9979315585714
6 rows selected.
SQL> select file#,checkpoint_change# from v$datafile_header;
               FILE#   CHECKPOINT_CHANGE#
-------------------- --------------------
                   1        9979315585714
                   2        9979315585714
                   3        9979315585714
                   4        9979315585714
                   5        9979315585714
                   6        9979315587069
我尝试着在主库上执行alter database checkpoint和在备库上开启实时应用日志依然无法解决此问题，备库始终无法以一致性的状态打开。
请问导致此现象的原因是不是因为配置了stream replication？是否有解决办法?感谢！
2#
发表于 2013-5-6 13:13:29
我觉得不是 ， recover managed standby  切几个日志观察 checkpoint scn变化

回复 只看该作者 道具 举报

3#
发表于 2013-5-6 13:18:43
Maclean Liu(刘相兵 发表于 2013-5-6 13:13
我觉得不是 ， recover managed standby  切几个日志观察 checkpoint scn变化

我在主库端切换了n多次日志，而且在备库这端开启了实时日志应用依然无法打开备库，而且我观察到主库的checkpoint scn信息都是与stream想关的数据文件scn不一致，其余的文件都一致，所以我才怀疑是和stream配置有关！

回复 只看该作者 道具 举报

4#
发表于 2013-5-6 13:22:57
2边的 alert.log上传

回复 只看该作者 道具 举报

5#
发表于 2013-5-6 21:44:43
Maclean Liu(刘相兵 发表于 2013-5-6 13:22
2边的 alert.log上传

为了让备库能够以一致性状态启动，我首先让备库应用完主库产生的所有归档(除当前的redo log外），接着我一致性关闭主库，然后在备库上执行"alter database recover database"根据提示应用主库的当前日志，这是我再启动备库，备库已经可以启动到read only状态了。
现在出现新问题是“当我启动主库后重新切换日志，归档日志都可以正常的传输到备库，但当我在备库应用日志时mrp0进程启动后马上关闭，也就说说我现在的备库只能接受日志不能应用日志了，以下是我mrp0的后台trace，希望刘大帮我看看，感谢
MRP0: Background Managed Standby Recovery process started
*** 2013-05-06 20:23:09.062 1118 krsm.c
Managed Recovery: Initialization posted.
*** 2013-05-06 20:23:09.062 62692 kcrr.c
Managed Standby Recovery not using Real Time Apply
Recovery target incarnation = 2, activation ID = 0
Influx buffer limit = 17537 (50% x 35074)
Successfully allocated 2 recovery slaves
Using 550 overflow buffers per recovery slave
Start recovery at thread 1 ckpt scn 9979315587703 logseq 31 block 687
*** 2013-05-06 20:23:09.604
Media Recovery add redo thread 1
*** 2013-05-06 20:23:09.614 1118 krsm.c
Managed Recovery: Active posted.
*** 2013-05-06 20:23:09.686
Media Recovery Log /u01/arch/1_31_814545128.dbf
File 1 (stop scn 9979315587703) completed recovery at checkpoint scn 9979315587705
File 2 (stop scn 9979315587703) completed recovery at checkpoint scn 9979315587705
File 3 (stop scn 9979315587703) completed recovery at checkpoint scn 9979315587705
File 4 (stop scn 9979315587703) completed recovery at checkpoint scn 9979315587705
File 5 (stop scn 9979315587703) completed recovery at checkpoint scn 9979315587705
File 6 (stop scn 9979315587703) completed recovery at checkpoint scn 9979315587705
ARCH: Connecting to console port...
*** 2013-05-06 20:23:09.730 62692 kcrr.c
MRP0: Media Recovery Complete
*** 2013-05-06 20:23:09.730
Media Recovery drop redo thread 1
*** 2013-05-06 20:23:12.184 1118 krsm.c
Managed Recovery: Not Active posted.
ARCH: Connecting to console port...
*** 2013-05-06 20:23:12.188 62692 kcrr.c
MRP0: Background Media Recovery process shutdown

回复 只看该作者 道具 举报

6#
发表于 2013-5-7 14:12:54

2边的 alert.log上传

回复 只看该作者 道具 举报

7#
发表于 2013-5-7 14:19:08
Maclean Liu(刘相兵 发表于 2013-5-7 14:12
2边的 alert.log上传

刘大，两边的alert日志和mrp0的trace已上传

tl.rar

18.98 KB, 下载次数: 1362

回复 只看该作者 道具 举报

8#
发表于 2013-5-7 17:52:59
更改楼主上述环境（11g） dg+ stream
将备库一直open，搭建stream，没出现楼主上述情况：
  1. standby11g>select file#,checkpoint_change# from v$datafile_header;

  3.      FILE# CHECKPOINT_CHANGE#
  4. ---------- ------------------
  5.          1            9950130
  6.          2            9950130
  7.          3            9950130
  8.          4            9950130
  9.          5            9950130
  10.          6            9950130

  12. 6 rows selected.

  14. standby11g> select file#,checkpoint_change# from v$datafile;

  16.      FILE# CHECKPOINT_CHANGE#
  17. ---------- ------------------
  18.          1            9950130
  19.          2            9950130
  20.          3            9950130
  21.          4            9950130
  22.          5            9950130
  23.          6            9950130

  25. 6 rows selected
复制代码
  1. primary11g>select file#,checkpoint_change# from v$datafile_header;

  3. FILE# CHECKPOINT_CHANGE#
  4. ----- ------------------
  5.     1            9954358
  6.     2            9954358
  7.     3            9954358
  8.     4            9954358
  9.     5            9954358
  10.     6            9954358

  12. 6 rows selected.

  14. primary11g> select file#,checkpoint_change# from v$datafile;

  16. FILE# CHECKPOINT_CHANGE#
  17. ----- ------------------
  18.     1            9954358
  19.     2            9954358
  20.     3            9954358
  21.     4            9954358
  22.     5            9954358
  23.     6            9954358

  25. 6 rows selected.
复制代码
  1. strm_dest11g>select file#,checkpoint_change# from v$datafile_header;
  2.      FILE# CHECKPOINT_CHANGE#
  3. ---------- ------------------
  4.          1            9909470
  5.          2            9909470
  6.          3            9909470
  7.          4            9909470
  8.          5            9909470
  9.          6            9909470

  11. 6 rows selected.

  13. strm_dest11g>select file#,checkpoint_change# from v$datafile;

  15.      FILE# CHECKPOINT_CHANGE#
  16. ---------- ------------------
  17.          1            9909470
  18.          2            9909470
  19.          3            9909470
  20.          4            9909470
  21.          5            9909470
  22.          6            9909470

  24. 6 rows selected.
复制代码
望楼主在做一次。可以尝试standby 不应用日志。先open。然后再搭建stream，然后再启动standby的日志应用。

回复 只看该作者 道具 举报

9#
发表于 2013-5-7 20:13:42
monkeybron 发表于 2013-5-7 17:52
更改楼主上述环境（11g） dg+ stream
将备库一直open，搭建stream，没出现楼主上述情况：望楼主在做一次。 ...

感谢monkeyborn的回复，我再试试！

回复 只看该作者 道具 举报

10#
发表于 2013-5-16 10:30:57
问题已解决，重新配置一次后故障消失，猜测当时出现此问题的原因是频繁的在recover managed状态与read only状态之间来回切换且之间没有cancel后再启动到read only

回复 只看该作者 道具 举报

返回列表
高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-12-29 01:53 , Processed in 0.055122 second(s), 23 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569