【Oracle数据库恢复】ORA-00600 [4194]: 内部错误代码, 参数: [4194]又一例

2014/10/11 by admin Leave a Comment

某用户11.1.0.6的系统在系统断电重启后遭遇了ORA-600 [4194]错误：

Starting background process QMNC
Wed Dec 10 21:26:24 2014
QMNC started with pid=21, OS id=2932
Errors in file d:\app\administrator\diag\rdbms\erp\erp\trace\erp_smon_3612.trc (incident=33600227):
ORA-00600: 内部错误代码, 参数: [4194], [60], [59], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\erp\erp\incident\incdir_33600227\erp_smon_3612_i33600227.trc
Doing block recovery for file 3 block 4378
Block recovery from logseq 1, block 127 to scn 1309041534
Recovery of Online Redo Log: Thread 1 Group 1 Seq 1 Reading mem 0
Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ERP\REDO01.LOG
Block recovery stopped at EOT rba 1.129.16
Block recovery completed at rba 1.129.16, scn 0.1309041534
Doing block recovery for file 3 block 121
Block recovery from logseq 1, block 127 to scn 1309041531
Recovery of Online Redo Log: Thread 1 Group 1 Seq 1 Reading mem 0
Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ERP\REDO01.LOG
Block recovery completed at rba 1.128.16, scn 0.1309041533
Errors in file d:\app\administrator\diag\rdbms\erp\erp\trace\erp_smon_3612.trc:
ORA-01595: 释放区 (2) 回退段 (8) 时出错
ORA-00607: 当更改数据块时出现内部错误
ORA-00600: 内部错误代码, 参数: [4194], [60], [59], [], [], [], [], []
LOGSTDBY: Validating controlfile with logical metadata
LOGSTDBY: Validation complete
Wed Dec 10 21:26:26 2014
Trace dumping is performing id=[cdmp_20141210212626]
Wed Dec 10 21:26:31 2014
Sweep Incident[33600227]: completed
Wed Dec 10 21:26:31 2014
Errors in file d:\app\administrator\diag\rdbms\erp\erp\trace\erp_m004_4524.trc (incident=33600347):
ORA-00600: 内部错误代码, 参数: [4194], [60], [59], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\erp\erp\incident\incdir_33600347\erp_m004_4524_i33600347.trc
Trace dumping is performing id=[cdmp_20141210212632]
Doing block recovery for file 3 block 4378
Block recovery from logseq 1, block 127 to scn 1309041534

