标签云
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,883)
- DB2 (22)
- MySQL (82)
- Oracle (1,708)
- 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备份恢复 (662)
- 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)
-
最近发表
- aix平台Oracle数据库由于断电无法启动故障处理
- 断电引起ORA-600 3005故障处理
- 记录一次云存储资源到期之后引起的数据库恢复
- 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故障恢复
标签归档:ORA-600 4193
ORA-600 4193 错误说明和解决
ORA-600 4193 解释说明
ERROR:
Format: ORA-600 [4193] [a] [b]
VERSIONS:
versions 6.0 to 12.1
DESCRIPTION:
A mismatch has been detected between Redo records and Rollback (Undo)
records.
We are validating the Undo block sequence number in the undo block against
the Redo block sequence number relating to the change being applied.
This error is reported when this validation fails.
ARGUMENTS:
Arg [a] Undo record seq number
Arg [b] Redo record seq number
FUNCTIONALITY:
KERNEL TRANSACTION UNDO
ORA-600 [4193] [a] [b] [ ] [ ] [ ]
Versions: 7.2.2 - 9.2.0 Source: ktuc.c
===========================================================================
Meaning: seq# mismatch while adding an undo record to an undo block. This
is done by the application of redo.
---------------------------------------------------------------------------
Argument Description:
a. (ktubhseq): undo record seq# - this is the seq# of the block that
this undo record WILL BE APPLIED TO.
This is from the Undo Block. It is
NOT the seq# of the undo block itself.
b. (ktudbseq): redo RECORD seq# - this is the seq# number in the block
that this redo WILL BE APPLIED TO.
This is from the Redo Record.
---------------------------------------------------------------------------
Diagnosis:
This error is raised in kturdb which handles the adding of undo records
by the application of redo.
When we try to apply redo to an undo block (forward changes are made by
the application of redo to a block) we check that the seq# in the undo
record matches the seq# in the redo record. These seq# should be the
same because when we apply a redo record we must apply it to the
correct version of the block. We can only apply a redo record to a
block that contains the same seq# as in the redo record.
If the seq# do not match then this error is raised. This implies some
kind of block corruption in either the redo or the undo block.
7.3.x - 8.1.7.x
ASSERT2(ubh->ktubhseq == db->ktudbseq, OERI(4193), KSESVSGN,
ubh->ktubhseq, db->ktudbseq);
9.2.x
ksesic2(OERI(4193), ksenrg(ubh->ktubhseq), ksenrg(db->ktudbseq));
struct ktubh
{
kxid ktubhxid; /* txid of tx currently using or last used this block */
ub2 ktubhseq; /* undo block sequence number */
ub1 ktubhcnt; /* high water mark record index, number of undo entries */
ub1 ktubhirb; /* rollback record index, rec index to start the rollback */
ub1 ktubhicl; /* collecting record index, rec index to start retrieving col info */
ub1 ktubhflg; /* dummy */
ub2 ktubhidx[1]; /* byte offset of record in block, grows at runtime */
};
struct ktudb Kernel Transaction Undo Data operation Block (redo)
{
ub2 ktudbsiz; /* size of entry */
ub2 ktudbspc; /* verification: space left in undo block */
ub2 ktudbflg; /* flag to indicate the kind of redo operation */
kxid ktudbxid; /* current tx id */
ub2 ktudbseq; /* block sequence number */
ub1 ktudbrec; /* new record index for this change */
};
ORA 600 4193 处理方法同How to resolve ORA-600 [4194] errors
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数据库故障恢复
记录一次ORA-600 3004 恢复过程和处理思路
10.1.0.2数据库在启动的时候报ORA-00600[3004]错误
SQL> startup ORACLE 例程已经启动。 Total System Global Area 1042254360 bytes Fixed Size 743960 bytes Variable Size 503316480 bytes Database Buffers 536870912 bytes Redo Buffers 1323008 bytes 数据库装载完毕。 ORA-00600: 内部错误代码,参数: [3004], [1], [0], [0], [], [], [], []
alert日志信息
Tue Jul 15 10:57:11 2014 Database mounted in Exclusive Mode. Completed: ALTER DATABASE MOUNT Tue Jul 15 10:57:12 2014 ALTER DATABASE OPEN Tue Jul 15 10:57:12 2014 Beginning crash recovery of 1 threads attempting to start a parallel recovery with 3 processes parallel recovery started with 3 processes Tue Jul 15 10:57:12 2014 Started first pass scan Tue Jul 15 10:57:12 2014 Errors in file d:\oracle\product\10.1.0\admin\orcl\udump\orcl_ora_1084.trc: ORA-00600: 内部错误代码, 参数: [3004], [1], [0], [0], [], [], [], [] Tue Jul 15 10:57:13 2014 Errors in file d:\oracle\product\10.1.0\admin\orcl\bdump\orcl_p000_3780.trc: ORA-10388: parallel query server interrupt (failure) Tue Jul 15 10:57:13 2014 Errors in file d:\oracle\product\10.1.0\admin\orcl\bdump\orcl_p002_3420.trc: ORA-10388: parallel query server interrupt (failure) Tue Jul 15 10:57:14 2014 Errors in file d:\oracle\product\10.1.0\admin\orcl\bdump\orcl_p001_3784.trc: ORA-10388: parallel query server interrupt (failure) Tue Jul 15 10:57:14 2014 Aborting crash recovery due to error 600 Tue Jul 15 10:57:14 2014 Errors in file d:\oracle\product\10.1.0\admin\orcl\udump\orcl_ora_1084.trc: ORA-00600: 内部错误代码, 参数: [3004], [1], [0], [0], [], [], [], [] ORA-600 signalled during: ALTER DATABASE OPEN...
根据老杨的blog,出现该问题,很可能是crontrolfile异常导致,所以这里可以考虑通过重建控制文件或者把当前控制文件当作备份控制文件来使用
Tue Jul 15 13:42:31 2014 ALTER DATABASE RECOVER database using backup controlfile Tue Jul 15 13:42:31 2014 Media Recovery Start WARNING! Recovering data file 1 from a fuzzy file. If not the current file it might be an online backup taken without entering the begin backup command. WARNING! Recovering data file 2 from a fuzzy file. If not the current file it might be an online backup taken without entering the begin backup command. WARNING! Recovering data file 3 from a fuzzy file. If not the current file it might be an online backup taken without entering the begin backup command. WARNING! Recovering data file 4 from a fuzzy file. If not the current file it might be an online backup taken without entering the begin backup command. WARNING! Recovering data file 5 from a fuzzy file. If not the current file it might be an online backup taken without entering the begin backup command. WARNING! Recovering data file 6 from a fuzzy file. If not the current file it might be an online backup taken without entering the begin backup command. WARNING! Recovering data file 7 from a fuzzy file. If not the current file it might be an online backup taken without entering the begin backup command. WARNING! Recovering data file 8 from a fuzzy file. If not the current file it might be an online backup taken without entering the begin backup command. WARNING! Recovering data file 9 from a fuzzy file. If not the current file it might be an online backup taken without entering the begin backup command. WARNING! Recovering data file 10 from a fuzzy file. If not the current file it might be an online backup taken without entering the begin backup command. WARNING! Recovering data file 11 from a fuzzy file. If not the current file it might be an online backup taken without entering the begin backup command. attempting to start a parallel recovery with 3 processes parallel recovery started with 3 processes Starting datafile 1 with incarnation depth 0 in thread 1 sequence 794 Datafile 1: 'D:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\SYSTEM01.DBF' Starting datafile 2 with incarnation depth 0 in thread 1 sequence 794 Datafile 2: 'D:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\UNDOTBS01.DBF' Starting datafile 3 with incarnation depth 0 in thread 1 sequence 794 Datafile 3: 'D:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\SYSAUX01.DBF' Starting datafile 4 with incarnation depth 0 in thread 1 sequence 794 Datafile 4: 'D:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\USERS01.DBF' Starting datafile 5 with incarnation depth 0 in thread 1 sequence 794 Datafile 5: 'E:\ORADB\USER1_1.ORA' Starting datafile 6 with incarnation depth 0 in thread 1 sequence 794 Datafile 6: 'E:\ORADB\USER1_2.ORA' Starting datafile 7 with incarnation depth 0 in thread 1 sequence 794 Datafile 7: 'E:\ORADB\USER1_3.ORA' Starting datafile 8 with incarnation depth 0 in thread 1 sequence 794 Datafile 8: 'E:\ORADB\USER1_4.ORA' Starting datafile 9 with incarnation depth 0 in thread 1 sequence 794 Datafile 9: 'E:\ORADB\INDEX1_1.ORA' Starting datafile 10 with incarnation depth 0 in thread 1 sequence 794 Datafile 10: 'E:\ORADB\INDEX1_2.ORA' Starting datafile 11 with incarnation depth 0 in thread 1 sequence 794 Datafile 11: 'E:\ORADB\TEMP1_1.ORA' Media Recovery Log ORA-279 signalled during: ALTER DATABASE RECOVER database using backup cont... Tue Jul 15 13:43:03 2014 ALTER DATABASE RECOVER LOGFILE 'D:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\REDO01.LOG' Tue Jul 15 13:43:03 2014 Media Recovery Log D:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\REDO01.LOG Completed: ALTER DATABASE RECOVER LOGFILE 'D:\ORACLE\PRODU Tue Jul 15 13:43:17 2014 alter database open resetlogs RESETLOGS after complete recovery through change 3142208 Resetting resetlogs activation ID 1378452168 (0x522982c8) Setting recovery target incarnation to 3 Tue Jul 15 13:43:18 2014 Setting recovery target incarnation to 3 Tue Jul 15 13:43:18 2014 Flashback Database Disabled Tue Jul 15 13:43:19 2014 Assigning activation ID 1380750902 (0x524c9636) Maximum redo generation record size = 120832 bytes Maximum redo generation change vector size = 116476 bytes Private_strands 7 at log switch Thread 1 opened at log sequence 1 Current log# 1 seq# 1 mem# 0: D:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\REDO01.LOG Successful open of redo thread 1 Tue Jul 15 13:43:19 2014 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Tue Jul 15 13:43:19 2014 SMON: enabling cache recovery Tue Jul 15 13:43:20 2014 Errors in file d:\oracle\product\10.1.0\admin\orcl\udump\orcl_ora_1484.trc: ORA-00600: 内部错误代码, 参数: [2662], [0], [3142214], [0], [3142438], [8388617], [], [] Tue Jul 15 13:43:21 2014 Errors in file d:\oracle\product\10.1.0\admin\orcl\udump\orcl_ora_1484.trc: ORA-00600: 内部错误代码, 参数: [2662], [0], [3142214], [0], [3142438], [8388617], [], [] Tue Jul 15 13:43:21 2014 Error 600 happened during db open, shutting down database USER: terminating instance due to error 600
这里出现ORA-600[2662]因为scn相差较小,直接重启几次,然后数据库出现如下启动正常但是出现ORA-01595和ORA-00600[4194]错误
Tue Jul 15 13:48:26 2014 Starting background process MMON Starting background process MMNL MMON started with pid=17, OS id=2896 MMNL started with pid=18, OS id=3828 Tue Jul 15 13:48:26 2014 Block recovery completed at rba 2.90.16, scn 0.3162303 Tue Jul 15 13:48:26 2014 Errors in file d:\oracle\product\10.1.0\admin\orcl\bdump\orcl_smon_3724.trc: ORA-01595: error freeing extent (3) of rollback segment (1)) ORA-00607: Internal error occurred while making a change to a data block ORA-00600: internal error code, arguments: [4194], [57], [6], [], [], [], [], [] Tue Jul 15 13:48:26 2014 Completed: alter database open Tue Jul 15 13:48:27 2014 Errors in file d:\oracle\product\10.1.0\admin\orcl\bdump\orcl_j000_2956.trc: ORA-00600: internal error code, arguments: [4193], [1375], [1379], [], [], [], [], []
通过设置undo_management=manual,重建undo表空间解决,至此本数据库恢复完成,建议对其进行逻辑方式重建

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

