标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-01595 ORA-08103 ORA-600 2131 ORA-600 2662 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-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 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (103)
- 数据库 (1,763)
- DB2 (22)
- MySQL (76)
- Oracle (1,605)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (166)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (69)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (588)
- Oracle安装升级 (97)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (86)
- PostgreSQL (30)
- pdu工具 (6)
- PostgreSQL恢复 (9)
- SQL Server (32)
- SQL Server恢复 (13)
- TimesTen (7)
- 达梦数据库 (3)
- 达梦恢复 (1)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (39)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (22)
-
最近发表
- .sstop勒索加密数据库恢复
- 解决一次硬件恢复之后数据文件0kb的故障恢复case
- Error in invoking target ‘libasmclntsh19.ohso libasmperl19.ohso client_sharedlib’问题处理
- ORA-01171: datafile N going offline due to error advancing checkpoint
- linux环境oracle数据库被文件系统勒索加密为.babyk扩展名溯源
- ORA-600 ksvworkmsgalloc: bad reaper
- ORA-600 krccfl_chunk故障处理
- Oracle Recovery Tools恢复案例总结—202505
- ORA-600 kddummy_blkchk 数据库循环重启
- 记录一次asm disk加入到vg通过恢复直接open库的案例
- CHECKDB 发现了 N 个分配错误和 M 个一致性错误
- 达梦数据库dm.ctl文件异常恢复
- Oracle Recovery Tools修复ORA-00742、ORA-600 ktbair2: illegal inheritance故障
- 可能是 tempdb 空间用尽或某个系统表不一致故障处理
- 11.2.0.4库中遇到ORA-600 kcratr_nab_less_than_odr报错
- [MY-013183] [InnoDB] Assertion failure故障处理
- Oracle 19c 202504补丁(RUs+OJVM)-19.27
- Oracle Recovery Tools修复ORA-600 6101/kdxlin:psno out of range故障
- pdu完美支持金仓数据库恢复(KingbaseES)
- 虚拟机故障引起ORA-00310 ORA-00334故障处理
分类目录归档:Oracle
ORA-600 3417故障处理
数据库突然报ORA-600 3417错误
Mon Sep 26 06:42:51 2022 Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl2\trace\orcl2_lgwr_7984.trc (incident=176185): ORA-00600: 内部错误代码, 参数: [3417], [3], [0], [1], [0], [3], [3], [], [], [], [], [] Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl2\incident\incdir_176185\orcl2_lgwr_7984_i176185.trc Mon Sep 26 06:42:54 2022 Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl2\trace\orcl2_lgwr_7984.trc: ORA-00600: 内部错误代码, 参数: [3417], [3], [0], [1], [0], [3], [3], [], [], [], [], [] LGWR (ospid: 7984): terminating the instance due to error 470
节点2异常之后,节点1由于跨节点实例恢复导致异常
Mon Sep 26 06:44:26 2022 Instance recovery: looking for dead threads Beginning instance recovery of 1 threads Submitted all GCS remote-cache requests Post SMON to start 1st pass IR Fix write in gcs resources Reconfiguration complete parallel recovery started with 31 processes Started redo scan Completed redo scan read 887 KB redo, 348 data blocks need recovery Started redo application at Thread 2: logseq 9907, block 1980 Recovery of Online Redo Log: Thread 2 Group 3 Seq 9907 Reading mem 0 Mem# 0: +DATA/orcl/onlinelog/group_3.265.1078882689 Mem# 1: +OCR/orcl/onlinelog/group_3.259.1078882689 Completed redo application of 0.32MB Completed instance recovery at Thread 2: logseq 9907, block 3755, scn 231951271 338 data blocks read, 348 data blocks written, 887 redo k-bytes read Mon Sep 26 06:44:36 2022 Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl1\trace\orcl1_smon_7972.trc (incident=208205): ORA-00600: 内部错误代码, 参数: [3417], [3], [0], [1], [0], [3], [3], [], [], [], [], [] Mon Sep 26 06:44:38 2022 Reconfiguration started (old inc 14, new inc 16) List of instances: 1 2 (myinst: 1) Global Resource Directory frozen Communication channels reestablished Master broadcasted resource hash value bitmaps Non-local Process blocks cleaned out Mon Sep 26 06:44:38 2022 LMS 0: 0 GCS shadows cancelled, 0 closed, 0 Xw survived Mon Sep 26 06:44:38 2022 Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Mon Sep 26 06:44:38 2022 LMS 1: 0 GCS shadows cancelled, 0 closed, 0 Xw survived Mon Sep 26 06:44:38 2022 LMS 2: 0 GCS shadows cancelled, 0 closed, 0 Xw survived Set master node info Submitted all remote-enqueue requests Dwn-cvts replayed, VALBLKs dubious All grantable enqueues granted ORA-600 occurred during recovery, instance will be terminated Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl1\trace\orcl1_smon_7972.trc: ORA-00600: 内部错误代码, 参数: [3417], [3], [0], [1], [0], [3], [3], [], [], [], [], [] System state dump requested by (instance=1,osid=7972 (SMON)),summary=[abnormal instance termination]. SMON (ospid: 7972): terminating the instance due to error 600 Mon Sep 26 06:44:43 2022 ORA-1092 : opitsk aborting process Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl1\trace\orcl1_diag_6956_20220926064442.trc: ORA-00601: ?????? Mon Sep 26 06:44:46 2022 opiodr aborting process unknown ospid (6688) as a result of ORA-1092
再次重启实例无法正常启动报ORA-600 3417错误
Completed: ALTER DATABASE MOUNT Mon Sep 26 08:08:34 2022 alter database open This instance was first to open Picked broadcast on commit scheme to generate SCNs Mon Sep 26 08:08:36 2022 LGWR: STARTING ARCH PROCESSES Mon Sep 26 08:08:36 2022 ARC0 started with pid=39, OS id=5004 ARC0: Archival started LGWR: STARTING ARCH PROCESSES COMPLETE ARC0: STARTING ARCH PROCESSES Mon Sep 26 08:08:37 2022 ARC1 started with pid=38, OS id=3568 Mon Sep 26 08:08:37 2022 ARC2 started with pid=41, OS id=3308 Mon Sep 26 08:08:37 2022 ARC3 started with pid=42, OS id=8180 Mon Sep 26 08:08:37 2022 ARC4 started with pid=43, OS id=7768 Mon Sep 26 08:08:37 2022 ARC5 started with pid=44, OS id=4628 Mon Sep 26 08:08:37 2022 ARC6 started with pid=45, OS id=6920 Mon Sep 26 08:08:37 2022 ARC7 started with pid=46, OS id=7960 ARC1: Archival started ARC2: Archival started ARC3: Archival started ARC4: Archival started ARC5: Archival started ARC6: Archival started ARC1: Becoming the 'no FAL' ARCH ARC1: Becoming the 'no SRL' ARCH ARC2: Becoming the heartbeat ARCH Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl2\trace\orcl2_lgwr_7924.trc(incident=400186): ORA-00600: ??????, ??: [3417], [3], [0], [1], [0], [3], [3], [], [], [], [], [] ARC7: Archival started ARC0: STARTING ARCH PROCESSES COMPLETE Mon Sep 26 08:08:39 2022 Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl2\trace\orcl2_lgwr_7924.trc: ORA-00600: ??????, ??: [3417], [3], [0], [1], [0], [3], [3], [], [], [], [], [] LGWR (ospid: 7924): terminating the instance due to error 470 Mon Sep 26 08:08:44 2022 ORA-1092 : opitsk aborting process
故障比较明显,数据库两个节点故障之后,启动其中一个节点,已经完成了实例恢复,但是无法open,通过10046进行跟踪发下你open过程没有执行任何语句直接导致win服务异常,然后终止
通过进一步分析确认是redo组异常
SQL> select group#,sequence#,status,thread# from v$log; GROUP# SEQUENCE# STATUS THREAD# ---------- ---------- ---------------- ---------- 1 10837 CURRENT 1 2 0 UNUSED 1 3 9907 CURRENT 2 4 0 UNUSED 2
进一步查询数据文件是否正常
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_TIME LAST_CHANGE# ROW_NUM ------- ------------------ ------------------- ---------------- ---------------- ONLINE 231971314 2022-09-26 06:44:37 231971314 44 SYSTEM 231971314 2022-09-26 06:44:37 231971314 1 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,chec kpoint_change#, 3 count(*) ROW_NUM 4 FROM v$datafile_header 5 GROUP BY status, checkpoint_change#, to_char(checkpoint_time,'yyyy-mm-dd hh 24:mi:ss'),fuzzy 6 ORDER BY status, checkpoint_change#, checkpoint_time; STATUS CHECKPOINT_TIME FUZ CHECKPOINT_CHANGE# ROW_NUM ------- ---------------------------------------- --- ------------------ -------- -------- ONLINE 2022-09-26 06:44:37 NO 231971314 45
基于上述情况,对于这个库,可以直接open库,实现数据0丢失
又一例asm disk 加入vg故障
通过asm层面查看


