Tag Archives: rman

ORA-600(krbb2ec_stamp_mismtach)错误

备份归档日志导致的ORA-600错误。 错误信息如下: Tue Aug 16 02:43:58 2011 ALTER SYSTEM ARCHIVE LOG Tue Aug 16 02:44:01 2011 Thread 1 advanced TO log SEQUENCE 5940 (LGWR switch) CURRENT log# 7 seq# 5940 mem# 0: /dev/orcl3vg1/rdb3vg1_1_redo71 CURRENT log# 7 seq# 5940 mem# 1: … Continue reading

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

控制文件自动备份报错并产生TRACE文件

客户10.2.0.1数据库在控制文件自动备份过程中出现错误信息。 错误信息为: Thu Jun 30 02:15:46 2011 Starting control autobackup Thu Jun 30 02:15:47 2011 Errors IN file /u01/app/oracle/admin/orcl/udump/orcl_ora_1167402.trc: Thu Jun 30 02:15:47 2011 Errors IN file /u01/app/oracle/admin/orcl/udump/orcl_ora_1167402.trc: Thu Jun 30 02:15:47 2011 Errors IN file /u01/app/oracle/admin/orcl/udump/orcl_ora_1167402.trc: Control autobackup written … Continue reading

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

删除归档出现ORA-15028错误

在10.2.0.4 RAC环境中使用RMAN删除归档报错ORA-15028。 错误信息如下: RMAN> DELETE archivelog ALL completed BEFORE ‘sysdate-3’; Do you really want TO DELETE the above objects (enter YES OR NO)? YES RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03009: failure OF DELETE command … Continue reading

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

10g RMAN的REDUNDANCY策略改变

最近发现10g的RMAN备份保留REDUNDANCY策略和9i相比发生了改变。 在Oracle9i中,备份保留策略的REDUNDANCY的值,指的是备份冗余的个数。也就是说,如果REDUNDANCY设置为1,那么Oracle会保留2个备份。 但是在10g以后,REDUNDANCY的值,就是最终备份保留的值,手头没有10g的环境,用11g的rman做了一个例子: solaris*orcl-/home/oracle$ rman target / Recovery Manager: Release 11.2.0.3.0 – Production ON Sun Jul 8 19:04:43 2012 Copyright (c) 1982, 2011, Oracle AND/OR its affiliates. ALL rights reserved. connected TO target DATABASE: ORCL (DBID=1299676637) RMAN> SHOW retention policy; … Continue reading

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

备份导致ORA-245错误

客户的11.2 RAC数据库在备份是出现ORA-245错误。 从告警日志中可以看到错误信息为: Errors IN file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_ora_18335.trc: ORA-00245: control file backup operation failed 详细TRACE信息为: Trace file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_ora_18335.trc Oracle DATABASE 11g Enterprise Edition Release 11.2.0.2.0 – 64bit Production WITH the Partitioning, REAL Application Clusters, Automatic Storage Management, OLAP, DATA Mining AND … Continue reading

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

RMAN-600(8201)错误

客户数据库在执行RMAN备份时碰到这个错误。 错误信息如下: RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure OF backup command at 03/25/2012 02:31:18 RMAN-00600: internal error, arguments [8201] [] [] [] [] 根据MOS文档Rman Backup Failed With Error Rman-00600 [8201] [ID 412786.1]描述,导致错误的原因是控制文件中记录的信息和CATALOG中记录的信息出现了不一致的地方。Oracle给出的解决方案是CATALOG的全同步,不过执行RECYNC CATALOG后问题依旧: … Continue reading

Posted in BUG | Tagged , , , , , | 4 Comments

一次客户数据库恢复的过程

