某政府客户Oracle恢复遭遇ORA-01190 和 ORA-600 [krhpfh_03-1202]

 某客户的Oracle数据库环境,由于硬件故障导致undo损坏,且是非归档环境。我们通过通过dbv检测发现大量数据库文件发现存在大量的数据库坏块,如下所示:

通过分析trace文件,我发现里面有如下信息:

于是使用
_corrupted_rollback_segments= (_SYSSMU4$, _SYSSMU5$, _SYSSMU6$, _SYSSMU7$, _SYSSMU8$, _SYSSMU9$, _SYSSMU10$)

然后再次mount,然后recover一下,成功open数据库,但是查询发现file 5和file 6有问题。显示为missing,经过询问在另外一个路径下找到了文件,然后我进行了rename操作,接着进行recover,发现报错。

我们可以看到,reset logs count 和scn 都不一致,这里我们其实可以bbed直接修改即可。
由于这里是windows 平台,比较麻烦,我就不用bbed了,直接用oracle的10015 event 来推进数据库的SCN。

首先启动到mount状态,执行如下命令:

成功open数据库,由于undo datafile本身损坏了,且又是非归档,故直接重建undo了,搞定。

补充下:在操作过程中发现smon在进程recover时有点问题,故使用了下面的event:

event=’10513 trace name context forever,level 2′ event=’10512 trace name context forever,level 1′ event=’10511 trace name context forever,level 2′ event=’10510 trace name context forever,level 1′

某银行客户一套1.4TB ASM(RAC) 磁盘损坏恢复小记

这周折腾了2天的时间帮客户成功恢复了一套近1.4TB的10.2.0.5 RAC(ASM). 该库在3月4号直接crash了。

大家可以看到,该库在开始报错读取redo,controlfile报错,本质原因是DISKGROUP dismount了,信息如下:

数据库实例挂了之后,我们来看下ASM实例的alert log信息,如下:

大家可以看到,ASM报了一个ORA-15081错误,在该错误之前是报对其中一个盘/dev/raw/raw5的IO操作错误。
细心的朋友可以看到,这里由于IO 操作异常后,该disk被offline了。最后磁盘组无法mount。

我们测试使用kfed read无法读取该disk,dd也无法操作。但是却可以直接dd 该disk对应的物理盘。

磁盘组无法mount,从其中trace来看显然是磁盘头损坏,如下:

大家知道Oracle ASM 10.2.0.5版本开始会对ASM disk header 进行自动备份,如果如果仅仅是盘头
损坏那么恢复是很easy的。但是其实并不是这么简单,通过dd判断,该盘的前面几个block其实被损坏。

最后我们通过ODU 直接将数据文件从磁盘拷贝到文件系统,然后起库,最后完成整个恢复过程。

备注:在恢复过程中,发现ODU无法直接拷贝test201402.dbf 这样的文件,然而通过检查

asm alias directory发现,其实是完好的,这里可能odu处理还有点小问题,我们通过手工将该元数据

的AU 读取出来,然后匹配将剩下的文件全部抽取出来了,包括redo,controlfile,直接顺利打开数据库。

最终经过我们的抢救,使用我们的数据库恢复软件成功帮助客户恢复了数据!当遇到类似问题时,请记得一定要保持现场,尽量不要做其他操作,防止进一步恶化。

一次TB级ERP(ASM RAC)库的恢复案例

前不见某客户的ERP 库出现故障(Linux x64,10204 rac ams环境). 大概问题是由于一些列操作之后导致磁盘组无法mount,
只能进行数据恢复,针对该case,我们前后投入了8个人力,进行了3天3夜终于成功抢救该数据库。

首先是客户在rac其中一个节点add disk时,发现在另外节点未添加成功,后面又反复折腾add,甚至dd 盘头进行了add。
最为致命的一个动作是强制add disk,其实在该步骤之前这几个disk已经add过一次,且完成了reblance,但是drop disk
却并未成功,最后客户尝试强制添加,如下:

首先利用kfed 读取相关的disk,发现asm的相关元数据基本上都不存在了,因为前面的add disk force其实相当于是吧
diskgroup 重建了一次,其中最为关键的file directory元数据没了。这是非常麻烦的一件事。

在恢复的过程中,我们甚至尝试了Oracle DUL,发现file directory完全丢失的情况下,dul根本无法正常工作。当然,

我们利用老熊的ODU成功的恢复了该库。ODU目前有这样的一个强悍功能,可以进行scan asm disk,然后将所有数据文件

的AU分配信息扫描出并记录到一个文件asm_fileext_meta.odu 中,然后可以自动的将AU进行拼接,也就形成了一个完整

的数据文件,大致的语法如下:

