-
3D Cloud
asm恢复 bbed bootstrap$ dmp损坏 dul In Memory kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00353 ORA-00607 ORA-00704 ORA-01110 ORA-01190 ORA-01555 ORA-01578 ORA-08103 ORA-600 2662 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-15042 ORACLE 12C oracle dul ORACLE PATCH oracle加密恢复 oracle勒索 oracle异常恢复 ORACLE恢复 Oracle 恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 redo异常 sql加密恢复 undo异常 YOUR FILES ARE ENCRYPTED 勒索恢复 数据库恢复 比特币 oracle 比特币加密
文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (87)
- 数据库 (1,334)
- DB2 (22)
- MySQL (57)
- Oracle (1,220)
- Data Guard (40)
- EXADATA (7)
- GoldenGate (19)
- ORA-xxxxx (145)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (8)
- Oracle ASM (56)
- Oracle Bug (7)
- Oracle RAC (41)
- Oracle 安全 (6)
- Oracle 开发 (25)
- Oracle 监听 (26)
- Oracle备份恢复 (403)
- Oracle安装升级 (55)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (49)
- PostgreSQL (10)
- SQL Server (26)
- SQL Server恢复 (7)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (24)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (7)
-
最近发表
- 记录一次oracle现场故障处理经过
- .Globeimposter-Beta666qqz扩展名数据库加密恢复
- .makop病毒加密数据库恢复
- ORA-600 kcratr_scan_lastbwr 恢复
- ORA-600 16703直接把orachk备份表插入到tab$恢复
- oracle dul 12.2正式版发布
- .eking扩展名数据库恢复
- 一次 CRS-1013: ASM 磁盘组中的 OCR 位置不可访问 故障分析
- Oracle Recovery Tools恢复—ORA-00704 ORA-01555故障
- 使用rman from service 搭建dataguard
- rm -rf 删除数据文件恢复方法—文件系统反删除+oracle碎片重组
- [star-new@email.tg].Devos加密数据库恢复
- 硬件恢复之后,数据库无法open故障恢复
- ORA-00742 ORA-00312 故障恢复
- 硬件故障导致ORA-600 2662错误处理
- ORA-00600: internal error code, arguments: [16513], [1403] 恢复
- .IQ0003后缀名勒索恢复
- .Globeimposter-Alpha666qqz加密恢复
- Assistant: Download Reference for Oracle Database/GI PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases-202101
- .sql文件被加密恢复
友情链接
分类目录归档:数据库
记录一次oracle现场故障处理经过
近期到现场进行了一个数据库恢复,我在恢复之前该库先由于硬件进行恢复,然后由其他人对其进行了一系列数据库恢复,但是未恢复成功,客户希望我们到现场进行处理(因为网络原因无法远程).接手库之后,处理第一个问题,是客户在进行现场备份的时候(把linux数据拷贝到win的过程中)发现有几个文件拷贝异常,这个错误很可能是由于当初的硬件故障修复之后留下的后遗症(由于io设备错误,无法运行此项请求),通过工具进行拷贝,恢复出来
DUL> copy file from /oradata2/xifenfeidata.dbf to /oradata2/xifenfeidata.dbf starting copy datafile '/oradata1/xifenfeidata.dbf' to '/oradata2/xifenfeidata.dbf' read data error from file '/oradata1/xifenfeidata.dbf'.error message:Input/output error read block# error: 560171 read data error from file '/oradata1/xifenfeidata.dbf'.error message:Input/output error read block# error: 560179 datafile copy completed with 2 block error.
[oracle@localhost ~]$ dbv file=/oradata2/xifenfeidata.dbf blocksize=16384 DBVERIFY: Release 11.2.0.3.0 - Production on Mon Mar 29 17:28:17 2021 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. DBVERIFY - Verification starting : FILE = /oradata2/xifenfeidata.dbf Page 560171 is marked corrupt Corrupt block relative dba: 0x3bc88c2b (file 239, block 560171) Completely zero block found during dbv: Page 560179 is marked corrupt Corrupt block relative dba: 0x3bc88c33 (file 239, block 560179) Completely zero block found during dbv: DBVERIFY - Verification complete Total Pages Examined : 4194302 Total Pages Processed (Data) : 2230726 Total Pages Failing (Data) : 0 Total Pages Processed (Index): 1936953 Total Pages Failing (Index): 0 Total Pages Processed (Other): 26618 Total Pages Processed (Seg) : 0 Total Pages Failing (Seg) : 0 Total Pages Empty : 3 Total Pages Marked Corrupt : 2 Total Pages Influx : 0 Total Pages Encrypted : 0 Highest block SCN : 304929867 (106.304929867)
修复完相关无法拷贝文件之后,启动数据库报控制文件异常
Mon Mar 29 15:03:38 2021 alter database mount USER (ospid: 29044): terminating the instance Mon Mar 29 15:03:42 2021 System state dump requested by (instance=1, osid=29044), summary=[abnormal instance termination]. System State dumped to trace file /u01/app/oracle/diag/rdbms/xff/xff/trace/xff_diag_28961.trc Instance terminated by USER, pid = 29044
尝试重建ctl
[oracle@localhost ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.3.0 Production on Mon Mar 29 17:40:17 2021 Copyright (c) 1982, 2011, Oracle. All rights reserved. Connected to an idle instance. SQL> startup nomount pfile='/tmp/pfile' ORACLE instance started. Total System Global Area 1.7704E+10 bytes Fixed Size 2235568 bytes Variable Size 2348811088 bytes Database Buffers 1.5301E+10 bytes Redo Buffers 52580352 bytes SQL> @/tmp/ctl.sql CREATE CONTROLFILE REUSE DATABASE xff NORESETLOGS NOARCHIVELOG * ERROR at line 1: ORA-01503: CREATE CONTROLFILE failed ORA-01189: file is from a different RESETLOGS than previous files ORA-01110: data file 249: '/oradata/xff/system03.dbf'
初步判断是由于对方之前恢复导致部分文件resetlogs scn异常,通过bbed进行判断确认
BBED> set file 1 FILE# 1 BBED> p kcvfhrls struct kcvfhrls, 8 bytes @116 ub4 kscnbas @116 0x00000001 ub2 kscnwrp @120 0x0000 BBED> set file 249 FILE# 249 BBED> p kcvfhrls struct kcvfhrls, 8 bytes @116 ub4 kscnbas @116 0x00000001 ub2 kscnwrp @120 0x0000
通过bbed修改相关值,然后重建控制文件成功,尝试resetlogs库,报ORA-01248错误
SQL> alter database open resetlogs; alter database open resetlogs * ERROR at line 1: ORA-01248: file 234 was created in the future of incomplete recovery ORA-01110: data file 234: '/oradata1/xifenfeidata5.DBF'
关于ORA-01248的错误解释
01248, 00000, "file %s was created in the future of incomplete recovery" // *Cause: Attempting to do a RESETLOGS open with a file entry in the // control file that was originally created after the UNTIL time // of the incomplete recovery. // Allowing such an entry may hide the version of the file that // is needed at this time. The file number may be in use for // a different file which would be lost if the RESETLOGS was allowed. // *Action: If more recovery is desired then apply redo until the creation // time of the file is reached. If the file is not wanted and the // same file number is not in use at the stop time of the recovery, // then the file can be taken offline with the FOR DROP option. // Otherwise a different control file is needed to allow the RESETLOGS. // Another backup can be restored and recovered, or a control file can // be created via CREATE CONTROLFILE.
大概的意思是文件的创建时间大于文件当前的scn,通过查询确实如此
SQL> select file#,CREATION_CHANGE#,CREATION_TIME from v$datafile_header where file#=234; FILE# CREATION_CHANGE# CREATION_ ---------------- ---------------- --------- 234 419298664864 02-AUG-19 SQL> SELECT status, 2 to_char(checkpoint_change#,'9999999999999999') "SCN", 3 to_char(checkpoint_time,'yyyy-mm-dd hh24:mi:ss') checkpoint_time,FUZZY, 4 count(*) ROW_NUM 5 FROM v$datafile_header 6 GROUP BY status, checkpoint_change#, to_char(checkpoint_time,'yyyy-mm-dd hh24:mi:ss'),fuzzy 7 ORDER BY status, checkpoint_change#, checkpoint_time; STATUS SCN CHECKPOINT_TIME FUZ ROW_NUM ------- ----------------- ------------------- --- ---------------- ONLINE 417750848223 2021-02-23 23:50:46 YES 7 ONLINE 417750848223 2021-03-21 11:44:25 NO 396
通过对部分scn进行修改(比如减小创建时间的scn),然后尝试resetlogs库
SQL> alter database open resetlogs; alter database open resetlogs * ERROR at line 1: ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00604: error occurred at recursive SQL level 1 ORA-01555: snapshot too old: rollback segment number 5 with name "_SYSSMU5_2708889888$" too small Process ID: 3182 Session ID: 1 Serial number: 3
这个错误比较简单,参考以前的部分文章:在数据库open过程中常遇到ORA-01555汇总数据库open过程遭遇ORA-1555对应sql语句补充,处理之后,数据库open成功
SQL> startup mount; ORACLE instance started. Total System Global Area 1.7704E+10 bytes Fixed Size 2235568 bytes Variable Size 2348811088 bytes Database Buffers 1.5301E+10 bytes Redo Buffers 52580352 bytes Database mounted. SQL> alter database open; Database altered.
本次数据库恢复基本上完成,已经最大限度恢复数据,导出数据到新库,完成恢复任务
.Globeimposter-Beta666qqz扩展名数据库加密恢复
又接一医院客户请求,多套win系统被勒索病毒加密,其中有几套是oracle数据库,请求我们进行分析,确认是否可以恢复.
HOW TO BACK YOUR FILES.txt文件信息
YOUR FILES ARE ENCRYPTED !!! TO DECRYPT, FOLLOW THE INSTRUCTIONS: To recover data you need decrypt tool. To get the decrypt tool you should: 1.In the letter include your personal ID! Send me this ID in your first email to me! 2.We can give you free test for decrypt few files (NOT VALUE) and assign the price for decryption all files! 3.After we send you instruction how to pay for decrypt tool and after payment you will receive a decryption tool! 4.We can decrypt few files in quality the evidence that we have the decoder. DO NOT TRY TO DO SOMETHING WITH YOUR FILES BY YOURSELF YOU WILL BRAKE YOUR DATA !!! ONLY WE ARE CAN HELP YOU! CONTACT US: China.Helper@aol.com ATTENTION !!! THIS IS YOUR PERSONAL ID WICH YOU HAVE TO SEND IN FIRST LETTER: Tq rx zo f3 B1 Eg S/ m1 SI Yw KS av ip Js /5 oU uk FL LY Wa pF P1 Dc ss 8l dU cl pE xe Sa Gw oC Fq /+ rF dz D3 DU Pz S6 6e uB M5 Wx zD 3C DW EC nk 1I V1 rf zK R4 36 tq 7o bJ rK Rq 81 ib hf lh +8 Oz rR 4g VM rz FH ST rJ ve 1S K2 PN FL 7I Gg yp Wq vv 1j V8 Fz vN 0x y9 l2 Ig Ql fD lK MJ +H Vw WV 80 FY /s OE oG 9V nC TY Ys Zd nQ is T2 Bw U4 cK yM km OB Ko 8p Yg g/ DA 5N S+ DX e5 /v 0s A9 Ae B6 Q1 aO Q9 gN 5/ pg HA LS jD 50 1K p6 Jn T0 g4 MR Gp 3L l4 GM Fv rD Pq gC pp Tf kz 4k vh ZG rz SB CD 1f lh M5 UA QI mn ky CG es re GI qc 7s 7h aZ /B sR 6V yn /I xC h7 Xc oR 4G uQ ZC DU Bs Ij AI 1f 0c w0 Y7 Vd xy FI R2 lz L1 8r dK lF zS SM CK Mb Rm wo EQ ht ht zj 1m R0 NM 0W 0T lA 9A AP vl dA dB XA Fx cH iR ux C8 Hn uv B9 H0 tk 0J Ph Cn VZ S+ 6b NT BT YZ jC Wf ah Ml N5 q6 FS uZ Tk 5o 0+ Sq 3c lZ 0a SH LR nW jn 1f A2 rg k6 jx qq eD T1 GT 6w cC 6C TP 3j 6Z KV 6D 1N tS Jo p/ Sl DB J2 yD Q1 u5 Y7 GS E9 /c kh U6 r8 QP wy jU Fa +Y Um TZ Mo PY gQ /L pj 5d QD EK A8 g2 qY 8Z 1d Np 3M qm Ri Sf Nc IT cN 2O Uj Ou Gw DZ H3 Wb Lo BV mE wZ 4=
通过底层分析,只是小部分数据被加密破坏

这个客户相对比较幸运,他们有3月19日的备份,通过结合备份,实现比较好的效果数据恢复
如果此类的数据库文件(oracle,mysql,sql server)等被加密,需要专业恢复技术支持,请联系我们:
电话/微信:13429648788 Q Q:107644445

.makop病毒加密数据库恢复
最近接到客户几套oracle数据库所在的机器文件被加密,readme-warning.txt内容如下
::: Greetings ::: Little FAQ: .1. Q: Whats Happen? A: Your files have been encrypted and now have the "makop" extension. The file structure was not damaged, we did everything possible so that this could not happen. .2. Q: How to recover files? A: If you wish to decrypt your files you will need to pay in bitcoins. .3. Q: What about guarantees? A: Its just a business. We absolutely do not care about you and your deals, except getting benefits. If we do not do our work and liabilities - nobody will cooperate with us. Its not in our interests. To check the ability of returning files, you can send to us any 2 files with SIMPLE extensions(jpg,xls,doc, etc... not databases!) and low sizes(max 1 mb), we will decrypt them and send back to you. That is our guarantee. .4. Q: How to contact with you? A: You can write us to our mailbox: Evilminded@privatemail.com .5. Q: How will the decryption process proceed after payment? A: After payment we will send to you our scanner-decoder program and detailed instructions for use. With this program you will be able to decrypt all your encrypted files. .6. Q: If I don抰 want to pay bad people like you? A: If you will not cooperate with our service - for us, its does not matter. But you will lose your time and data, cause only we have the private key. In practice - time is much more valuable than money. :::BEWARE::: DON'T try to change encrypted files by yourself! If you will try to use any third party software for restoring your data or antivirus solutions - please make a backup for all encrypted files! Any changes in encrypted files may entail damage of the private key and, as result, the loss all data.
通过恢复工具进行处理,直接open数据库,并导入新库


如果此类的数据库文件(oracle,mysql,sql server)等被加密,需要专业恢复技术支持,请联系我们:
电话/微信:13429648788 Q Q:107644445
