分类目录归档:Oracle

.locked加密勒索数据库级别恢复

有客户数据库被加密成.locked结尾的扩展名,数据库无法正常使用
.locked


对应的READ_ME1.html文件中信息类似:
send 0.1btc to my address:bc1ql8an5slxutu3yjyu9rvhsfcpv29tsfhv3j9lr4. contact email:service@hellowinter.online,if you can’t contact my email, please contact some data recovery company(suggest taobao.com), may they can contact to me .your id: ATNtkQxKZ8uaTNt3etgDXVdN2MjvPC8XoWOpoc7l25Dyg5ePEA6AFtj0sE8rYUX+Jm+1ajXASCAREJO8GD+53eqiUX26/s2aTX4uTkaAY90xTg6UIQ1SqhPpylXRsY759aUnOPeHWuv8fwj03g7vN68ctgjiRgHz3h1gNoOEDzT0GLGbr9+X6G2oCx23kNyWj3m2IXPJtyY8XqRa0UI1zNyjwyNoE6qNu0ZufInCnHKVrAp95ngibtUSmc6z+vYl8ROQlsPqi9UfyO0P3Wk2k9pLxLKsej7cBl0qtYEfRTou1v0/Ca4y57o1Djpaieklk2Ne03gYGztrGtS77S/zVzrg5B3x64qVuYNzQH9+LtmPE+6RqJY06CSmYr5f3GN1kEBuhsnGlNWjVJjjWimEMJXYMqqAY8fwb5DYxC/XCYg6jbg85R4CTOeE9DfC6yoPpsG1yXpDilBIFhFiTjWj9t94g0TBHi11dNBz1Fr+0x6TpmgfA9d0L/yjZSOTr7hQ9CeMn2eWjkYZ2jIoSV7XlHyDCbPRPlCTOnOX3ZP9zgQ48tXgJWbkds8SATOzjJk3+ttl+JNN7jScNvs7MZX0oVSyXVDrAdCHpftY63riuDuyE7rVBjtkOPr5njKSpA6K9EBD+FnCwQDzja7z78kOKXA/ddFj79mznzcnbODE8qnxitzNdv9SuQkJU+qVoH+fSndDGkDDxNliZJypHdwKM3ooO2q7fayq1Iw0dEN3FHbqgY/m3drUqge3UV07VrV9ht+tUzozUPoVBZbKSgZuYK2FKlXhlxhV/PXlskNtx+YFi1T4yzqjcT0a8HE5huQQzehDPeKQTRRpU+u9aq4TAxotjcTS1sfe/qgRKYyq+qLHg9rfFCcr5NjJPDSpWLTlhB+hUTK/iZqjYBaEccJjyvi0i+/5bDqmGmqkFeyWToyqhwlk4hN1IGyOHJY7Jf6a1S6CogVb34ArTOPFk2gKD7o4vXbERUmhw5xiP9c6Zwir2ENBdDaCl5p9oh44jpeoJqptZR4Uu1k8eqQNtUuXqlU9xvjaxt+dgXMQaul65nmgxgMmLUHjSSXZhGNzyeVGkz2KrP97ZLqYCq29iYoUt9WTLAmFtj0F+l4uYTj58+7xHM1/oXIMEOt3RmFv183I/yDesJaoV11cpbQUp1KJZvRvbws6CcajMnaH3zHJ7FHg74=
通过自研的oracle勒索加密恢复工具快速恢复文件
oracle-btb-recovery-tools

实现数据库直接open成功,实现数据0丢失
20230610185254

对于类似这种被加密的勒索的数据文件,我们可以实现比较好的恢复效果,如果此类的数据库(oracle,mysql,sql server)等被加密,需要专业恢复技术支持,请联系我们:
电话/微信:17813235971    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com
系统安全防护措施建议:
1.多台机器,不要使用相同的账号和口令
2.登录口令要有足够的长度和复杂性,并定期更换登录口令
3.重要资料的共享文件夹应设置访问权限控制,并进行定期备份
4.定期检测系统和软件中的安全漏洞,及时打上补丁。
5.定期到服务器检查是否存在异常。
6.安装安全防护软件,并确保其正常运行。
7.从正规渠道下载安装软件。
8.对不熟悉的软件,如果已经被杀毒软件拦截查杀,不要添加信任继续运行。
9.保存良好的备份习惯,尽量做到每日备份,异地备份。

发表在 勒索恢复 | 标签为 , , , , , , | 评论关闭

ORA-16038 ORA-00354故障处理

遇到一个案例,数据库open报ORA-16038,ORA-00354等错误
ORA-16038-ORA-00354


查询该redo状态(使用Oracle数据库异常恢复检查脚本(Oracle Database Recovery Check)脚本收集),确认为inactive
20230524213907

