Oracle 重建控制文件和undo损坏的处理

设为首页加入收藏

三通it学院：www.santongit.com

聚焦: 网络技术-思科华为 H3C Juniper 编程开发-软件 Web 移动项目 H3C 华为虚拟化 Juniper

生活: 数据库 Oracle MySQL 服务器 Linux Windows MySQL Linux 微软 IBM Oracle Windows

休闲: 云计算大数据 Hadooop OpenStack Spark 虚拟化 Vmware Citrix F5负载均衡 Docker Vmware Hadooop OpenStack Citrix F5负载均衡 Docker

分类: 软考等考美图美工网络营销 Office

三通IT学院 › 门户 ›技术频道› 数据库 › 查看内容

2014-8-20 15:07

Oracle 重建控制文件和undo损坏的处理

摘要 : 由于服务器死机，只能重启服务器，重启服务器后启动数据库无法启动报如下错误： alter database mount Errors in file /u01/app/oracle/admin/SZXDB/udump/szxdb_ora_9233.trc: ORA-00600: internal error code, ...

时光与梦2014-8-20 15:0774528

原作者: Liuxuebo

由于服务器死机，只能重启服务器，重启服务器后启动数据库无法启动报如下错误：
alter database mount
Errors in file /u01/app/oracle/admin/SZXDB/udump/szxdb_ora_9233.trc:
ORA-00600: internal error code, arguments: [kccpb_sanity_check_2], [1449], [1448], [0x000000000], [], [], []
在数据库进行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）中，对于头块的写入丢失了。
这个错误如果只是存在于控制文件上，可以通过重建控制文件来解决，毫无疑问，这是最为简单的处理方式。
如果有备份，也可以从备份中恢复完好的控制文件，但是重建通常是很快捷的方式。
因为没有备份只能重建控制文件

因为数据库无法mount  所以控制文件无法进行trace  只能手写创建控制文件的SQL
CREATE CONTROLFILE REUSE DATABASE "sxzdb" NORESETLOGS
  DATAFILE
'/oracle/oradata/system01.dbf',
'/oracle/oradata/undotbs01.dbf',
'/oracle/oradata/sysaux01.dbf',
'/oracle/oradata/users01.dbf',
'/oracle/oradata/tbsaddm.dbf'
  NOARCHIVELOG
  MAXLOGFILES 16
  MAXLOGMEMBERS 3
  MAXDATAFILES 100
  MAXINSTANCES 8
  MAXLOGHISTORY 292
  LOGFILE
GROUP 1 'oracle/oradata/szxdb/redo01.log',
GROUP 2 'oracle/oradata/szxdb/redo02.log',
GROUP 3 'oracle/oradata/szxdb/redo03.log'
CHARACTER SET GBK；