标签云
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,883)
- DB2 (22)
- MySQL (82)
- Oracle (1,708)
- 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备份恢复 (662)
- Oracle安装升级 (108)
- 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)
-
最近发表
- aix平台Oracle数据库由于断电无法启动故障处理
- 断电引起ORA-600 3005故障处理
- 记录一次云存储资源到期之后引起的数据库恢复
- Firebird 损坏数据库数据抢救工具—firebirdext
- Oracle 19c 202610补丁(RUs+OJVM)-19.33
- 由于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故障恢复
分类目录归档:数据库
注意:PostgreSQL库出现readme_to_recover勒索
以前恢复过不少mysql库被删除的勒索case,比如:
read_me_recover_tn勒索恢复
A_H_README_TO_RECOVER勒索恢复
A____Z____RECOVER____DATA勒索恢复
今天在PostgreSQL库中也简单了类似的勒索案例
[postgres@xifenfei database]$ psql
psql (12.8)
Type "help" for help.
postgres=> \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
-------------------+----------+----------+------------+------------+-----------------------
ldar-test | postgres | UTF8 | en_US.utf8 | en_US.utf8 |
postgres | postgres | UTF8 | en_US.utf8 | en_US.utf8 |
readme_to_recover | postgres | UTF8 | en_US.utf8 | en_US.utf8 |
template0 | postgres | UTF8 | en_US.utf8 | en_US.utf8 | =c/postgres +
| | | | | postgres=CTc/postgres
template1 | postgres | UTF8 | en_US.utf8 | en_US.utf8 | =c/postgres +
| | | | | postgres=CTc/postgres
(5 rows)
postgres=> \c readme_to_recover
You are now connected to database "readme_to_recover" as user "postgres".
readme_to_recover=> \d
List of relations
Schema | Name | Type | Owner
--------+--------+-------+----------
public | readme | table | postgres
(1 row)
readme_to_recover=> select * from readme;
text_field
-------------------------------------------------------------------------------------------------------
-------------------------------------------------
All your data is backed up. You must pay 0.0051 BTC to bc1q9p333xxxxxxxxxxxxxj2z5fs27pu3u In 48 hours,
your data will be publicly disclosed and deleted . (more information: go to http://2info.win/psg)
After paying send mail to us: rambler+3d2l7@onionmail.org and we will provide a link for
you to download your data. Your DBCODE is: xxxxx
(2 rows)
readme_to_recover=> select oid,relname from pg_class;
oid | relname
---------+-----------------------------------------------
2196735 | readme
2619 | pg_statistic
1247 | pg_type
4159 | pg_toast_2600
4160 | pg_toast_2600_index
2830 | pg_toast_2604
2831 | pg_toast_2604_index
4161 | pg_toast_3456
4162 | pg_toast_3456_index
2832 | pg_toast_2606
2833 | pg_toast_2606_index
………………
13373 | _pg_foreign_tables
13377 | foreign_table_options
13383 | _pg_user_mappings
13391 | user_mappings
13387 | user_mapping_options
(396 rows)
根据这里的readme的oid值,初步怀疑是drop所有业务表,然后创建了readme表,并且插入了勒索信息.
我做的各种数据库恢复比较多,说实话一直对pg这个特点非常不满意:
1. pg的数据存储本身依赖文件系统,通过oid(来表示库,表示表以及其他各种对象,和很多商业化数据库不一样,对于文件系统过于依赖,这样的情况如果发生了drop/truncate表等操作,表从文件系统中被删除,恢复难度较大
2. pg的表对应本身没有在每个数据块的block记录表的id信息,这样使得无法很好的进行底层基于block的扫描恢复数据,目前我知道的pdu一定的这样的功能,但是那是依赖列匹配,原则上来说对于一个稍微复杂一点的系统,这个恢复思路基本上不可行(因为列相似的数据表可能很多,导致恢复的数据过于混乱)
基于上述的两个特点,如果整个业务库被这种勒索破坏,如果没有备份,想比较好的恢复效果基本上很难(除非你运气非常好,os层面反删除恢复效果特别好,这要取决被删除的表在os上没有覆盖,文件系统元数据没有回收,系统没有识别是ssd环境等因素决定)
基于这种故障在没有备份的情况下很难恢复,那我们要做的就是:
1)有有效的备份或者容灾不被破坏;
1> 数据需要有效的备份,有条件的建议异机或者离线
2> 如果有条件可以部署延迟同步的备库,避免发生故障备库同步 被破坏
2)尽可能不让这种故障发生:
1>数据库不要暴露在公网上,减少被攻击和入侵的风险
2>数据库不要使用弱口令,减少被暴力攻破密码的风险
3>注意应用漏洞,减少通过sql注入进行数据库进行破坏
4>注意已知的数据库安全漏洞,防止被利用进行攻击
5>注意操作系统安全,因为登录了数据库服务器对于数据库来说就没有安全可言
Oracle 19c 202601补丁(RUs+OJVM)-19.30
| Description | Database Update | GI Update | Windows Bundle Patch |
| JAN2026(19.30.0.0.0) | 38632161 | 38629535 | 38597735 |
| OCT2025(19.29.0.0.0) | 38291812 | 38298204 | 38111211 |
| JUL2025 (19.28.0.0.0) | 37960098 | 37957391 | 37962957 |
| APR2025 (19.27.0.0.0) | 37642901 | 37641958 | 37532350 |
| JAN2025 (19.26.0.0.0) | 37260974 | 37257886 | 37486199 |
| OCT2024 (19.25.0.0.0) | 36912597 | 36916690 | 36878821 |
| JUL2024 (19.24.0.0.0) | 36582781 | 36582629 | 36521936 |
| APR2024 (19.23.0.0.0) | 36233263 | 36233126 | 36219938 |
| JAN2024 (19.22.0.0.0) | 35943157 | 35940989 | 35962832 |
| OCT2023 (19.21.0.0.0) | 35643107 | 35642822 | 35681552 |
| JUL2023 (19.20.0.0.0) | 35320081 | 35319490 | 35348034 |
| APR2023 (19.19.0.0.0) | 35042068 | 35037840 | 35046439 |
| JAN2023 (19.18.0.0.0) | 34765931 | 34762026 | 34750795 |
| Oct2022 (19.17.0.0.0) | 34419443 | 34416665 | 34468114 |
| JUL2022 (19.16.0.0.0) | 34133642 | 34130714 | 34110685 |
| APR2022 (19.15.0.0.0) | 33806152 | 33803476 | 33829175 |
| JAN2022 (19.14.0.0.0) | 33515361 | 33509923 | 33575656 |
| OCT2021(19.13.0.0.0) | 33192793 | 33182768 | 33155330 |
| JUL2021 (19.12.0.0.0) | 32904851 | 32895426 | 32832237 |
| APR2021 (19.11.0.0.0) | 32545013 | 32545008 | 32409154 |
| JAN2021 (19.10.0.0.0) | 32218454 | 32226239 | 32062765 |
| OCT2020 (19.9.0.0.0) | 31771877 | 31750108 | 31719903 |
| JUL2020 (19.8.0.0.0) | 31281355 | 31305339 | 31247621 |
| APR2020 (19.7.0.0.0) | 30869156 | 30899722 | 30901317 |
| JAN2020 (19.6.0.0.0) | 30557433 | 30501910 | 30445947 |
| OCT2019 (19.5.0.0.0) | 30125133 | 30116789 | 30151705 |
| JUL2019 (19.4.0.0.0) | 29834717 | 29708769 | NA |
| APR2019 (19.3.0.0.0) | 29517242 | 29517302 | NA |
| Description | OJVM Update | OJVM + DB Update | OJVM + GI Update |
| JAN2025(19.30.0.0.26.01.20) | 38523609 | 38658587 | 38658588 |
| OCT2025(19.29.0.0.25.10.21) | 38194382 | 38273545 | 38273558 |
| JUL2025 (19.28.0.0.250715) | 37847857 | 37952354 | 37952382 |
| APR2025 (19.27.0.0.250415) | 37499406 | 37591483 | 37591516 |
| JAN2025 (19.26.0.0.250121) | 37102264 | 37262172 | 37262208 |
| OCT2024 (19.25.0.0.241015) | 36878697 | 36866623 | 36866740 |
| JUL2024 (19.24.0.0.240716) | 36414915 | 36522340 | 36522439 |
| APR2024 (19.23.0.0.240416) | 36199232 | 36209492 | 36209493 |
| JAN2024 (19.22.0.0.240116) | 35926646 | 36031426 | 36031453 |
| OCT2023 (19.21.0.0.231017) | 35648110 | 35742413 | 35742441 |
| JUL2023 (19.20.0.0.230718) | 35354406 | 35370174 | 35370167 |
| APR2023 (19.19.0.0.230418) | 35050341 | 35058163 | 35058172 |
| JAN2023 (19.18.0.0.230117) | 34786990 | 34773489 | 34773504 |
| OCT2022 (19.17.0.0.221018) | 34411846 | 34449114 | 34449117 |
| JUL2022 (19.16.0.0.220719) | 34086870 | 34160831 | 34160854 |
| APR2022 (19.15.0.0.220419) | 33808367 | 33859194 | 33859214 |
| JAN2022 (19.14.0.0.220118) | 33561310 | 33567270 | 33567274 |
| OCT2021 (19.13.0.0.211019) | 33192694 | 33248420 | 33248471 |
| JUL2021 (19.12.0.0.210720) | 32876380 | 32900021 | 32900083 |
| APR2021 (19.11.0.0.210420) | 32399816 | 32578972 | 32578973 |
| JAN2021 (19.10.0.0.210119) | 32067171 | 32126828 | 32126842 |
| OCT2020 (19.9.0.0.201020) | 31668882 | 31720396 | 31720429 |
| JUL2020 (19.8.0.0.200714) | 31219897 | 31326362 | 31326369 |
| APR2020 (19.7.0.0.200414) | 30805684 | 30783543 | 30783556 |
| JAN2020 (19.6.0.0.200114) | 30484981 | 30463595 | 30463609 |
| OCT2019 (19.5.0.0.191015) | 30128191 | 30133124 | 30133178 |
| JUL2019 (19.4.0.0.190716) | 29774421 | 29699079 | 29699097 |
| APR2019 (19.3.0.0.190416) | 29548437 | 29621253 | 29621299 |
最新的patch信息整合来自:Primary Note for Database Quarterly Release Updates KB106822
Patch_SCN快速解决ORA-600 2663故障
一个维保客户和我说他们测试库删除了日志文件导致库无法启动,让我帮忙看看
客户现场现况
1. 磁盘空间使用100%
[oracle@We1-db_Test ~]$ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 880K 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/vda1 40G 38G 92M 100% / tmpfs 783M 0 783M 0% /run/user/0
2. 数据库redo被删除了部分,而且是active状态的被删除
[oracle@We1-db_Test ~]$ ls -l /opt/app/oracle/oradata/orcl/redo0*
-rw-r----- 1 oracle oinstall 52429312 Jan 15 15:29 /opt/app/oracle/oradata/orcl/redo04.log
-rw-r----- 1 oracle oinstall 52429312 Jan 15 16:26 /opt/app/oracle/oradata/orcl/redo05.log
SQL> select group#,SEQUENCE#,STATUS FROM V$lOG;
GROUP# SEQUENCE# STATUS
---------- ---------- ----------------
1 8989 CURRENT
2 0 UNUSED
5 0 UNUSED
4 0 UNUSED
3 8988 ACTIVE
SQL> select member from v$logfile;
MEMBER
-----------------------------------------------------
/opt/app/oracle/oradata/orcl/redo03.log
/opt/app/oracle/oradata/orcl/redo02.log
/opt/app/oracle/oradata/orcl/redo01.log
/opt/app/oracle/oradata/orcl/redo04.log
/opt/app/oracle/oradata/orcl/redo05.log
基于当前情况,直接open库无望,但是空间不足问题需要先解决,不然恢复过程中创建redo空间不足依旧会报错卡死,所以先清理了监听和alert等日志,系统空闲了3G多空间,可以进行恢复操作
[oracle@We1-db_Test trace]$ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 880K 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/vda1 40G 34G 3.9G 90% / tmpfs 783M 0 783M 0% /run/user/0
恢复数据库
1. 由于active redo丢失,毫无疑问,直接强制拉库,使用_allow_resetlogs_corruption参数开干
SQL> startup mount pfile='/tmp/pfile';
ORACLE instance started.
Total System Global Area 2455228416 bytes
Fixed Size 2255712 bytes
Variable Size 905970848 bytes
Database Buffers 1526726656 bytes
Redo Buffers 20275200 bytes
Database mounted.
SQL> recover database until cancel;
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done
SQL> recover database using backup controlfile;
ORA-00279: change 311982775 generated at 12/31/2025 17:35:11 needed for thread
1
ORA-00289: suggestion :
/opt/app/oracle/fast_recovery_area/ORCL/archivelog/2026_01_16/o1_mf_1_8988_%u_.a
rc
ORA-00280: change 311982775 for thread 1 is in sequence #8988
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [2663], [0], [311982792], [0],
[311982833], [], [], [], [], [], [], []
Process ID: 11917
Session ID: 576 Serial number: 3
alert日志报错
Fri Jan 16 21:25:31 2026 Assigning activation ID 1750515127 (0x6856bdb7) Thread 1 opened at log sequence 1 Current log# 1 seq# 1 mem# 0: /opt/app/oracle/oradata/orcl/redo01.log Successful open of redo thread 1 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Fri Jan 16 21:25:31 2026 SMON: enabling cache recovery Errors in file /opt/app/oracle/diag/rdbms/orcl/we1db/trace/we1db_ora_11917.trc (incident=81753): ORA-00600: internal error code, arguments: [2663], [0], [311982792], [0], [311982833], [], [] Incident details in: /opt/app/oracle/diag/rdbms/orcl/we1db/incident/incdir_81753/we1db_ora_11917_i81753.trc 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 /opt/app/oracle/diag/rdbms/orcl/we1db/trace/we1db_ora_11917.trc: ORA-00600: internal error code, arguments: [2663], [0], [311982792], [0], [311982833], [], [] Errors in file /opt/app/oracle/diag/rdbms/orcl/we1db/trace/we1db_ora_11917.trc: ORA-00600: internal error code, arguments: [2663], [0], [311982792], [0], [311982833], [], [] Error 600 happened during db open, shutting down database USER (ospid: 11917): terminating the instance due to error 600 Instance terminated by USER, pid = 11917 ORA-1092 signalled during: alter database open resetlogs... opiodr aborting process unknown ospid (11917) as a result of ORA-1092 Fri Jan 16 21:25:33 2026 ORA-1092 : opitsk aborting process
不幸数据库遇到ORA-600 2663错误,这个故障在以前的文章中描述过,基本上和ORA-600 2662的处理思路类似,这里直接使用:Patch_SCN for Linux进行恢复
2. 使用Patch_SCN处理数据库SCN
SQL> startup nomount pfile='/tmp/pfile'; ORACLE instance started. Total System Global Area 2455228416 bytes Fixed Size 2255712 bytes Variable Size 905970848 bytes Database Buffers 1526726656 bytes Redo Buffers 20275200 bytes SQL>@rectl Control file created. SQL> recover database; Media recovery complete.
SQL> alter database open;
Database altered.
SQL> SELECT CURRENT_SCN FROM V$DATABASE;
CURRENT_SCN
----------------
322002903
到这里完成数据库open操作,后续逻辑导出完成恢复任务


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

