- 博客(130)
- 资源 (21)
- 收藏
- 关注
原创 200T 数据库非归档无备份恢复---惜分飞
一套近200T的,6个节点的RAC,由于存储管线链路不稳定,导致服务器经常性掉盘,引起asm 磁盘组频繁dismount/mount,数据库集群节点不停的重启,修复好链路问题之后,数据库启动报ORA-01113,ORA-01110。由于数据库是非归档模式,该库无法通过应用归档日志来实现对这些文件进行恢复,对于这种情况,直接使用dbms_diskgroup把数据文件头拷贝到文件系统中,类似操作。通过上述操作,确认bbed修改文件头成功,后续类似方法对其他9个文件进行修改,并打开数据库。
2024-08-15 21:18:30
906
原创 [comingback2022@cock.li].eking和[tsai.shen@mailfence.com].faust扩展名勒索病毒数据库可以完美恢复---惜分飞
最近接到两个由于操作系统文件被加密,其中的Oracle数据库文件被勒索病毒加密恢复的请求,通过底层分析,确认这两种勒索病毒加密的数据库能够非常好的恢复(可以通过修复,直接open库,然后导出数据,业务直接使用)通过定期的网络安全培训和教育,向用户传达有关勒索病毒及其传播方式的知识,让他们能够警惕潜在的威胁,并学会如何正确应对可疑的电子邮件、链接和附件。5. 访问控制:实施严格的访问控制措施,限制用户对系统和文件的访问权限,避免使用管理员权限进行日常操作,以减少恶意软件感染的风险。
2024-08-08 11:47:20
404
原创 断电引起redo和数据文件不一致故障恢复---惜分飞
尝试数据库恢复各种报错ORA-600 kdourp_inorder2,ORA-600 3020,ORA-7445 kdxlin等。有些时候故障总是来的让人非常意外,这个在准备停机迁移数据库之前的几分钟由于某种原因直接导致主机掉电,再次开机数据库无法启动。通过分析确认有部分数据文件和redo信息不匹配,导致无法正常recover成功。后续处理异常表,lob,index等数据,客户业务测试都ok,完成本次恢复工作。然后重建ctl,recover 数据库并open成功。
2024-08-04 21:09:46
728
原创 存储宕机导致Oracle异常故障处理---惜分飞
操作到这里,后续问题就比较麻烦了,因为在asm磁盘组中数据文件重建ctl的时候遗漏3个并且还被resetlogs操作过,导致这三个文件的resetlogs scn和其他数据文件不一致,对于这个问题,解决办法通过。客户尝试重建ctl进行恢复,结果由于分析不正确,导致在重建ctl的时候,遗漏了3个数据文件,并且在屏蔽一致性的情况下,强制resetlogs操作,结果数据库没有被正常打开,而是报ORA-600 2662错误。工具或者bbed修改相关resetlogs scn,然后重建ctl。
2024-07-28 22:37:11
486
原创 ORA-00756 ORA-10567故障处理---惜分飞
由于无法直接应用日志打开库,尝试屏蔽一致性,强制打开库,报ORA-600 kcbzib_kcrsds_1错误。数据库异常断电之后,recover 报ORA-00756 ORA-10567等错。,open数据库之后,尝试导出数据,报各种错误。),然后打开库,报ORA-600 6711。alert日志报大量block逻辑错误。使用Patch_SCN工具修改scn(dbv检查system文件报有坏块。进行处理,数据库可以正常导出。ORA-600 6711报错。ORA-01578报错。
2024-07-17 22:13:05
876
原创 ORA-01092 ORA-00604 ORA-08103故障处理---惜分飞
因为数据库启动执行的delete from histgrm$操作不是必须的,因此在数据库启动过程中让该sql不执行,实现数据库open成功。跟踪启动过程发现delete from histgrm$ where obj# = :1遭遇到ORA-08103错误。然后再对histgrm$表对象进行处理,数据库恢复正常。对应的alert日志。
2024-07-15 16:25:06
182
原创 数据库启动报ORA-600 6711故障分析处理---惜分飞
确认对对象为cluster C_OBJ#_INTCOL#,对应的表为HISTGRM$(统计信息中存储直方图信息表),明白这一些,处理起来就比较容易了,open数据库过程中绕过该对象访问,然后对该表进行处理即可。几个月以前的一个数据库故障,今天拿出来在win上重新分析,数据库启动报ORA-600 6711错。通过对相关rdba进行dump分析,确认对象id为64和trace中报的信息匹配。进一步分析该id为什么对象,使用dul unload obj$查看对应的trace文件。这个操作触发了递归查询。
2024-07-15 16:24:24
320
原创 Patch SCN使用说明---惜分飞
该软件是惜分飞(https://www.xifenfei.com)开发,仅用来查看和修改Oracle数据库SCN(System Change Number),主要使用在数据库因为某种原因导致无法正常启动的情况下使用该工具进行解决.特别是Oracle新版本中使用隐含参数,event,oradebug等方法无法推进Oracle SCN的情况下,使用该工具能够快速修改SCN,实现数据库启动成功.
2024-07-05 22:37:21
874
原创 异常断电数据库恢复-从ORA-600 2131到ORA-08102: 未找到索引关键字, 对象号 39---惜分飞
该对象属于bootstrap$中核心对象,无法直接rebuild,参考下面文章处理,然后再尝试导出数据。错误,这些错误本质都是由于redo信息和block信息不匹配导致。obj 39 为OBJ$的I_OBJ4对象报ORA-08102。尝试导出数据报ORA-08102,导致数据库无法正常导出。通过屏蔽一致性,修改文件头scn,强制打开数据库。重建ctl,然后重试recover 数据库,报。
2024-06-06 11:21:33
557
原创 ORA-600 2131故障处理---惜分飞
这个错误是由于controlfile损坏导致,有这个库以前部署过rman备份,解决起来比较简单,使用rman还原控制文件,并尝试recover。这种恢复情况下,如果现在要打开库,需要resetlogs方式,考虑通过创建ctl直接打开(不想用resetlogs)数据库启动报ORA-600 2131错误,查看alert日志发现是在mount过程报错。
2024-05-30 22:35:24
526
原创 truncate IDL_UB1$导致数据库open hang---惜分飞
trace数据库启动过程发现卡在select /*+ index(idl_ub2$ i_idl_ub21) +*/ piece#,length,piece from idl_ub2$ where obj#=:1 and part=:2 and version=:3 order by piece# 语句部分.一直卡在db file sequential read等待事件上,而且等待的block信息一直不变,读取对象为IDL_UB2$检查确认IDL_UB1$表被truncate成功。alert日志报错信息。
2024-05-30 22:34:53
763
原创 resetlogs强制拉库失败并使用备份system文件还原数据库故障处理---惜分飞
这个问题比较简单,通过bbed或者Oracle Recovery Tools修改文件头相关信息,然后open数据库成功。然后客户使用备份的system01.dbf文件替换了被resetlogs之后文件,导致数据库后续操作无法继续。接手一个库,在open的过程中遭遇到ORA-600 2662错误。但是由于system文件有大量坏块导致数据库无法正常登录和导出。通过dbv检查system数据文件。,实现数据库可以完美导出数据。
2024-05-30 22:33:46
350
原创 数据库open报ORA-600 kcratr_scan_lastbwr故障处理---惜分飞
由于断电,导致数据库正常open报ORA-600 kcratr_scan_lastbwr错误。尝试recover 数据库报ORA-600 3020错误。加上隐含参数尝试强制拉库。
2024-05-30 22:33:08
518
原创 rm -rf误删Oracle数据库恢复---惜分飞
有客户把虚拟化环境中装有oracle数据库的linux操作系统,由于操作失误在/下面执行了rm -rf *,导致所有文件被删除,系统无法启动.客户希望要求恢复出其中的Oracle数据库.由于是虚拟化环境,然后客户直接从虚拟化平台下载下来磁盘文件,通过工具加载和分析确认是一个xfs的文件系统。1. 尝试恢复oracle的control01.ctl文件,然后通过该文件尝试分析其他数据文件位置,运气不错该文件恢复出来是好的,直接加载到新库查询v$datafile,分析出来所有数据文件信息。
2024-05-16 20:33:17
540
原创 分布式存储故障导致数据库无法启动故障处理---惜分飞
国内xx医院使用了国外医疗行业龙头的pacs系统,由于是一个历史库,存放在分布式存储中,由于存储同时多个节点故障,导致数据库多个文件异常,数据库无法启动,三方维护人员尝试通通过rman归档进行应用日志,结果发现日志有损坏报ORA-00354 ORA-00353,无法记录恢复,希望我们给予支持。由于该系统是历史库,不会有新业务写入,通过对异常表和索引进行处理之后,客户测试业务可以正常访问,完成本次恢复。接手故障之后,通过尝试恢复发现除该错误之外,还有ORA-600 4552之类错误。
2024-05-11 23:13:04
221
原创 mysql数据库:read_me_recover_tn勒索恢复---惜分飞
建议先对系统进行镜像或者快照,然后按照先os层面恢复,如果效果不好,考虑block级别恢复的方法处理。
2024-05-10 00:49:20
356
原创 存储故障后oracle报—ORA-01122/ORA-01207故障处理---惜分飞
客户存储异常,通过硬件恢复解决存储故障之后,oracle数据库无法正常启动(存储cache丢失),尝试recover数据库报ORA-00283 ORA-01122 ORA-01110 ORA-01207错误。数据库无法通过正常recover的思路解决.通过屏蔽一致性,强制打开数据库,alert日志报ORA-600 2662错误。这个错误比较明显,由于28号回滚段异常导致,对异常回滚段进行处理,重建undo,数据库恢复主要工作完成。通过修改数据库scn,open数据库报ORA-600 4137。
2024-05-06 22:24:37
637
1
原创 PostgreSQL恢复系列:pg_filedump恢复字典构造---惜分飞
通过pg_namespace,pg_class信息,可以获取到对象所属的模式关系,基于上述汇总,可以获取到某个模式下面,所有表id和实际存储路径,现在使用pg_filedump进行恢复,还缺少表的列类型信息,通过pg_type和pg_attribute来获取。通过pg_class、pg_type和pg_attribute可以获取对象的表的列名称,数据类型等信息。结合上述的pg_database,pg_tablespace,pg_class信息,可以获取到每个表对应实际的存储路径。
2024-04-19 16:53:15
517
原创 PostgreSQL恢复系列:pg_filedump批量处理---惜分飞
2. 特别是在pg库无法正常运行的情况下,如果没有业务提供表创建语句,恢复基本上无法正常进行.,为了解决上述的两个,弄了一个pg_filedump_batch脚本实现批量恢复需求。在测试的pg库中创建了一些测试表,并查看部分表数据,便于对比后续恢复效果。1. 在没有人工列出列类型的情况下实现批量pg_filedump恢复功能。把pg_class恢复数据导入库中进行对比,证明恢复的数据完全正确。1. 需要人工一个个枚举各个列类型无法实现批量恢复,参考以前写的。3. 实现pg数据库的批量恢复。
2024-04-19 16:51:24
368
原创 ORA-600 ktsiseginfo1故障---惜分飞
从上述信息看,由于ora-600 kcbnew_3错误导致70/73号回滚段异常,smon无法正常对其进行扩展,关于ora-600 kcbnew_3报错描述。客户尝试关闭数据库重启,数据库报ora-600 ktsiseginfo1错误,无法正常启动。oracle 9i的库在运行途中突然报ORA-600 kcbnew_3错误。
2024-04-15 11:45:46
645
原创 数据库open成功后报ORA-00353 ORA-00354错误引起的一系列问题(本质ntfs文件系统异常)---惜分飞
因为这个库有ctl备份,通过rman还原ctl备份,然后尝试recover库,结果报ORA-00310 ORA-00334(由于需要的redo无法正常应用导致)服务器异常断电之后,开机启动数据库启动成功,但是报ORA-00353 ORA-00354以及ORA-600 kdsgrp1错误。对于正常open的库,出现此类问题属于反常现象,通过分析系统事件确定是由于ntfs文件系统本身有问题导致。数据报ORA-600 2662错误,此类错误比较简单,使用patch scn工具一键搞定(
2024-04-15 11:44:47
412
原创 ORA-00742 ORA-00312 恢复---惜分飞
有客户反馈,断电之后数据库启动报ORA-00742和ORA-00312,无法正常open。因为recover已经成功,但是依旧报ORA-742错误,尝试查询scn相关信息。后面比较不幸,数据库报ORA-600 4194错误导致数据库异常。基于这样的情况,我们判断数据库直接open成功。我们远程上去尝试open库结果也报同样错误。报错比较明显,对undo进行处理即可.
2024-04-15 11:44:04
784
原创 ORA-00600: internal error code, arguments: [16703], [1403], [4] 原因---惜分飞
其实ORA-600 16703 1403 N的错误,表示数据库在检索tab$表的时候,N为发现异常的obj#的值,这里的报错表示数据库在启动过程中无法检索到tab$中的tab$对象,应该是恢复过程中缺少该记录导致,解决问题的思路就是把该记录回写到tab$表中即可。
2024-03-22 10:37:41
447
原创 ORA-600 2662快速恢复之Patch scn工具---惜分飞
通过自研开发的patch scn工具,修改数据库scn值。对于这类故障,patch scn工具是最快速的解决方案。有客户数据库启动报ORA-600 2662错误。然后open数据库成功。
2024-03-21 00:36:27
193
原创 断电引起文件scn异常数据库恢复---惜分飞
检查发现/data2挂载点所有数据文件异常,由于以前的操作日志已经被清空无法判断原因,初步怀疑和这个挂载点本身有关系。这种情况直接使用bbed修改文件头,然后open库,再逻辑导出数据,完成本次数据恢复工作,参考类似文档。接手现场之后,尝试单个文件recover操作。经过应用厂商一系列操作,主要是如下操作。由于异常断电,数据库最初启动报错。基于这样的情况,通过。
2024-03-03 16:35:00
763
原创 .[hudsonL@cock.li].mkp勒索加密数据库完美恢复---惜分飞
通过定期的网络安全培训和教育,向用户传达有关勒索病毒及其传播方式的知识,让他们能够警惕潜在的威胁,并学会如何正确应对可疑的电子邮件、链接和附件。5. 访问控制:实施严格的访问控制措施,限制用户对系统和文件的访问权限,避免使用管理员权限进行日常操作,以减少恶意软件感染的风险。此外,定期进行系统维护和检查,确保系统的安全配置和设置。6. 应急响应计划:制定和实施应急响应计划,明确团队成员的责任和任务,建立应对勒索病毒和其他安全事件的应急响应流程,以最大程度地减少损失并快速恢复业务正常运营。
2024-02-26 23:21:04
550
原创 Oracle误删除数据文件恢复---惜分飞
由于涉及system表空间数据文件被删除,无法在open情况下直接操作,直接关闭数据库,启动到mount状态,重命名数据文件路径,recover数据文件,open库,恢复完成。有客户通过sftp误删除oracle数据文件,咨询我们是否可以恢复,通过远程上去检查,发现运气不错,数据库还没有crash,通过句柄找到被删除文件。查询数据文件大小(被删除的文件文件大小通过v$datafile查询为0)
2024-02-21 22:07:30
554
原创 ORA-600 kclchkblk_4和2662故障---惜分飞
有客户恢复请求:由于未知原因导致aix环境的rac两台主机同时重启之后数据库无法正常启动,初步判断是由于写丢失导致故障(ORA-00742 ORA-00353)后续检查发现obj$中的index异常(ORA-08102: index key not found, obj# 39)尝试屏蔽一致性强制拉库后数据库报ORA-600 kclchkblk_4。后续处理中出现和这个错误类似的ORA-600 2662错误。通过对oracle scn进行修改,数据库open成功。
2024-02-21 22:06:46
460
原创 从ORA-00283 ORA-16433报错开始恢复---惜分飞
接手一个客户无法正常启动的故障数据库,尝试recover 报ORA-00283 ORA-16433错误。由于redo和数据文件不匹配,无法正常recover库,尝试强制打开库报ORA-600 2662错误。第一次通过其他方法处理,由于计算失误导致数据库启动报ORA-600 2252错误。处理正确的scn值之后,数据库open成功,然后逻辑方式导出数据,恢复工作完成。通过对控制文件进行处理,再次尝试recover库。基于这种错误,尝试oradebug修改scn。
2024-02-03 22:13:26
877
2
原创 近期又遇到ORA-600 16703和ORA-702故障---惜分飞
比较常见的由于软件注入恶意代码或者被人恶意破坏的常见故障ORA-600 16703和ORA-702故障。
2024-01-30 15:17:06
307
原创 ORA-01033: ORACLE initialization or shutdown in progress---惜分飞
客户反馈数据库使用plsql dev登录报ORA-01033: ORACLE initialization or shutdown in progress的错误。在恢复过程中中还遇到了ORA-00700 kcrf_split_brain_error错误,但是没有影响数据库open。出现该错误一般是由于数据库没有正常open成功,查看oracle 告警日志发现。至此数据库open成功但是dbv检测system有很多坏块需要分析处理。通过分析aud$的extent,确认这些坏块全部属于该对象。
2024-01-22 21:36:18
1377
原创 存储故障,强制拉库报ORA-600 kcbzib_kcrsds_1处理---惜分飞
这个相对比较简单,对异常undo进行处理,cdb和pdb都open成功,使用数据泵把数据迁移到新库,完成本次恢复(比较幸运,硬件故障的库直接迁移成功,没有报其他错误)硬件故障,客户自行强制resetlogs库,报ORA-600 kcbzib_kcrsds_1错误。处理好该错误之后,数据库在open pdb的时候报ORA-600 4193错误。这个错误处理过多次一般是由于scn异常导致,以前部分类似文章。
2024-01-19 21:12:50
877
原创 mysql数据库被黑恢复—应用层面delete删除---惜分飞
确认这类的业务破坏是通过delete操作实现的,客户那边不太幸,客户找了多人进行恢复,现场严重破坏,老库被删除,并且还原了历史的备份文件(非故障第一现场),通过底层扫描恢复出来ibd和page文件,然后解析对应的文件,运气不错,恢复出来客户需要的数据。客户的mysql被人从应用层面攻击,并且删除了一些数据,导致业务无法正常使用,通过底层分析binlog确认类似恢复操作。
2024-01-12 16:11:25
1116
原创 记录一次ORA-01200完美恢复---惜分飞
报错比较明显system01.dbf文件本来大小应该为1131521个block,但是实际上只有1122561个block,因此无法正常启动,通过修改数据文件欺骗数据库。客户虚拟化平台断电,导致oracle其数据库启动ORA-01200错误。然后对异常的system文件进行处理,把人工构造的部分除掉。rman检测system文件正常。对应的alert日志如下。
2024-01-12 12:53:50
1093
原创 resetlogs失败故障恢复-ORA-01555---惜分飞
这个库由于客户在resetlogs之前offline了数据文件,导致一些麻烦,先使用Oracle Recovery Tools修改resetlogs scn。3. 在resetlogs之前,先offline了83号文件,这个将导致该文件的reseltogs scn和其他文件不一致,通过。2. 数据库在强制拉库的时候,很可能是屏蔽了一致性,导致文件头scn过小。然后增加temp,导出数据数据,完成本次数据库救援。然后重建ctl,修改scn,打开数据库。hcheck检测字典一切正常。
2024-01-03 18:08:54
1309
原创 在线mv方式迁移数据文件导致数据库无法正常启动---惜分飞
此类故障是由于在线拷贝数据文件,可能有不少最新写入的数据都有数据文件和redo不一致的风险,引起这里的ORA-600 3020最好不要通过allow N corruption的方式跳过,因为可能导致大量数据文件坏块,这样就不光丢失了redo数据,可能数据文件中好的block中的很多数据也丢失.对于这种情况,我们为了减少客户的数据丢失,选择了最少数据丢失的方法:通过bbed修改文件头,然后直接recover 数据文件,open库。alert日志报ORA-600 3020错误。sqlplus恢复数据库报错。
2024-01-03 18:08:08
638
原创 kettle导致MySQL数据丢失恢复---惜分飞
通过分析(相关文件的时间),判断kettle应该是在插入数据之前触发了truncate操作导致数据丢失,而且还插入了部分数据。有客户通过kettle 插入数据,由于配置不当导致原数据丢失,希望能够恢复之前数据(mysql数据库)遇到此类误操作,最重要的是保护现场,尽可能减少对数据文件所在分区的写入操作,可以实现最大限度数据恢复.通过数据块层面扫描分析,找出来需要恢复表对应的page文件。解析这些page文件恢复出来客户需要数据。
2023-12-21 11:16:45
413
原创 mysql数据库文件丢失恢复---惜分飞
这个客户出现该故障的原因大概率是由于文件系统损坏导致.最终可以比较好的恢复,主要是故障之后第一时间保护了现场,没进行任何的写入覆盖,如果覆盖了神仙也没有办法.如果此类问题无法自行解决或者恢复效果不好,可以联系“惜分飞”进行技术支持,最大限度抢救和数据,减少损失。通过底层工具进行分析,无法正确恢复数据库名字,一个个单个ibd文件(而且很多本身是错误的)对于这种情况,通过mysql block扫描恢复出来page文件。客户服务器重启,mysql相关数据文件丢失。恢复出来客户需要数据。
2023-12-10 22:49:22
161
原创 ORA-600 kcbzib_kcrsds_1一键恢复
一个19c库由于某种原因redo损坏强制打开库报ORA-600 kcbzib_kcrsds_1错误。工具快速修改数据库scn。
2023-12-07 22:30:48
266
oracle scn修改利器-Patch SCN最新版-202407
2024-07-05
Patch-SCN 小工具使用说明
2024-07-05
Oracle Recovery Tools-最新版(202407)
2023-04-10
ORA-702_Recovery使用说明
2022-07-21
Oracle Recovery Tools-202207版
2022-06-26
修改oracle scn小工具(patch scn)
2022-06-18
oracle patch scn--修改oracle scn工具(oracle异常恢复利器)
2022-06-18
Oracle Recovery Tools-202208版本
2021-10-19
Oracle Recovery Tools 使用说明
2021-10-06
12c – 使用跨平台增量备份来减少传输表空间的停机时间 (Doc ID 2102859.1).pdf
2020-08-15
rman_xttconvert_VER4.3.zip.7z
2020-08-15
ufsxpci64.zip
2020-03-08
基于odp.net的oraclehelper
2010-04-16
silverlight访问数据库汇总
2009-08-19
html+ashx论坛
2009-06-29
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人