备注:
1.   第一次使用抽取文件的方式进行了恢复,由于数据字典损坏严重,导致数据库open后问题不断(其中还修复了
大量的block,因为部分block是空的,空块是因为部分disk完成了reblance,部分没有,导致抽取的数据字典不完整),
因此我们又重新抽取了一次数据,并重建库导入,前后花费了大量的人力,当然这也是我第一次利用ODU
恢复ERP库,并完美的解决问题。 这里必须赞一个!

 

Oracle数据恢复:Oracle RAC系统Redo/Undo损坏恢复

昨天,一个客户的数据库系统出现故障,RAC无法启动,大量的错误信息,经过分析检查,最后我们通过强制手段打开数据库,帮助用户挽回了数据损失。

故障的起因应该是主机和存储之间出现连接故障,message信息里可以看到大量如下提示:

Jun  1 19:57:18 Oracle-02 kernel: end_request: I/O error, dev sdb, sector 12931135
Jun  1 19:57:18 Oracle-02 kernel: sd 6:0:0:1: Device not ready: <6>: Current: sense key: Not Ready
Jun  1 19:57:18 Oracle-02 kernel:     Add. Sense: Logical unit not accessible, asymmetric access state transition
Jun  1 19:57:18 Oracle-02 kernel:
Jun  1 19:57:18 Oracle-02 kernel: end_request: I/O error, dev sdb, sector 12931647
Jun  1 19:57:18 Oracle-02 kernel: sd 6:0:0:1: Device not ready: <6>: Current: sense key: Not Ready
Jun  1 19:57:18 Oracle-02 kernel:     Add. Sense: Logical unit not accessible, asymmetric access state transition
Jun  1 19:57:18 Oracle-02 kernel:
Jun  1 19:57:18 Oracle-02 kernel: end_request: I/O error, dev sdb, sector 12932671
Jun  1 19:57:18 Oracle-02 kernel: sd 6:0:0:1: Device not ready: <6>: Current: sense key: Not Ready
Jun  1 19:57:18 Oracle-02 kernel:     Add. Sense: Logical unit not accessible, asymmetric access state transition

一旦出现IO写失败或者写丢失,则数据库将遭受数据损失,一旦UNDO和REDO损坏,数据库就将会无法启动。

在数据库的告警日志层面,首先出现的错误是如下类型:

WARNING: Read Failed. group:3 disk:0 AU:102 offset:16384 size:16384
WARNING: failed to read mirror side 1 of virtual extent 0 logical extent 0 of file 256 in group [3.3870646521] from disk REDO1  allocation unit 102 reason error; if possible,will try another mirror side
WARNING: Read Failed. group:3 disk:0 AU:102 offset:16384 size:16384
WARNING: failed to read mirror side 1 of virtual extent 0 logical extent 0 of file 256 in group [3.3870646521] from disk REDO1  allocation unit 102 reason error; if possible,will try another mirror side

这些错误首先提示REDO写操作失败,读写AU单位失败,这类错误信息教Oracle 11gR2之前详细了很多,精确到了AU单位及Offset。

在启动过程中出现了ORA-00600错误:

ARC0: STARTING ARCH PROCESSES COMPLETE
Redo thread 2 internally disabled at seq 1 (CKPT)
ARC2: Archiving disabled thread 2 sequence 1
Archived Log entry 785 added for thread 2 sequence 1 ID 0x0 dest 1:
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Errors in file /oracle/diag/rdbms/spsp/SPSP1/trace/SPSP1_ora_19044.trc:
ORA-00600: internal error code, arguments: [2662], [0], [7291890], [0], [7314785], [12583040], [], [], [], [], [], []
Errors in file /oracle/diag/rdbms/spsp/SPSP1/trace/SPSP1_ora_19044.trc:
ORA-00600: internal error code, arguments: [2662], [0], [7291890], [0], [7314785], [12583040], [], [], [], [], [], []

Errors in file /oracle/diag/rdbms/spsp/SPSP2/trace/SPSP2_smon_14335.trc  (incident=291384):
ORA-00600: internal error code, arguments: [4194], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /oracle/diag/rdbms/spsp/SPSP2/incident/incdir_291384/SPSP2_smon_14335_i291384.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.

注意Oracle 11gR2的提示,非常详尽,居然提示你通过My Oracle Support去参考 Note 411.1 学习ADRCI知识。

ORA-600的 4193 和 4194 错误,可以通过重建回滚表空间解决。
此处需要提醒的是,Oracle 11g的缺省UNDO段命名,增加了一个Unix Time的时间戳在回滚段名称里,如下所示:

SQL> select * from v$rollname;

USN NAME
———- ——————————
0 SYSTEM
31 _SYSSMU31_1012201531$
32 _SYSSMU32_3505455792$
33 _SYSSMU33_760762808$
34 _SYSSMU34_2022544229$
35 _SYSSMU35_774751923$
36 _SYSSMU36_3132287946$
37 _SYSSMU37_1634453262$
38 _SYSSMU38_1341527290$
39 _SYSSMU39_2970077311$
40 _SYSSMU40_1403026629$