前一段时间给一个客户恢复了一个数据库。 事情其实已经过去一段时间了,而且整个过程无非是一个数据库的基于时间的不完全恢复,从技术角度讲,没有什么太多可以值得描述的,而且由于所有的操作都是在客户的主机上进行,因此没有留下任何的痕迹,因此这件事情很难写成一篇技术相关的文章,所以也就一直没有写出来。 今天打算简单描述一下这个问题,主要是受Eygle的影响,Eygle最近刚刚写完一本新书《数据安全警示录》,我在帮他进行一些文字上的检查工作。在这本书中,Eygle用他帮别人恢复数据库的案例来警示大家,希望大家能利用别人的失败教训来警醒我们自己。 虽然我的这个案例在技术上并没有太多值得描述的,但是这个案例本身却很有借鉴意义,在这里和大家分享一下。 我们接到客户的请求是周五的下午,据说客户的数据库在周四夜里DOWN机,随后负责维护的人员对数据库进行了恢复,但是数据库丢失了部分数据,客户对于恢复的程度不认可,于是找到了我们。 开始以为只是由于不完全恢复的RESETLOGS导致了少量的数据丢失,可能需要通过类似LOGMINER的方法来看看能否多恢复一些数据,但是到了现场进行了简单的沟通后,发现我们之前得到的信息非常的不准确。 客户的数据库在周四夜里11点左右DOWN机,随后负责维护的人员对数据库进行了恢复,但是数据库最终只恢复到了周四上午10点左右,客户对于这种程度的恢复当然是不认可的,以致于最终对于现场负责维护的技术人员的不信任,最终找到了我们。 而对于现场环境的检查后,发现了很多的问题。 数据库DOWN机的原因是由于当前日志损坏,由于数据库的日志每组只有一个,这个当前日志的损坏不但导致数据库的DOWN机,而且会造成数据的丢失。但是损失仅此而已,只是当前日志中少部分已经COMMIT但是还没有写到数据文件的数据。对于这种情况,最差的情况是丢失一个小时的数据,也就是说到上一个日志切换时刻数据都是正常的。而对于当前日志丢失的情况,完全没有必要也没有理由去执行全库的恢复,只要清除当前损坏的日志就可以打开数据库。执行全库的恢复说明维护人员根本不理解Oracle的备份恢复机制,只是发现数据库无法正常打开,就去盲目的还原并恢复数据库,导致更多的问题产生。 维护人员水平不高,因此备份策略的不严谨以及备份和恢复过程的混乱也是意料之内的事情。首先,Oracle的备份策略存在比较严重的问题,客户的环境中有存储备份的带库,这对于数据库备份而言,应该是更安全的保障,但是备份策略的设置不但没有提高备份的安全性,反而使得备份的可用性下降。 客户的数据库每周执行一次全库备份,每天进行一次增量的备份,此外每天要进行多次的归档日志的备份。除了全库备份一定存储在带库上之外,增量备份和归档日志的备份有可能存储在带库上,也有可能存储在磁盘上,且没有任何一个位置上的备份是齐备的。以这次的问题为例,进行数据库的恢复首先需要恢复4天前带库上的全备,然后需要应用3天前带库上的增量,2天前磁盘上的增量,1天前带库上的增量,以及带库和本地磁盘上最近一天的归档备份。这种备份策略导致的一个问题就是,如果磁盘或带库任意出现一点损坏,就会导致数据库无法完全恢复。带库设备本来可以增加备份的可靠性,但是这种备份策略的设置使得备份的安全性和可靠性被降到最低。此外这种备份的存储和恢复也会给备份恢复的性能带来很大的影响。 除了备份策略的问题之外,操作过程也存在非常严重的问题。其中一点就是,数据库恢复过程的RMAN输出日志被删除。由于缺少当时恢复过程的日志,无法确定维护人员当时具体执行的操作是什么,所有的信息只能来自当事人的口述,本来口述这个方式就不靠谱,何况还是一个概念本身就不很清晰的人,而且问题产生的后果已经比较严重,很难说他在描述的过程中是否为自己开脱。总之,按照当事人的描述,恢复步骤应该是没有问题的,但是恢复后数据库中的数据只到早上10点左右,缺少了最后一天12个小时的数据。 最后维护人员还犯了一个更加严重的错误,第一次在进行数据库恢复的过程中,有一些带库上的归档日志文件被恢复到本地磁盘上。在数据库恢复完成后,出于空间的考虑,所有硬盘上恢复出来的归档日志被删除。但是由于删除的时候没有进行限定,删除操作删除了数据库硬盘上所有的归档,不仅包括恢复过程中从带库恢复到硬盘上的,还包括最新的几个还没有进行过备份的归档文件。这个删除的操作最终导致了数据库再次进行恢复时,丢失了最后两个小时的数据。 可以看到,原本一个只是损失几分钟数据,造成半个小时左右停机时间的故障,由于维护人员的错误,导致问题一步步放大,最终造成了损失2个小时左右的数据,且数据库停机一天半以上的重大事故。

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

AIX环境dd迁移控制文件出现ORA-202和ORA-27047错误

客户尝试利用dd来迁移裸设备上的控制文件,结果出现了这个错误。 利用dd命令将控制文件从旧存储的裸设备迁移到新存储上,命令如下: dd IF=/dev/oldcontrol OF=/dev/newcontrol bs=2048k 然后尝试启动数据库,在MOUNT时报错: SQL> startup nomount ORACLE instance started. Total System Global Area 1.5032E+10 bytes Fixed SIZE 2046960 bytes Variable SIZE 2483029008 bytes DATABASE Buffers 1.2533E+10 bytes Redo Buffers 14729216 bytes SQL> ALTER DATABASE mount; ALTER … Continue reading

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