标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 obet ORA-00312 ORA-00704 ORA-00742 ORA-01110 ORA-01200 ORA-01555 ORA-01578 ORA-01595 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-600 kcratr_nab_less_than_odr ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 ORACLE恢复 Oracle 恢复 ORACLE数据库恢复 oracle碎片 OSD-04016 YOUR FILES ARE ENCRYPTED 比特币加密文章分类
- MongoDB (1)
- MongoDB恢复 (1)
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (112)
- 数据库 (1,880)
- DB2 (22)
- MySQL (82)
- Oracle (1,705)
- Data Guard (53)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (168)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (72)
- Oracle Bug (8)
- Oracle RAC (56)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (659)
- Oracle安装升级 (108)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (91)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (5)
- 达梦恢复 (3)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (51)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (34)
- MongoDB (1)
-
最近发表
- Firebird 损坏数据库数据抢救工具—firebirdext
- Oracle 19c 202610补丁(RUs+OJVM)-19.33
- 由于con$.con#值达到极限,触发数据库增加约束报ORA-600 12807错误
- MongoDB 离线提取工具—mongoext
- .bres勒索病毒加密数据库dmp文件可恢复
- ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch
- 记录一次0丢失的ORA-00354: 损坏重做日志块标头故障恢复
- 不当数据库恢复操作导致一个月数据丢失
- obet快速修复oracle 位图损坏块
- 不太常见的10.2.0.1的oracle redo损坏恢复
- obet forcecopy功能抢救硬件故障中的数据文件
- kcratr_nab_less_than_odr和system坏块故障处理
- 通过obet 恢复system坏块,打开数据库
- obet dbv功能完整说明
- 分享一例运行在aix上的sap系统数据库恢复过程
- OBET-Oracle Block Editor Tool使用说明
- 几乎动用了所有手段的Oracle故障恢复
- Oracle Block Edit Tool (obet) 功能增强–2026.07
- Oracle 19c 202607补丁(RUs+OJVM)-19.32
- Patch_SCN快速修复ORA-01555数据库open故障
分类目录归档:Oracle备份恢复
ORA-600 2663 故障恢复
朋友数据库启动遭遇ORA-00600[2663]
Mon Sep 22 19:24:20 2014 Thread 1 advanced to log sequence 17 (thread open) Thread 1 opened at log sequence 17 Current log# 17 seq# 17 mem# 0: /u02/orayali2/redo17.log Successful open of redo thread 1 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Mon Sep 22 19:24:20 2014 SMON: enabling cache recovery Errors in file /u01/app/oracle/diag/rdbms/orayali2/orayali2/trace/orayali2_ora_20722.trc (incident=336180): ORA-00600: internal error code, arguments: [2663], [13], [3140023138], [13], [3141216403], [], [], [], [], [], [], [] Incident details in: /u01/app/oracle/diag/rdbms/orayali2/orayali2/incident/incdir_336180/orayali2_ora_20722_i336180.trc 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 /u01/app/oracle/diag/rdbms/orayali2/orayali2/trace/orayali2_ora_20722.trc: ORA-00600: internal error code, arguments: [2663], [13], [3140023138], [13], [3141216403], [], [], [], [], [], [], [] Errors in file /u01/app/oracle/diag/rdbms/orayali2/orayali2/trace/orayali2_ora_20722.trc: ORA-00600: internal error code, arguments: [2663], [13], [3140023138], [13], [3141216403], [], [], [], [], [], [], [] Error 600 happened during db open, shutting down database USER (ospid: 20722): terminating the instance due to error 600 Instance terminated by USER, pid = 20722 ORA-1092 signalled during: alter database open... opiodr aborting process unknown ospid (20722) as a result of ORA-1092 Mon Sep 22 19:24:24 2014 ORA-1092 : opitsk aborting process
ORA-600[2663]与常见的ORA-600[2662]类似,都是由于block的scn大于文件头的scn导致,只不过错误的对象不一样而已.对于该类问题,我们的处理方法一般就是简单的推scn
[oracle@orayali2 OPatch]$ uname -a Linux orayali2 2.6.32-279.el6.x86_64 #1 SMP Wed Jun 13 18:24:36 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux [oracle@orayali2 OPatch]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.3.0 Production on Mon Sep 22 19:09:18 2014 Copyright (c) 1982, 2011, Oracle. All rights reserved. Connected to an idle instance. SQL> startup mount ORACLE instance started. Total System Global Area 1.6535E+10 bytes Fixed Size 2244792 bytes Variable Size 9898561352 bytes Database Buffers 6610223104 bytes Redo Buffers 24256512 bytes Database mounted. SQL> alter database open; alter database open * ERROR at line 1: ORA-01092: ORACLE instance terminated. Disconnection forced ORA-30012: undo tablespace 'SYSTEM' does not exist or of wrong type Process ID: 21174 Session ID: 1563 Serial number: 3
现在错误已经改变,而是出现了ORA-30012的错误
alter database open Beginning crash recovery of 1 threads parallel recovery started with 31 processes Started redo scan Completed redo scan read 4 KB redo, 0 data blocks need recovery Started redo application at Thread 1: logseq 17, block 2, scn 58974597984 Recovery of Online Redo Log: Thread 1 Group 17 Seq 17 Reading mem 0 Mem# 0: /u02/orayali2/redo17.log Completed redo application of 0.00MB Completed crash recovery at Thread 1: logseq 17, block 3, scn 58974617986 0 data blocks read, 0 data blocks written, 4 redo k-bytes read Mon Sep 22 19:30:05 2014 Thread 1 advanced to log sequence 18 (thread open) Thread 1 opened at log sequence 18 Current log# 18 seq# 18 mem# 0: /u02/orayali2/redo18.log Successful open of redo thread 1 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Mon Sep 22 19:30:05 2014 SMON: enabling cache recovery Undo initialization errored: err:30012 serial:0 start:1143146928 end:1143147338 diff:410 (4 seconds) Errors in file /u01/app/oracle/diag/rdbms/orayali2/orayali2/trace/orayali2_ora_21174.trc: ORA-30012: undo tablespace 'SYSTEM' does not exist or of wrong type Errors in file /u01/app/oracle/diag/rdbms/orayali2/orayali2/trace/orayali2_ora_21174.trc: ORA-30012: undo tablespace 'SYSTEM' does not exist or of wrong type Error 30012 happened during db open, shutting down database USER (ospid: 21174): terminating the instance due to error 30012 Instance terminated by USER, pid = 21174 ORA-1092 signalled during: alter database open... opiodr aborting process unknown ospid (21174) as a result of ORA-1092 Mon Sep 22 19:30:08 2014 ORA-1092 : opitsk aborting process
猜测原因是undo设置有问题导致,检查果然发现undo_management=auto,而undo_tablespace=SYSTEM
SQL> startup mount ORACLE instance started. Total System Global Area 1.6535E+10 bytes Fixed Size 2244792 bytes Variable Size 9898561352 bytes Database Buffers 6610223104 bytes Redo Buffers 24256512 bytes Database mounted. SQL> show parameter undo; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ undo_management string AUTO undo_retention integer 10800 undo_tablespace string SYSTEM SQL> alter system set undo_management=manual scope=spfile; System altered. SQL> shutdown immediate; ORA-01109: database not open Database dismounted. ORACLE instance shut down. SQL> startup ORACLE instance started. Total System Global Area 1.6535E+10 bytes Fixed Size 2244792 bytes Variable Size 9898561352 bytes Database Buffers 6610223104 bytes Redo Buffers 24256512 bytes Database mounted. Database opened.
解决该问题修改undo_management=manual即可
记录一次system表空间坏块(ORA-01578)数据库恢复
半夜朋友打来求救电话,说xx医院his系统因为存储异常导致system坏块无法正常启动,因为是win平台无法使用bbed,无法修复system 坏块,请求技术支持
dbv检查system文件报坏块