ump of buffer cache at level 4 for tsn=2, rdba=12587290
BH (0x000000016BFB7308) file#: 3 rdba: 0x00c0111a (3/4378) class: 32 ba: 0x000000016B7EA000
set: 11 bsz: 8192 bsi: 0 sflg: 2 pwc: 51 lid: 0x00000000,0x00000000
dbwrid: 0 obj: -1 objn: 0 tsn: 2 afn: 3
hash: [0x00000001E2F7DCC0,0x00000001E2F7DCC0] lru: [0x000000016BFB74C8,0x000000016BFB7268]
obj-flags: object_ckpt_list
ckptq: [0x000000016BF8F7F8,0x000000016BFB7478] fileq: [0x00000001E3BDB698,0x000000016BFB7488] objq: [0x000000016BFEAFC8,0x000000016BF821D8]
use: [0x00000001D8653448,0x00000001D8653448] wait: [NULL]
st: XCURRENT md: EXCL tch: 0
flags: buffer_dirty mod_started gotten_in_current_mode
change state: ACTIVE
change count: 1
LRBA: [0x14.7d.0] LSCN: [0x0.4e0c7c32] HSCN: [0x0.4e0c7c32] HSUB: [65535]
cr pin refcnt: 0 sh pin refcnt: 0
buffer tsn: 2 rdba: 0x00c0111a (3/4378)
scn: 0x0000.4e0662ff seq: 0x02 flg: 0x04 tail: 0x62ff0202
frmt: 0x02 chkval: 0xa54a type: 0x02=KTU UNDO BLOCK
*** ktuc_diag_dmp: dump of redo for rdba 0x00c0111a
Cleaning up copy latch 0
Copy latch cleanup completed
DUMP REDO
Opcodes *.*
DBAs (file#, block#):
(3, 4378) .
SCNs: scn: 0x0000.00000000 thru scn: 0xffff.ffffffff
**NOTE: Only Dumping Redo less then 12 hours**
Times: 12/10/2014 21:23:27 thru eternity

*** 2014-12-11 09:23:27.382
SCN Start Scan Point: scn: 0x0000.4e0bd8c2 (1309399234)
INCARNATION:
START: scn: 0x0000.4e0662ee (1309041390) Timestamp: 12/10/2014 21:26:17
END: scn: 0xffff.ffffffff
descrip:"Thread 0001, Seq# 0000000018, SCN 0x00004e0bd8c2-0x00004e0c295e"

REDO RECORD - Thread:1 RBA: 0x000012.00000002.0010 LEN: 0x0070 VLD: 0x05
SCN: 0x0000.4e0bd8c4 SUBSCN: 1 12/11/2014 09:19:10
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:17.3
descrip:"Thread 0001, Seq# 0000000019, SCN 0x00004e0c295e-0x00004e0c79f5"

REDO RECORD - Thread:1 RBA: 0x000013.00000002.0010 LEN: 0x0070 VLD: 0x05
SCN: 0x0000.4e0c2960 SUBSCN: 1 12/11/2014 09:20:14
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:17.3
descrip:"Thread 0001, Seq# 0000000020, SCN 0x00004e0c79f5-0xffffffffffff"

REDO RECORD - Thread:1 RBA: 0x000014.00000002.0010 LEN: 0x0070 VLD: 0x05
SCN: 0x0000.4e0c79f7 SUBSCN: 1 12/11/2014 09:23:13
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:17.3
END OF DUMP REDO
Incident 35120409 created, dump file: d:\app\administrator\diag\rdbms\erp\erp\incident\incdir_35120409\erp_ora_548_i35120409.trc
ORA-00600: 内部错误代码, 参数: [4194], [60], [59], [], [], [], [], []

Error 607 in redo application callback
Dump of change vector:
TYP:0 CLS:32 AFN:3 DBA:0x00c0111a OBJ:4294967295 SCN:0x0000.4e0662ff SEQ: 2 OP:5.1
ktudb redo: siz: 208 spc: 1094 flg: 0x0012 seq: 0x91a4 rec: 0x3b
xid: 0x0008.01d.001511ce
ktubl redo: slt: 29 rci: 0 opc: 11.1 objn: 74 objd: 74 tsn: 0
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
0x00000000 prev ctl uba: 0x00c0111a.91a4.39
prev ctl max cmt scn: 0x0000.4e065bc8 prev tx cmt scn: 0x0000.4e065be6
txn start scn: 0xffff.ffffffff logon user: 0 prev brb: 12587289 prev bcl: 0 BuExt idx: 0 flg2: 0
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
compat bit: 4 (post-11) padding: 0
op: L itl: xid: 0x000d.012.000346f7 uba: 0x00c01d8e.1899.2a
flg: C--- lkc: 0 scn: 0x0000.4e0c7c3e
KDO Op code: URP row dependencies Disabled
xtype: XAxtype KDO_KDOM2 flags: 0x00000080 bdba: 0x00400222 hdba: 0x00400221
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 8(0x8) flag: 0x2c lock: 0 ckix: 0
ncol: 10 nnew: 9 size: 0
Vector content:
col 1: [ 2] c1 02
col 2: [ 2] c1 02
col 3: [ 2] c5 15
col 4: [ 2] c1 02
col 5: [ 1] 80
col 6: [ 2] c3 02
col 7: [ 5] c4 06 4a 13 0b
col 8: [32]
2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d
2d 2d 2d 2d 2d 2d 2d
col 9: [ 1] 80
Block after image is corrupt:
buffer rdba: 0x00c0111a
scn: 0x0000.4e0662ff seq: 0x02 flg: 0x04 tail: 0x62ff0202
frmt: 0x02 chkval: 0xa54a type: 0x02=KTU UNDO BLOCK
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x000000016B7EA000 to 0x000000016B7EC000
16B7EA000 0000A202 00C0111A 4E0662FF 04020000 [.........b.N....]

该ORA-00600: 内部错误代码, 参数: [4194]错误我们之前有多次提过，

【Oracle数据恢复】通过BBED修复ORA-600[4193]和ORA-600[4194]的例子

【Oracle数据恢复】ORA-600[4194]错误一例

ORA-600[4194]内部错误一般由重做记录与回滚记录不匹配引发。Oracle在验证Undo record number时，会对比redo change 和回滚段中的undo record number，若发现2者存在差异则报该4194错误。其错误argument[a][b]，a代表回滚块中的最大undo record number，b代表重做日志中记录的undo record number。这个错误可能由回滚段或者redo log日志文件讹误引起。

ORA-00600[4194]错误的根本原因是 redo记录与回滚段(rollback/undo)记录之间的不一致。当ORACLE在验证undo记录时相对应的变化需要应用到undo数据块的最大undo记录上，此时若检验出错则会报ORA-00600[4194]

ORA-600[4194]的2个的含义：

Arg [a] Maximum Undo record number in Undo block
Arg [b] Undo record number from Redo block

以上可以通过trace定位到可能存在触发该UNDO问题的数据块是rdba: 0x00c0111a (3/4378)，该问题一般可以通过设置EVENT、隐藏参数或BBED来修复。

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

PRM: Warning:scaned 10MB data, couldn’t find file header

2014/10/11 by admin Leave a Comment

PRM: Warning:scaned 10MB data, couldn’t find file header ，如果在使用PRM-DUL过程中遇到了该问题，则可能是：

1、选择了错误的 BLOCK_SIZE

2、选择了错误的endian ，AIX、HPUX 、Solaris Sparc上的datafile均为Big Endian。其他的操作系统Windows、Linux、Solaris X86基本都为Little Endian，如上图

3、启动PRM的用户没有足够的权限读取数据文件，这个情况下WIndows下可能出现

4、加入的数据文件的文件头真的丢失或者损坏了，这个情况请联系我们 service@parnassusdata.com

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

about db_lost_write_protect

2014/10/06 by admin 1 Comment


SQL> create table lost_write(t1 int) tablespace users; 

Table created.

SQL> 
SQL> insert into lost_write values(1);

1 row created.

SQL> commit;

Commit complete.

SQL> alter system checkpoint;

System altered.


select dbms_rowid.rowid_block_number(rowid),dbms_rowid.rowid_relative_fno(rowid) from lost_write;

DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID)
------------------------------------ ------------------------------------
                                 222                                    6

								 
								 

	alter system set db_lost_write_protect=typical;
	
	
	
	