ASMCMD> lsdsk Path /dev/asmdisk/asm-arch01 /dev/asmdisk/asm-data01 /dev/asmdisk/asm-ocr01 /dev/asmdisk/asm-ocr02 /dev/asmdisk/asm-ocr03 dbsrv2-> ls -l /dev/asm* /dev/asm: total 0 /dev/asmdisk: total 0 lrwxrwxrwx 1 root root 6 Sep 14 17:39 asm-arch01 -> ../sdb lrwxrwxrwx 1 root root 6 Sep 14 17:35 asm-data01 -> ../sda lrwxrwxrwx 1 root root 6 Sep 11 09:11 asm-ocr01 -> ../sdc lrwxrwxrwx 1 root root 6 Sep 11 09:11 asm-ocr02 -> ../sdd lrwxrwxrwx 1 root root 6 Sep 11 09:11 asm-ocr03 -> ../sde
对于这类情况,由于客户的系统是ext4,根据这个文件系统特性,每隔2G会有一点破坏,最终数据恢复效果看运气,运气好直接通过元数据恢复出来所有数据文件,然后open库,然后不好可能需要底层碎片等,参见类似恢复:
asm disk被加入vg恢复
asm disk 磁盘部分被清空恢复
文件系统重新分区oracle恢复
删除分区 oracle asm disk 恢复
pvcreate asm disk导致asm磁盘组异常恢复
对于使用asm的客户,在对文件系统进行操作时,一定要注意asm disk,别弄错磁盘(把asm disk磁盘给误操作掉了),适当情况下linux平台可以考虑AFD(ASM FILTER DRIVER)
发表在 Oracle备份恢复
评论关闭
.Devos加密数据库恢复
通过资源的oracle勒索加密恢复工具进行处理

