标签云
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,878)
- DB2 (22)
- MySQL (82)
- Oracle (1,704)
- 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安装升级 (107)
- 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)
-
最近发表
- 由于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故障
- 快速处理 ORA-01210: data file header is media corrupt 故障
- ORA-00314: log 3 of thread 1, expected sequence# N doesn’t match 0
分类目录归档:Oracle备份恢复
ORA-600 kcvent_internal_02故障处理
数据库启动报ORA-00600: internal error code, arguments: [kcvent_internal_02]错,无法正常open
Reconfiguration complete parallel recovery started with 32 processes Started redo scan Completed redo scan read 22775 KB redo, 5055 data blocks need recovery Started redo application at Thread 2: logseq 166395, block 88 Recovery of Online Redo Log: Thread 2 Group 3 Seq 166395 Reading mem 0 Mem# 0: +DATA/orcl/onlinelog/group_3.283.1036687245 Mem# 1: +FLASH/orcl/onlinelog/group_3.264.1036687257 Recovery of Online Redo Log: Thread 2 Group 4 Seq 166396 Reading mem 0 Mem# 0: +DATA/orcl/onlinelog/group_4.284.1036687257 Mem# 1: +FLASH/orcl/onlinelog/group_4.265.1036687257 Completed redo application of 15.97MB Completed instance recovery at Thread 2: logseq 166396, block 15854, scn 27533037896 5055 data blocks read, 5055 data blocks written, 22775 redo k-bytes read Thread 2 advanced to log sequence 166397 (thread recovery) Redo thread 2 internally disabled at seq 166397 Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_ora_35652472.trc (incident=195549): ORA-00600: internal error code, arguments: [kcvent_internal_02], [], [], [], [], [], [], [], [], [], [], [] Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl1/incident/incdir_195549/orcl1_ora_35652472_i195549.trc
对应的trace文件信息
Dump continued from file: /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_ora_35652472.trc
ORA-00600: internal error code, arguments: [kcvent_internal_02], [], [], [], [], [], [], [], [], [], [], []
========= Dump for incident 195549 (ORA 600 [kcvent_internal_02]) ========
*** 2022-06-06 22:17:48.743
dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)
----- Current SQL Statement for this session (sql_id=5fmpzya54p4hf) -----
ALTER DATABASE OPEN /* db agent *//* {1:38339:2} */
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
skdstdst()+40 bl 0000000109B1E77C 000000000 ? 000000001 ?
000000003 ? 000000000 ?
000000000 ? 000000001 ?
000000003 ? 000000000 ?
ksedst1()+112 call skdstdst() 16F60DC8B26FAB02 ?
4846284100000000 ?
FFFFFFFFFFE46D0 ?
283C6E7C6A9A6 ? 10A6B923C ?
000000000 ? 110737880 ?
2050033FFFE46D8 ?
ksedst()+40 call ksedst1() 000000000 ? 00000000A ?
07FFFFFFF ? 700000000003670 ?
000000000 ? 000000000 ?
000002004 ? 000000001 ?
dbkedDefDump()+1516 call ksedst() 000000000 ? 000000000 ?
000000000 ? 000000000 ?
000000000 ? 000000000 ?
000000000 ? 300000003 ?
ksedmp()+72 call dbkedDefDump() 310737880 ? 110000D40 ?
FFFFFFFFFFE4EE0 ? 1106AB740 ?
100124BB8 ? 000000000 ?
700011D7387FF08 ? 1106AB740 ?
ksfdmp()+100 call ksedmp() 000000002 ? 000000000 ?
000000002 ? 10AF01CA8 ?
10A041C38 ? 000000000 ?
11073C760 ? 110737880 ?
dbgexPhaseII()+1904 call ksfdmp() 000000000 ? 00000000A ?
000000002 ? 000000000 ?
000000002 ? 10A041C30 ?
000000000 ? 001050005 ?
dbgexProcessError() call dbgexPhaseII() 110737880 ? 11073A970 ?
+1556 00002FBDD ? 200000000 ?
FFFFFFFFFFE5DF8 ? 00000006C ?
200000000 ? 1000000000 ?
dbgeExecuteForError call dbgexProcessError() 110737880 ? 11073C760 ?
()+72 100000703 ? 000004000 ?
000000000 ? FFFFFFFFFFE9608 ?
000000001 ? 11073E4A8 ?
dbgePostErrorKGE()+ call dbgeExecuteForError FFFFFFFFFFE92B0 ?
2044 () 700011D61558BB8 ? 102878B5C ?
000000000 ? 000000000 ?
FFFFFFFFFFE9608 ? 000000000 ?
000000000 ?
dbkePostKGE_kgsf()+ call dbgePostErrorKGE() 07FFFFFFF ? 700000000003670 ?
68 25800000001 ? 109E4A618 ?
000000000 ? 000000000 ?
FFFFFFFFFFEA0B0 ? 1109C0040 ?
kgeadse()+380 call dbkePostKGE_kgsf() 000000000 ? 000000000 ?
000000000 ? 000000000 ?
000000000 ? 000000000 ?
000000000 ? 069186EAB ?
kgerinv_internal()+ call kgeadse() 000000002 ? 000000002 ?
48 000000001 ? FFFFFFFFFFEAB58 ?
10A4E02F0 ? 000000002 ?
FFFFFFFFFFE9FE0 ? 000000000 ?
kgerinv()+48 call kgerinv_internal() 200000002 ? 000000002 ?
FFFFFFFFFFEA060 ? 000000000 ?
102860EB0 ? FFFFFFFFFFEA458 ?
10285CE74 ? FFFFFFFFFFEA358 ?
kgeasnmierr()+72 call kgerinv() 38400000001 ? 000000000 ?
10A4E0D20 ? 497F0A29CAE0 ?
000000001 ? FFFFFFFFFFEA1C0 ?
10A4E0D20 ? 110000D78 ?
kcvent_internal()+1 call kgeasnmierr() FFFFFFFFFFEA1C0 ? 200000002 ?
532 1F0410001F041 ? 000000000 ?
000000000 ? 000000000 ?
000000000 ? 000000004 ?
kctenb_internal()+2 call kcvent_internal() FFFFFFFFFFEB378 ? 200000002 ?
772 FFFFFFFFFFEB448 ?
FFFFFFFFFFEB2E8 ?
41F6C57900000000 ?
000000000 ? FFFFFFFFFFEB330 ?
1106AB740 ?
kcfopd()+1508 call kctenb_internal() 07FFFFFFF ? 000000000 ?
000000018 ? FFFFFFFFFFEC380 ?
000000000 ? 110A39050 ?
FFFFFFFFFFEC390 ? 000000000 ?
adbdrv()+8028 call kcfopd() 081F0AD00 ? 00000000F ?
0FFFED4C0 ? 000000000 ?
FFFFFFFFFFED548 ? 100000000 ?
000000000 ? 1000100000000 ?
opiexe()+16048 call adbdrv() 2300000023 ? 100000001 ?
000000000 ? FFFFFFFFFFF6960 ?
000000000 ? FFFFFFFFFFF6B60 ?
FFFFFFFFFFF6A98 ? 200000002 ?
opiosq0()+3984 call opiexe() 700011E117B3B20 ? 000000000 ?
FFFFFFFFFFF7ED8 ? 110000D78 ?
000000001 ? 1109FA438 ?
FFFFFFFFFFF7E70 ?
2216414400000001 ?
kpooprx()+316 call opiosq0() 300000000 ? 000000000 ?
000000000 ? A4000000000000 ?
000000000 ? FFFFFFFFFFF87F0 ?
28104221FFFF86F0 ?
1109FAB08 ?
kpoal8()+872 call kpooprx() 1000CE68C ? 000000001 ?
FFFFFFFFFFFAD14 ? 100000001 ?
000000000 ? A40000000000A4 ?
109EB6D00 ? 000000000 ?
opiodr()+908 call kpoal8() 100000000 ? 9001000A0091108 ?
000000FFF ? 07FFFFFF8 ?
FFFFFFFFFFF8F10 ? 000000018 ?
000000000 ? 000072FFF ?
ttcpip()+1028 call opiodr() 5EFFFFA480 ? 1C00200048 ?
FFFFFFFFFFFA9F8 ? 000530058 ?
1108BEE30 ? 000000028 ?
FFFFFFFFFFFA3A0 ? 1108BEC70 ?
opitsk()+1612 call ttcpip() 110135440 ? 000002078 ?
000000000 ? 110000D78 ?
110005210 ? 000000000 ?
FFFFFFFFFFFAA20 ?
2222208009EF13C0 ?
opiino()+940 call opitsk() 110024C58 ? 000000000 ?
11079B550 ? 1107A0850 ?
110737880 ? FFFFFFFFFFFCAE0 ?
FFFFFFFFFFFEB3C ? 000000101 ?
opiodr()+908 call opiino() 3C006C787C ?
BFF0000000000000 ?
FFFFFFFFFFFEF60 ?
FFFFFFFFFFFD5E9 ?
FFFFFFFFFFFD630 ? 1106AB740 ?
FFFFFFFFFFFD650 ?
9FFFFFFF000E608 ?
opidrv()+1132 call opiodr() 3C0AFBC600 ? 410134340 ?
FFFFFFFFFFFEF60 ? 07530312F ?
108820CE4 ? 1106AB740 ?
7264626D732F6F72 ?
1106AB740 ?
sou2o()+136 call opidrv() 3C0882A9D0 ? 41170031F ?
FFFFFFFFFFFEF60 ?
110017002A0000 ? 0E0DDF00D ?
1106AB740 ?
BADC0FFEE0DDF00D ?
BADC0FFEE0DDF00D ?
opimai_real()+560 call sou2o() FFFFFFFFFFFEFD0 ?
BADC0FFEE0DDF00D ?
90000000008BE3C ?
BADC0FFEE0DDF00D ?
000000002 ? 9001000A0091108 ?
A0000000A000000 ? 10B671248 ?
ssthrdmain()+276 call opimai_real() 10B6B1D74 ? 9001000A0095260 ?
FFFFFFFFFFFF0B0 ? 10B6B1598 ?
FFFFFFFFFFFF0D0 ?
FFFFFFFFFFFF428 ?
900000000100968 ?
9001000A0091108 ?
main()+204 call ssthrdmain() 240000000 ? FFFFFFFFFFFF418 ?
8FFFFFFF0000090 ? 000000000 ?
000000000 ? 000000000 ?
BADC0FFEE0DDF00D ?
BADC0FFEE0DDF00D ?
__start()+112 call main() 000000000 ? 000000000 ?
000000000 ? 000000000 ?
000000000 ? 000000000 ?
000000000 ? 000000000 ?
--------------------- Binary Stack Dump ---------------------
该错误在mos,互联网上没有任何信息,不过在alert日志中发现类似信息
Mon Jun 06 23:03:58 2022
Error: Controlfile sequence number in file header is different from the one in memory
Please check that the correct mount options are used if controlfile is located on NFS
初步判断可能和这个错误有关系,解决相关问题后,尝试open库
SQL> recover database;
ORA-00279: change 27533037896 generated at 06/06/2022 22:17:46 needed for
thread 2
ORA-00289: suggestion :
+FLASH/orcl/archivelog/2022_06_06/thread_2_seq_166396.6532.1106691471
ORA-00280: change 27533037896 for thread 2 is in sequence #166396
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
Log applied.
Media recovery complete.
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01216: thread 2 is expected to be disabled after CREATE CONTROLFILE
SQL> !oerr ora 01216
01216, 00000, "thread %s is expected to be disabled after CREATE CONTROLFILE"
// *Cause: A thread that was given during CREATE CONTROLFILE is enabled, but
// the datafiles indicate that it should be disabled. This is
// probably because the logs supplied to the CREATE CONTROLFILE
// are old (from before the disabling of the thread).
// *Action: This thread is not required to run the database. The CREATE
// CONTROLFILE statement can be reissued without the problem thread,
// and, if desired, the thread can be recreated after the database
// is open.
ORA-01216这个错误比较也比较少见,但是感觉和thread有关系,大概的意思是thread 被disable了
SQL> select thread#,STATUS FROM V$THREAD;
THREAD# STATUS
---------- ------------------
1 CLOSED
2 CLOSED
通过人工强制把thread个open,然后数据库启动成功
SQL> select thread#,status from v$thread;
THREAD# STATUS
---------- ------------------
1 OPEN
2 CLOSED
SQL> alter database open;
Database altered.
然后启动thread 2,open 第二个节点
--需要open节点 QL> startup ORACLE instance started. Total System Global Area 1.2961E+11 bytes Fixed Size 2262400 bytes Variable Size 3.3018E+10 bytes Database Buffers 9.6368E+10 bytes Redo Buffers 221818880 bytes ORA-01618: redo thread 2 is not enabled - cannot mount --已经open节点 SQL> ALTER DATABASE ENABLE THREAD 2; Database altered. --需要open节点 SQL> ALTER DATABASE MOUNT; Database altered. SQL> ALTER DATABASE OPEN; Database altered.
xifenfei1:/home/grid$crsctl status res -t
--------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATA.dg
ONLINE ONLINE xifenfei1
ONLINE ONLINE xifenfei2
ora.FLASH.dg
ONLINE ONLINE xifenfei1
ONLINE ONLINE xifenfei2
ora.LISTENER.lsnr
ONLINE ONLINE xifenfei1
ONLINE ONLINE xifenfei2
ora.OCR.dg
ONLINE ONLINE xifenfei1
ONLINE ONLINE xifenfei2
ora.asm
ONLINE ONLINE xifenfei1 Started
ONLINE ONLINE xifenfei2 Started
ora.gsd
OFFLINE OFFLINE xifenfei1
OFFLINE OFFLINE xifenfei2
ora.net1.network
ONLINE ONLINE xifenfei1
ONLINE ONLINE xifenfei2
ora.ons
ONLINE ONLINE xifenfei1
ONLINE ONLINE xifenfei2
ora.registry.acfs
ONLINE ONLINE xifenfei1
ONLINE ONLINE xifenfei2
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
1 ONLINE ONLINE xifenfei1
ora.cvu
1 OFFLINE OFFLINE
ora.xifenfei1.vip
1 ONLINE ONLINE xifenfei1
ora.xifenfei2.vip
1 ONLINE ONLINE xifenfei2
ora.oc4j
1 ONLINE ONLINE xifenfei2
ora.orcl.db
1 ONLINE ONLINE xifenfei1 Open
2 ONLINE ONLINE xifenfei2 Open
ora.scan1.vip
1 ONLINE ONLINE xifenfei1
Oracle断电故障处理
异常断电导致数据库异常恢复文件报ORA-00283 ORA-00742 ORA-00312
D:\check_db>sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on 星期二 5月 31 00:38:42 2022 Copyright (c) 1982, 2013, Oracle. All rights reserved. 连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> recover datafile 1; ORA-00283: 恢复会话因错误而取消 ORA-00742: 日志读取在线程 %d 序列 %d 块 %d 中检测到写入丢失情况 ORA-00312: 联机日志 3 线程 1: 'D:\APP\ADMINISTRATOR\FAST_RECOVERY_AREA\ORCL\ONLINELOG\O1_MF_3_HJ32KJD5_.LOG'
这个错误比较明显是由于异常断电引起的写丢失导致.而且这种故障在没有备份的情况下,没有什么好处理方法,只能屏蔽一致性强制拉库,尝试强制拉库报错如下
SQL> startup mount pfile='d:/pfile.txt'
ORACLE 例程已经启动。
Total System Global Area 2.0310E+10 bytes
Fixed Size 2290000 bytes
Variable Size 3690991280 bytes
Database Buffers 1.6576E+10 bytes
Redo Buffers 40837120 bytes
数据库装载完毕。
SQL> recover database until cancel;
ORA-00279: 更改 18755939194213 (在 生成) 对于线程 1 是必需的
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
D:\APP\ADMINISTRATOR\FAST_RECOVERY_AREA\ORCL\ONLINELOG\O1_MF_3_HJ32KJD5_.LOG
ORA-00600: internal error code, arguments: [3020], [2], [78824], [8467432], [],
[], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 2, block# 78824, file
offset is 645726208 bytes)
ORA-10564: tablespace SYSAUX
ORA-01110: data file 2: 'D:\ORADATA\ORCL\SYSAUX01.DBF'
ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 80834
ORA-01112: 未启动介质恢复
SQL> alter database open resetlogs;
alter database open resetlogs
*
第 1 行出现错误:
ORA-00600: 内部错误代码, 参数: [krsi_al_hdr_update.15], [4294967295], [], [],[], [], [], [], [], [], [], []
ORA-600 krsi_al_hdr_update.15错误,主要是由于redo异常导致无法resetlogs成功,具体参考:Alter Database Open Resetlogs returns error ORA-00600: [krsi_al_hdr_update.15], (Doc ID 2026541.1)描述,处理这个问题之后,再次resetlogs库,报ORA-600 2662错误
SQL> alter database open resetlogs; alter database open resetlogs * 第 1 行出现错误: ORA-00603: ORACLE server session terminated by fatal error ORA-00600: internal error code, arguments: [2662], [4366], [4112122046], [4366], [4112228996], [12583040], [], [], [], [], [], [] ORA-00600: internal error code, arguments: [2662], [4366], [4112122045], [4366], [4112228996], [12583040], [], [], [], [], [], [] ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00600: internal error code, arguments: [2662], [4366], [4112122040], [4366], [4112228996], [12583040], [], [], [], [], [], [] 进程 ID: 4644 会话 ID: 1701 序列号: 3
这个问题比较简单,通过修改scn即可绕过去,之后数据库open报ORA-600 4194等错误
SQL> alter database open ; alter database open * 第 1 行出现错误: ORA-00600: 内部错误代码, 参数: [4194], [
SMON: enabling tx recovery Database Characterset is ZHS16GBK Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_smon_5112.trc (incident=322982): ORA-00600: internal error code, arguments: [4137], [10.33.3070116], [0], [0], [], [], [], [], [], [], [], [] Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\incident\incdir_322982\orcl_smon_5112_i322982.trc Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. ARC3: Archival started ARC0: STARTING ARCH PROCESSES COMPLETE replication_dependency_tracking turned off (no async multimaster replication found) LOGSTDBY: Validating controlfile with logical metadata LOGSTDBY: Validation complete Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_ora_3340.trc (incident=323030): ORA-00600: 内部错误代码, 参数: [4194], [ Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\incident\incdir_323030\orcl_ora_3340_i323030.trc Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Tue May 31 09:05:04 2022 Sweep [inc][322982]: completed ORACLE Instance orcl (pid = 13) - Error 600 encountered while recovering transaction (10, 33). Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_smon_5112.trc: ORA-00600: internal error code, arguments: [4137], [10.33.3070116], [0], [0], [], [], [], [], [], [], [], [] Checker run found 1 new persistent data failures Tue May 31 09:05:05 2022 Sweep [inc][323030]: completed Sweep [inc2][322982]: completed Tue May 31 09:05:14 2022 Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_smon_5112.trc (incident=322983): ORA-00600: internal error code, arguments: [4193], [10.33.3070116], [0], [], [], [], [], [], [], [], [], [] Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\incident\incdir_322983\orcl_smon_5112_i322983.trc Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Tue May 31 09:05:14 2022 ORA-600 signalled during: alter database open... Block recovery stopped at EOT rba 2.61.16 Block recovery completed at rba 2.61.16, scn 4366.4112429058 Block recovery from logseq 2, block 60 to scn 18755939643393 Recovery of Online Redo Log: Thread 1 Group 2 Seq 2 Reading mem 0 Mem# 0: D:\APP\ADMINISTRATOR\FAST_RECOVERY_AREA\ORCL\ONLINELOG\O1_MF_2_K9BSVC11_.LOG Block recovery completed at rba 2.61.16, scn 4366.4112429058 Dumping diagnostic data in directory=[cdmp_2022053],requested by(instance=1,osid=5112(SMON)),summary=[incident=322983]. Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_smon_5112.trc: ORA-01595: error freeing extent (3) of rollback segment (1)) ORA-00600: internal error code, arguments: [4193], [10.33.3070116], [3], [], [], [], [], [], [], [], [], []
对异常undo进行处理,数据库正常open成功
SQL> shutdown immediate; ORA-00600: 内部错误代码, 参数: [4193], [ SQL> shutdown abort; ORACLE 例程已经关闭。 SQL> startup mount ORACLE 例程已经启动。 Total System Global Area 2.0310E+10 bytes Fixed Size 2290000 bytes Variable Size 3690991280 bytes Database Buffers 1.6576E+10 bytes Redo Buffers 40837120 bytes 数据库装载完毕。 SQL> alter database open; 数据库已更改。
hcheck检测有一些字典不一致,建议客户逻辑导出,然后导入到新库中
HCheck Version 07MAY18 on 31-5月 -2022 09:12:22
----------------------------------------------
Catalog Version 11.2.0.4.0 (1102000400)
db_name: ORCL
Catalog Fixed
Procedure Name Version Vs Release Timestamp Resul
t
------------------------------ ... ---------- -- ---------- -------------- -----
-
.- LobNotInObj ... 1102000400 <= *All Rel* 05/31 09:12:22 PASS
.- MissingOIDOnObjCol ... 1102000400 <= *All Rel* 05/31 09:12:22 PASS
.- SourceNotInObj ... 1102000400 <= *All Rel* 05/31 09:12:22 PASS
.- OversizedFiles ... 1102000400 <= *All Rel* 05/31 09:12:22 PASS
.- PoorDefaultStorage ... 1102000400 <= *All Rel* 05/31 09:12:22 PASS
.- PoorStorage ... 1102000400 <= *All Rel* 05/31 09:12:22 PASS
.- TabPartCountMismatch ... 1102000400 <= *All Rel* 05/31 09:12:22 PASS
.- OrphanedTabComPart ... 1102000400 <= *All Rel* 05/31 09:12:22 PASS
.- MissingSum$ ... 1102000400 <= *All Rel* 05/31 09:12:22 PASS
.- MissingDir$ ... 1102000400 <= *All Rel* 05/31 09:12:22 PASS
.- DuplicateDataobj ... 1102000400 <= *All Rel* 05/31 09:12:22 PASS
.- ObjSynMissing ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- ObjSeqMissing ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- OrphanedUndo ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- OrphanedIndex ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- OrphanedIndexPartition ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- OrphanedIndexSubPartition ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- OrphanedTable ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- OrphanedTablePartition ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- OrphanedTableSubPartition ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- MissingPartCol ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- OrphanedSeg$ ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- OrphanedIndPartObj# ... 1102000400 <= *All Rel* 05/31 09:12:23 FAIL
HCKE-0024: Orphaned Index Partition Obj# (no OBJ$) (Doc ID 1360935.1)
ORPHAN INDPART$: OBJ#=149167 BO#=6378 - no OBJ$ row
ORPHAN INDPART$: OBJ#=149168 BO#=6378 - no OBJ$ row
.- DuplicateBlockUse ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- FetUet ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- Uet0Check ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- SeglessUET ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- BadInd$ ... 1102000400 <= *All Rel* 05/31 09:12:23 FAIL
HCKE-0030: OBJ$ INDEX entry has no IND$ or INDPART$/INDSUBPART$ entry (Doc ID 13
60528.1)
OBJ$ INDEX PARTITION has no INDPART$ entry: Obj#=148278 SYS Name=WRH$_FILESTATXS
_PK PARTITION=WRH$_FILEST_1572571104_16462
OBJ$ INDEX PARTITION has no INDPART$ entry: Obj#=148920 SYS Name=WRH$_FILESTATXS
_PK PARTITION=WRH$_FILEST_1572571104_16678
.- BadTab$ ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- BadIcolDepCnt ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- ObjIndDobj ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- TrgAfterUpgrade ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- ObjType0 ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- BadOwner ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- StmtAuditOnCommit ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- BadPublicObjects ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- BadSegFreelist ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- BadDepends ... 1102000400 <= *All Rel* 05/31 09:12:23 WARN
HCKW-0016: Dependency$ p_timestamp mismatch for VALID objects (Doc ID 1361045.1)
[E] - P_OBJ#=6376 D_OBJ#=6765
.- CheckDual ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- ObjectNames ... 1102000400 <= *All Rel* 05/31 09:12:23 PASS
.- BadCboHiLo ... 1102000400 <= *All Rel* 05/31 09:12:24 PASS
.- ChkIotTs ... 1102000400 <= *All Rel* 05/31 09:12:24 PASS
.- NoSegmentIndex ... 1102000400 <= *All Rel* 05/31 09:12:24 PASS
.- BadNextObject ... 1102000400 <= *All Rel* 05/31 09:12:24 PASS
.- DroppedROTS ... 1102000400 <= *All Rel* 05/31 09:12:24 PASS
.- FilBlkZero ... 1102000400 <= *All Rel* 05/31 09:12:24 PASS
.- DbmsSchemaCopy ... 1102000400 <= *All Rel* 05/31 09:12:24 PASS
.- OrphanedObjError ... 1102000400 > 1102000000 05/31 09:12:24 PASS
.- ObjNotLob ... 1102000400 <= *All Rel* 05/31 09:12:24 PASS
.- MaxControlfSeq ... 1102000400 <= *All Rel* 05/31 09:12:24 PASS
.- SegNotInDeferredStg ... 1102000400 > 1102000000 05/31 09:12:24 PASS
.- SystemNotRfile1 ... 1102000400 > 902000000 05/31 09:12:24 PASS
.- DictOwnNonDefaultSYSTEM ... 1102000400 <= *All Rel* 05/31 09:12:24 PASS
.- OrphanTrigger ... 1102000400 <= *All Rel* 05/31 09:12:24 PASS
.- ObjNotTrigger ... 1102000400 <= *All Rel* 05/31 09:12:24 PASS
---------------------------------------
31-5月 -2022 09:12:24 Elapsed: 2 secs
---------------------------------------
Found 4 potential problem(s) and 1 warning(s)
Contact Oracle Support with the output and trace file
to check if the above needs attention or not
PL/SQL 过程已成功完成。
发表在 Oracle备份恢复
标签为 krsi_al_hdr_update.15, ORA-00742, ORA-600 2662, ORA-600 4194, oracle异常恢复, oracle断电恢复
评论关闭
O/S-Error: (OS 23) 数据错误(循环冗余检查) 数据库恢复
有客户数据库运行过程中突然crash,检测发现ORA-27070 OSD-04016 O/S-Error: (OS 23) 等报错
Thu May 12 11:25:53 2022
KCF: write/open error block=0x19e95f online=1
file=57 H:\ORADATA\xifenfei\XFF51.DBF
error=27070 txt: 'OSD-04016: 异步 I/O 请求排队时出错。
O/S-Error: (OS 23) 数据错误(循环冗余检查)。'
Thu May 12 11:25:53 2022
Errors in file e:\oracle\product\10.2.0\admin\xifenfei\bdump\xifenfei_dbw0_3532.trc:
ORA-01242: 数据文件出现介质故障: 数据库处于 NOARCHIVELOG 模式
ORA-01114: 将块写入文件 57 时出现 IO 错误 (块 # 1698143)
ORA-01110: 数据文件 57: 'H:\ORADATA\xifenfei\XFF51.DBF'
ORA-27070: 异步读取/写入失败
OSD-04016: 异步 I/O 请求排队时出错。
O/S-Error: (OS 23) 数据错误(循环冗余检查)。
DBW0: terminating instance due to error 1242
Thu May 12 11:25:54 2022
Errors in file e:\oracle\product\10.2.0\admin\xifenfei\bdump\xifenfei_mman_3528.trc:
ORA-01242: 数据文件出现介质故障: 数据库处于 NOARCHIVELOG 模式
Thu May 12 11:25:54 2022
Errors in file e:\oracle\product\10.2.0\admin\xifenfei\bdump\xifenfei_lgwr_3544.trc:
ORA-01242: 数据文件出现介质故障: 数据库处于 NOARCHIVELOG 模式
Thu May 12 11:25:55 2022
Errors in file e:\oracle\product\10.2.0\admin\xifenfei\bdump\xifenfei_dbw1_3536.trc:
ORA-01242: 数据文件出现介质故障: 数据库处于 NOARCHIVELOG 模式
Thu May 12 11:25:55 2022
Errors in file e:\oracle\product\10.2.0\admin\xifenfei\bdump\xifenfei_psp0_3524.trc:
ORA-01242: 数据文件出现介质故障: 数据库处于 NOARCHIVELOG 模式
Thu May 12 11:25:55 2022
Errors in file e:\oracle\product\10.2.0\admin\xifenfei\bdump\xifenfei_ckpt_3548.trc:
ORA-01242: 数据文件出现介质故障: 数据库处于 NOARCHIVELOG 模式
Thu May 12 11:25:55 2022
Errors in file e:\oracle\product\10.2.0\admin\xifenfei\bdump\xifenfei_pmon_3520.trc:
ORA-01242: 数据文件出现介质故障: 数据库处于 NOARCHIVELOG 模式
Thu May 12 11:26:06 2022
Errors in file e:\oracle\product\10.2.0\admin\xifenfei\bdump\xifenfei_q002_37468.trc:
ORA-01242: 数据文件出现介质故障: 数据库处于 NOARCHIVELOG 模式
Thu May 12 11:26:08 2022
Errors in file e:\oracle\product\10.2.0\admin\xifenfei\bdump\xifenfei_reco_3556.trc:
ORA-01242: 数据文件出现介质故障: 数据库处于 NOARCHIVELOG 模式
Thu May 12 11:26:08 2022
Errors in file e:\oracle\product\10.2.0\admin\xifenfei\bdump\xifenfei_smon_3552.trc:
ORA-01242: 数据文件出现介质故障: 数据库处于 NOARCHIVELOG 模式
Thu May 12 11:26:10 2022
Instance terminated by DBW0, pid = 3532
再次重启数据库报错 ORA-27070: 异步读取/写入失败 OSD-04016: 异步 I/O 请求排队时出错。类似错误

dbv检查数据文件报异常

通过以上信息基本上可以确认是由于底层故障(文件系统或者硬件故障),导致数据库文件访问异常,检查系统日志发现异常

通过专业恢复软件对异常文件进行恢复,实现数据库正常open(跳过坏块)


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