SQL> select name from v$datafile where file#=6;

NAME
--------------------------------------------------------------------------------
/s01/oradata/PDPROD/datafile/o1_mf_users_b2wgb20l_.dbf


update lost_write set t1=9999;

alter system flush buffer_cache;



dd if=/s01/oradata/PDPROD/datafile/o1_mf_users_b2wgb20l_.dbf skip=222 bs=8192 count=1  of=222_block

dd if=222_block of=/s01/oradata/PDPROD/datafile/o1_mf_users_b2wgb20l_.dbf  seek=222 bs=8192 count=1 conv=notrunc

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

PRM-DUL成功案例：为某电信运营商恢复了误truncate的一百多张表

2014/10/03 by admin 4 Comments

PRM-DUL成功案例：为某电信运营商恢复了误删truncate的一百多张表。东南某电信运营商生产系统数据库部分数据表被误删除的问题，现场工作内容：采用PRM-DUL工具将所需要的共121张表恢复出来。

整个数据库大小在25T左右，由于还原的新环境存储空间有限，还原整个数据库不够现实。初步决定还原方案为先还原SYSTEM和data表空间，然后使用PRM-DUL直接读取数据文件，将数据导出。

实际这个case用户在带库里是由完整备份和归档的，但是实际情况所制约没有那么多空间和时间去从备份里恢复数据了，如果真的那么做，可能至少需要几天时间，而实际恢复业务要求在1天内。所幸的是业务对这些表的完整性要求不高，而且从后期来看在truncate后插入数据的量很少，所以这个case在协商后使用了PRM-DUL成功scan database字典模式下恢复truncate功能来恢复了。

免费的PRM-DUL License :http://www.parnassusdata.com/zh-hans/node/122

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复 Tagged With: dul, prm, truncate

PRM-DUL成功案例：恢复了700GB损坏严重的Oracle数据库

2014/10/02 by admin 1 Comment

PRM-DUL成功案例：恢复了700GB损坏严重的Oracle数据库。某中原企业存储断电重启后发现其700GB大小的数据库，存在十几万个坏块，数据库无法正常打开使用。

用户自行尝试采用ORACLE DUL做恢复，但是由于ORACLE DUL对于该超过500万个col$记录的数据字典出现DC_COLUMNS过大导致的coredump segmentfault，导致ORACLE DUL无法正常使用。

该场景中数据块的损坏模式主要是fracture断裂。诗檀软件工程师Biot.wang 通过修改checksum+ tailchk , tailchk=低2位的bas_kcbh+type_kcbh+seq_kcbh，伪装了大部分数据块为可用。此场景中之后exp可以导出大部分数据，但是由于数据字典严重损毁，所以可能出现表上字段混乱或者缺失数据等问题，大部分情况可以用PRM-DUL的非字典模式(NON-DICT)来解决。

在这个案例中由于用户的表和索引过多，导致数据字典异常庞大，ORACLE原厂的DUL在加载数据字典时由于其内存分配方式直接导致出现了coredump segmentfault，而COL$.DAT又过大了，很难处理分片。

在这个问题上PRM-DUL由于采用了内置一个derby数据库,所以即便数据字典再大也不会有问题，而且内置数据库中的数据也做了索引，这保证了PRM-DUL能迅速处理字典操作。另由于此例子中需要恢复的数据表实在太多，达到了几十万张，所以充分利用了PRM-DUL的schema-level Databridge功能。仅仅花了2天时间就基本处理完这个case了。

