标签云
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,882)
- DB2 (22)
- MySQL (82)
- Oracle (1,707)
- 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备份恢复 (661)
- 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)
-
最近发表
- 断电引起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故障恢复
- Oracle Block Edit Tool (obet) 功能增强–2026.07
分类目录归档:数据库
tcp连接过多导致监听TNS-12532 TNS-12560 TNS-00502错误
数据库监听启动报TNS-12532、TNS-12560、TNS-00502错误,无法正常启动
C:\Users\Administrator>lsnrctl start LSNRCTL for 32-bit Windows: Version 11.2.0.1.0 - Production on 20-6月 -2025 22:5 6:40 Copyright (c) 1991, 2010, Oracle. All rights reserved. 启动tnslsnr: 请稍候... TNSLSNR for 32-bit Windows: Version 11.2.0.1.0 - Production 写入e:\app\administrator\diag\tnslsnr\WIN-3D3QHVQUU65\listener\alert\log.xml的日志信息 监听该对象时出错: (ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PARTIAL=yes)(QUEUESIZE=1)) 不再监听: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=WIN-3D3QHVQUU65)(PORT=1521)) ) TNS-12532: TNS: 无效的参数 TNS-12560: TNS: 协议适配器错误 TNS-00502: 参数无效 32-bit Windows Error: 22: Invalid argument 监听程序未能启动。请参阅上面的错误消息... TNS-12560: TNS: 协议适配器错误 TNS-00530: 协议适配器错误 32-bit Windows Error: 55: Unknown error
尝试重建监听提示端口占用,对于这种情况,第一反应可能是数据库服务器的一些tcp链接异常.通过netstat -nao查看发现8080端口的应用占用TCP链接太多


通过分析发现该tcp链接已经达到7w多个,怀疑是该问题导致监听异常,重启应用释放这些连接之后,数据库监听恢复正常.
文件系统格式化MySQL数据库恢复
有客户在做迁移的时候,不慎把存放mysql数据库的硬盘进行了重新分区格式化,重新初始化mysql,并且导入了部分历史数据,不能满足客户需求,希望我们帮忙进行数据恢复.里面大概有100套左右mysql数据库,每个库里面表结构相同,数据不一样.接手这个故障,第一操作就是对磁盘进行镜像,然后使用恢复工具进行底层分析,尝试从文件系统层面恢复出来被格式化之前的数据库文件(需要有对应库目录,不然也没有意义,因为每个库里面表结构一样的,没有正确的库名字无法做到有效的区分),通过底层扫描分析,没有发现一个有效数据文件

对于这样的情况,只能寄希望于mysql 数据块层面扫描恢复,通过工具扫描发现大量的数据块page文件

然后尝试分析字典信息,主要是对于0000000000000001.page对应的表创建语句为:
CREATE TABLE `SYS_TABLES` ( `NAME` varchar(255) NOT NULL DEFAULT '', `ID` bigint(20) unsigned NOT NULL DEFAULT '0', `N_COLS` int(10) DEFAULT NULL, `TYPE` int(10) unsigned DEFAULT NULL, `MIX_ID` bigint(20) unsigned DEFAULT NULL, `MIX_LEN` int(10) unsigned DEFAULT NULL, `CLUSTER_NAME` varchar(255) DEFAULT NULL, `SPACE` int(10) unsigned DEFAULT NULL, PRIMARY KEY (`NAME`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
通过上述信息可以获取到name和id列的值(其中name中包含库名/表名),然后再通过0000000000000003.page文件结合对应的表创建语句:
CREATE TABLE `SYS_INDEXES` ( `TABLE_ID` bigint(20) unsigned NOT NULL DEFAULT '0', `ID` bigint(20) unsigned NOT NULL DEFAULT '0', `NAME` varchar(120) DEFAULT NULL, `N_FIELDS` int(10) unsigned DEFAULT NULL, `TYPE` int(10) unsigned DEFAULT NULL, `SPACE` int(10) unsigned DEFAULT NULL, `PAGE_NO` int(10) unsigned DEFAULT NULL, PRIMARY KEY (`TABLE_ID`,`ID`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
这个主要是或者表id和page id的对应关系(表id直接关联SYS_TABLES.ID,然后获取SYS_TABLES.NAME和SYS_INDEXES.ID对应关系,从而可以确定每一个表对应的需要恢复的page文件信息,再通过客户提供的表语句和对应的page关系,实现相关数据恢复,具体操作可以参考以往类似文章:
xfs文件系统mysql删库恢复
又一起mysql rm删除数据库目录事故
[MySQL异常恢复]恢复数据字典表讲解
[MySQL异常恢复]mysql drop table 数据恢复
mysql ibd文件反删除恢复之后异常处理
[MySQL异常恢复]使用工具直接抽取MySQL数据字典
MySQL drop database恢复(恢复方法同样适用MySQL drop table,delete,truncate table)
.sstop勒索加密数据库恢复
数据库文件被加密,扩展名类似:.[[dataserver@airmail.cc]].sstop,通过工具进行坏块检测确认破坏数据文件三段,每段8个block

根据经验可以确认,数据文件前面8个block肯定没有业务数据(主要是文件头信息和位图信息),可以使用Oracle数据文件勒索加密恢复工具对其文件头进行构造

尝试open数据库,在open过程中遭遇多次ORA-01555错误,参考以前类似文章:
在数据库open过程中常遇到ORA-01555汇总
数据库open过程遭遇ORA-1555对应sql语句补充
Oracle Recovery Tools恢复—ORA-00704 ORA-01555故障
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 2 ORA-01555: snapshot too old: rollback segment number 0 with name "SYSTEM" too small Process ID: 23720 Session ID: 243 Serial number: 13 SQL> alter database Open; alter database Open * 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_2520346804$" too small Process ID: 26636 Session ID: 232 Serial number: 1
然后使用expdp导出业务数据,完成本次恢复任务,原则上跳过中间坏块数据之外,没有业务数据丢失
对于类似这种被加密的勒索的数据库(oracle,mysql,sql server)等被加密,需要专业恢复技术支持,请联系我们:
电话/微信:17813235971 Q Q:107644445
E-Mail:dba@xifenfei.com系统安全防护措施建议:
1.多台机器,不要使用相同的账号和口令
2.登录口令要有足够的长度和复杂性,并定期更换登录口令
3.重要资料的共享文件夹应设置访问权限控制,并进行定期备份
4.定期检测系统和软件中的安全漏洞,及时打上补丁。
5.定期到服务器检查是否存在异常。
6.安装安全防护软件,并确保其正常运行。
7.从正规渠道下载安装软件。
8.对不熟悉的软件,如果已经被杀毒软件拦截查杀,不要添加信任继续运行。
9.保存良好的备份习惯,尽量做到每日备份,异地备份。


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

