重建control遗漏数据文件,reseltogs报ORA-1555错误处理

发表于 2023 年 2 月 12 日 由 惜分飞

又一客户,误删除oracle redo导致数据库无法正常启动,自己尝试重建ctl,结果遗漏部分oracle数据文件并且尝试过resetlogs,导致部分文件resetlogs scn不一致.导致重建ctl失败

Fri Feb 10 12:41:20 2023
CREATE CONTROLFILE REUSE DATABASE "orcl" RESETLOGS  NOARCHIVELOG
    MAXLOGFILES 50
    MAXLOGMEMBERS 5
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 226
LOGFILE
  GROUP 1 'H:\BaiduNetdisk\couga/redo01.log'  SIZE 50M,
  GROUP 2 'H:\BaiduNetdisk\couga/redo02.log'  SIZE 50M,
  GROUP 3 'H:\BaiduNetdisk\couga/redo03.log'  SIZE 50M
DATAFILE
'H:\BaiduNetdisk\couga\system01.dbf',
'H:\BaiduNetdisk\couga\cougaerp.DBF',
'H:\BaiduNetdisk\couga\cougajh.DBF',
'H:\BaiduNetdisk\couga\example01.dbf',
'H:\BaiduNetdisk\couga\sysaux01.dbf',
'H:\BaiduNetdisk\couga\undotbs01.dbf',
'H:\BaiduNetdisk\couga\users01.dbf'
CHARACTER SET zhs16gbk
WARNING: Default Temporary Tablespace not specified in CREATE DATABASE command
Default Temporary Tablespace will be necessary for a locally managed database in future release
Errors in file c:\app\xff\diag\rdbms\orcl\orcl11\trace\orcl11_ora_4132.trc:
ORA-01189: ????????????? RESETLOGS
ORA-01110: ???? 6: 'H:\BaiduNetdisk\couga\cougajh.DBF'

通过OraRecovery工具修改相关异常文件头resetlogs scn之后,重建ctl成功
20230212201432

尝试resetlogs 数据库报ORA-00704 ORA-00604 ORA-01555错误
ORA-704-ORA-604-ORA-01555
Fri Feb 10 12:46:04 2023
SMON: enabling cache recovery
ORA-01555 caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, SCN: 0x0000.09dab82d):
select ctime, mtime, stime from obj$ where obj# = :1
Errors in file c:\app\xff\diag\rdbms\orcl\orcl11\trace\orcl11_ora_7088.trc:
ORA-00704: 引导程序进程失败
ORA-00704: 引导程序进程失败
ORA-00604: 递归 SQL 级别 1 出现错误
ORA-01555: 快照过旧: 回退段号 5 (名称为 "_SYSSMU5_1527469038$") 过小
Errors in file c:\app\xff\diag\rdbms\orcl\orcl11\trace\orcl11_ora_7088.trc:
ORA-00704: 引导程序进程失败
ORA-00704: 引导程序进程失败
ORA-00604: 递归 SQL 级别 1 出现错误
ORA-01555: 快照过旧: 回退段号 5 (名称为 "_SYSSMU5_1527469038$") 过小
Error 704 happened during db open, shutting down database
USER (ospid: 7088): terminating the instance due to error 704

通过类似方法处理:
在数据库open过程中常遇到ORA-01555汇总
数据库open过程遭遇ORA-1555对应sql语句补充
顺利open数据库，并且逻辑方式导出数据,完成恢复

发表在 非常规恢复 | 评论关闭

InnoDB: Database page corruption on disk or a failed file read of page恢复

发表于 2023 年 2 月 12 日 由 惜分飞

由于文件系统或者硬件故障导致mysql启动报错InnoDB: Database page corruption on disk or a failed file read of page
mysql-error

使用innodb_force_recovery参数,数据库启动成功,但是部分表查询报错,对于这种情况,是由于ibd文件本身有损坏,通过DISCARD TABLESPACE和IMPORT TABLESPACE也无法解决,只能对ibd文件进行恢复，通过工具直接解析ibd文件恢复其中数据
20230212125347
发表在 MySQL恢复 | 标签为 , | 评论关闭

_locked加密数据库恢复

发表于 2023 年 2 月 11 日 由 惜分飞

最近比较多的客户被._locked勒索病毒加密
._locked

这种加密和以往的常见加密不太一样,它把文件名都给修改了,无法类似以前那样通过文件名判断出来对应的用途(比如哪些是oracle数据文件,哪些是sql server文件等),所有文件被加密成随机名字._locked,通过对其底层进行分析,可以确认该文件损坏很少,oracle和sql server基本上可以实现完美恢复(特别是11G及其以后版本,恢复效果和数据库直接运行状态下expdp/exp导出效果一样)
20230211233455
通过oracle数据文件加密勒索工具即可实现快速恢复oracle数据文件实现数据库open,然后导出数据
_locked-recovery-tools
预防远比救援重要，所以为了避免出现此类事件，强烈建议大家日常做好以下防护措施：
①及时给办公终端和服务器打补丁，修复漏洞，包括操作系统以及第三方应用的补丁，防止攻击者通过漏洞入侵系统。
②尽量关闭不必要的端口，如139、445、3389等端口。如果不使用，可直接关闭高危端口，降低被漏洞攻击的风险。
③不对外提供服务的设备不要暴露于公网之上，对外提供服务的系统，应保持较低权限。
④企业用户应采用高强度且无规律的密码来登录办公系统或服务器，要求包括数字、大小写字母、符号，且长度至少为8位的密码，并定期更换口令。
⑤数据备份保护，对关键数据和业务系统做备份，如离线备份，异地备份，云备份等， 避免因为数据丢失、被加密等造成业务停摆，甚至被迫向攻击者妥协。
⑥敏感数据隔离，对敏感业务及其相关数据做好网络隔离。避免双重勒索病毒在入侵后轻易窃取到敏感数据，对公司业务和机密信息造成重大威胁。
⑦尽量关闭不必要的文件共享。
⑧提高安全运维人员职业素养，定期进行木马病毒查杀。

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