免费的PRM-DUL License :http://www.parnassusdata.com/zh-hans/node/122

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

诗檀软件成功为某西南大型企业从不完整的备份中恢复了数据

2014/10/02 by admin Leave a Comment

诗檀软件成功为某西南大型国企从不完整的备份中恢复了数据；某西南大型企业数据库的ASM因为加盘意外损坏，用户自行重建ASM DISKGROUP并restore了热备份，由于丢失了归档，数据库无法打开。

诗檀软件工程师biot.wang 通过特殊恢复方案打开了该并不一致的数据库备份，大致经过为：手动修改bootstrap对象 ,commit事务；修改datafile header绕过已经不存在的archivelog，之后打开数据库exp导出数据并重建数据库。但是由于丢失部分redo，导致部分表exp时出现了ORA-600错误，这部分表通过PRM-DUL工具的DataBridge特性来特殊恢复了。

免费的PRM-DUL License :http://www.parnassusdata.com/zh-hans/node/122

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

诗檀软件成功为某电力企业恢复大量坏块的核心数据库

2014/10/02 by admin Leave a Comment

诗檀软件成功为某电力企业恢复大量坏块的核心数据库，某东北电力企业的核心数据库在存储意外断电后出现大量FRACTURED块断裂损坏，且数据库无任何形式备份。

SQL> select * from v$database_block_corruption;

     FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTIO                   
---------- ---------- ---------- ------------------ ---------                   
         1       3119          1                  0 FRACTURED                   
         1     142239          1                  0 FRACTURED                   
         1      11567          1                  0 FRACTURED                   
         1      79919          1                  0 FRACTURED                   
         1      87535          1                  0 FRACTURED                   
         1      88447          1                  0 FRACTURED                   
         1      89871          1                  0 FRACTURED                   
         1      89999          1                  0 FRACTURED                   
         1      91295          1                  0 FRACTURED                   
         1      93631          1                  0 FRACTURED                   
         1      94383          1                  0 FRACTURED                   

     FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTIO                   
---------- ---------- ---------- ------------------ ---------                   
         1      94639          1                  0 FRACTURED                   
         1      96799          1                  0 FRACTURED                   
         1      96895          1                  0 FRACTURED                   
         1      97647          1                  0 FRACTURED                   
         1     108671          1                  0 FRACTURED                   
         1     108863          1                  0 FRACTURED                   
         1     110927          1                  0 FRACTURED                   
         1     128095          1                  0 FRACTURED                   
         1     134751          1                  0 FRACTURED                   
         1     139423          1                  0 FRACTURED                   
         1     139471          1                  0 FRACTURED

FRACTURED断裂的损坏块数量大约有2万个，且FILE# 即system.dbf上也存在上百个坏块。
诗檀软件工程师Biot.Wang通过Patch数据字典的方式打开了数据库并，恢复了绝大多数数据。由存储断电或其他异常引起的数据库损坏在过去几年中为此类故障的主要诱发原因，即便在条件限制的情况下仍应当考虑至少采取一些周期较长的备份行为，例如逻辑备份，或者针对特定重要的表进行备份。这个例子中由于成功打开数据库，并exp了大部分数据，所以没有使用到PRM-DUL恢复工具。

免费的PRM-DUL License :http://www.parnassusdata.com/zh-hans/node/122

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复 Tagged With: FRACTURED

How to recover data from truncated oracle tables without backup?

2014/09/30 by admin Leave a Comment

Just Try PRM for Oracle

https://www.askmac.cn/wp-content/uploads/2014/09/howtorecoverfromtruncateusingprmparnassusdatarecoverymanager-140617102539-phpapp01.pdf

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

PRM- A FULL GUI DUL data unloader For Oracle Database

2014/09/28 by admin Leave a Comment

TRY PRM-DUL Data Unloader For Oracle Database

FULL GUI supported, easy to use, written in Java cross platform . PRM can help user recover data from truncated table or corrupted database!

PRM-DUL Data Unloader – For Oracle Database, from ParnassusData Software System Inc., which can save your ORACLE database

PRM – a public DUL with GUI , is free to download trial version.

PRM is designed for Enterprise Database Recovery, which includes all Oracle DUL data recovery functionalities, and also easy-to-use GUI. Users can purchase PRM for its rich GUI on your recovery. Or, you can contact ParnassusData for professional service that is either onsite or remote for your request. Rich GUI wizard can guide your recovery process. PRM can recovery your data direct from your database file system (dirty read). If your data has not been covered, PRM can guarantee your 99.9% data back.

[Read more…]

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复 Tagged With: ASM, dul, prm