标签云
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,880)
- DB2 (22)
- MySQL (82)
- Oracle (1,705)
- 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安装升级 (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)
-
最近发表
- 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故障恢复
- Oracle Block Edit Tool (obet) 功能增强–2026.07
- Oracle 19c 202607补丁(RUs+OJVM)-19.32
- Patch_SCN快速修复ORA-01555数据库open故障
分类目录归档:Oracle
对恢复案例:因对工作调整不满,链家一员工删除公司 9 TB数据:被判7年事件有感
从业生涯中恢复过各种删库的场景(有恶意,有无意),有rm数据库,rm数据文件,drop 数据库,dd asm磁盘头,drop table,truncate table,delete table等等.
两年前的一次给链家恢复EBS数据库案例,数据库服务器被人恶意rm 删除了/u01,/u02,rman备份目录等文件(还有ebs服务器相关程序也被删除,由另外一家公司对其进行处理),导致oracle集群异常,无可用备份恢复,通过对asm磁盘组直接恢复,实现数据0丢失.最近有了法院的终审判决:
北京市海淀区人民法院认为,被告人韩冰违反国家规定,对计算机信息系统中存储的数据和应用程序进行删除,造成计算机信息系统不能正常运行,后果特别严重,其行为已构成破坏计算机信息系统罪,依法应予惩处.海淀法院判决:被告人韩冰犯破坏计算机信息系统罪,判处有期徒刑七年。
由衷的感慨一个40岁的老dba,为了一时的赌气冲动的做出了错误的事情,需要使用自己的7年青春去弥补,实在不值得.

具体的关于判决的描述,参考:因对工作调整不满,链家一员工删除公司 9 TB数据:被判7年
我们做dba的,把握了企业的数据命脉,是很多企业最核心的资产,切莫因为一些工作/生活中的赌气去破坏数据库,引起系统无法正常使用,甚至导致数据丢失,给企业带来损失的同时,也让自己失去自由.
对于我们维护的数据库:切莫冲动!!!切莫冲动!!!切莫冲动!!!
发表在 Oracle
评论关闭
ORA-27303: failure occurred at: skgpwinit6
在客户联系我们,数据库在运行过程中突然报ORA-27140 ORA-27300 ORA-27301 ORA-27302 ORA-27303: failure occurred at: skgpwinit6错误