在设置初始化参数时大致设置如下:

  _allow_resetlogs_corruption= TRUE
_offline_rollback_segments= “_SYSSMU11_1202330240$”
_offline_rollback_segments= “_SYSSMU12_1617713323$”
_offline_rollback_segments= “_SYSSMU13_1359816937$”
_offline_rollback_segments= “_SYSSMU14_2078039711$”
_offline_rollback_segments= “_SYSSMU15_1538259293$”
_offline_rollback_segments= “_SYSSMU16_3126366281$”
_offline_rollback_segments= “_SYSSMU17_2553547900$”
_offline_rollback_segments= “_SYSSMU18_1481844821$”
_offline_rollback_segments= “_SYSSMU19_135756661$”
_offline_rollback_segments= “_SYSSMU20_2322289537$”
_corrupted_rollback_segments= “_SYSSMU11_1202330240$”
_corrupted_rollback_segments= “_SYSSMU12_1617713323$”
_corrupted_rollback_segments= “_SYSSMU13_1359816937$”
_corrupted_rollback_segments= “_SYSSMU14_2078039711$”
_corrupted_rollback_segments= “_SYSSMU15_1538259293$”
_corrupted_rollback_segments= “_SYSSMU16_3126366281$”
_corrupted_rollback_segments= “_SYSSMU17_2553547900$”
_corrupted_rollback_segments= “_SYSSMU18_1481844821$”
_corrupted_rollback_segments= “_SYSSMU19_135756661$”
_corrupted_rollback_segments= “_SYSSMU20_2322289537$”

屏蔽了事务的回滚与重做之后,数据库被成功打开。

SQL> select * from v$version;

BANNER
——————————————————————————–
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 – 64bit Production
PL/SQL Release 11.2.0.2.0 – Production
CORE    11.2.0.2.0      Production
TNS for Linux: Version 11.2.0.2.0 – Production
NLSRTL Version 11.2.0.2.0 – Production

数据库风险随时可能发生,备份必不可少啊

Oracle数据恢复:格式化,Raid损坏,文件覆盖恢复

最近接触了几则客户的Oracle数据库恢复案例,记录一下供大家参考。

案例一
某客户为了重新部署系统,将数据导出备份到移动硬盘,然后将Raid重新格式化,重新安装系统,当进行Oracle数据库重建,导入数据时发现,移动硬盘上的数据无法正确读取,文件缺失一半。数据灾难形成。

导入数据时出现 IMP-00009 错误,和以下文章描述的状况是相同的:
http://www.eygle.com/archives/2009/05/imp_00009_abnormal_end.html

我到现场进行分析,发现文件的确只复制了一半,丢失了大约200张数据表的数据。通过备份恢复数据已经不可能。
最后只有一种方式,就是从被格式化的硬盘上进行碎片重组,找回数据,最终这条路成功了,通过硬盘恢复找回数据恢复了业务运行。

这个案例给我们的提示是:重要数据,备份需要多留拷贝,在进行备份验证之前,备份的可靠性不能轻信。

案例二:
某用户,SUN的存储阵列,已经持续运行了7年,最后存储的Raid中,同时损坏了两块硬盘,热备盘早已损坏,但是由于存储所有的绿灯都亮,用户一直以为存储正常无故障运行。

此次故障出现,存储罢工,数据库服务无法提供,用户没有备份。

我们到现场,只有一个途径,就是通过存储级别恢复数据,找回文件,虽然磁盘出现故障,但是数据仍然是完好的,通过计算奇偶校验,回复数据,然后最终修复启动了数据库,在数据库级别存在坏块,不一致,通过BBED,隐含参数等,可以成功打开数据库。

这个案例给我们的提示是:硬件和人一样,过劳都会出现灾难,请大家注意健康。

在微博上,有朋友说,硬件总会出问题,要多监控就应当能够及时预警,我的观点是:
再严密的部门,再严密的监控,总有疏忽,这样的疏忽,有很多大牛的公司都犯过,我们也经历过,所以大家应当共同警示吧。细心多一万分不多,粗心就一次致命。

案例三
某用户,构建大型的ERP系统,在部署初始化环境时,由于疏忽,在安装数据库时,覆盖了原有的一个重要数据库。形成数据灾难。

对于这类操作,通常覆盖的只是SYSTEM表空间、UNDO表空间、Users表空间等,数据表空间通常不会覆盖,但是如果数据结构复杂,通过DUL等工具去抽取数据会根本不可实现。

如果你正好遇到类似严重故障,那么请第一时间联系我们

Oracle数据恢复:文件 数据错误(循环冗余检查) 恢复案例

前一段在某客户的系统中,就遇到了硬盘故障导致的数据库问题,仅仅是一个扇区损坏,碰巧位于数据文件上,就导致了如下错误:

