标签云
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-00600: internal error code, arguments: [16513], [1403] 恢复
接到客户请求,存储异常断电之后,一个40多T的经分数据库无法正常启动,通过各方一系列操作之后,数据库依旧无法open,报错信息为:ORA-00600: internal error code, arguments: [16513], [1403], [28]

Sun Feb 14 00:20:09 BEIST 2021 SMON: enabling cache recovery Sun Feb 14 00:20:09 BEIST 2021 ORA-01555 caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, SCN: 0x0f27.13cd4fc3): Sun Feb 14 00:20:09 BEIST 2021 select ctime, mtime, stime from obj$ where obj# = :1 Sun Feb 14 00:20:09 BEIST 2021 Errors in file /oracle10g/db/admin/xifenfei/udump/xifenfei1_ora_177254.trc: ORA-00600: internal error code, arguments: [16513], [1403], [28], [], [], [], [], [] Sun Feb 14 00:20:10 BEIST 2021 Errors in file /oracle10g/db/admin/xifenfei/udump/xifenfei1_ora_177254.trc: ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00600: internal error code, arguments: [16513], [1403], [28], [], [], [], [], [] Error 704 happened during db open, shutting down database USER: terminating instance due to error 704 Instance terminated by USER, pid = 177254 ORA-1092 signalled during: ALTER DATABASE OPEN...
通过对启动过程进行跟踪
=====================
PARSING IN CURSOR #5 len=52 dep=1 uid=0 oct=3 lid=0 tim=194171381576991 hv=429618617 ad='afcee60'
select ctime, mtime, stime from obj$ where obj# = :1
END OF STMT
PARSE #5:c=0,e=257,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,tim=194171381576990
BINDS #5:
kkscoacd
Bind#0
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0
kxsbbbfp=1104b8ed0 bln=22 avl=02 flg=05
value=28
EXEC #5:c=0,e=422,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,tim=194171381577472
WAIT #5: nam='db file sequential read' ela= 274 file#=1 block#=110 blocks=1 obj#=36 tim=194171381577809
WAIT #5: nam='db file sequential read' ela= 257 file#=1 block#=78943 blocks=1 obj#=36 tim=194171381578123
WAIT #5: nam='db file sequential read' ela= 253 file#=1 block#=111 blocks=1 obj#=36 tim=194171381578416
WAIT #5: nam='db file sequential read' ela= 226 file#=1 block#=62 blocks=1 obj#=18 tim=194171381578692
=====================
PARSING IN CURSOR #6 len=142 dep=2 uid=0 oct=3 lid=0 tim=194171381579134 hv=361892850 ad='df87eb0'
select /*+ rule */ name,file#,block#,status$,user#,undosqn,xactsqn,scnbas,scnwrp,
DECODE(inst#,0,NULL,inst#),ts#,spare1 from undo$ where us#=:1
END OF STMT
PARSE #6:c=0,e=368,p=0,cr=0,cu=0,mis=1,r=0,dep=2,og=3,tim=194171381579133
BINDS #6:
kkscoacd
Bind#0
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0
kxsbbbfp=1105af9a8 bln=22 avl=02 flg=05
value=92
EXEC #6:c=0,e=531,p=0,cr=0,cu=0,mis=1,r=0,dep=2,og=3,tim=194171381579736
WAIT #6: nam='db file sequential read' ela= 232 file#=1 block#=102 blocks=1 obj#=34 tim=194171381580011
WAIT #6: nam='db file sequential read' ela= 251 file#=1 block#=54 blocks=1 obj#=15 tim=194171381580307
FETCH #6:c=0,e=615,p=2,cr=2,cu=0,mis=0,r=1,dep=2,og=3,tim=194171381580369
STAT #6 id=1 cnt=1 pid=0 pos=1 obj=15 op='TABLE ACCESS BY INDEX ROWID UNDO$ (cr=2 pr=2 pw=0 time=584 us)'
STAT #6 id=2 cnt=1 pid=1 pos=1 obj=34 op='INDEX UNIQUE SCAN I_UNDO1 (cr=1 pr=1 pw=0 time=282 us)'
WAIT #5: nam='db file sequential read' ela= 260 file#=4290 block#=365090 blocks=1 obj#=0 tim=194171381580721
FETCH #5:c=10000,e=3327,p=7,cr=7,cu=0,mis=0,r=0,dep=1,og=4,tim=194171381580817
*** 2021-02-14 02:32:40.430
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [16513], [1403], [28], [], [], [], [], []
Current SQL statement for this session:
alter database open
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst+001c bl ksedst1 70000090FC00AE4 ? 000000000 ?
ksedmp+0290 bl ksedst 104C1CA58 ?
ksfdmp+02d8 bl 03F4BD0C
kgeriv+0108 bl _ptrgl
kgesiv+0080 bl kgeriv 7000008F6DB5890 ? 00000000C ?
7000008F6DB5890 ? 0FFFFFDC3 ?
0FFFFFFBF ?
ksesic2+0060 bl kgesiv 5FFFEC580 ? 500000000 ?
FFFFFFFFFFEC590 ? 0F5FAF808 ?
7000008F5FAF7E8 ?
kqdpts+0158 bl ksesic2 408100004081 ? 000000000 ?
00000057B ? 000000000 ?
00000001C ?
A006150571B05EF0 ?
1100CF0A8 ? 000000001 ?
kqrlfc+0274 bl kqdpts 000000000 ?
kqlbplc+00b4 bl 03F4E6A8
kqlblfc+0230 bl kqlbplc 00000009D ?
adbdrv+1a9c bl 03F4B66C
opiexe+2db4 bl adbdrv
opiosq0+1ac8 bl opiexe 1103B418C ? 000000000 ?
FFFFFFFFFFF9008 ?
kpooprx+016c bl opiosq0 300F1E1D4 ? 000000000 ?
000000000 ? A4FFFFFFFF9798 ?
000000000 ?
kpoal8+03cc bl kpooprx FFFFFFFFFFFB814 ?
FFFFFFFFFFFB5C0 ?
1300000013 ? 100000001 ?
000000000 ? A40000000000A4 ?
000000000 ? 1103B4378 ?
opiodr+0b2c bl _ptrgl
ttcpip+1020 bl _ptrgl
opitsk+117c bl 01FBD04C
opiino+09d0 bl opitsk 1EFFFFD7E0 ? 000000000 ?
opiodr+0b2c bl _ptrgl
opidrv+04a4 bl opiodr 3C102B1398 ? 404C6FF30 ?
FFFFFFFFFFFF7A0 ? 0102B1390 ?
sou2o+0090 bl opidrv 3C02705B3C ? 440663000 ?
FFFFFFFFFFFF7A0 ?
opimai_real+01bc bl 01FB9BF4
main+0098 bl opimai_real 000000000 ? 000000000 ?
__start+0098 bl main 000000000 ? 000000000 ?
--------------------- Binary Stack Dump ---------------------
报错比较明显,数据库在查询obj$取obj#=28的数据的时候无法正常获取到该数据,从而报错ORA-600 16513错误.通过对相关block进行分析,发现有事务异常
BBED> p ktbbh.ktbbhitl[1]
struct ktbbhitl[1], 24 bytes @44
struct ktbitxid, 8 bytes @44
ub2 kxidusn @44 0x5c00
ub2 kxidslt @46 0x0a00
ub4 kxidsqn @48 0x48b4fc01
struct ktbituba, 8 bytes @52
ub4 kubadba @52 0x22928531
ub2 kubaseq @56 0xe383
ub1 kubarec @58 0x01
ub2 ktbitflg @60 0x0120 (NONE)
union _ktbitun, 2 bytes @62
b2 _ktbitfsc @62 0
ub2 _ktbitwrp @62 0x0000
ub4 ktbitbas @64 0x95c2ff13
通过一些技巧处理规避掉该事务,然后启动库报熟悉的ORA-01555错误

相对比较简单参考(在数据库open过程中常遇到ORA-01555汇总),数据库顺利open成功,完成春节后第一个大库的恢复

.IQ0003后缀名勒索恢复
对应的HOW_TO_RECOVERY_FILES.txt文件内容为:
It's your IDENTIFER: 2EF9BE910E1AEBFF7FBD25107D5A10AAE4339771AD674E1A1F0046028B621009 FAA9B630BA4BB061874575AC0E0D42E2FCE86925E163A4005F43175D667E3846 47841028CC302707874E00127D3BC85E9FCE8AD523CD6B68CF3DCFB3FF6875EB 732842733231AA908EC047A68F658D14D4C3DE2C7C4E78846335367544DCC10F FD770BD8F1D29868067FE46DB43480CCEABCE012D9F1D4C1904AC8C86779DF4D E28E2EB268835AD5845FAE6EA1C679838E2FAC8F705FFDCBA891147F997F171B 6760E46E68CFBE9E511416CCBBBA46B57A20AEE1BEE1B15DF03178BD7B0A40B8 3D12424209E78ED267CAF1C6C594C8B5EF95FC239C532FEE75A4E430C642AB50 B942EA04068A2FDF6D6B67BB5C5697B0B5678449D1FB7A2464E0F2C307577E97 E1D21799C64BF9762187930BE2D10F4408DD4258255313E880724FC07A173EFE E17E75E542AA1BB83C9500DE6829EC00BF90578A2D781740D1C173BCF0BF656F 51260E94D2398FE5ADD316C52D82F63A0B7FA00F9812911E32C412AC788D4AE1 9DBEE9EA9B398C0307F4C3326E07712162DCC0EF7EA7CCEB77246F718721EE89 837F4E36BB987094507E3FF5E7C1ABECBA764BDAE1B4BCF337B09413CABE5621 875E72CF70A1B70F48185A121E75E44B29CF0E211E76BC3CE41E9097200B2D97 E62ABF49B37832003D78DC3DD482DE62FDA4EEBA445AF323846C530A29FEC09D 7E63543CF2ED96AD0A076AB578C6450B2EFF5D4663B9F9C546B40605ED801218 CBB2B3B641120216F2E94EE6A4B04E115341897323E160316A9BE35FF6B75D4A 9487EF923E0575DB34A85241888FB507A25BA1FE26ACEB81579796F8B5BEE818 C3D3548EACF82D80B002ACFA5C7B0B08042B5DDDE764473628057D97EC3584A3 DFC33147A973EC7FD81051F0AA741E2C79BDC7EC28B0774A00A4E74A3F1AFB76 B6DFDDB6B956896094267F52BC661806159757A0485157A5E61D9AF45532CED9 21D99EA1DBB27C15DE8547E7A9E06A7B2708251740246DA07BD9E33F513F2165 D935C7B7597B347C41CDBCF6275E2365639C10BB9A0C84F178B258B8BCC33F86 C46A5E431267C27141BA27A53BBBB57000B230D35CE1889E3E790A8072BE8E93 9F721DFBD6D26C000B HELLO All YOU FILES ENCRYPTED If you need recover your files: 1)send message with your personal IDENTIFER to helpyouhelpyou@cock.li and add 1 infected files from your server! 2)speak only by ENGLISH! 3)doesn't use free decryption tools, you can damage your files! ONLY helpyouhelpyou@cock.li can HELP YOU! helpyouhelpyou@cock.li helpyouhelpyou@cock.li helpyouhelpyou@cock.li
通过底层技术处理,实现绝大部分数据恢复

如果此类的数据库文件(oracle,mysql,sql server)等被加密,需要专业恢复技术支持,请联系我们:
电话/微信:17813235971 Q Q:107644445
E-Mail:dba@xifenfei.com






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

