- 博客(149)
- 资源 (21)
- 收藏
- 关注
转载 断电引起的ORA-08102: 未找到索引关键字, 对象号 39故障处理---惜分飞
最近有客户在虚拟化平台运行oracle,由于机房掉电,导致oracle数据库无法正常启动,通过第三方恢复,oracle被强制拉起,但是无法进行ddl操作,比如创建表报ORA-08102: 未找到索引关键字, 对象号 39, 文件 1, 块 122448 (2) 错误。处理完上述两个明显故障之后,然后使用expdp不落地方式把客户数据迁移到新库,完成本次恢复任务。这个问题解决之后,该客户还有另外一个问题需要解决(不然数据库运行一段时间之后就会crash)
2024-12-24 20:12:30
36
转载 ORA-00227: corrupt block detected in control file---惜分飞
由于对oracle粗心对于oracle版本判断失误,导致打开数据库失败,使用正确版本打开数据库发现ctl有报错,导致打开依旧失败(这种错误一般比较少见,大部分ctl异常都是在oracle mount状态无法成功)报错提示比较明显,是由于oracle恢复需要的redo损坏,导致无法进行正常恢复,这种情况下,只能尝试强制打开库。由于服务器断电,导致oracle数据库无法正常启动,recover报ORA-00353 ORA-00312错。重建ctl,打开数据库成功,导出数据,完成本次恢复任务。
2024-12-20 20:53:09
36
转载 解决oracle数据文件路径有回车故障---惜分飞
最近遇到一个硬件恢复朋友的请求,oracle数据库文件恢复出来了,但是在linux上面启动的时候,有两个文件无法检测到,dbv检测正常.2.操作系统层面查看文件(在我的ssh工具中,可以看到带回车键文件和不带回车文件不一样,使用的是crt工具,其他工具是否显示不确定)3. 数据库层面重启看文件情况,发现文件不能被正常发现(当然不能,文件被os层面mv了)进一步检查发现原库这两个文件结尾带有回车,但是恢复出来的文件不带回车。4. 解决控制文件和数据文件实际名称不一致问题。通过分析是由于文件无法找到原因导致。
2024-12-14 08:50:21
28
原创 .wstop扩展名勒索数据库恢复---惜分飞
通过定期的网络安全培训和教育,向用户传达有关勒索病毒及其传播方式的知识,让他们能够警惕潜在的威胁,并学会如何正确应对可疑的电子邮件、链接和附件。5. 访问控制:实施严格的访问控制措施,限制用户对系统和文件的访问权限,避免使用管理员权限进行日常操作,以减少恶意软件感染的风险。此外,定期进行系统维护和检查,确保系统的安全配置和设置。6. 应急响应计划:制定和实施应急响应计划,明确团队成员的责任和任务,建立应对勒索病毒和其他安全事件的应急响应流程,以最大程度地减少损失并快速恢复业务正常运营。
2024-12-08 10:11:41
888
3
原创 Oracle Recovery Tools工具一键解决ORA-00376 ORA-01110故障(文件offline)---惜分飞
客户在win上面迁移数据文件,由于原库非归档,结果导致有两个文件scn不一致,无法打开库,结果他们选择offline文件,然后打开数据库。对于这类缺少归档数据文件offline的故障Oracle Recovery Tools可以快速傻瓜式恢复。由于这两个文件处于offline状态导致客户很多操作报ORA-00376 ORA-01110之类错。后面自行尝试recover 数据文件没有成功。然后直接recover 数据文件成功。
2024-12-07 22:58:24
375
原创 dd破坏asm磁盘头恢复---惜分飞
从10.2.0.5之后版本,在第二个au的倒数第二个block上面,有asm disk header备份(每个block大小为4k),分析au大小(通过分析正常的asm disk快速找到au 大小【使用dd备份的正常的磁盘头查看】)基于上述分析,直接使用备份的asm disk header信息进行merge或者repair修复之后,asm 磁盘头状态恢复正常。确认被损坏的磁盘只有磁盘头信息损坏(即确认第二个block是否是好的)找到被破坏的asm disk的备份磁盘头信息。
2024-12-06 20:48:50
454
原创 删除asmlib磁盘导致磁盘组故障恢复---惜分飞
有客户执行drop disk磁盘组操作之后,然后立刻从oracle asmlib层面执行了oracleasm deletedisk,并且在操作系统层面delete partition(删除磁盘分区),导致磁盘组直接dismount。通过重新分区,并且kfed repair修复磁盘头操作之后,重新mount磁盘组报错。1. 直接恢复出来该磁盘组数据然后打开该库。2. 直接提取客户需要的核心表数据。
2024-12-06 20:47:03
291
原创 ntfs MFT损坏(ntfs文件系统故障)导致oracle异常恢复---惜分飞
通过对该文件底层block分析,确认最终丢失block就是最后20M(直接的数据文件的block的rdba均正确),对于这种故障,通过填补数据文件尾部,欺骗数据库完成该文件的恢复(最后20M中如果写入了业务数据,可能会丢失),做好该文件修复工作之后,尝试打开数据库,结果很不乐观,redo也损坏。客户虚拟化环境,由于断电,启动数据库报ORA-01157错误,通过操作系统层面查看,发现文件是存在的,但是dbv检测报不可访问。感觉是文件系统损坏了,尝试把该文件拷贝到其他磁盘。屏蔽一致性,强制打开库成功。
2024-10-19 22:03:30
525
原创 清空redo导致oracle故障恢复---惜分飞
这种情况下,所有redo全部被清空(包含current,active的redo),只能强制拉库,运气不错,拉库成功.客户由于空间不足,使用> redo命令清空了oracle的redo文件。数据库挂掉之后,启动报错。
2024-10-16 22:23:32
554
原创 A_H_README_TO_RECOVER勒索恢复---惜分飞
对于类似这种A_H_README_TO_RECOVER勒索恢复,建议先对系统进行镜像或者快照,然后按照先os层面恢复,在block级别恢复的方法处理,如果无法自行解决,可以联系我们进行技术支持,最大限度抢救和数据,减少损失,处理方法一般也就是先考虑os层面恢复,如果os层面无法恢复,就从block层面进行恢复,这个客户通过最终分析,恢复出来客户需要的表数据。有客户mysql数据库被黑(业务数据库被删除),创建了一个A_H_README_TO_RECOVER库。
2024-10-05 10:16:46
628
原创 ORA-01558: out of transaction ID‘s in rollback segment SYSTEM---惜分飞
客户一个11.2.0.1的库,在重启之前报ORA-00604和ORA-01558: out of transaction ID’s in rollback segment SYSTEM错误。由于客户遇到故障之后,第一时间保护了现场,没有进行二次破坏,使用bbed进行修改block,实现完美恢复.处理方法,通过bbed对异常的block进行编辑,修改Wrap#的值,重新dumpblock进行确认。数据库关闭之后无法open,报ORA-01092 ORA-00604 ORA-01558错误。
2024-09-21 23:58:30
1222
原创 Oracle 19c异常恢复—ORA-01209/ORA-65088---惜分飞
ORA-65088参见官方:ORA-65088 while opening DB with resetlogs for multi-tenant DB in 12.2 (Doc ID 2449591.1),应该不是一个技术问题(由于重建ctl+resetlogs导致)由于raid卡bug故障,导致文件系统异常,从而使得数据库无法正常启动,客户找到我之前已经让多人分析,均未恢复成功,查看alert日志,发现他们恢复的时候尝试resetlogs库,然后报ORA-600 kcbzib_kcrsds_1错误。
2024-09-17 21:52:37
1511
原创 ORA-600 16703故障再现---惜分飞
由于此类故障出现较多,破坏性加大,对其进行了深入的研究,在没有破坏现场的情况下,通过对tab$进行直接重建,实现数据库完美恢复(数据0丢失,数据库无需逻辑迁移[原库直接可用])尽可能不要从互联网下载Oracle安装介质和Patch,避免被注入恶意脚本,并检查已经存在的安装介质的sha256码。)至今已经7年多时间了,最近依旧有客户中招。从第一次发现ORA-600 16703(
2024-09-16 09:41:50
548
原创 .[metro777@cock.li].Elbie勒索病毒加密数据库恢复---惜分飞
通过定期的网络安全培训和教育,向用户传达有关勒索病毒及其传播方式的知识,让他们能够警惕潜在的威胁,并学会如何正确应对可疑的电子邮件、链接和附件。5. 访问控制:实施严格的访问控制措施,限制用户对系统和文件的访问权限,避免使用管理员权限进行日常操作,以减少恶意软件感染的风险。此外,定期进行系统维护和检查,确保系统的安全配置和设置。6. 应急响应计划:制定和实施应急响应计划,明确团队成员的责任和任务,建立应对勒索病毒和其他安全事件的应急响应流程,以最大程度地减少损失并快速恢复业务正常运营。
2024-09-13 20:59:52
375
原创 应用连接错误,初始化mysql数据库恢复---惜分飞
登录操作系统查看,发现数据库文件在根分区,创建了新库,写入了数据之外,还有几个G的binlog.全部恢复不太可能,最后客户决定需要恢复的2个核心表数据,估计也就几十M的数据.通过os层面进行分析,发现操作系统的反删除恢复无法实现这类数据恢复.最后决定从mysql innodb的的碎片级别记性扫描恢复,通过扫描发现较多碎片。有人在部署一个新网站的时候,写错了配置信息,直接导致原有数据库被清掉,并创建了新库和写入了数据(其实本质就是drop table恢复)
2024-09-10 20:24:13
452
原创 drop tablespace xxx including contents恢复---惜分飞
所以这个恢复相对比较简单,直接使用dul之类工具扫描数据文件获取到实际数据.结合客户导出的元数据和通过一些途径恢复出来的dataobj#信息,进行整合,实现数据接近完美恢复,可以业务直接启动成功,其中几个大表的lbo字段数据恢复情况。客户在咨询我的同时,也咨询了其他人,有人给客户答复是可以通过修改字典(以为有导出的元数据就可以逆向想改文件回去),然后把数据文件拷贝过去,实现恢复,成功概率65%[只能说是真牛]4)数据文件复制到新库,完全不是同一个库的,要大量修改文件头信息,我估计他们在这一步都不能成功。
2024-09-05 13:24:31
499
原创 ORA-600 krhpfh_03-1210故障处理---惜分飞
这样的情况,根据以往经验,ORA-01207: file is more recent than control file通过重建ctl即可恢复,先关闭所有节点,然后尝试启动一个节点。1. 是由于该集群本身多节点(6个节点),只要有节点是open状态,其他节点关闭再启动依旧可以正常启动,但是无法写入数据到报ORA-01207错误的数据文件中(可以读取数据).修改好这些值之后,recover database和open数据库成功,检查字典正常,业务读写也正常,完成本次恢复任务。
2024-08-26 12:28:57
734
原创 redo写丢失导致ORA-600 kcrf_resilver_log_1故障---惜分飞
有一个客户硬件故障,做完硬件恢复之后,数据库启动报ORA-600 kcrf_resilver_log_1错误.查询mos出现该问题的原因一般是由于redo log write lost导致。
2024-08-26 12:27:18
225
原创 19c库启动报ORA-600 kcbzib_kcrsds_1---惜分飞
官方关于kcbzib_kcrsds_1从解释只有:Bug 31887074 – sr21.1bigscn_hipu3 – trc – ksfdopn2 – ORA-600 [kcbzib_kcrsds_1] (Doc ID 31887074.8)一套19c的库由于某种情况,发现异常,当时的技术使用隐含参数强制拉库,导致数据库启动报ORA-00704 ORA-600 kcbzib_kcrsds_1错误。
2024-08-26 12:26:16
649
原创 200T 数据库非归档无备份恢复---惜分飞
一套近200T的,6个节点的RAC,由于存储管线链路不稳定,导致服务器经常性掉盘,引起asm 磁盘组频繁dismount/mount,数据库集群节点不停的重启,修复好链路问题之后,数据库启动报ORA-01113,ORA-01110。由于数据库是非归档模式,该库无法通过应用归档日志来实现对这些文件进行恢复,对于这种情况,直接使用dbms_diskgroup把数据文件头拷贝到文件系统中,类似操作。通过上述操作,确认bbed修改文件头成功,后续类似方法对其他9个文件进行修改,并打开数据库。
2024-08-15 21:18:30
973
原创 [comingback2022@cock.li].eking和[tsai.shen@mailfence.com].faust扩展名勒索病毒数据库可以完美恢复---惜分飞
最近接到两个由于操作系统文件被加密,其中的Oracle数据库文件被勒索病毒加密恢复的请求,通过底层分析,确认这两种勒索病毒加密的数据库能够非常好的恢复(可以通过修复,直接open库,然后导出数据,业务直接使用)通过定期的网络安全培训和教育,向用户传达有关勒索病毒及其传播方式的知识,让他们能够警惕潜在的威胁,并学会如何正确应对可疑的电子邮件、链接和附件。5. 访问控制:实施严格的访问控制措施,限制用户对系统和文件的访问权限,避免使用管理员权限进行日常操作,以减少恶意软件感染的风险。
2024-08-08 11:47:20
518
原创 断电引起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
788
原创 存储宕机导致Oracle异常故障处理---惜分飞
操作到这里,后续问题就比较麻烦了,因为在asm磁盘组中数据文件重建ctl的时候遗漏3个并且还被resetlogs操作过,导致这三个文件的resetlogs scn和其他数据文件不一致,对于这个问题,解决办法通过。客户尝试重建ctl进行恢复,结果由于分析不正确,导致在重建ctl的时候,遗漏了3个数据文件,并且在屏蔽一致性的情况下,强制resetlogs操作,结果数据库没有被正常打开,而是报ORA-600 2662错误。工具或者bbed修改相关resetlogs scn,然后重建ctl。
2024-07-28 22:37:11
571
原创 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
1017
原创 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
312
原创 数据库启动报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
447
原创 Patch SCN使用说明---惜分飞
该软件是惜分飞(https://www.xifenfei.com)开发,仅用来查看和修改Oracle数据库SCN(System Change Number),主要使用在数据库因为某种原因导致无法正常启动的情况下使用该工具进行解决.特别是Oracle新版本中使用隐含参数,event,oradebug等方法无法推进Oracle SCN的情况下,使用该工具能够快速修改SCN,实现数据库启动成功.
2024-07-05 22:37:21
924
原创 异常断电数据库恢复-从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
633
原创 ORA-600 2131故障处理---惜分飞
这个错误是由于controlfile损坏导致,有这个库以前部署过rman备份,解决起来比较简单,使用rman还原控制文件,并尝试recover。这种恢复情况下,如果现在要打开库,需要resetlogs方式,考虑通过创建ctl直接打开(不想用resetlogs)数据库启动报ORA-600 2131错误,查看alert日志发现是在mount过程报错。
2024-05-30 22:35:24
587
原创 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
816
1
原创 resetlogs强制拉库失败并使用备份system文件还原数据库故障处理---惜分飞
这个问题比较简单,通过bbed或者Oracle Recovery Tools修改文件头相关信息,然后open数据库成功。然后客户使用备份的system01.dbf文件替换了被resetlogs之后文件,导致数据库后续操作无法继续。接手一个库,在open的过程中遭遇到ORA-600 2662错误。但是由于system文件有大量坏块导致数据库无法正常登录和导出。通过dbv检查system数据文件。,实现数据库可以完美导出数据。
2024-05-30 22:33:46
390
原创 数据库open报ORA-600 kcratr_scan_lastbwr故障处理---惜分飞
由于断电,导致数据库正常open报ORA-600 kcratr_scan_lastbwr错误。尝试recover 数据库报ORA-600 3020错误。加上隐含参数尝试强制拉库。
2024-05-30 22:33:08
593
原创 rm -rf误删Oracle数据库恢复---惜分飞
有客户把虚拟化环境中装有oracle数据库的linux操作系统,由于操作失误在/下面执行了rm -rf *,导致所有文件被删除,系统无法启动.客户希望要求恢复出其中的Oracle数据库.由于是虚拟化环境,然后客户直接从虚拟化平台下载下来磁盘文件,通过工具加载和分析确认是一个xfs的文件系统。1. 尝试恢复oracle的control01.ctl文件,然后通过该文件尝试分析其他数据文件位置,运气不错该文件恢复出来是好的,直接加载到新库查询v$datafile,分析出来所有数据文件信息。
2024-05-16 20:33:17
594
原创 分布式存储故障导致数据库无法启动故障处理---惜分飞
国内xx医院使用了国外医疗行业龙头的pacs系统,由于是一个历史库,存放在分布式存储中,由于存储同时多个节点故障,导致数据库多个文件异常,数据库无法启动,三方维护人员尝试通通过rman归档进行应用日志,结果发现日志有损坏报ORA-00354 ORA-00353,无法记录恢复,希望我们给予支持。由于该系统是历史库,不会有新业务写入,通过对异常表和索引进行处理之后,客户测试业务可以正常访问,完成本次恢复。接手故障之后,通过尝试恢复发现除该错误之外,还有ORA-600 4552之类错误。
2024-05-11 23:13:04
249
原创 mysql数据库:read_me_recover_tn勒索恢复---惜分飞
建议先对系统进行镜像或者快照,然后按照先os层面恢复,如果效果不好,考虑block级别恢复的方法处理。
2024-05-10 00:49:20
440
原创 存储故障后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
824
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
586
原创 PostgreSQL恢复系列:pg_filedump批量处理---惜分飞
2. 特别是在pg库无法正常运行的情况下,如果没有业务提供表创建语句,恢复基本上无法正常进行.,为了解决上述的两个,弄了一个pg_filedump_batch脚本实现批量恢复需求。在测试的pg库中创建了一些测试表,并查看部分表数据,便于对比后续恢复效果。1. 在没有人工列出列类型的情况下实现批量pg_filedump恢复功能。把pg_class恢复数据导入库中进行对比,证明恢复的数据完全正确。1. 需要人工一个个枚举各个列类型无法实现批量恢复,参考以前写的。3. 实现pg数据库的批量恢复。
2024-04-19 16:51:24
445
原创 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
679
原创 数据库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
580
oracle scn修改利器-Patch SCN最新版-202501
2024-07-05
Patch-SCN 小工具使用说明
2024-07-05
Oracle Recovery Tools-最新版(202501)
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关注的人