Mon Jun 13 09:14:10 2011
Errors in file f:\oracle\admin\yydb\udump\yydb1_ora_3960.trc:
ORA-01110: 数据文件 11: ‘F:\ORACLE\ORADATA\YYDB\NDNS001.ORA’
ORA-01115: 从文件 11 读取块时出现 IO 错误 (块 # 1)
ORA-27070: skgfdisp: 异步读取/写入失败
OSD-04016: 异步 I/O 请求排队时出错。
O/S-Error: (OS 23) 数据错误(循环冗余检查)。
ORA-01113: 文件 1 需要介质恢复
ORA-01110: 数据文件 1: ‘F:\ORACLE\ORADATA\YYDB\SYSTEM01.DBF’

当从系统访问文件时,出现”循环冗余检查”,无法读取和复制文件,数据库也无法访问该文件,数据库使用受损,导致了严重的业务故障。
在这种情况下,通常的手段就无能为力了,然后我们可以通过DD等工具,将该文件完好的部分DD出来,还原成一个独立的文件或文件碎片,然后修复该文件,可以完成数据恢复。

在这个案例中,坏块位于数据文件头部,我们复制了其他部分之后,使用BBED修复了数据文件头块(Header Block)就完成了数据恢复。

这是一则非常幸运的恢复,但是事故总是警告我们:备份不可一日或缺。

Oracle数据恢复:SYSTEM回滚段损坏案例一则

前一段时间,接收到一次用户报告,用户因为断电导致了数据库故障.启动时遇到了01555的错误.
通常ORA-01555错误并不可怕,但是如果出现在SYSTEM回滚段上,则问题就严重了,因为SYSTEM回滚段无法Offline,也无法重建.以下是错误的主要信息:
Thu Jul 07 15:18:20 CST 2011
ARC0: LGWR is actively archiving destination LOG_ARCHIVE_DEST_2
Thu Jul 07 15:18:20 CST 2011
ORA-01555 caused by SQL statement below (SQL ID: 7bd391hat42zk, Query Duration=0 sec, SCN: 0x000a.79ed044d):
Thu Jul 07 15:18:20 CST 2011
select /*+ rule */ name,file#,block#,status$,user#,undosqn,xactsqn,scnbas,scnwrp,DECODE(inst#,0,NULL,inst#),ts#,spare1 from undo$ where us#=:1
Thu Jul 07 15:18:20 CST 2011
Errors in file /home/oracle/oracle/admin/EDB01/udump/edb01_ora_1208.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 0 with name “SYSTEM” too small
Error 604 happened during db open, shutting down database
USER: terminating instance due to error 604
Instance terminated by USER, pid = 1208
ORA-1092 signalled during: alter database open…
注意,以下一段SQL非常著名:
select /*+ rule */ name,file#,block#,status$,user#,undosqn,xactsqn,scnbas,scnwrp,DECODE(inst#,0,NULL,inst#),ts#,spare1 from undo$ where us#=:1
这是启动过程中对于undo$的递归读取,获得其中的回滚段信息.如果某个回滚段上存在活动事务,则该事务必须被读取回滚,以便保证事务的一致性.
以下是Oracle 9i的SYSTEM回滚段空间分配,通常这些数据块损坏会非常复杂:
SQL> select segment_name,block_id,blocks from dba_extents where segment_name=’SYSTEM’;
SEGMENT_NAME                     BLOCK_ID     BLOCKS
—————————— ———- ———-
SYSTEM                                  9          8
SYSTEM                                 17          8
SYSTEM                                385          8
SYSTEM                                393          8
SYSTEM                                401          8
SYSTEM                                409          8
对于SYSTEM回滚段,其为Oracle数据库第一个创建的回滚段,主要用于数据库的内部事务或SYS的事务信息记录。如果数据库创建了其他用户的回滚段,则SYSTEM回滚段将近用于UNDO$的信息记录,这也是为什么在出现问题时,我们看到的是在undo$读取时抛出的异常。
在sql.bsq文件中,记录了数据库创建第一个步骤中的SYSTEM回滚段信息:
create tablespace SYSTEM datafile “D_DBFN”
  “D_DSTG” online
/
create rollback segment SYSTEM tablespace SYSTEM
  storage (initial 50K next 50K)
/
系统回滚段的作用如下:
When a database is first created using the CREATE DATABASE command, only a single rollback segment is created.
This is the system rollback segment and it is created in the system tablespace.
The system rollback segment has one basic difference from any other rollback segment, including any other rollback segments that are created in the system tablespace.
This difference is that the system rollback segment can only be used for transactions that occur on objects inside the system tablespace.
This is done because the main purpose of the system rollback segment is to handle rollback for DDL transactions – that is transactions against the data dictionary tables themselves.  Making the system rollback usable only for the system tablespace was simply an easy way to enforce that.
It is possible for the system rollback segment to be used for non-data dictionary tables, but only if those tables are created inside the system tablespace (which is very bad development practice).
Steve对此的重要注解
When other rollback segments are available, the SYSTEM rollback segment is only used for the changes to UNDO$ associated with bringing other rollback segments online, or taking them offline.
至于SYSTEM回滚段损坏,你最好有备份,否则就只能通过BBED去修改相关的数据块。我们处理过类似大量案例。如果你正好遇到类似问题,那么请直接联系我们.

数据恢复:ORA-600 kccpb_sanity_check_2解决

最近在客户的数据库恢复中再次遇到了ORA-00600 kccpb_sanity_check_2错误,这个错误是因为控制文件不一致导致的。

出现这个错误时,数据库将无法Mount挂载,影响数据库服务。
这个错误,多数是因为存储故障,丢失了数据写。

Oracle对此错误的解释是:

[kccpb_sanity_check_2] indicates that the seq# of the last read block is higher than the seq# of the control file header block. This is indication of the lost write of the header block during commit of the previous cf transaction.

其解释是:kccpb_sanity_check_2 表示最后读取的控制文件块其 seq# 控制序列号大于控制文件头块的 seq# ,这是不应该出现的情况。这说明在最后执行提交的控制文件事务(CF Transaction)中,对于头块的写入丢失了

这个错误如果只是存在于控制文件上,可以通过重建控制文件来解决,毫无疑问,这是最为简单的处理方式。
如果有备份,也可以从备份中恢复完好的控制文件,但是重建通常是很快捷的方式。

以下是一些错误的记录:

Fri Jan 16 10:47:45 2009
alter database mount
Fri Jan 16 10:47:50 2009
Errors in file /u01/app/oracle/admin/SZFDB/udump/szfdb_ora_7805.trc:
ORA-00600: internal error code, arguments: [kccpb_sanity_check_2], [1449], [1448], [0x000000000], [], [], [], []
Fri Jan 16 10:47:51 2009
ORA-600 signalled during: alter database mount…
Fri Jan 16 10:58:50 2009
alter database mount
Fri Jan 16 10:58:54 2009
Errors in file /u01/app/oracle/admin/SZFDB/udump/szfdb_ora_9233.trc:
ORA-00600: internal error code, arguments: [kccpb_sanity_check_2], [1449], [1448], [0x000000000], [], [], [], []

案例二:

Mon Aug 27 19:15:26 2007
ORACLE V10.2.0.1.0 – Production vsnsta=0
vsnsql=14 vsnxtr=3
Windows Server 2003 Version V5.2 Service Pack 2
CPU                 : 2 – type 586, 2 Physical Cores
Process Affinity    : 0x00000000
Memory (Avail/Total): Ph:2673M/3035M, Ph+PgF:4701M/4926M, VA:1938M/2047M
Mon Aug 27 19:15:26 2007
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Mon Aug 27 19:15:37 2007
Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on.
IMODE=BR
ILAT =18
LICENSE_MAX_USERS = 0
SYS auditing is disabled
ksdpec: called for event 13740 prior to event group initialization
Starting up ORACLE RDBMS Version: 10.2.0.1.0.
System parameters with non-default values:
processes                = 150
__shared_pool_size       = 230686720
__large_pool_size        = 4194304
__java_pool_size         = 4194304
__streams_pool_size      = 0
sga_target               = 612368384
control_files            = E:\DB_SERVER_GROUP\ORACLE\PRODUCT\10.2.0\ORADATA\ADB\CONTROLFILE\O1_MF_3B37YF0H_.CTL, E:\DB_SERVER_GROUP\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ADB\CONTROLFILE\O1_MF_3B37YF8S_.CTL
db_block_size            = 8192
__db_cache_size          = 364904448
compatible               = 10.2.0.1.0
db_file_multiblock_read_count= 16
db_create_file_dest      = E:\DB_Server_Group\Oracle\product\10.2.0\oradata
db_recovery_file_dest    = E:\DB_Server_Group\Oracle\product\10.2.0\flash_recovery_area
db_recovery_file_dest_size= 21474836480
undo_management          = AUTO
undo_tablespace          = UNDOTBS1
remote_login_passwordfile= EXCLUSIVE
db_domain                =
dispatchers              = (PROTOCOL=TCP) (SERVICE=adbXDB)
job_queue_processes      = 10
audit_file_dest          = E:\DB_SERVER_GROUP\ORACLE\PRODUCT\10.2.0\ADMIN\ADB\ADUMP
background_dump_dest     = E:\DB_SERVER_GROUP\ORACLE\PRODUCT\10.2.0\ADMIN\ADB\BDUMP
user_dump_dest           = E:\DB_SERVER_GROUP\ORACLE\PRODUCT\10.2.0\ADMIN\ADB\UDUMP
core_dump_dest           = E:\DB_SERVER_GROUP\ORACLE\PRODUCT\10.2.0\ADMIN\ADB\CDUMP
db_name                  = adb
open_cursors             = 300
pga_aggregate_target     = 203423744
PSP0 started with pid=3, OS id=2396
PMON started with pid=2, OS id=2392
MMAN started with pid=4, OS id=2400
DBW0 started with pid=5, OS id=2404
LGWR started with pid=6, OS id=2408
CKPT started with pid=7, OS id=2412
SMON started with pid=8, OS id=2416
RECO started with pid=9, OS id=2420
CJQ0 started with pid=10, OS id=2424
MMON started with pid=11, OS id=2432
Mon Aug 27 19:15:54 2007
starting up 1 dispatcher(s) for network address ‘(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))’…
MMNL started with pid=12, OS id=2444
Mon Aug 27 19:15:54 2007
starting up 1 shared server(s) …
Mon Aug 27 19:16:00 2007
alter database mount exclusive
Mon Aug 27 19:16:07 2007
Errors in file e:\db_server_group\oracle\product\10.2.0\admin\adb\udump\adb_ora_2472.trc:
ORA-00600: internal error code, arguments: [kccpb_sanity_check_2], [1558], [1423], [0x0], [], [], [], []

