【DataGuard】10GR2 DataGuard的几个redo log相关问题

1.备库启动报redo log不存在的问题:

错误信息:

Errors in file /home/oracle/admin/kgbdwmyj/bdump/kgbdwmyj_mrp0_11986.trc:

ORA-00313: open failed for members of log group 2 of thread 1

ORA-00312: online log 2 thread 1: '/oradata/kgbdwmyj/redo02.log'

ORA-27037: unable to obtain file status

Linux-x86_64 Error: 2: No such file or directory

Additional information: 3

解决方法:

设置log_file_name_convert参数,即使备库与主库目录位置完全一样也需设置,如:*.log_file_name_convert='/oradata/kgbdwmyj/','/oradata/kgbdwmyj/'

原因:

这个错误会在10g出现,9i是不会出现的。因为做switch over的时候需要清空联机日志,在10g中,oracle为了加快swich over的速度,Oracle10g在将备库置于manged standby状态的时候就提前将这个clear的动作做了,但具体实现做的不够好

2.备库报redo log必须改名的错误:

错误信息:

Errors in file /home/oracle/admin/kgbdwmyj/bdump/kgbdwmyj_mrp0_4846.trc:

ORA-19527: physical standby redo log must be renamed

ORA-00312: online log 1 thread 1: '/oradata/kgbdwmyj/redo01.log'

解决方法:

设置log_file_name_convert参数,即使备库与主库目录位置完全一样也需设置,如:*.log_file_name_convert='/oradata/kgbdwmyj/','/oradata/kgbdwmyj/'

3.备库报找不到standby redo log的问题:

错误信息:

Errors in file /home/oracle/admin/kgbdwmyj/udump/kgbdwmyj_rfs_5119.trc:

ORA-00313: open failed for members of log group 6 of thread 1

ORA-00312: online log 6 thread 1: '/oradata/kgbdwmyj/standby_redo06.log'

ORA-27037: unable to obtain file status

Linux-x86_64 Error: 2: No such file or directory

Additional information: 3

且无法通过alter database add standby logfile group 6 ('/oradata/kgbdwmyj/standby_redo06.log') size 1000M增加standby redolog

原因:

出现这个错误主要是因为在备份前主库创建了standby redo log,备库是根据主库的信息创建的,一开始它是包含了主库的standby redo log信息,如果主库设置的日志传送方式是LGWR,当主库发生日志切换时,备库的RFS会尝试使用standby redo log来存储主库传送过来的日志,因为此时备库实际上是不存在standby redo log的,所以备库会报错。当备库尝试打开字典信息的所有standby redo log失败以后,备库会自动把日志传送方式转为ARCN,并同时清除数据字典中的standby redo log信息。

解决方法:当备库尝试打开字典信息的所有standby redo log失败以后,备库会自动把日志传送方式转为ARCN,并同时清除数据字典中的standby redo log信息。这时你再去增加standby redo log即可

参考:

作者:george.ma blog:http://blog.chinaunix.net/u/12521/

参考metalinkNote:352879.1

时间: 2024-09-05 11:23:08

【DataGuard】10GR2 DataGuard的几个redo log相关问题的相关文章

redo log buffer小结

整理自<OCA/OCP认证考试指南> 001     日志重做缓冲区是小型的.用于短期存储将写入到磁盘上的重做日志的变更向量的临时区域."变更向量"是应用于某些对象的修改,执行DML语句会生成应用于数据的变更向量.有了重做日志,数据库就可以确保数据永不丢失:每当数据块发生更改时,都会将应用于块的变更向量写到重做日志,如果需要还原数据文件,则通过重做日志,可以将变更向量提取并应用于数据文件备份. 002     会话服务器进程不将重做记录直接写入重做日志文件,否则,每当执行D

DataGuard - 利用Cascaded Redo Log Destinations避免WAN稳定性问题

问题 最近一直头疼于DataGuard环境中万一网络失败将导致的Primary库短时间内无法正常工作的问题. 这个问题的现象基本上是这样:当Primary和Standby之间的网络出现问题,比如说在测试环境中我们拔掉Standby的网线,此时当Primary发生日志切换(Log Switch)的时候,Primary将试图通知Standby同样作归档,但是由于网络不通,就会默认有30秒的TimeOut,而在这30秒的时间内,Primary上的任何DML操作都将被悬停.至今为止我还没有找到很好的办法

