标签云
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,762)
- DB2 (22)
- MySQL (76)
- Oracle (1,604)
- 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)
- 勒索恢复 (85)
- 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)
-
最近发表
- 解决一次硬件恢复之后数据文件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故障处理
- pg创建gbk字符集库
分类目录归档:Oracle
被.mallox数据库恢复
.mallox勒索病毒加密文件破坏较多,很多时候无法正常通过工具恢复数据或者直接打开库
最近两例oracle数据库被该病毒加密,通过一系列处理,实现较为完美恢复(均为恢复之后,业务直接使用),这种病毒的FILE RECOVERY.txt内容类似为:
Hello Your files are encrypted and can not be used To return your files in work condition you need decryption tool Follow the instructions to decrypt all your data Do not try to change or restore files yourself, this will break them If you want, on our site you can decrypt one file for free. Free test decryption allowed only for not valuable file with size less than 3MB How to contact us: The fastest way: 1) Download and install TOR browser by this link: https://www.torproject.org/download/ 2) If TOR blocked in your country and you can't access to the link then use any VPN software 3) Run TOR browser and open the site: wtyafjyhwqrgo4a45wdvvwhen3cx4euie73qvlhkhvlrexljoyuklaad.onion/mallox/privateSignin 4) Copy your private ID in the input field. Your Private key: xxxxxxxxxxxxxxxxxxxx 5) You will see payment information and we can make free test decryption here The slowest way: If you are unable to contact us through the site, then you can email us: mallox@stealthypost.net Waiting for a response via mail can be several days. Do not use it if you have not tried contacting through the site. Our blog of leaked companies: wtyafjyhwqrgo4a45wdvvwhen3cx4euie73qvlhkhvlrexljoyuklaad.onion
h:\BaiduNetdisk>dir *.dmp.mallox 驱动器 H 中的卷是 SSD-SX 卷的序列号是 84EB-F434 h:\BaiduNetdisk 的目录 2022-11-08 17:18 17,016,836,196 1.dmp.mallox 2022-11-08 17:18 16,801,267,812 6.dmp.mallox 2022-11-08 16:22 17,016,152,164 7.dmp.mallox 3 个文件 50,834,256,172 字节 0 个目录 433,633,767,424 可用字节
对于类似这种被加密的勒索的数据文件,我们可以实现比较好的恢复效果,如果此类的数据库(oracle,mysql,sql server)等被加密,需要专业恢复技术支持,请联系我们:
电话/微信:17813235971 Q Q:107644445

系统安全防护措施建议:
1.多台机器,不要使用相同的账号和口令
2.登录口令要有足够的长度和复杂性,并定期更换登录口令
3.重要资料的共享文件夹应设置访问权限控制,并进行定期备份
4.定期检测系统和软件中的安全漏洞,及时打上补丁。
5.定期到服务器检查是否存在异常。
6.安装安全防护软件,并确保其正常运行。
7.从正规渠道下载安装软件。
8.对不熟悉的软件,如果已经被杀毒软件拦截查杀,不要添加信任继续运行。
9.保存良好的备份习惯,尽量做到每日备份,异地备份。
ora-600 kccpb_sanity_check_2故障处理
数据库启动报ORA-600 kccpb_sanity_check_2
SQL> startup mount pfile='d:/pfile.txt' ORACLE 例程已经启动。 Total System Global Area 1258291200 bytes Fixed Size 1250548 bytes Variable Size 243272460 bytes Database Buffers 1006632960 bytes Redo Buffers 7135232 bytes ORA-00600: ??????, ??: [kccpb_sanity_check_2], [66014], [66011], [0x0], [], [],[], []
重建控制文件报错ora-600 kccsga_update_amx_1
SQL> CREATE CONTROLFILE REUSE DATABASE "zs" NORESETLOGS NOARCHIVELOG 2 MAXLOGFILES 50 3 MAXLOGMEMBERS 5 4 MAXDATAFILES 100 5 MAXINSTANCES 8 6 MAXLOGHISTORY 226 7 LOGFILE 8 GROUP 1 'd:\zs\redo01.log' SIZE 50M, 9 GROUP 2 'd:\zs\redo02.log' SIZE 50M, 10 GROUP 3 'd:\zs\redo03.log' SIZE 50M 11 DATAFILE 12 'd:\zs\SYSAUX01.DBF', ……………… 22 'd:\zs\SYSTEM01.DBF', 23 'd:\zs\UNDOTBS01.DBF', 24 'd:\zs\USERS01.DBF' 25 CHARACTER SET zhs16gbk 26 ; CREATE CONTROLFILE REUSE DATABASE "zs" NORESETLOGS NOARCHIVELOG * 第 1 行出现错误: ORA-01503: CREATE CONTROLFILE ?? ORA-00600: ??????, ??: [kccsga_update_amx_1], [9], [2920], [292], [], [], [],[]
重启实例,重建ctl成功.尝试恢复库提示需要很久之前的日志,因为有两个数据文件scn异常
通过oracle recovery tools修改文件头

再次recover数据库成功顺利open库导出客户需要数据