Mon Aug 27 19:16:40 2007
ORA-600 signalled during: alter database mount exclusive…

适当的备份控制文件的创建语句,在恢复时可能会起到很大的帮助作用。

ORA-00600 kclchkblk_4 错误恢复案例一则

最近客户在恢复数据库时遇到了ORA-600 kclchkblk_4错误,这个错误在MOS上有官方的解释和解决方案。

在以下错误提示下:

Errors in file /u01/app/oracle/admin/orcl/bdump/orcl_smon_7493.trc:
ORA-600: internal error code, arguments: [kclchkblk_4], [1904],[18446744073431179384], [1904],18446744073403569507], [], [], []

Starting background process QMNC
QMNC started with pid=24, OS id=8329

Errors in file /u01/app/oracle/admin/orcl/bdump/orcl_smon_7493.trc:
ORA-600: internal error code, arguments: [2662], [1904], [3988985522],[1904], [4016595064], [8388610], [], []

Errors in file /u01/app/oracle/admin/orcl/bdump/orcl_smon_7493.trc:
ORA-600: internal error code, arguments: [2662], [1904], [3988985525],[1904], [4016595064], [8388610], [], []
SMON: terminating instance due to error 474
Instance terminated by SMON, pid = 7493

其问题,可能是由于临时表空间的SCN问题导致的,可以尝试删除所有的临时文件,启动数据库,通常可能正常启动。
可能的采取步骤是,在Mount状态下确定并删除临时文件:

    SQL>select file_name, file_id from dba_temp_files;