通过Startup Instance Failed with ORA-27140 ORA-27300 ORA-27301 ORA-27302 and ORA-27303on skgpwinit6 (Doc ID 1274030.1)分析,确认可能是由于$ORACLE_HOME/bin/oracle文件权限异常导致,通过分析确认是有系统被chmod修改了权限导致数据库异常.把oracle全下修改为chmod 6751 oracle后,数据库启动正常
ORA-600 kffmLoad_1 kffmVerify_4
有朋友asm运行一段时间asm实例会报错导致数据库实例异常
Wed Dec 23 08:31:55 2020 Errors in file /u01/app/oracle/admin/+ASM/bdump/+asm1_asmb_6729.trc: ORA-00600: internal error code, arguments: [kffmLoad_1], [4365], [1], [], [], [], [], [] Wed Dec 23 08:31:55 2020 Errors in file /u01/app/oracle/admin/+ASM/bdump/+asm1_asmb_6729.trc: ORA-00600: internal error code, arguments: [kffmLoad_1], [4365], [1], [], [], [], [], [] Errors in file /u01/app/oracle/admin/+ASM/bdump/+asm1_asmb_29743.trc: ORA-00600: internal error code, arguments: [kffmLoad_1], [670], [1], [], [], [], [], [] Wed Dec 23 09:10:22 2020 Errors in file /u01/app/oracle/admin/+ASM/bdump/+asm1_asmb_29743.trc: ORA-00600: internal error code, arguments: [kffmLoad_1], [670], [1], [], [], [], [], [] Wed Dec 23 09:10:22 2020 Wed Dec 23 10:18:33 2020 Errors in file /u01/app/oracle/admin/+ASM/udump/+asm1_ora_25890.trc: ORA-00600: internal error code, arguments: [kffmVerify_4], [0], [0], [887], [1005986561], [1352], [1], [0]
对应的trace文件
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
ORACLE_HOME = /u01/app/oracle/product/10.2.0/db
System name: Linux
Node name: shb01
Release: 2.6.18-348.el5
Version: #1 SMP Wed Nov 28 21:22:00 EST 2012
Machine: x86_64
Instance name: +ASM1
Redo thread mounted by this instance: 0 <none>
Oracle process number: 29
Unix process pid: 26337, image: oracle@xff01 (TNS V1-V3)
*** ACTION NAME:() 2020-12-22 19:03:41.272
*** MODULE NAME:(sp_ocap@xff01 (TNS V1-V3)) 2020-12-22 19:03:41.272
*** SERVICE NAME:() 2020-12-22 19:03:41.272
*** SESSION ID:(143.1) 2020-12-22 19:03:41.272
*** 2020-12-22 19:03:41.272
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [kffmVerify_4], [0], [0], [1657], [1005987045], [152], [1], [0]
Current SQL statement for this session:
DECLARE
fileType varchar2(16);
fileName varchar2(1024);
blkSz number;
fileSz number;
hdl number;
plksz number;
BEGIN
fileName := '+DATA4/xifenfei/onlinelog/group_6.1657.1005987045';
BEGIN
dbms_diskgroup.getfileattr(fileName,fileType,fileSz, blkSz);
dbms_diskgroup.open(fileName,'r',fileType,blkSz,hdl,plkSz,fileSz);
EXCEPTION
WHEN OTHERS then
:rc := SQLCODE;
:err_msg := SQLERRM;
return;
END;
:handle := hdl;
:bsz := blkSz;
:bcnt := fileSz;
:rc := 0;
END;
----- PL/SQL Call Stack -----
object line object
handle number name
0x15ce59360 96 package body SYS.X$DBMS_DISKGROUP
0x15cd88568 12 anonymous block
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst()+31 call ksedst1() 000000000 ? 000000001 ?
7FFFBDFC3450 ? 7FFFBDFC34B0 ?
7FFFBDFC33F0 ? 000000000 ?
ksedmp()+610 call ksedst() 000000000 ? 000000001 ?
7FFFBDFC3450 ? 7FFFBDFC34B0 ?
7FFFBDFC33F0 ? 000000000 ?
ksfdmp()+21 call ksedmp() 000000003 ? 000000001 ?
7FFFBDFC3450 ? 7FFFBDFC34B0 ?
7FFFBDFC33F0 ? 000000000 ?
kgerinv()+161 call ksfdmp() 000000003 ? 000000001 ?
7FFFBDFC3450 ? 7FFFBDFC34B0 ?
7FFFBDFC33F0 ? 000000000 ?
kgeasnmierr()+163 call kgerinv() 0068996E0 ? 009AA2670 ?
7FFFBDFC34B0 ? 7FFFBDFC33F0 ?
000000000 ? 000000000 ?
kffmVerify()+379 call kgeasnmierr() 0068996E0 ? 009AA2670 ?
7FFFBDFC34B0 ? 7FFFBDFC33F0 ?
000000000 ? 000000000 ?
kfioIdentify()+1276 call kffmVerify() 000000000 ? 00000000D ?
000000001 ?
927B814400000004 ?
3BF624E500000679 ?
000000000 ?
ksfd_osmopn()+1138 call kfioIdentify() 7FFFBDFC4820 ? 15DB873F4 ?
15DB87556 ? 000000200 ?
7FFF00000003 ? 15DB873C8 ?
ksfdopn()+1014 call ksfd_osmopn() 7FFFBDFC4820 ? 00000002D ?
000000200 ? 000000003 ?
2B3800020000 ? 15F3031F0 ?
kfpkgDGOpenFile()+2 call ksfdopn() 7FFFBDFC4820 ? 00000002D ?
301 000000200 ? 000000003 ?
000020000 ? 15F3031F0 ?
pevm_icd_call_commo call kfpkgDGOpenFile() 2B383F459FA8 ? 00000002D ?
n()+1003 2B383F439070 ? 000000003 ?
000020000 ? 15F3031F0 ?
pfrinstr_ICAL()+228 call pevm_icd_call_commo 7FFFBDFC5700 ? 000000000 ?
n() 000000001 ? 000000001 ?
000000007 ? 7FFF00000000 ?
pfrrun_no_tool()+65 call pfrinstr_ICAL() 2B383F459FA8 ? 005DBD8AA ?
2B383F45A010 ? 000000001 ?
000000007 ? 7FFF00000000 ?
pfrrun()+906 call pfrrun_no_tool() 2B383F459FA8 ? 005DBD8AA ?
2B383F45A010 ? 000000001 ?
000000007 ? 7FFF00000000 ?
plsql_run()+841 call pfrrun() 2B383F459FA8 ? 000000000 ?
2B383F45A010 ? 7FFFBDFC5700 ?
000000007 ? 15CD77BD6 ?
peicnt()+298 call plsql_run() 2B383F459FA8 ? 000000001 ?
000000000 ? 7FFFBDFC5700 ?
000000007 ? 900000000 ?
kkxexe()+503 call peicnt() 7FFFBDFC5700 ? 2B383F459FA8 ?
2B383F438830 ? 7FFFBDFC5700 ?
2B383F4367D8 ? 900000000 ?
opiexe()+4691 call kkxexe() 2B383F4561D8 ? 2B383F459FA8 ?
2B383F438830 ? 15C160BD8 ?
0040D677F ? 900000000 ?
kpoal8()+2273 call opiexe() 000000049 ? 000000003 ?
7FFFBDFC6950 ? 000000001 ?
0040D677F ? 900000000 ?
opiodr()+984 call kpoal8() 00000005E ? 000000017 ?
7FFFBDFC9830 ? 000000001 ?
000000001 ? 900000000 ?
ttcpip()+1012 call opiodr() 00000005E ? 000000017 ?
7FFFBDFC9830 ? 000000000 ?
0059C35D0 ? 900000000 ?
opitsk()+1322 call ttcpip() 0068A13B0 ? 7FFFBDFC75A0 ?
7FFFBDFC9830 ? 000000000 ?
7FFFBDFC9328 ? 7FFFBDFC9998 ?
opiino()+1026 call opitsk() 000000003 ? 000000000 ?
7FFFBDFC9830 ? 000000001 ?
000000000 ? 4E6111C00000001 ?
opiodr()+984 call opiino() 00000003C ? 000000004 ?
7FFFBDFCA9F8 ? 000000001 ?
000000000 ? 4E6111C00000001 ?
opidrv()+547 call opiodr() 00000003C ? 000000004 ?
7FFFBDFCA9F8 ? 000000000 ?
0059C3080 ? 4E6111C00000001 ?
sou2o()+114 call opidrv() 00000003C ? 000000004 ?
7FFFBDFCA9F8 ? 000000000 ?
0059C3080 ? 4E6111C00000001 ?
opimai_real()+163 call sou2o() 7FFFBDFCA9D0 ? 00000003C ?
000000004 ? 7FFFBDFCA9F8 ?
0059C3080 ? 4E6111C00000001 ?
main()+116 call opimai_real() 000000002 ? 7FFFBDFCAA60 ?
000000004 ? 7FFFBDFCA9F8 ?
0059C3080 ? 4E6111C00000001 ?
__libc_start_main() call main() 000000002 ? 7FFFBDFCAA60 ?
+244 000000004 ? 7FFFBDFCA9F8 ?
0059C3080 ? 4E6111C00000001 ?
_start()+41 call __libc_start_main() 0007230B8 ? 000000002 ?
7FFFBDFCABB8 ? 000000000 ?
0059C3080 ? 000000002 ?
--------------------- Binary Stack Dump ---------------------
结合mos信息ORA-600[KFFMVERIFY_4] OR ORA-600 [kffmLoad_1], [131635] REPORTED ON THE ASMINSTANCE (Doc ID 794103.1)的描述,由于多个进程/现场使用dbms_diskgroup访问不同磁盘组之时可能触发
BUG:6377738 – ASMB ORA-00600 [KFFMVERIFY_4]
BUG:8328467 – ASM CRASHED WITH ORA-600[KFFMVERIFY_4] OR [KFFMVERIFY_4] AND [KFFMLOAD_1]
从而导致asm实例crash,引起数据库异常.结合客户这边的情况,确认他们是使用了多个SharePlex程序同步数据,而且redo放在多个磁盘组中,从而出现该问题.临时解决方案为把所有的redo和归档放一个磁盘组,这样多个SharePlex进程调用dbms_diskgroup访问redo/arch不会触发该bug.

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