由于inactive 状态的redo损坏,无法被arch进程归档导致数据库无法正常open,尝试强制clear联机日志
ORA-00393-ORA-00312

由于25号文件属于offline状态,导致联机日志无法正常被clear,报ORA-00393 ORA-00312等错误.通过试验重现该问题.

SQL> alter database datafile 5 offline;

Database altered.

--使用一些技巧让数据库无法归档

SQL> select group#,status,archived from v$log;

    GROUP# STATUS           ARC
---------- ---------------- ---
         1 INACTIVE         NO
         2 ACTIVE           NO
         3 CURRENT          NO

SQL> shutdown abort;
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.

Total System Global Area  626327552 bytes
Fixed Size                  2255832 bytes
Variable Size             234882088 bytes
Database Buffers          385875968 bytes
Redo Buffers                3313664 bytes
Database mounted.
SQL> alter database clear unarchived logfile group 1;
alter database clear unarchived logfile group 1
*
ERROR at line 1:
ORA-00393: log 1 of thread 1 is needed for recovery of offline datafiles
ORA-00312: online log 1 thread 1: '/u01/app/oracle/oradata/orcl/redo01.log'
ORA-01110: data file 5: '/u01/app/oracle/oradata/orcl/t_xifenfei01.dbf'

SQL> !oerr ora 393
00393, 00000, "log %s of thread %s is needed for recovery of offline datafiles"
// *Cause:  Log cannot be cleared because the redo in it is needed to recover
//          offline datafiles. It has not been archived so there is no
//          other copy available. If the log is cleared the tablespaces
//          containing the files will have to be dropped.
// *Action: Archive the log then repeat the clear command. If archiving is not
//          possible, and dropping the tablespaces is acceptible, then add the
//          clause UNRECOVERABLE DATAFILE at the end of the clear command.


SQL>  alter database clear unarchived logfile group 1 unrecoverable datafile;

Database altered.

SQL> select group#,status,archived from v$log;

    GROUP# STATUS           ARC
---------- ---------------- ---
         1 UNUSED           YES
         3 CURRENT          NO
         2 ACTIVE           NO

客户的问题也是通过unrecoverable datafile 方式强制clear联机日志成功,数据库open成功

发表在 Oracle备份恢复 | 标签为 , , , , | 评论关闭

ORA-600 16703故障,客户找人恢复数据库,数据库被进一步恶意破坏—ORA-00704 ORA-00922

有朋友找到我,数据库报ORA-600 16703错误,这个本来是一个比较常见的破坏故障(警告:互联网中有oracle介质被注入恶意程序导致—ORA-600 16703数据库启动报错如下:
ora-600-16703


修复tab$启动库报ORA-00704 ORA-00922错误

SQL> alter database Open;
alter database Open
*
第 1 行出现错误:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00704: bootstrap process failure
ORA-00922: missing or invalid option
进程 ID: 1340
会话 ID: 191 序列号: 3

ORA-704-ORA-922


ORA-00704 ORA-00922是比较少见的错误,第一感觉bootstrap$损坏了,对数据库启动过程进行跟踪

PARSING IN CURSOR #11700472 len=600 dep=1 uid=0 oct=1 lid=0 tim=338738406773 hv=4034608779 
ad='7ffdef83f360' sqlid='asgjp8bs7qgnb'
CREATE TABLE UNDO$("US#" 
END OF STMT
PARSE #11700472:c=0,e=361,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=0,tim=338738406773
EXEC #11700472:c=0,e=73,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,plh=0,tim=338738406917
CLOSE #11700472:c=0,e=3,dep=1,type=0,tim=338738406997
=====================
PARSE ERROR #635423520:len=841 dep=1 uid=0 oct=1 lid=0 tim=338738407066 err=922
CREATE TABLE TS$<"TS#" NU ...
ORA-00704: 引导程序进程失败
ORA-00922: 选项缺失或无效
ORA-00704: 引导程序进程失败
ORA-00922: 选项缺失或无效

*** 2023-05-17 19:27:51.813
USER (ospid: 1340): terminating the instance due to error 704

*** 2023-05-17 19:27:54.050
EXEC #11710688:c=0,e=2481834,p=16,cr=62,cu=0,mis=0,r=0,dep=0,og=1,plh=0,tim=338740646732
ERROR #11710688:err=1092 tim=338740646777

进一步分析bootstrap$表记录
ts11


通过上述分析,可以确认原库的CREATE TABLE TS$(“TS#”被人修改为CREATE TABLE TS$<“TS#”,通过观察客户机器以及和客户确认,客户找的技术人员上传了bbed工具,并进行了一些操作.基于上述信息,大概率是被人通过bbed工具把TS$(修改为了TS$<,从而使得数据库修复tab$之后也无法正常启动.

发表在 Oracle备份恢复 | 标签为 , | 评论关闭