SQL>alter database tempfile_name drop;
SQL>alter tablespace add tempfile size N;

如果数据库能够成功启动,可以重建临时文件。

顺便引用一下ITPUB上一个朋友的帖子供参考: http://www.itpub.net/thread-1404451-1-1.html

问题描述:
服务器突然故障死机,导致数据库无法驱动,redo的CURRENT组的损坏。oracle 10g rac环境,asm磁盘组,redhat linux系统。每个组一个成员这个是组被破坏无法修复的关键。
没有归档,没有备份。使用ASM无法将数据文件冷备份出来。

ORA-00368: checksum error in redo log block
ORA-00353: log corruption near block 254606 change 12131176305969 time 03/08/2011 01:03:00
ORA-00312: online log 2 thread 1: ‘+DG1/police/onlinelog/group_2.258.657430669’

查看日志组文件信息,报错的日志组为CURRENT模式。

SQL> select group#,sequence#,archived,status from v$log;

GROUP#  SEQUENCE# ARC STATUS
———- ———- — —————-
1      17495 NO  INACTIVE
2      17496 NO  CURRENT
3      17365 NO  INACTIVE
4      17366 NO  CURRENT

组成员只有一个。

SQL>

Group   Instance             Member             STATUS             Size(MB)
———- ———- —————————— —————- ———-
1          1 +DG1/police/onlinelog/group_1. INACTIVE                500
257.657430665

2          1 +DG1/police/onlinelog/group_2. CURRENT                 500
258.657430669

3          2 +DG1/police/onlinelog/group_3. INACTIVE                500
265.657431819

4          2 +DG1/police/onlinelog/group_4. CURRENT                 500
266.657431825

无法使用clear命令清楚redo的信息

SQL> alter database clear unarchived logfile group 2
2  ;
alter database clear unarchived logfile group 2
*
ERROR at line 1:
ORA-01624: log 2 needed for crash recovery of instance police1 (thread 1)
ORA-00312: online log 2 thread 1: ‘+DG1/police/onlinelog/group_2.258.657430669’

SQL> alter database clear logfile group 2;
alter database clear logfile group 2
*
ERROR at line 1:
ORA-01624: log 2 needed for crash recovery of instance police1 (thread 1)
ORA-00312: online log 2 thread 1: ‘+DG1/police/onlinelog/group_2.258.657430669’

处理步骤

把数据库down掉

   SQL>shutdown immediate

