标签云
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,767)
- DB2 (22)
- MySQL (77)
- Oracle (1,608)
- 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 监听 (29)
- Oracle备份恢复 (590)
- Oracle安装升级 (97)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (86)
- 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)
-
最近发表
- ORA-00756 ORA-10567故障数据0丢失恢复
- 数据库文件变成32k故障恢复
- tcp连接过多导致监听TNS-12532 TNS-12560 TNS-00502错误
- 文件系统格式化MySQL数据库恢复
- .sstop勒索加密数据库恢复
- 解决一次硬件恢复之后数据文件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 rac
在某些时候,需要删除掉手工删除19c RAC,重新安装,以下是比较简便的操作(root用户操作)
source /home/grid/.bash_profile crsctl stop crs systemctl disable oracle-ohasd systemctl stop oracle-ohasd systemctl disable oracle-tfa.service systemctl stop oracle-tfa rm -rf /etc/oracle rm -rf /etc/ora* rm -rf /u01 rm -rf /tmp/CVU* rm -rf /tmp/.oracle rm -rf /var/tmp/.oracle rm -f /etc/init.d/init.ohasd rm -f /etc/systemd/system/oracle-ohasd.service rm -f /etc/systemd/system/oracle-tfa.service dd if=/dev/zero of=/dev/asm_ocr1 bs=1024 count=1 dd if=/dev/zero of=/dev/asm_ocr2 bs=1024 count=1 dd if=/dev/zero of=/dev/asm_ocr3 bs=1024 count=1
发表在 ORACLE 19C, Oracle RAC
评论关闭
解决oracle数据文件路径有回车故障
最近遇到一个硬件恢复朋友的请求,oracle数据库文件恢复出来了,但是在linux上面启动的时候,有两个文件无法检测到,dbv检测正常.
通过分析是由于文件无法找到原因导致

进一步检查发现原库这两个文件结尾带有回车,但是恢复出来的文件不带回车

对于这个故障,我在测试环境进行了重现并且给予解决
1. 创建带回车键数据文件
SQL> create tablespace xifenfei datafile '/u01/app/oracle/oradata/xifenfei/xff01.dbf 2 ' size 128m; Tablespace created. SQL> alter tablespace xifenfei add datafile '/u01/app/oracle/oradata/xifenfei/xff02.dbf' size 128M; Tablespace altered. SQL> select name from v$datafile; NAME -------------------------------------------------------------------------------- /u01/app/oracle/oradata/xifenfei/system01.dbf /u01/app/oracle/oradata/xifenfei/sysaux01.dbf /u01/app/oracle/oradata/xifenfei/undotbs01.dbf /u01/app/oracle/oradata/xifenfei/users01.dbf /u01/app/oracle/oradata/xifenfei/xff01.dbf /u01/app/oracle/oradata/xifenfei/xff02.dbf 6 rows selected.
2.操作系统层面查看文件(在我的ssh工具中,可以看到带回车键文件和不带回车文件不一样,使用的是crt工具,其他工具是否显示不确定)
[oracle@xifenfei ~]$ cd /u01/app/oracle/oradata/xifenfei/ [oracle@xifenfei xifenfei]$ ls -l xff* -rw-r----- 1 oracle oinstall 134225920 Dec 14 08:05 xff01.dbf? -rw-r----- 1 oracle oinstall 134225920 Dec 14 08:05 xff02.dbf
3. 操作系统层面重命名数据文件
[oracle@xifenfei xifenfei]$ mv xff01.dbf* xff01.dbf [oracle@xifenfei xifenfei]$ ls -l xff* -rw-r----- 1 oracle oinstall 134225920 Dec 14 08:05 xff01.dbf -rw-r----- 1 oracle oinstall 134225920 Dec 14 08:05 xff02.dbf
3. 数据库层面重启看文件情况,发现文件不能被正常发现(当然不能,文件被os层面mv了)
SQL> shutdown abort; ORACLE instance shut down. SQL> startup mount; ORACLE instance started. Total System Global Area 551165952 bytes Fixed Size 2255112 bytes Variable Size 369100536 bytes Database Buffers 171966464 bytes Redo Buffers 7843840 bytes Database mounted. SQL> select file#, CHECKPOINT_CHANGE# from v$datafile_header; FILE# CHECKPOINT_CHANGE# ---------- ------------------ 1 306775013 2 306775013 3 306775013 4 306775013 5 0 6 306779423 6 rows selected. RMAN> report schema; Report of database schema for database with db_unique_name XIFENFEI List of Permanent Datafiles =========================== File Size(MB) Tablespace RB segs Datafile Name ---- -------- -------------------- ------- ------------------------ 1 770 SYSTEM *** /u01/app/oracle/oradata/xifenfei/system01.dbf 2 1950 SYSAUX *** /u01/app/oracle/oradata/xifenfei/sysaux01.dbf 3 70 UNDOTBS1 *** /u01/app/oracle/oradata/xifenfei/undotbs01.dbf 4 12 USERS *** /u01/app/oracle/oradata/xifenfei/users01.dbf 5 0 XIFENFEI *** /u01/app/oracle/oradata/xifenfei/xff01.dbf 6 128 XIFENFEI *** /u01/app/oracle/oradata/xifenfei/xff02.dbf
4. 解决控制文件和数据文件实际名称不一致问题
RMAN> catalog datafilecopy '/u01/app/oracle/oradata/xifenfei/xff01.dbf'; using target database control file instead of recovery catalog cataloged datafile copy datafile copy file name=/u01/app/oracle/oradata/xifenfei/xff01.dbf RECID=1 STAMP=1187684217 RMAN> switch datafile 5 to copy; datafile 5 switched to datafile copy "/u01/app/oracle/oradata/xifenfei/xff01.dbf" RMAN> report schema; Report of database schema for database with db_unique_name XIFENFEI List of Permanent Datafiles =========================== File Size(MB) Tablespace RB segs Datafile Name ---- -------- -------------------- ------- ------------------------ 1 770 SYSTEM *** /u01/app/oracle/oradata/xifenfei/system01.dbf 2 1950 SYSAUX *** /u01/app/oracle/oradata/xifenfei/sysaux01.dbf 3 70 UNDOTBS1 *** /u01/app/oracle/oradata/xifenfei/undotbs01.dbf 4 12 USERS *** /u01/app/oracle/oradata/xifenfei/users01.dbf 5 128 XIFENFEI *** /u01/app/oracle/oradata/xifenfei/xff01.dbf 6 128 XIFENFEI *** /u01/app/oracle/oradata/xifenfei/xff02.dbf List of Temporary Files ======================= File Size(MB) Tablespace Maxsize(MB) Tempfile Name ---- -------- -------------------- ----------- -------------------- 1 123 TEMP 32767 /u01/app/oracle/oradata/xifenfei/temp01.dbf RMAN> alter database open; database opened
.wstop扩展名勒索数据库恢复
操作系统文件被加密成.[[gmtaP2R5]].[[dataserver@airmail.cc]].wstop扩展名,类似
运行的oracle数据库文件,从名称上看没有被加上明显的后缀名