直接顺利open数据库,并且导出数据
C:\Windows\system32>expdp "'/ as sysdba'" schemas=XFF DIRECTORY=expdp_dir logfile=XFF.log dumpfile=XFF.dmp Export: Release 11.2.0.1.0 - Production on 星期四 9月 22 18:05:59 2022 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. 连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options 启动 "SYS"."SYS_EXPORT_SCHEMA_01": "/******** AS SYSDBA" schemas=XFF DIRECTORY=expdp_dir logfile=XFF.log dumpfile=XFF.dmp 正在使用 BLOCKS 方法进行估计... 处理对象类型 SCHEMA_EXPORT/TABLE/TABLE_DATA 使用 BLOCKS 方法的总估计: 4.089 GB 处理对象类型 SCHEMA_EXPORT/USER 处理对象类型 SCHEMA_EXPORT/SYSTEM_GRANT 处理对象类型 SCHEMA_EXPORT/ROLE_GRANT 处理对象类型 SCHEMA_EXPORT/DEFAULT_ROLE 处理对象类型 SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA 处理对象类型 SCHEMA_EXPORT/SEQUENCE/SEQUENCE 处理对象类型 SCHEMA_EXPORT/TABLE/TABLE 处理对象类型 SCHEMA_EXPORT/TABLE/INDEX/INDEX 处理对象类型 SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT 处理对象类型 SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS 处理对象类型 SCHEMA_EXPORT/TABLE/COMMENT 处理对象类型 SCHEMA_EXPORT/PACKAGE/PACKAGE_SPEC 处理对象类型 SCHEMA_EXPORT/FUNCTION/FUNCTION 处理对象类型 SCHEMA_EXPORT/PROCEDURE/PROCEDURE 处理对象类型 SCHEMA_EXPORT/PACKAGE/COMPILE_PACKAGE/PACKAGE_SPEC/ALTER_PACKAGE_SPEC 处理对象类型 SCHEMA_EXPORT/FUNCTION/ALTER_FUNCTION 处理对象类型 SCHEMA_EXPORT/PROCEDURE/ALTER_PROCEDURE 处理对象类型 SCHEMA_EXPORT/VIEW/VIEW 处理对象类型 SCHEMA_EXPORT/PACKAGE/PACKAGE_BODY 处理对象类型 SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT 处理对象类型 SCHEMA_EXPORT/TABLE/TRIGGER . . 导出了 "XFF"."LIS_R_IMAGE_7" 608.4 MB 29616 行 . . 导出了 "XFF"."LIS_R_IMAGE_36" 660.6 MB 8698 行 . . 导出了 "XFF"."LIS_REPORT" 9.553 MB 36826 行 . . 导出了 "XFF"."LIS_R_DETAIL_10" 584.9 KB 11816 行 . . 导出了 "XFF"."SCV_SAMPLE_INFO" 9.428 MB 38148 行 . . 导出了 "XFF"."SVC_SAMPLE_INST" 1.537 MB 47328 行 . . 导出了 "XFF"."LIS_REPORT_CLASS" 79.91 MB 1226246 行 …………………………………… . . 导出了 "XFF"."SY_FILTERCASE" 0 KB 0 行 . . 导出了 "XFF"."SY_FILTERDETAIL" 0 KB 0 行 . . 导出了 "XFF"."SY_TABLE" 0 KB 0 行 . . 导出了 "XFF"."XK_CODE_REASON" 0 KB 0 行 已成功加载/卸载了主表 "SYS"."SYS_EXPORT_SCHEMA_01" ****************************************************************************** SYS.SYS_EXPORT_SCHEMA_01 的转储文件集为: E:\XFF.DMP 作业 "SYS"."SYS_EXPORT_SCHEMA_01" 已于 18:06:32 成功完成
对于类似这种被加密的勒索的数据文件(.id[0D160C61-3327].[ferguson@cock.li].Devos),我们可以实现比较好的恢复效果,如果此类的数据库(oracle,mysql,sql server)等被加密,需要专业恢复技术支持,请联系我们:
电话/微信:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com
系统安全防护措施建议:
1.多台机器,不要使用相同的账号和口令
2.登录口令要有足够的长度和复杂性,并定期更换登录口令
3.重要资料的共享文件夹应设置访问权限控制,并进行定期备份
4.定期检测系统和软件中的安全漏洞,及时打上补丁。
5.定期到服务器检查是否存在异常。
6.安装安全防护软件,并确保其正常运行。
7.从正规渠道下载安装软件。
8.对不熟悉的软件,如果已经被杀毒软件拦截查杀,不要添加信任继续运行。
9.保存良好的备份习惯,尽量做到每日备份,异地备份。