5、在init<sid>.ora中加入如下参数

_allow_resetlogs_corruption=TRUE

6、重新启动数据库,利用until cancel恢复

SQL>recover database until cancel;
Cancel

如果出错,不再理会,发出

SQL>alter database open resetlogs;

如果运气好的话可以正常启动数据库,就可以导出数据了。但是这里有点意外不知道是点背还是rac环境的恢复比较特殊。在alert.log中有如下报错:

Errors in file /u01/app/oracle/admin/police/bdump/police2_j003_17720.trc:
ORA-00600: internal error code, arguments: [4194], [9], [8], [], [], [], [], []
Wed Mar  9 18:08:06 2011
Errors in file /u01/app/oracle/admin/police/bdump/police2_j004_17722.trc:
ORA-00600: internal error code, arguments: [4193], [55749], [55753], [], [], [], [], []
Wed Mar  9 18:08:08 2011
Errors in file /u01/app/oracle/admin/police/bdump/police2_mmon_11328.trc:
ORA-00600: internal error code, arguments: [4194], [12], [17], [], [], [], [], []
Wed Mar  9 18:08:08 2011
Errors in file /u01/app/oracle/admin/police/bdump/police2_j002_17718.trc:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [0], [0], [1], [], [], [], []

能后我就重复启动数据库这个错误就过去了,网上有一篇文档是这么说的,真的可以过去,不过我是将两个节点都同时启动的时候过去的,但是在开始出现如下错误:
ORA-600[KCLCHKBLK_4]【2824】,但是没有出现ORA-600[2662]的报错,不知道为什么,有人说是temp文件不一致造成,但是别人都有2662的报错我这里没有,不管了先将temp删了在说。

能后速度将temp删除,能后发现问题依旧。当时我就很失望了,情绪低落。这个报错在网上的解决办法只有这一个。也没有什么人有更好的建议。
ORA-00600: internal error code, arguments: [kclchkblk_4], [2824], [18446744071603238605], [2824], [18446744071593491338], [], [], []
Wed Mar  9 14:29:55 2011
Errors in file /u01/app/oracle/admin/police/udump/police1_ora_27660.trc:
ORA-00600: internal error code, arguments: [kclchkblk_4], [2824], [18446744071603238605], [2824], [18446744071593491338], [], [], []
Wed Mar  9 14:29:55 2011
Error 600 happened during db open, shutting down database
USER: terminating instance due to error 600

但是仔细观察后我发现18446744071593491338这个数据有问题,它在我每次重新启动数据库的时候会和前面的数值有所改变18446744071593491338,我的目标就是将
这个数值尽量的缩小和18446744071603238605的值,重复几遍后发现使用srvctl start database -d sid数据库会自动重启多次,我就不停地启动关闭。有希望了两个者还是相差太大,
这一步我们在这里卡了很久。这里有一个scn的问题,我这里碰到的是后面的比前面的低,所以adjust_scn没有效果。
无赖我将_allow_resetlogs_corruption=TRUE增加到spfile中让数据库同时启动。结果发现错误改变了,后来想想估计是要将参数添加到spfile中同时启动数据库才有效果,因为我单独启动数据库的时候效果不大。

Errors in file /u01/app/oracle/admin/police/bdump/police2_smon_11322.trc:
ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], []
Wed Mar  9 18:08:35 2011
ORACLE Instance police2 (pid = 16) – Error 600 encountered while recovering transaction (9, 46).
Wed Mar  9 18:08:35 2011
Errors in file /u01/app/oracle/admin/police/bdump/police2_smon_11322.trc:
ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], []
Wed Mar  9 18:08:35 2011
Trace dumping is performing id=[cdmp_20110309180835]
Wed Mar  9 18:08:37 2011
Errors in file /u01/app/oracle/admin/police/bdump/police2_smon_11322.trc:
ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], []
Errors in file /u01/app/oracle/admin/police/bdump/police2_p007_19333.trc:
ORA-00600: internal error code, arguments: [4198], [9], [], [], [], [], [], []

出现了这些报错,现在好了,4137,4138 ,4139不都是undo的报错吧,
新建立两个undo,修改spfile使用新的undo启动,删除旧的undo。
添加spfile参数

_allow_resetlogs_corruption”=true ”
_allow_terminal_recovery_corruption”=true
_corrupted_rollback_segments =’_SYSSMU1$’,’_SYSSMU2$’,’_SYSSMU3$’

如果不能确定多少个,但是我在删除UNDO的时候提示_SYSSMU2无法删除,我还是坚持加到了20个,后来我查了一下一共有400多个还好没有每个都坏掉。
修改undo_management 这个参数
把参数文件中的undo_management 改为MANUAL

SQL> create undo tablespace undotbs3 datafile ‘/opt/oracle/oradata/conner/undotbs3.dbf’ size 10M;
Tablespace created.
SQL> alter system set undo_tablespace=undotbs1 scope=spfile sid=’sid’;
System altered.
SQL> drop tablespace undotbs2;
Tablespace dropped.