通过winhex打开文件分析,虽然文件名称没有改变,但是文件依旧被破坏

通过专业工具检测具体破坏情况,每个文件破坏三段,破坏24个block左右

因为损坏block较少,这种情况,可以通过我开发的Oracle数据文件勒索加密工具进行处理,然后open数据库

类似勒索病毒预防建议:
1. 教育和培训:提高用户的网络安全意识非常重要。通过定期的网络安全培训和教育,向用户传达有关勒索病毒及其传播方式的知识,让他们能够警惕潜在的威胁,并学会如何正确应对可疑的电子邮件、链接和附件。
2. 更新和维护:及时更新操作系统、应用程序和安全软件,以修补已知的漏洞,并确保系统能够及时获取最新的安全补丁。此外,定期进行系统维护和检查,确保系统的安全配置和设置。
3. 备份数据:定期备份重要的数据和文件,并将备份存储在安全的离线或云存储中。确保备份是完整的、可靠的,并且能够及时恢复,以便在发生勒索病毒感染或其他数据丢失事件时能够快速恢复数据。
4. 网络安全工具:使用可信赖的网络安全工具,包括防病毒软件、防火墙、入侵检测系统等,以提高系统的安全性和防护能力。定期对系统进行全面的安全扫描和检测,及时发现并清除潜在的威胁。
5. 访问控制:实施严格的访问控制措施,限制用户对系统和文件的访问权限,避免使用管理员权限进行日常操作,以减少恶意软件感染的风险。此外,定期审查和更新访问控制策略,确保系统安全性得到有效维护。
6. 应急响应计划:制定和实施应急响应计划,明确团队成员的责任和任务,建立应对勒索病毒和其他安全事件的应急响应流程,以最大程度地减少损失并快速恢复业务正常运营。
如果此类的数据库(oracle,mysql,sql server)等被加密,需要专业恢复技术支持,请联系我们:
电话/微信:17813235971 Q Q:107644445