ORA-600 3417和ORA-600 3005故障处理
运行中的数据库突然报ORA-600 3417错误,lgwr进程异常数据库crash
Thu Nov 17 03:00:14 2022 Archived Log entry 23860 added for thread 2 sequence 1958 ID 0x6200e2f5 dest 1: Thu Nov 17 03:13:11 2022 Auto-tuning: Shutting down background process GTX1 Thu Nov 17 04:00:02 2022 Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl2\trace\orcl2_lgwr_1740.trc (incident=672186): ORA-00600: 内部错误代码, 参数: [3417], [2], [0], [0], [0], [1], [2], [], [], [], [], [] Thu Nov 17 04:00:04 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_1740.trc: ORA-00600: 内部错误代码, 参数: [3417], [2], [0], [0], [0], [1], [2], [], [], [], [], [] LGWR (ospid: 1740): terminating the instance due to error 470
重启之后报ORA-600 3005错误,数据库启动失败
Thu Nov 17 04:03:09 2022 Successful mount of redo thread 2, with mount id 1648753015 Database mounted in Shared Mode (CLUSTER_DATABASE=TRUE) Lost write protection disabled Completed: ALTER DATABASE MOUNT /* db agent *//* {0:1:38} */ ALTER DATABASE OPEN /* db agent *//* {0:1:38} */ This instance was first to open Beginning crash recovery of 1 threads parallel recovery started with 31 processes Thu Nov 17 04:03:14 2022 Started redo scan ORA-00600: ??????, ??: [3005], [1], [706], [10374], [0], [0], [], [], [], [], [], [] Thu Nov 17 04:03:15 2022 Reconfiguration started (old inc 14, new inc 16) List of instances: 1 2 (myinst: 2) Global Resource Directory frozen Thu Nov 17 04:03:15 2022 Communication channels reestablished Thu Nov 17 04:03:16 2022 * domain 0 valid = 0 according to instance 1 Master broadcasted resource hash value bitmaps Non-local Process blocks cleaned out Thu Nov 17 04:03:16 2022 LMS 0: 0 GCS shadows cancelled, 0 closed, 0 Xw survived Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Thu Nov 17 04:03:16 2022 Sweep [inc][688298]: completed Sweep [inc2][688298]: completed Thu Nov 17 04:03:16 2022 LMS 1: 0 GCS shadows cancelled, 0 closed, 0 Xw survived Thu Nov 17 04:03:16 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 Post SMON to start 1st pass IR Submitted all GCS remote-cache requests Post SMON to start 1st pass IR Fix write in gcs resources Reconfiguration complete Abort recovery for domain 0 Aborting crash recovery due to error 600 Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl2\trace\orcl2_ora_15352.trc: ORA-00600: ??????, ??: [3005], [1], [706], [10374], [0], [0], [], [], [], [], [], [] Abort recovery for domain 0 Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl2\trace\orcl2_ora_15352.trc: ORA-00600: ??????, ??: [3005], [1], [706], [10374], [0], [0], [], [], [], [], [], [] ORA-600 signalled during: ALTER DATABASE OPEN /* db agent *//* {0:1:38} */...
尝试人工进行recover恢复库
SQL> recover database; ORA-00279: 更改 310644203 (在 11/17/2022 01:00:05 生成) 对于线程 2 是必需的 ORA-00289: 建议: +DATA/orcl/archivelog/2022_11_17/thread_2_seq_1956.22763.1120960801 ORA-00280: 更改 310644203 (用于线程 2) 在序列 #1956 中 指定日志: {<RET>=suggested | filename | AUTO | CANCEL} auto ORA-00279: 更改 310663747 (在 11/17/2022 02:00:01 生成) 对于线程 2 是必需的 ORA-00289: 建议: +DATA/orcl/archivelog/2022_11_17/thread_2_seq_1957.22764.1120962585 ORA-00280: 更改 310663747 (用于线程 2) 在序列 #1957 中 ORA-10877: error signaled in parallel recovery slave ORA-01112: 未启动介质恢复
通过查看alert日志确认由于ORA-00353错误导致recover database失败
Thu Nov 17 08:07:39 2022 ALTER DATABASE RECOVER database Media Recovery Start started logmerger process Parallel Media Recovery started with 32 slaves Thu Nov 17 08:07:41 2022 Recovery of Online Redo Log: Thread 1 Group 1 Seq 705 Reading mem 0 Mem# 0: +DATA/orcl/onlinelog/group_1.261.1116409583 ORA-279 signalled during: ALTER DATABASE RECOVER database ... Thu Nov 17 08:08:07 2022 ALTER DATABASE RECOVER CONTINUE DEFAULT Media Recovery Log +DATA/orcl/archivelog/2022_11_17/thread_2_seq_1956.22763.1120960801 ORA-279 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ... ALTER DATABASE RECOVER CONTINUE DEFAULT Media Recovery Log +DATA/orcl/archivelog/2022_11_17/thread_2_seq_1957.22764.1120962585 Thu Nov 17 08:08:14 2022 Recovery of Online Redo Log: Thread 2 Group 4 Seq 1958 Reading mem 0 Mem# 0: +DATA/orcl/onlinelog/group_4.266.1116409589 Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl2\trace\orcl2_pr00_7116.trc (incident=704315): ORA-00353: 日志损坏接近块 20866 更改 310761542 时间 11/17/2022 03:00:04 ORA-00312: 联机日志 1 线程 1: '+DATA/orcl/onlinelog/group_1.261.1116409583' Thu Nov 17 08:08:26 2022 Sweep [inc][704315]: completed Thu Nov 17 08:08:27 2022 Media Recovery failed with error 354 Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl2\trace\orcl2_pr00_7116.trc: ORA-00283: 恢复会话因错误而取消 ORA-00354: 损坏重做日志块标头 ORA-00353: 日志损坏接近块 20866 更改 310761542 时间 11/17/2022 03:00:04 ORA-00312: 联机日志 1 线程 1: '+DATA/orcl/onlinelog/group_1.261.1116409583' Thu Nov 17 08:08:27 2022 ORA-10877 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ... ALTER DATABASE RECOVER CANCEL ORA-1112 signalled during: ALTER DATABASE RECOVER CANCEL ...
通过对redo进行处理顺利recover成功并完美open库
SQL> recover database; 完成介质恢复。 SQL> alter database open; 数据库已更改。