Tag Archives: failover

RMAN-600(8201)错误的解决

根据错误信息的判断,找到一个不重建控制文件的解决方案。 RMAN-600(8201)错误:http://yangtingkun.net/?p=690 RMAN-600(8201)错误的重现:http://yangtingkun.net/?p=716 其实解决方法很简单,由于导致错误的原因是目前的主库做过FAILOVER,导致RESETLOGS的时间比当前控制文件中的RESETLOGS时间要大,Oracle在进行RMAN同步的时候判断不严谨,导致数据同步不完整,并最终体现在一些RMAN命令上,比如SHOW ALL或BACKUP等。 这个问题只影响10.2.0.3及以下版本,因此升级是可以解决问题的。 此外,由于导致问题的根源在于控制文件中的ORPHAN记录,因此手工重建控制文件也是确实可行的方案。 其实除了这些方法外,还有一个办法。就是利用备库或之前备份的控制文件来创建CATALOG。由于只是当前的主库经历过FAILOVER,也就是RESETLOGS的操作,而原来的主库也就是现在的备库并没有经历这个操作,因此用之前的主库也就是目前的备库的控制文件来注册CATALOG就可以屏蔽这个错误。 测试将备库SWITCHOVER为主库,然后通过REGISTER DATABASE命令,可以顺利的进行CATALOG的同步。再次执行SWITCHOVER,切换当前主库为问题主库,这时通过问题主库连接刚才同步后的CATALOG,此时运行SHOW ALL和BACKUP命令都不会再出现错误。 这种方法可以临时的解决这个问题,但是一旦需要对问题主库执行完全同步,则问题可能会重现。 除了使用STANDBY控制文件外,如果可以找到数据库FAILOVER之前的备份控制文件,采用类似的方法,同样可以解决这个问题。

Posted in BUG | Tagged , , , , , , , | Leave a comment

RMAN-600(8201)错误的重现

前两天,客户的数据库在执行CATALOG方式的备份时出现了RMAN-600(8201)错误。由于比较了解客户的环境,在加上客户本身对于系统的了解,使得成功的模拟出这个错误。 RMAN-600(8201)错误:http://yangtingkun.net/?p=690 其实重现这个错误并不算太复杂,要求数据库的版本是10.2.0.3以下。 首先搭建一套DATA GUARD环境。然后在备库启用数据库的FLASHBACK功能,创建一个恢复点,然后将备库激活打开。备库打开后就可以关闭,然后重新MOUNT数据库,并利用FLASHBACK将数据库回滚到激活之前的恢复点,然后利用ALTER DATABASE CONVERT命令再次将这个数据库转化为物理备库,DATA GUARD环境恢复后,使备库应用日志一直到和主库保持一致,然后进行一次DATA GUARD的SWITCHOVER的操作,使得备库变成主库,主库变成备库。 这时,对新的主库创建CATALOG,执行REGISTER DATABASE后,执行show all命令,就会重新错误。 [orat1@hpserver2 ~]$ rman target / catalog rcat_user/rcat_password Recovery Manager: Release 10.2.0.3.0 – Production ON Sat Apr 4 20:51:56 2012 Copyright (c) 1982, 2005, Oracle. ALL rights reserved. connected … Continue reading

Posted in BUG | Tagged , , , , , , , , , , , , | Leave a comment

RAC环境关闭CLUSTER后导致连接缓慢

客户的四节点RAC在停掉三个后,发现连接RAC明显变慢。 数据库环境是4节点的10.2 RAC for Linux X86-64。由于心跳存在问题,目前将三个节点上的CLUSTER关闭,但是随后不久,客户反应数据库访问变慢。 虽然本来4个节点繁忙程度都不高,但是将4个实例上的压力集中到1个实例上,那么性能有所下降也是正常的。不过检查数据库的工作状态,并未发现异常,无论是从后台cpu忙闲程度,还是从awr报告中查看,似乎并没有太大的压力。 询问客户是查询变慢还是登录变慢,客户也搞不清其中的差别,于是在尝试连接数据库,结果发现,无论是tnsping还是sqlplus登录,有时登录很快,有时要经历3秒到6秒的等待,这应该就是客户反应慢的原因。 检查登录数据库的TNSNAMES.ORA中的配置,客户默认4个节点作为LOAD BALANCE和静态FAILOVER,这种配置方式在节点关闭后并不会导致错误,但是有可能由于需要等待超时而经受性能问题。 检查服务器上CLUSTER的状态,发现4个节点上,有两个VIP的服务都停掉了,应该是用户关闭整个CLUSTER服务是导致的。在此情况下,静态FAILOVER发挥作用,但是会引入超时的问题。而由于配置了LOAD_BALANCE,Oracle会轮训4个VIP地址,这就导致了有时候连接很快完成,而有时连接需要等待3秒以上。 由于存在众多的客户端,无法一一修改客户端使用的TNS配置,那么最简单的解决办法就是将CLUSTER启动,只是关闭其他三个节点的数据库,这样所有的VIP都处于启动状态,即使连接到没有提供的服务的节点,也可以快速的重新启动到启动节点上。 将其他两个VIP关闭的CLUSTER启动,保持DB关闭状态,数据库连接缓慢的问题就此解决。

Posted in ORACLE | Tagged , , , | 2 Comments