- 博客(113)
- 资源 (21)
- 收藏
- 关注
RSS订阅原创 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
244
原创 PostgreSQL恢复系列:pg_filedump批量处理---惜分飞
2. 特别是在pg库无法正常运行的情况下,如果没有业务提供表创建语句,恢复基本上无法正常进行.,为了解决上述的两个,弄了一个pg_filedump_batch脚本实现批量恢复需求。在测试的pg库中创建了一些测试表,并查看部分表数据,便于对比后续恢复效果。1. 在没有人工列出列类型的情况下实现批量pg_filedump恢复功能。把pg_class恢复数据导入库中进行对比,证明恢复的数据完全正确。1. 需要人工一个个枚举各个列类型无法实现批量恢复,参考以前写的。3. 实现pg数据库的批量恢复。
2024-04-19 16:51:24
149
原创 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
616
原创 数据库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
261
原创 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
401
原创 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
309
原创 ORA-600 2662快速恢复之Patch scn工具---惜分飞
通过自研开发的patch scn工具,修改数据库scn值。对于这类故障,patch scn工具是最快速的解决方案。有客户数据库启动报ORA-600 2662错误。然后open数据库成功。
2024-03-21 00:36:27
168
原创 断电引起文件scn异常数据库恢复---惜分飞
检查发现/data2挂载点所有数据文件异常,由于以前的操作日志已经被清空无法判断原因,初步怀疑和这个挂载点本身有关系。这种情况直接使用bbed修改文件头,然后open库,再逻辑导出数据,完成本次数据恢复工作,参考类似文档。接手现场之后,尝试单个文件recover操作。经过应用厂商一系列操作，主要是如下操作。由于异常断电，数据库最初启动报错。基于这样的情况,通过。
2024-03-03 16:35:00
727
原创 .[[email protected]].mkp勒索加密数据库完美恢复---惜分飞
通过定期的网络安全培训和教育，向用户传达有关勒索病毒及其传播方式的知识，让他们能够警惕潜在的威胁，并学会如何正确应对可疑的电子邮件、链接和附件。5. 访问控制：实施严格的访问控制措施，限制用户对系统和文件的访问权限，避免使用管理员权限进行日常操作，以减少恶意软件感染的风险。此外，定期进行系统维护和检查，确保系统的安全配置和设置。6. 应急响应计划：制定和实施应急响应计划，明确团队成员的责任和任务，建立应对勒索病毒和其他安全事件的应急响应流程，以最大程度地减少损失并快速恢复业务正常运营。
2024-02-26 23:21:04
467
原创 Oracle误删除数据文件恢复---惜分飞
由于涉及system表空间数据文件被删除,无法在open情况下直接操作,直接关闭数据库,启动到mount状态,重命名数据文件路径,recover数据文件,open库,恢复完成。有客户通过sftp误删除oracle数据文件,咨询我们是否可以恢复,通过远程上去检查,发现运气不错,数据库还没有crash,通过句柄找到被删除文件。查询数据文件大小（被删除的文件文件大小通过v$datafile查询为0）
2024-02-21 22:07:30
523
原创 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
440
原创 从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
362
原创 近期又遇到ORA-600 16703和ORA-702故障---惜分飞
比较常见的由于软件注入恶意代码或者被人恶意破坏的常见故障ORA-600 16703和ORA-702故障。
2024-01-30 15:17:06
273
原创 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
1128
原创 存储故障,强制拉库报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
818
原创 mysql数据库被黑恢复—应用层面delete删除---惜分飞
确认这类的业务破坏是通过delete操作实现的,客户那边不太幸,客户找了多人进行恢复,现场严重破坏,老库被删除,并且还原了历史的备份文件(非故障第一现场),通过底层扫描恢复出来ibd和page文件,然后解析对应的文件,运气不错,恢复出来客户需要的数据。客户的mysql被人从应用层面攻击,并且删除了一些数据,导致业务无法正常使用,通过底层分析binlog确认类似恢复操作。
2024-01-12 16:11:25
1067
原创 记录一次ORA-01200完美恢复---惜分飞
报错比较明显system01.dbf文件本来大小应该为1131521个block,但是实际上只有1122561个block,因此无法正常启动,通过修改数据文件欺骗数据库。客户虚拟化平台断电，导致oracle其数据库启动ORA-01200错误。然后对异常的system文件进行处理,把人工构造的部分除掉。rman检测system文件正常。对应的alert日志如下。
2024-01-12 12:53:50
1046
原创 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
1233
原创 在线mv方式迁移数据文件导致数据库无法正常启动---惜分飞
此类故障是由于在线拷贝数据文件,可能有不少最新写入的数据都有数据文件和redo不一致的风险,引起这里的ORA-600 3020最好不要通过allow N corruption的方式跳过,因为可能导致大量数据文件坏块,这样就不光丢失了redo数据,可能数据文件中好的block中的很多数据也丢失.对于这种情况,我们为了减少客户的数据丢失,选择了最少数据丢失的方法:通过bbed修改文件头,然后直接recover 数据文件,open库。alert日志报ORA-600 3020错误。sqlplus恢复数据库报错。
2024-01-03 18:08:08
602
原创 kettle导致MySQL数据丢失恢复---惜分飞
通过分析（相关文件的时间）,判断kettle应该是在插入数据之前触发了truncate操作导致数据丢失,而且还插入了部分数据。有客户通过kettle 插入数据，由于配置不当导致原数据丢失,希望能够恢复之前数据（mysql数据库）遇到此类误操作,最重要的是保护现场,尽可能减少对数据文件所在分区的写入操作,可以实现最大限度数据恢复.通过数据块层面扫描分析,找出来需要恢复表对应的page文件。解析这些page文件恢复出来客户需要数据。
2023-12-21 11:16:45
323
原创 mysql数据库文件丢失恢复---惜分飞
这个客户出现该故障的原因大概率是由于文件系统损坏导致.最终可以比较好的恢复,主要是故障之后第一时间保护了现场,没进行任何的写入覆盖,如果覆盖了神仙也没有办法.如果此类问题无法自行解决或者恢复效果不好,可以联系“惜分飞”进行技术支持,最大限度抢救和数据,减少损失。通过底层工具进行分析,无法正确恢复数据库名字,一个个单个ibd文件(而且很多本身是错误的)对于这种情况,通过mysql block扫描恢复出来page文件。客户服务器重启,mysql相关数据文件丢失。恢复出来客户需要数据。
2023-12-10 22:49:22
135
原创 ORA-600 kcbzib_kcrsds_1一键恢复
一个19c库由于某种原因redo损坏强制打开库报ORA-600 kcbzib_kcrsds_1错误。工具快速修改数据库scn。
2023-12-07 22:30:48
167
原创 A____Z____RECOVER____DATA勒索恢复---惜分飞
对于类似这种A____Z____RECOVER____DATA勒索恢复,建议先对系统进行镜像或者快照,然后按照先os层面恢复,在block级别恢复的方法处理,如果无法自行解决,可以联系我们进行技术支持,最大限度抢救和数据,减少损失,对于这种情况,本质就是mysql drop 库或者drop表级别的恢复,通过反删除软件恢复,可惜恢复效果很差（底层发生了大量的覆盖）另外建议加强系统和mysql安全加固,数据库尽量不要暴露在公网上。对于这种情况,只能采用底层block级别恢复,通过底层扫描分析。
2023-11-21 21:28:08
2092
原创 再现ORA-600 4000故障处理---惜分飞
resetlogs失败,报ora-600 4000错误,查看相关trace文件。有一个10g的库，由于redo损坏导致无法正常recover成功。正常途径无法open成功,尝试强制打开库。
2023-10-18 15:25:47
166
原创 ORA-07445: exception encountered: core dump [kdxlin()+4088]---惜分飞
出现这种情况是由于redo和数据文件块不一致导致无法正常应用日志,人工对于异常的block进行处理,数据库open成功,然后遭遇undo回滚段异常,对其进行规避,数据库open并且稳定运行。重建ctl之后，尝试recover数据库报错ORA-600 3020和ORA-07445 kdxlin等错误。尝试随机恢复文件，也遭遇ORA-07445 kdxlin异常。abort方式关闭数据库，启动报错。
2023-09-23 22:55:54
603
原创 bbed解决ORA-01578---惜分飞
业务报ORA-01578坏块,无法正常使用,alert日志报错如下。通过dbv检查数据文件,发现只有这一个坏块。业务测试正常,数据完美恢复。通过bbed进入进行修复。
2023-09-15 09:52:18
345
原创 asm disk被加入到另外一个磁盘组故障恢复---惜分飞
通过lscfg 命令确认两套rac使用了同一块盘导致一个磁盘组异常，在新加的机器上查询确认新盘被破坏情况(新加入的磁盘由于reblance操作,已经被写入了380G左右数据[也就意味着这个磁盘在老磁盘组中最少会丢失380G数据]怀疑把报错这个磁盘组的rhdisk37加入到另外一套rac的asm中了(也就是说两套asm使用了同一块磁盘)，aix操作系统层面分析确认。有朋友在aix环境对其中一个rac的asm磁盘组进行扩容。之后另外一套rac的磁盘组直接dismount。
2023-09-05 14:21:55
131
原创 ORA-600 ksuloget2 恢复----惜分飞
由于是应用日志失败,屏蔽日志一致性,强制打开数据库,检查数据ok,业务可以直接使用,对于这类问题,官方建议:ORA-600: [Ksuloget2] Hit on Windows When SGA Greater Than 1G (Doc ID 836109.1)客户在win 32位的操作系统上调至sga超过2G,数据库运行过程中报ORA-600 ksuloget2错误。重启数据库,进行尝试恢复继续报ORA-600 ksuloget2。
2023-08-19 21:58:13
178
原创 Patch SCN一键解决ORA-600 2662故障---惜分飞
客户强制重启库之后,数据库启动报ORA-600 2037,ORA-745 kcbs_reset_pool/kcbzre1等错误。屏蔽数据库一致性,强制拉库报ORA-600 2662错误。这种ORA-600 2662的错误比较常见,通过。实现数据库open成功，并顺利导出数据。
2023-08-13 00:19:46
996
原创 Oracle 19c 报ORA-704 ORA-01555故障处理---惜分飞
异常断电导致数据库无法启动,尝试对数据文件进行recover操作,报ORA-00283 ORA-00742 ORA-00312错误,由于redo写丢失无法正常应用。屏蔽数据一致性,尝试强制打开库,报ORA-00604,ORA-00704,ORA-01555错误。alert日志对应错误。
2023-07-30 16:14:53
655
原创 Exadata磁盘损坏导致磁盘组无法mount恢复（oracle一体机磁盘组异常恢复）---惜分飞
在实际恢复过程中由于客户进行了各种尝试,直接新镜像盘然后插入新盘,强制拉磁盘组drop异常disk操作等,导致第一现场发生一些破坏,增加了恢复难道,但是最终通过各种方法弥补,实现了预期的恢复效果(业务数据0丢失)故障原因是由于asm disk 32还已经损坏在换盘过程中(数据没有reblance完成),又损坏了asm disk 39,而这两份磁盘中有数据互为镜像,因此磁盘组无法正常mount起来.),然后比较顺利恢复数据,实现业务数据0丢失。多套库顺利open成功。
2023-07-28 13:24:13
686
原创 .faust加密勒索数据库恢复---惜分飞
然后直接open数据库,并且导出数据,实现数据库非常完美的恢复(这个是目前除直接解密之外最好的恢复效果,没有之一)对于这种级别的损坏,可以通过我开发的Oracle数据文件勒索加密恢复工具直接重构文件头。8.对不熟悉的软件，如果已经被杀毒软件拦截查杀，不要添加信任继续运行。对于类似这种被加密的勒索的数据文件,我们可以实现比较好的恢复效果。2.登录口令要有足够的长度和复杂性，并定期更换登录口令。9.保存良好的备份习惯，尽量做到每日备份，异地备份。4.定期检测系统和软件中的安全漏洞，及时打上补丁。
2023-07-25 21:56:35
460
原创 ORA-01122 ORA-01208 故障处理---惜分飞
确认数据库恢复需要sequence为254986的日志,但是数据库为非归档模式,redo已经被覆盖,因此常规方法无法正常open库,通过。数据库突然故障ORA-01122 ORA-01208,导致实例crash。工具快速修改文件头实现数据库文件头一致,open数据库成功。重启实例无法open。
2023-07-15 20:18:16
845
原创 硬件故障恢复出文件之后数据库故障处理---惜分飞
客户那边硬件故障(raid损坏磁盘超过了极限,导致raid offline),通过硬件恢复出来数据文件,然后尝试自行恢复,我接手的时候大量数据文件resetlogs scn异常.对于这种硬件恢复之后文件上次到服务器上进行恢复的,一定要确认上传文件和原文件一致,不然做无用功或者恢复效果差很多。通过修改文件头然后重建控制文件,可以通过bbed,或者我的小工具。解决好该问题之后,数据库open成功,实现了最大限度抢救数据.通过对比发现是由于客户上传恢复文件异常导致。然后继续重建ctl发现以下错误。
2023-07-13 00:30:05
225
原创 win系统删除oracle数据文件恢复---惜分飞
有客户联系我们,说win平台下的数据库,在由于空间紧张,在关闭数据库的情况下删除的两个数据文件,导致数据库无法正常访问很多业务表,需要对其进行恢复,查看alert日志发现大概操作,删除文件之后,启动数据库失败。另外一个数据文件,从os层面无法恢复,对于这种情况,只能基于底层的block层面进行恢复(恢复没有覆盖的block)接手现场之后,关闭数据库,使用操作系统层面反删除工具进行扫描恢复,发现其中一个文件(另外一个文件os层面无法恢复)offline相关数据文件,启动库成功,但是job开始报错。
2023-07-07 15:11:16
844
原创 ORA-01122 ORA-01200故障处理---惜分飞
让客户把system01.dbf文件发给我进行分析,发现system01.dbf文件大于32G(在8k的blocksize库中,默认情况system01.dbf文件不会超过32G),这个明显异常。通过bbed修改合适的值,并且把文件截取到适当大小,提供system文件给客户,直接启动库成功,实现数据库完美恢复。由于某种原因客户的数据库启动报ORA-01122 ORA-01200错误。检测坏块情况发现4096000之后的block全部为全0块。通过bbed分析文件头记录文件大小。
2023-07-04 16:59:18
550
原创 asm磁盘加入vg恢复---惜分飞
这个客户做了上述操作之后,没有对lv进行写入其他数据,所以破坏较少(主要的破坏就是ext4的每个一段就会置空一部分block预留给文件系统写入元数据使用),通过winhex查看被破坏磁盘发现lvm信息。然后直接恢复dbf中数据文件（对于异常的主要是segment header被置空的tab使用dul单独扫描处理）,实现客户数据的最大限度恢复。对于这种情况,通过对文件头进行修复,结合工具直接拷贝出来数据文件（个别文件元数据损坏通过基于block的方式恢复dbf）
2023-06-25 22:36:14
69
原创 Oracle Recovery Tools恢复csc higher than block scn---惜分飞
有客户强制关闭数据库,结果有数据块报坏块,dbv检查为:csc higher than block scn问题。通过OraRecovery工具快速解决csc higher than block scn故障。dbv再次验证数据块ok,Oracle Recovery完美代替bbed解决该问题。该问题主要是由于scn异常导致通过Oracle Recovery工具进行修复。
2023-06-22 23:16:18
157
原创 .mdf.locked加密sql server完美恢复---惜分飞
对于类似这种被加密的勒索的数据文件,我们可以实现比较好的恢复效果,如果此类的数据库(oracle,mysql,sql server)等被加密,需要专业支持。有可能用友ERP软件的sql server 数据库所在机器被勒索病毒加密,扩展名为.locked和昨天恢复的基本类似(8.对不熟悉的软件，如果已经被杀毒软件拦截查杀，不要添加信任继续运行。2.登录口令要有足够的长度和复杂性，并定期更换登录口令。9.保存良好的备份习惯，尽量做到每日备份，异地备份。4.定期检测系统和软件中的安全漏洞，及时打上补丁。
2023-06-12 00:09:57
1148
Oracle Recovery Tools-最新版
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关注的人