MySQL: 对超长blob列的redo log限制

我们知道,Innodb使用固定长度的N个iblog文件来存储redo log,文件空间可以被复用.这些被复用的空间redo需要保证已经做了checkpoint. 假定我们的iblog大小为1G,如果我们更新一个非常大的字段,就有可能覆盖掉未checkpoint的redo log,因为Innodb并没有根据其可能产生的log长度来判断redo log空间是否够用.而只是保证会预留一定比例的redo log空间.详细见bug链接:http://bugs.mysql.com/bug.php?id=69

Oracle Online Redo Log能否放在Flash闪存卡上?

Flash 闪存卡的性能远超SAS 盘,所以在数据库中使用广泛. 但是online redo log 是否应该存放在闪存卡上一直是有争议的话题.今天由DBA+社群合肥发起人戴明明来谈一谈他通过理论和实际的实验去测试这个问题.   专家简介     戴明明 DBA+社群合肥发起人   Oracle ACE Associate,中国 ORACLE 用户组(ACOUG) 核心成员,中国浙江应用中间件与数据库用户组成员. 超过7年的DBA经验,在Oracle 高可用性方面有一定的经验积累,擅长Oracl

Oracle高并发系列2:事务日志写入引发的Redo log风波

作者介绍 王鹏冲,平安科技数据库技术专家,浸淫数据库行业十多年,对Oracle数据库有浓厚兴趣,也对MySQL.MongoDB.Redis等数据库有一定架构和运维经验,目前正沉迷在PostgreSQL数据库与Oracle数据库的PK之中,重点在关系型数据库的分布式架构研究.   引言   关系型数据库强调事务的ACID特性,对于事务的持久性,主流的关系型数据库都是通过写事务日志来实现的.写数据是随机IO,写日志是顺序IO,常规的机械磁盘,随机IO比顺序IO要昂贵很多.所以虽然写日志同样要刷到磁盘

MySQL · 引擎特性 · InnoDB redo log漫游

前言 InnoDB 有两块非常重要的日志,一个是undo log,另外一个是redo log,前者用来保证事务的原子性以及InnoDB的MVCC,后者用来保证事务的持久性. 和大多数关系型数据库一样,InnoDB记录了对数据文件的物理更改,并保证总是日志先行,也就是所谓的WAL,即在持久化数据文件前,保证之前的redo日志已经写到磁盘. LSN(log sequence number) 用于记录日志序号,它是一个不断递增的 unsigned long long 类型整数.在 InnoDB 的日志

数据库内核月报 - 2015 / 05-MySQL · 引擎特性 · InnoDB redo log漫游

前言 InnoDB 有两块非常重要的日志,一个是undo log,另外一个是redo log,前者用来保证事务的原子性以及InnoDB的MVCC,后者用来保证事务的持久性. 和大多数关系型数据库一样,InnoDB记录了对数据文件的物理更改,并保证总是日志先行,也就是所谓的WAL,即在持久化数据文件前,保证之前的redo日志已经写到磁盘. LSN(log sequence number) 用于记录日志序号,它是一个不断递增的 unsigned long long 类型整数.在 InnoDB 的日志

mysql源码-关于mysql redo log的问题。

问题描述 关于mysql redo log的问题. http://bugs.mysql.com/bug.php?id=73202 上面是一个官方的patch, According to the crash recovery logic of mysql server, we only need to write/sync prepared transaction before writing to binlog. And currently transactions are not groupe

oracle-Redo log频繁切换问题,生成的archivelog文件远小于Redo log设置大小

问题描述 Redo log频繁切换问题,生成的archivelog文件远小于Redo log设置大小 Dear all, 遇到个问题Oracle DB Redo log每分钟差不多切换两次,设置的大小为600MB,但实际切换生成的archivelog文件只有1MB左右. 在alert log每分钟都有alter system archive log的记录,请教各位可能是什么原因造成?