标签云
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备份恢复
云主机快照之后Oracle无法正常启动处理
某客户数据库放在x云上面,需要对数据库盘进行扩容,在扩容之前对该盘做了快照,结果没有想到悲剧发生了
[root@xifenfei ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/vda1 99G 64G 31G 68% / devtmpfs 16G 0 16G 0% /dev tmpfs 16G 0 16G 0% /dev/shm tmpfs 16G 720K 16G 1% /run tmpfs 16G 0 16G 0% /sys/fs/cgroup /dev/vdb 2.0T 1.2T 910G 56% /www/xifenfei tmpfs 3.2G 0 3.2G 0% /run/user/1004 tmpfs 3.2G 0 3.2G 0% /run/user/0
如上显示,客户的数据文件都放在/dev/vdb中了,但是很不幸,redo文件放在/data中(也就是vda磁盘组中),没有被做快照,结果客户还原vdb快照之后,发现现象如下
SQL> set pages 10000 SQL> set numw 16 SQL> SELECT status, 2 checkpoint_change#, 3 checkpoint_time,last_change#, 4 count(*) ROW_NUM 5 FROM v$datafile 6 GROUP BY status, checkpoint_change#, checkpoint_time,last_change# 7 ORDER BY status, checkpoint_change#, checkpoint_time; STATUS CHECKPOINT_CHANGE# CHECKPOINT_T LAST_CHANGE# ROW_NUM -------------- ------------------ ------------ ---------------- ---------------- ONLINE 69632585947 04-JUL-22 38 SYSTEM 69632585947 04-JUL-22 2 SQL> set numw 16 SQL> col CHECKPOINT_TIME for a40 SQL> set lines 150 SQL> set pages 1000 SQL> SELECT status, 2 to_char(checkpoint_time,'yyyy-mm-dd hh24:mi:ss') checkpoint_time,FUZZY,checkpoint_change#, 3 count(*) ROW_NUM 4 FROM v$datafile_header 5 GROUP BY status, checkpoint_change#, to_char(checkpoint_time,'yyyy-mm-dd hh24:mi:ss'),fuzzy 6 ORDER BY status, checkpoint_change#, checkpoint_time; STATUS CHECKPOINT_TIME FUZZY CHECKPOINT_CHANGE# ROW_NUM -------------- ---------------------------------------- ------ ------------------ ---------------- ONLINE 2022-07-04 09:03:24 YES 69631105424 40
通过上述分析,该库相当数据文件和redo文件之间相差了一段时间数据,而且该库为非归档,基于这种情况,该库只能强制打开,在打开过程中遇到ORA-600 ktpridestroy2错误
SMON: enabling tx recovery Database Characterset is AL32UTF8 No Resource Manager plan active replication_dependency_tracking turned off (no async multimaster replication found) SMON: Restarting fast_start parallel rollback Errors in file /data/oracle/diag/rdbms/orcl/orcl/trace/orcl_smon_7332.trc (incident=41257): ORA-00600: internal error code, arguments: [ktpridestroy2], [], [], [], [], [], [], [], [], [], [], [] Incident details in: /data/oracle/diag/rdbms/orcl/orcl/incident/incdir_41257/orcl_smon_7332_i41257.trc Starting background process QMNC Mon Jul 04 16:31:44 2022 QMNC started with pid=36, OS id=7454 LOGSTDBY: Validating controlfile with logical metadata LOGSTDBY: Validation complete Fatal internal error happened while SMON was doing active transaction recovery. Errors in file /data/oracle/diag/rdbms/orcl/orcl/trace/orcl_smon_7332.trc: ORA-00600: internal error code, arguments: [ktpridestroy2], [], [], [], [], [], [], [], [], [], [], [] SMON (ospid: 7332): terminating the instance due to error 474 Instance terminated by SMON, pid = 7332
对应trace文件
Dump continued from file: /data/oracle/diag/rdbms/orcl/orcl/trace/orcl_smon_7332.trc
ORA-00600: internal error code, arguments: [ktpridestroy2], [], [], [], [], [], [], [], [], [], [], []
========= Dump for incident 41257 (ORA 600 [ktpridestroy2]) ========
*** 2022-07-04 16:31:44.261
dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)
----- SQL Statement (None) -----
Current SQL information unavailable - no cursor.
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
skdstdst()+36 call kgdsdst() 000000000 ? 000000000 ?
7FFCD123B998 ? 000000001 ?
7FFCD123FE98 ? 000000000 ?
ksedst1()+98 call skdstdst() 000000000 ? 000000000 ?
7FFCD123B998 ? 000000001 ?
000000000 ? 000000000 ?
ksedst()+34 call ksedst1() 000000000 ? 000000001 ?
7FFCD123B998 ? 000000001 ?
000000000 ? 000000000 ?
dbkedDefDump()+2736 call ksedst() 000000000 ? 000000001 ?
7FFCD123B998 ? 000000001 ?
000000000 ? 000000000 ?
ksedmp()+36 call dbkedDefDump() 000000003 ? 000000002 ?
7FFCD123B998 ? 000000001 ?
000000000 ? 000000000 ?
ksfdmp()+64 call ksedmp() 000000003 ? 000000002 ?
7FFCD123B998 ? 000000001 ?
000000000 ? 000000000 ?
dbgexPhaseII()+1764 call ksfdmp() 000000003 ? 000000002 ?
7FFCD123B998 ? 000000001 ?
000000000 ? 000000000 ?
dbgexProcessError() call dbgexPhaseII() 7F3C5D15C6F0 ? 7F3C5A851598 ?
+2279 7FFCD1247C88 ? 000000001 ?
000000000 ? 000000000 ?
dbgeExecuteForError call dbgexProcessError() 7F3C5D15C6F0 ? 7F3C5A851598 ?
()+83 000000001 ? 000000000 ?
7FFC00000000 ? 000000000 ?
dbgePostErrorKGE()+ call dbgeExecuteForError 7F3C5D15C6F0 ? 7F3C5A851598 ?
1615 () 000000001 ? 000000001 ?
000000000 ? 000000000 ?
dbkePostKGE_kgsf()+ call dbgePostErrorKGE() 000000000 ? 7F3C5A6C1228 ?
63 000000258 ? 7F3C5A851598 ?
000000000 ? 000000000 ?
kgeadse()+383 call dbkePostKGE_kgsf() 00A984C60 ? 7F3C5A6C1228 ?
000000258 ? 7F3C5A851598 ?
000000000 ? 000000000 ?
kgerinv_internal()+ call kgeadse() 00A984C60 ? 7F3C5A6C1228 ?
45 000000258 ? 000000000 ?
000000000 ? 000000000 ?
kgerinv()+33 call kgerinv_internal() 00A984C60 ? 7F3C5A6C1228 ?
D124022000000000 ?
000000258 ? 000000000 ?
000000000 ?
kgeasnmierr()+143 call kgerinv() 00A984C60 ? 7F3C5A6C1228 ?
D124022000000000 ?
000000000 ? 000000000 ?
000000000 ?
ktpridestroy()+912 call kgeasnmierr() 00A984C60 ? 7F3C5A6C1228 ?
D124022000000000 ?
000000000 ? 1E0F02D40 ?
1EC6DA410 ?
ktprw1s()+527 call ktpridestroy() D124022000000000 ?
000000000 ? 1E7A1C2B0 ?
000000000 ? 1E0F02D40 ?
1EC6DA410 ?
ktprsched()+197 call ktprw1s() D124022000000000 ?
000000000 ? 1E7A1C2B0 ?
000000000 ? 1E0F02D40 ?
1EC6DA410 ?
kturRecoverUndoSegm call ktprsched() D124022000000000 ?
ent()+1057 000000000 ? 1E7A1C2B0 ?
000000000 ? 1E0F02D40 ?
1EC6DA410 ?
kturRecoverActiveTx call kturRecoverUndoSegm 000000000 ? 000000000 ?
ns()+710 ent() 000000001 ? 000000000 ?
0D124FFFF ? 6200000005 ?
ktprbeg()+2506 call kturRecoverActiveTx 000000004 ? 000000000 ?
ns() 000000027 ? 000000000 ?
0D124FFFF ? 6200000005 ?
ktmmon()+13588 call ktprbeg() 000000000 ? 000000000 ?
000000027 ? 000000000 ?
0D124FFFF ? 6200000005 ?
ktmSmonMain()+201 call ktmmon() 06002DEC0 ? 000000000 ?
000000027 ? 000000000 ?
0D124FFFF ? 6200000005 ?
ksbrdp()+923 call ktmSmonMain() 06002DEC0 ? 000000000 ?
000000000 ? 000000000 ?
0D124FFFF ? 6200000005 ?
opirip()+618 call ksbrdp() 06002DEC0 ? 000000000 ?
000000000 ? 000000000 ?
0D124FFFF ? 6200000005 ?
opidrv()+598 call opirip() 000000032 ? 000000004 ?
7FFCD124B658 ? 000000000 ?
0D124FFFF ? 6200000005 ?
sou2o()+98 call opidrv() 000000032 ? 000000004 ?
7FFCD124B658 ? 000000000 ?
0D124FFFF ? 6200000005 ?
opimai_real()+261 call sou2o() 7FFCD124B630 ? 000000032 ?
000000004 ? 7FFCD124B658 ?
0D124FFFF ? 6200000005 ?
ssthrdmain()+209 call opimai_real() 000000000 ? 7FFCD124B820 ?
000000004 ? 7FFCD124B658 ?
0D124FFFF ? 6200000005 ?
main()+196 call ssthrdmain() 000000003 ? 7FFCD124B820 ?
000000001 ? 000000000 ?
0D124FFFF ? 6200000005 ?
__libc_start_main() call main() 000000003 ? 7FFCD124B9C0 ?
+245 000000001 ? 000000000 ?
0D124FFFF ? 6200000005 ?
_start()+36 call __libc_start_main() 0009C12F0 ? 000000001 ?
7FFCD124B9B8 ? 000000000 ?
0D124FFFF ? 6200000005 ?
--------------------- Binary Stack Dump ---------------------
通过分析确认该错误和并行恢复有关系,绕过该错误之后,再次尝试启动库报错为ORA-600 4137
Mon Jul 04 16:33:41 2022 SMON: enabling cache recovery Verifying file header compatibility for 11g tablespace encryption.. Verifying 11g file header compatibility for tablespace encryption completed SMON: enabling tx recovery Database Characterset is AL32UTF8 Errors in file /data/oracle/diag/rdbms/orcl/orcl/trace/orcl_smon_7554.trc (incident=42457): ORA-00600: internal error code, arguments: [4137], [6.11.21484016], [0], [0], [], [], [], [], [], [], [], [] Incident details in: /data/oracle/diag/rdbms/orcl/orcl/incident/incdir_42457/orcl_smon_7554_i42457.trc Stopping background process MMNL Errors in file /data/oracle/diag/rdbms/orcl/orcl/trace/orcl_smon_7554.trc: ORA-00339: archived log does not contain any redo ORA-00334: archived log: '/data/oracle/oradata/orcl/redo03.log' ORA-00600: internal error code, arguments: [4137], [6.11.21484016], [0], [0], [], [], [], [], [], [], [], [] Errors in file /data/oracle/diag/rdbms/orcl/orcl/trace/orcl_smon_7554.trc: ORA-00339: archived log does not contain any redo ORA-00334: archived log: '/data/oracle/oradata/orcl/redo03.log' ORA-00600: internal error code, arguments: [4137], [6.11.21484016], [0], [0], [], [], [], [], [], [], [], [] ORACLE Instance orcl (pid = 13) - Error 600 encountered while recovering transaction (6, 11). Errors in file /data/oracle/diag/rdbms/orcl/orcl/trace/orcl_smon_7554.trc: ORA-00600: internal error code, arguments: [4137], [6.11.21484016], [0], [0], [], [], [], [], [], [], [], []
该错误比较常见,一般是由于undo中有异常事务,对异常事务进行处理,数据库open成功,并顺利导入数据到新库中,完成本次数据恢复
发表在 Oracle备份恢复
标签为 ktpridestroy2, ORA-600 4137, ORA-600 ktpridestroy2, 云主机oracle恢复, 云主机快照oracle恢复
评论关闭
ORA-600 2032故障处理
有客户数据库,异常断电之后,数据库运行不稳定(经常性的重启),通过分析发现
Wed Jun 29 01:04:39 2022 Completed: alter database open Wed Jun 29 01:04:42 2022 Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_j000_3284.trc: ORA-12012: error on auto execute of job 1 ORA-01578: ORACLE data block corrupted (file # 2, block # 552) ORA-01110: data file 2: 'E:\ORACLE\PRODUCT\10.2.0\ORADATA_2\ORCL\UNDOTBS01.DBF' ………… Wed Jun 29 01:13:28 2022 Non-fatal internal error happenned while SMON was doing logging scn->time mapping. SMON encountered 1 out of maximum 100 non-fatal internal errors. Wed Jun 29 01:15:34 2022 Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_m000_5488.trc: ORA-00600: internal error code, arguments: [6002], [6], [48], [5], [0], [], [], [] Wed Jun 29 01:20:54 2022 Non-fatal internal error happenned while SMON was doing logging scn->time mapping. SMON encountered 2 out of maximum 100 non-fatal internal errors. Wed Jun 29 01:20:55 2022 Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_smon_6956.trc: ORA-00600: internal error code, arguments: [2032], [8389160], [8389160], [8192], [2], [255], [0], [767] Non-fatal internal error happenned while SMON was doing flushing of monitored table stats. SMON encountered 3 out of maximum 100 non-fatal internal errors. Wed Jun 29 01:20:57 2022 Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_smon_6956.trc: ORA-00600: internal error code, arguments: [2032], [8389160], [8389160], [8192], [2], [255], [0], [767] ……………… Wed Jun 29 01:21:41 2022 Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_q001_2124.trc: ORA-00474: SMON process terminated with error Wed Jun 29 01:21:42 2022 Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_dbw0_3376.trc: ORA-00474: SMON process terminated with error Wed Jun 29 01:21:42 2022 Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_reco_2412.trc: ORA-00474: SMON process terminated with error Instance terminated by PMON, pid = 7160
对ora-600 2032进行分析
*** 2022-06-29 01:13:26.907
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [2032], [8389160], [8389160], [8192], [2], [255], [0], [767]
Current SQL statement for this session:
insert into smon_scn_time (thread, time_mp, time_dp, scn, scn_wrp, scn_bas, num_mappings,
tim_scn_map) values (0, :1, :2, :3, :4, :5, :6, :7)
check trace file e:\oracle\product\10.2.0\db_2\rdbms\trace\orcl_ora_0.trc for preloading .sym file messages
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedmp+663 CALL??? ksedst+55 003C878B8 000000000 00FF57178
000000000
ksfdmp+19 CALL??? ksedmp+663 000000003 00ED07680 010453DA8
003CACC80
kgeriv+184 CALL??? ksfdmp+19 7FF2378C000 7FF5E2F81D8
7FF5EBB9300 7FF5EBB92F0
kgesiv+102 CALL??? kgeriv+184 000000002 00ED07040 000000002
00FF59110
ksesic7+125 CALL??? kgesiv+102 7FFFFFFF00800228 100000002
200000001 00FF59328
kcopcv+1014 CALL??? ksesic7+125 0000007F0 000000000 000800228
000000000
kcbchg1_main+3115 CALL??? kcopcv+1014 00001E778 7FF00000001
00001E980 00001E650
kcbchg1+238 CALL??? kcbchg1_main+3115 00ED07040 00ED07040 000040013
000000000
ktuchg+1331 CALL??? kcbchg1+238 7FF00000000 000000003
00FF597C8 00FF59780
ktbchg2+341 CALL??? ktuchg+1331 000000000 000000401 000000046
000BB5D21
kdtchg+916 CALL??? ktbchg2+341 000000001 000000000 000000240
000000000
kdtwrp+2582 CALL??? kdtchg+916 01077A268 01044404C 010444054
010441710
kdtInsRow+705 CALL??? kdtwrp+2582 01077A268 7FF5E2F8510
003CB3358 0009C20C4
insrowFastPath+125 CALL??? kdtInsRow+705 00ED07040 7FF55A86E30
7FF58E87918 00001F318
insdrvFastPath+478 CALL??? insrowFastPath+125 000000067 000000000 000000000
000000000
inscovexe+434 CALL??? insdrvFastPath+478 01077A268 000000000 010440070
00521E0C9
insExecStmtExecIniE CALL??? inscovexe+434 7FF55A88FD8 7FF55A86E30
ngine+99 00FF5BAD8 0009FA3EC
insexe+453 CALL??? insExecStmtExecIniE 8B2D554D9623 000000006
ngine+99 000000006 0000000C0
opiexe+4991 CALL??? insexe+453 7FF55A885A0 00FF5BAD8
000000102 000000000
opiall0+1931 CALL??? opiexe+4991 7FF00000049 000000003
00FF5C160 000000020
opikpr+660 CALL??? opiall0+1931 000000065 000000022 00FF5C638
000000000
opiodr+1136 CALL??? opikpr+660 000000065 000000017 01044B798
07EEF1FCF
rpidrus+230 CALL??? opiodr+1136 000000065 000000017 01044B798
80005900000000
rpidru+112 CALL??? rpidrus+230 00FF5D3F0 000000003 01078D4A0
7FF5B6F1A80
rpiswu2+517 CALL??? rpidru+112 7FF5DA52BB8 000000000
000000000 000000008
kprball+1446 CALL??? rpiswu2+517 7FF5E408820 000000000
00FF5DAD0 000000002
ktf_scn_time+4951 CALL??? kprball+1446 01044B798 8B2D00000140
000000000 000000005
ktmmon+4107 CALL??? ktf_scn_time+4951 000000000 000000001 07FFFFFFF
00521A3C2
ktmSmonMain+26 CALL??? ktmmon+4107 0049CBAC0 000000004
8B2D554D9623 00001E768
ksbrdp+903 CALL??? ktmSmonMain+26 003CC2A18 0049CBADC 000000008
000000004
opirip+700 CALL??? ksbrdp+903 726F77740000001E 003C8B000
00FF5FA30 000000000
opidrv+860 CALL??? opirip+700 000000032 000000004 00FF5FD50
000000000
sou2o+52 CALL??? opidrv+860 000000032 000000004 00FF5FD50
000000003
opimai_real+272 CALL??? sou2o+52 000000000 000000000 000000000
000000000
opimai+96 CALL??? opimai_real+272 000000000 000000000 000000000
000000000
BackgroundThreadSta CALL??? opimai+96 00FF5FEA8 000000001 000000000
rt+633 000000000
000000007738F56D CALL??? BackgroundThreadSta 0069E4590 000000000 000000000
rt+633 000000000
0000000077703021 CALL??? 000000007738F56D 000000000 000000000 000000000
000000000
--------------------- Binary Stack Dump ---------------------
通过该trace和alert日志信息可以确认是由于smon_scn_time的操作需要使用到undo,但是对应的undo block异常,从而使得该操作失败,进而引起数据库smon进程异常从而引起ORA-00474,数据库自动crash.处理问题比较简单:
1. 对异常undo进行处理,创建新undo,删除老undo
2. 对于smon_scn_time异常数据进行处理
Oracle Recovery Tools实战批量坏块修复
有客户数据库无法正常启动ORA-600 6711错误
SQL> startup mount pfile='d:/pfile.txt' ORACLE instance started. Total System Global Area 4294964032 bytes Fixed Size 9036608 bytes Variable Size 889192448 bytes Database Buffers 3388997632 bytes Redo Buffers 7737344 bytes Database mounted. SQL> alter database open ; alter database open * ERROR at line 1: ORA-00603: ORACLE server session terminated by fatal error ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00600: internal error code, arguments: [6711], [4313028], [1], [4309898], [0], [], [], [], [], [], [], [] Process ID: 22708 Session ID: 978 Serial number: 56675
alert日志报错
2022-06-26T12:34:41.855326+08:00 alter database open 2022-06-26T12:34:41.984974+08:00 Ping without log force is disabled: instance mounted in exclusive mode. Endian type of dictionary set to little Undo initialization finished serial:0 start:313418906 end:313418906 diff:0 ms (0.0 seconds) Database Characterset is ZHS16GBK No Resource Manager plan active 2022-06-26T12:34:43.302315+08:00 Errors in file C:\APP\XFF\diag\rdbms\orcl\ora19c\trace\ora19c_ora_22708.trc (incident=38629): ORA-00600: internal error code, arguments: [6711], [4313028], [1], [4309898], [0], [], [], [], [], [], [], [] Incident details in: C:\APP\XFF\diag\rdbms\orcl\ora19c\incident\incdir_38629\ora19c_ora_22708_i38629.trc Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. 2022-06-26T12:34:44.232115+08:00 ***************************************************************** An internal routine has requested a dump of selected redo. This usually happens following a specific internal error, when analysis of the redo logs will help Oracle Support with the diagnosis. It is recommended that you retain all the redo logs generated (by all the instances) during the past 12 hours, in case additional redo dumps are required to help with the diagnosis. ***************************************************************** 2022-06-26T12:34:44.315431+08:00 Errors in file C:\APP\XFF\diag\rdbms\orcl\ora19c\trace\ora19c_ora_22708.trc: ORA-00600: internal error code, arguments: [6711], [4313028], [1], [4309898], [0], [], [], [], [], [], [], [] 2022-06-26T12:34:44.315431+08:00 Errors in file C:\APP\XFF\diag\rdbms\orcl\ora19c\trace\ora19c_ora_22708.trc: ORA-00600: internal error code, arguments: [6711], [4313028], [1], [4309898], [0], [], [], [], [], [], [], [] Error 600 happened during db open, shutting down database Errors in file C:\APP\XFF\diag\rdbms\orcl\ora19c\trace\ora19c_ora_22708.trc (incident=38630): ORA-00603: ORACLE server session terminated by fatal error ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00600: internal error code, arguments: [6711], [4313028], [1], [4309898], [0], [], [], [], [], [], [], [] Incident details in: C:\APP\XFF\diag\rdbms\orcl\ora19c\incident\incdir_38630\ora19c_ora_22708_i38630.trc 2022-06-26T12:34:45.266678+08:00 opiodr aborting process unknown ospid (22708) as a result of ORA-603 2022-06-26T12:34:45.274688+08:00 ORA-603 : opitsk aborting process License high water mark = 1 USER (ospid: (prelim)): terminating the instance due to ORA error
通过分析trace文件进行分析,确认是由于histgrm$表异常导致,通过一些特殊处理,绕过该表相关sql,open数据库,并且尝试导出数据
SQL> startup mount pfile='d:/pfile.txt'; ORACLE instance started. Total System Global Area 4294964032 bytes Fixed Size 9036608 bytes Variable Size 889192448 bytes Database Buffers 3388997632 bytes Redo Buffers 7737344 bytes Database mounted. SQL> SQL> SQL> alter database open; Database altered.
通过分析是由于system有坏块导致,dbv检查文件

通过Oracle Recovery Tools工具批量坏块修复功能修复


通过工具修复大量主要坏块被修复,还有一些内部逻辑错误(后续工具继续完善),再次尝试逻辑导出数据,无任何报错,数据比较完美恢复

发表在 小工具, 非常规恢复
标签为 expdp ora-1578, ORA-600 6711, Oracle Recovery Tools, Oracle Recovery Tools修复坏块, 恢复修复
评论关闭



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