将两个节点的undo都替换后发现数据库可以起来了,但还是有报错,

Errors in file /u01/app/oracle/admin/police/bdump/police2_j000_7977.trc:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [0], [0], [1], [], [], [], []
Wed Mar  9 23:56:10 2011

但还好可以exp数据了。

导出数据后,删除数据库,删除asm,
关闭第二台的asm实例,
登入第一台asm

SQL> select name from v$asm_diskgroup;
NAME
——————————
DG1
SQL> drop diskgroup DG1 including contents;       –>删除磁盘组
SQL>SHUTDOWN IMMEDIATE

最后
crs_unregister ora.node1.ASM1.asm
crs_unregister ora.node1.ASM1.asm(后来极度后悔,应该在unregister前备份一下就好了)
在dbs和admin下删除asm相关文档
修改/etc/oratab文件将asm的注释。
dbca重新建立asm磁盘发现asm实例无法启动晕倒。好像是出现prks-1011,和ora-0210的报错
使用srvctl add asm -n node1 -i +ASM1 -o $ORACLE_HOME -p init+ASM1.ora
提示ora.node1.ASM1.asm服务已经存在了,但是crs_stat -t查看又没有ora.node1.ASM1.asm服务。
于是我使用crs_register ora.node1.ASM1.asm的时候提示找不到 ora.node1.ASM1.asm.cap的文件(这里折腾了一段时间)
没法我从别的rac上使用crs_stat -p ora.node1.ASM1.asm > ora.node1.ASM1.asm.cap导出了一份拷贝到提示的目录下,并且修改了文件中的主机信息等。
在使用crs_register ora.node1.ASM1.asm就注册成功了。其实 ora.node1.ASM1.asm.cap这个文件的东西和 ora.node1.lsnr的文件内容一样。就是有些东西自己动手修改一下就可以替代了。
重新建库导入文件
艰苦的数据恢复终于完成了。

ORA-600 2252 错误与SCN的一致性

当数据库系统的时间被调整,回到历史状态时,数据库可能出现ORA-600 2252错误。

这个错误指,数据库的SCN被认为是错误和不合理的,Oracle内部控制每秒产生的SCN数量小于 16K 个,然后以1988年1月1日,0点0分0秒开始,可以计算出一个SCN可能的合理最大值。

如果当前SCN的指标超过了这个合理值,则系统就会出现ORA-600 2252错误。
这类错误的错误号可能类似如下:

Mon May 14 17:55:54 2012
Errors in file /t3/orat3/product/admin/ora1020410/bdump/ora1020410_mmon_25386.trc:
ORA-00600: internal error code, arguments: [2252], [2988], [9], [], [], [], [], []
Mon May 14 17:56:06 2012
Errors in file /t3/orat3/product/admin/ora1020410/bdump/ora1020410_smon_23805.trc:
ORA-00600: internal error code, arguments: [2252], [2988], [13], [], [], [], [], []
Mon May 14 17:56:06 2012
Non-fatal internal error happenned while SMON was doing extent coalescing.
SMON encountered 1 out of maximum 100 non-fatal internal errors.
Mon May 14 17:56:07 2012
Errors in file /t3/orat3/product/admin/ora1020410/bdump/ora1020410_smon_23805.trc:
ORA-00600: internal error code, arguments: [2252], [2988], [13], [], [], [], [], []
Non-fatal internal error happenned while SMON was doing extent coalescing.
SMON encountered 2 out of maximum 100 non-fatal internal errors.
Mon May 14 17:56:09 2012
Errors in file /t3/orat3/product/admin/ora1020410/bdump/ora1020410_smon_23805.trc:
ORA-00600: internal error code, arguments: [2252], [2988], [14], [], [], [], [], []
Non-fatal internal error happenned while SMON was doing extent coalescing.
SMON encountered 3 out of maximum 100 non-fatal internal errors.
Mon May 14 17:56:10 2012
Errors in file /t3/orat3/product/admin/ora1020410/bdump/ora1020410_smon_23805.trc:
ORA-00600: internal error code, arguments: [2252], [2988], [14], [], [], [], [], []
Non-fatal internal error happenned while SMON was doing extent coalescing.
SMON encountered 4 out of maximum 100 non-fatal internal errors.
Mon May 14 17:56:11 2012
Errors in file /t3/orat3/product/admin/ora1020410/bdump/ora1020410_smon_23805.trc:
ORA-00600: internal error code, arguments: [2252], [2988], [15], [], [], [], [], []
Non-fatal internal error happenned while SMON was doing extent coalescing.
SMON encountered 5 out of maximum 100 non-fatal internal errors.

如果确实因为调整系统时间导致,则可以将时间调整回正确日期,如果系统SCN真的非法跃迁,则可以等候一定时间,等候SCN合理值可以容纳该跃迁或不一致。