对应具体地址为:file 1 block 39041和66738
判断控制文件异常
通过数据库恢复检查脚本(Oracle Database Recovery Check)脚本检测数据库发现控制文件明显异常(checkpoint scn

尝试恢复数据库
因此对该库进行了不完全恢复,然后尝试resetlogs打开数据库,数据库报ORA-600 2662错误
Fri Aug 29 02:35:08 2014 alter database open resetlogs Fri Aug 29 02:35:11 2014 RESETLOGS after complete recovery through change 451371288 Resetting resetlogs activation ID 1232269761 (0x4972f1c1) Fri Aug 29 02:35:15 2014 Setting recovery target incarnation to 3 Fri Aug 29 02:35:15 2014 Assigning activation ID 1384652231 (0x52881dc7) LGWR: STARTING ARCH PROCESSES ARC0 started with pid=17, OS id=1084 Fri Aug 29 02:35:15 2014 ARC0: Archival started ARC1: Archival started LGWR: STARTING ARCH PROCESSES COMPLETE ARC1 started with pid=18, OS id=2836 Fri Aug 29 02:35:15 2014 Thread 1 opened at log sequence 1 Current log# 1 seq# 1 mem# 0: Z:\ORACLE\PRODUCT\10.2.0\ORCL\REDO01.LOG Successful open of redo thread 1 Fri Aug 29 02:35:15 2014 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Fri Aug 29 02:35:15 2014 ARC1: Becoming the 'no FAL' ARCH ARC1: Becoming the 'no SRL' ARCH Fri Aug 29 02:35:15 2014 ARC0: Becoming the heartbeat ARCH Fri Aug 29 02:35:15 2014 SMON: enabling cache recovery Fri Aug 29 02:35:16 2014 Errors in file d:\oracle\product\10.2.0\admin\orcl\udump\orcl_ora_4824.trc: ORA-00600: 内部错误代码, 参数: [2662], [0], [451371311], [0], [451374534], [8388977], [], [] Fri Aug 29 02:35:16 2014 Errors in file d:\oracle\product\10.2.0\admin\orcl\udump\orcl_ora_4824.trc: ORA-00600: 内部错误代码, 参数: [2662], [0], [451371311], [0], [451374534], [8388977], [], [] Fri Aug 29 02:35:16 2014 Error 600 happened during db open, shutting down database USER: terminating instance due to error 600 Fri Aug 29 02:35:17 2014 Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_smon_2928.trc: ORA-00600: ??????, ??: [], [], [], [], [], [], [], [] Instance terminated by USER, pid = 4824 ORA-1092 signalled during: alter database open resetlogs...
ORA-600 2662 该错误解决思路很明显,推进scn,数据库报ORA-01578
Fri Aug 29 02:42:47 2014 SMON: enabling cache recovery Fri Aug 29 02:42:47 2014 Successfully onlined Undo Tablespace 1. Dictionary check beginning Dictionary check complete Fri Aug 29 02:42:49 2014 SMON: enabling tx recovery Fri Aug 29 02:42:49 2014 Database Characterset is ZHS16GBK Opening with internal Resource Manager plan where NUMA PG = 1, CPUs = 16 replication_dependency_tracking turned off (no async multimaster replication found) Fri Aug 29 02:42:50 2014 Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_smon_4804.trc: ORA-00604: 递归 SQL 级别 1 出现错误 ORA-01578: ORACLE 数据块损坏 (文件号 1, 块号 39041) ORA-01110: 数据文件 1: 'Z:\ORACLE\PRODUCT\10.2.0\ORCL\SYSTEM01.DBF' Fri Aug 29 02:42:50 2014 LOGSTDBY: Validating controlfile with logical metadata Fri Aug 29 02:42:51 2014 LOGSTDBY: Validation complete ORA-604 signalled during: alter database open...
对坏块进行处理,启动数据库成功
Fri Aug 29 02:48:59 2014 SMON: enabling cache recovery Fri Aug 29 02:49:00 2014 Successfully onlined Undo Tablespace 1. Fri Aug 29 02:49:00 2014 SMON: enabling tx recovery Fri Aug 29 02:49:00 2014 Database Characterset is ZHS16GBK Opening with internal Resource Manager plan where NUMA PG = 1, CPUs = 16 replication_dependency_tracking turned off (no async multimaster replication found) Starting background process QMNC QMNC started with pid=34, OS id=3096 Fri Aug 29 02:49:01 2014 db_recovery_file_dest_size of 4096 MB is 0.00% used. This is a user-specified limit on the amount of space that will be used by this database for recovery-related files, and does not reflect the amount of space available in the underlying filesystem or ASM diskgroup. Fri Aug 29 02:49:01 2014 Completed: alter database open
查询坏块对象


因为这些对象均不是核心对象,直接进行truncate然后插入老数据
后续还有大量错误修复
ORA-12012: error on auto execute of job 1 ORA-08102: index key not found, obj# 239, file 1, block 1674 (2) ORA-00600: 内部错误代码, 参数: [kcbz_check_objd_typ], [0], [0], [1], [], [], [], [] ORA-00600: internal error code, arguments: [6749], [3], [12606796], [173], [], [], [], [] ORA-00600: 内部错误代码, 参数: [13013], [52898], [52895], [38288618], [44], [38288618], [17], [] ORA-00600: 内部错误代码, 参数: [13013], [5001], [52895], [38286476], [5], [38286476], [17], []
再次说明,很多时候数据库恢复不要看成多神秘,就是几个参数搞定,更加不要神化有坏块就bbed修复,当然非常极端,使用N中工具,N种尝试的也存在.做好备份重于一切
发表在 Oracle备份恢复
标签为 ORA-01578, ORA-600 13011, ORA-600 13013, ORA-600 2662, ORA-600 6749, ORACLE恢复, system坏块
评论关闭
ORACLE 8.1.7 数据库ORA-600 4000故障恢复
在数据库的恢复过程中遇到ORA-600 4000错误挺多的,但是在oracle 8i(8.1.7)中遇到此类问题,还是第一次,做个记忆,供参考:
数据库故障起因:因为存储异常,导致当前redo损坏,并_allow_resetlogs_corruption参数尝试打开数据库
Media Recovery Log kcrrga: Warning. Log sequence in archive filename wrapped to fix length as indicated by %S in LOG_ARCHIVE_FORMAT. Old log archive with same name might be overwritten. ORA-279 signalled during: ALTER DATABASE RECOVER database using backup cont... Wed Aug 20 23:01:43 2014 ALTER DATABASE RECOVER CANCEL Media Recovery Cancelled Completed: ALTER DATABASE RECOVER CANCEL Wed Aug 20 23:01:50 2014 alter database open resetlogs RESETLOGS is being done without consistancy checks. This may result in a corrupted database. The database should be recreated. RESETLOGS after incomplete recovery UNTIL CHANGE 262618871 Wed Aug 20 23:01:50 2014 Thread 1 opened at log sequence 1 Current log# 3 seq# 1 mem# 0: F:\REDO01.LOG Successful open of redo thread 1. Wed Aug 20 23:01:50 2014 SMON: enabling cache recovery Wed Aug 20 23:01:50 2014 Errors in file C:\oracle\admin\YCFD\udump\ORA00320.TRC: ORA-00600: ??????????: [4000], [3], [], [], [], [], [], [] SMON: disabling cache recovery Wed Aug 20 23:01:51 2014 ORA-704 signalled during: alter database open resetlogs
数据库遭遇ORA-600 4000错误,数据库无法打开,分析对应trace日志
Dump file C:\oracle\admin\YCFD\udump\ORA00320.TRC Wed Aug 20 23:01:50 2014 ORACLE V8.1.7.0.0 - Production vsnsta=0 vsnsql=e vsnxtr=3 Windows 2000 Version 5.2 Service Pack 2, CPU type 586 Oracle8i Release 8.1.7.0.0 - Production JServer Release 8.1.7.0.0 - Production Windows 2000 Version 5.2 Service Pack 2, CPU type 586 Instance name: ycfd Redo thread mounted by this instance: 1 Oracle process number: 8 Windows thread id: 320, image: ORACLE.EXE *** SESSION ID:(7.1) 2014-08-20 23:01:50.838 *** 2014-08-20 23:01:50.838 ksedmp: internal or fatal error ORA-00600: ??????????: [4000], [3], [], [], [], [], [], [] Current SQL statement for this session: select ctime, mtime, stime from obj$ where obj# = :1 ----- Call Stack Trace -----
这里可以看出来,是因为数据库在启动之时需要执行select ctime, mtime, stime from obj$ where obj# = :1语句,但是由于每种原因出现ORA-600 4000导致数据库无法正常启动,继续分析日志
lock header dump: 0x0040003e
Object id on Block? Y
seg/obj: 0x12 csc: 0x00.fb5c5c5 itc: 1 flg: - typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01
Itl Xid Uba Flag Lck Scn/Fsc
0x01 xid: 0x0003.012.0002ae94 uba: 0x00801f5b.5389.11 --U- 1 fsc 0x0000.0fb5c5c6
SQL> select checkpoint_change# from v$database;
263570122
此处比较明显,通过xid可以知道三号回滚段中对应一个事务出现问题:
1. 该block为file 1 bock 62,object_id为 18(obj$)上有一个事务
2. 该事务的scn为263,570,886>database scn(263570122)导致该故障发生
3. 当数据库访问到file 1 block 62的时候,发现有一个事务,而该事务的scn大于数据库scn,从而出现ORA-600[4000]
解决该问题有几种方法
1. 修改block 62,人工提交该事务
2. 修改数据库scn,让数据库scn大于itl scn
解决block 62 事务问题后出现如下错误
Wed Aug 20 23:03:55 2014 SMON: enabling cache recovery Wed Aug 20 23:03:55 2014 Dictionary check beginning Dictionary check complete Wed Aug 20 23:03:55 2014 SMON: enabling tx recovery Wed Aug 20 23:03:56 2014 Errors in file C:\oracle\admin\YCFD\bdump\ycfdSMON.TRC: ORA-00600: internal error code, arguments: [4193], [21173], [21181], [], [], [], [], [] Recovery of Online Redo Log: Thread 1 Group 1 Seq 2 Reading mem 0 Mem# 0 errs 0: F:\REDO03.LOG SMON: terminating instance due to error 600 Instance terminated by SMON, pid = 2468
数据库出现ORA-600 4193,这个是常见错误,因为redo记录和undo记录不匹配导致,可以直接使用_corrupted_rollback_segments/_offline_rollback_segments屏蔽回滚段跳过
Wed Aug 20 23:08:10 2014 SMON: enabling cache recovery SMON: enabling tx recovery SMON: about to recover undo segment 1 SMON: mark undo segment 1 as needs recovery SMON: about to recover undo segment 2 SMON: mark undo segment 2 as needs recovery SMON: about to recover undo segment 3 SMON: mark undo segment 3 as needs recovery SMON: about to recover undo segment 4 SMON: mark undo segment 4 as needs recovery SMON: about to recover undo segment 5 SMON: mark undo segment 5 as needs recovery SMON: about to recover undo segment 6 SMON: mark undo segment 6 as needs recovery SMON: about to recover undo segment 7 SMON: mark undo segment 7 as needs recovery SMON: about to recover undo segment 1 SMON: mark undo segment 1 as needs recovery SMON: about to recover undo segment 2 SMON: mark undo segment 2 as needs recovery SMON: about to recover undo segment 3 SMON: mark undo segment 3 as needs recovery SMON: about to recover undo segment 4 SMON: mark undo segment 4 as needs recovery SMON: about to recover undo segment 5 SMON: mark undo segment 5 as needs recovery SMON: about to recover undo segment 6 SMON: mark undo segment 6 as needs recovery SMON: about to recover undo segment 7 SMON: mark undo segment 7 as needs recovery Wed Aug 20 23:08:15 2014 Completed: alter database open
其他类似文章:
ORA-600[4194]/[4193]解决
通过bbed解决ORA-600 4000案例
通过bbed解决ORA-00600[4000]案例
记录一次ORA-600 4000数据库故障恢复

加我微信(17813235971)
加我QQ(107644445)

