- 博客(166)
- 资源 (21)
- 收藏
- 关注
RSS订阅原创 ORA-600 kokiasg1故障分析---惜分飞
客户正常关闭数据库,然后启动报ORA-600 kokiasg1错误,通过对启动分析确认是由于IDGEN1$序列丢失导致,修复该故障之后,数据库启动成功,但是后台大量报ORA-600 12803,ORA-600 15264等错误,业务用户无法登录.经过深入分析,发现数据库字典obj$中所有核心字典的序列全部被删除,但是在seq$中这些对象的obj#记录还存在.初步怀疑是有人恶意删除了obj$中字典核心序列对象导致.
2025-07-08 22:59:01
575
原创 Oracle数据库文件变成32k故障恢复--惜分飞
这里有一个问题,由于磁盘空间不足,导致部分备份不成功,但是系统级别删除操作依旧正常进行,导致以前有效的备份被删除,后面的备份又没有成功（这个是本次该文件无法还原的主要原因）,慎重提醒,rman备份尽量使用rman本身的策略来管理不要使用系统命令来维护备份策略,基于这样的情况,可以使用反删除命令找出来了一些该文件的备份集,并注册到控制文件中。基于当前情况,可以确认该文件异常,而且没有有效的rman备份.通过分析备份脚本,发现每个备份集1个数据文件,而且没有压缩，并按照10g进行分割为多个文件。
2025-06-27 23:35:15
463
原创 文件系统格式化MySQL数据库恢复---惜分飞
有客户在做迁移的时候,不慎把存放mysql数据库的硬盘进行了重新分区格式化,重新初始化mysql,并且导入了部分历史数据,不能满足客户需求,希望我们帮忙进行数据恢复.里面大概有100套左右mysql数据库,每个库里面表结构相同,数据不一样.接手这个故障,第一操作就是对磁盘进行镜像,然后使用恢复工具进行底层分析,尝试从文件系统层面恢复出来被格式化之前的数据库文件(需要有对应库目录,不然也没有意义,因为每个库里面表结构一样的,没有正确的库名字无法做到有效的区分),通过底层扫描分析,没有发现一个有效数据文件。
2025-06-19 22:28:36
283
原创 一次硬件恢复之后数据文件0kb的故障恢复---惜分飞
导出需要的业务用户字典信息,然后把客户那边提供的users01.dbf文件(users02.dbf是客户在21年之后增加的,原则上客户要的数据都在users01.dbf中)中的数据恢复到导出的字典中,完成本次数据恢复,客户远程验证业务,运行正常,客户需要的配置信息都在其中.基于这种情况,我这边在客户恢复的整个目录文件中,再三查找,发现了一个类似rman备份的文件(是21年的),对其进行还原尝试。客户一个比较久远系统,由于长期没有人维护,导致硬件故障,客户找人进行了硬件恢复之后,发现大量数据文件为0kb。
2025-06-16 23:10:14
814
原创 .sstop勒索加密数据库恢复---惜分飞
数据库文件被加密,扩展名类似:.[[dataserver@airmail.cc]].sstop,通过工具进行坏块检测确认破坏数据文件三段,每段8个block。根据经验可以确认,数据文件前面8个block肯定没有业务数据(主要是文件头信息和位图信息),可以使用Oracle数据文件勒索加密恢复工具对其文件头进行构造。8.对不熟悉的软件，如果已经被杀毒软件拦截查杀，不要添加信任继续运行。9.保存良好的备份习惯，尽量做到每日备份，异地备份。4.定期检测系统和软件中的安全漏洞，及时打上补丁。
2025-06-16 23:08:10
321
原创 linux环境oracle数据库被文件系统勒索加密为.babyk扩展名溯源---惜分飞
这些程序都是4月24日14:58:40-14:58:50之间创建,通过咨询客户,客户的应用在4月24日上午进行了升级.基于上述情况,初步怀疑是通过应用给数据库层面注入了恶意脚本,创建了函数和一些java包,实现提权获取了操作系统权限,然后对操作系统文件进行加密.最终结论需要等应用和安全厂商进行确认。通过解密成功的system01.dbf文件打开库,然后检查数据库中对象,发现一个异常的函数shellrun。分析对应的java相关的ShellUtil,检查发现有以下部分。这些程序的创建时间分析。
2025-05-27 09:01:03
414
原创 记录一次asm disk加入到vg通过恢复直接open库的案例---惜分飞
通过底层对磁盘进行分析,发现备份的磁盘头均以损坏,通过深入分析确认f1b1在sdb磁盘的第10个au上,通过相关信息,使用dul工具加载磁盘组,并分析元数据信息,发现恢复数据需要的元数据都可以正常加载。1)asm disk 加入到vg,并分配给lv之后,立刻停止写入操作,避免了因为写入数据而覆盖asm 磁盘的带来的风险。客户在不清楚磁盘被asm disk使用的情况下,直接分区做pv,加入到vg中并且分配给了lv,导致数据库异常。4)是云环境的ssd磁盘,没有触发trim功能。
2025-05-07 15:01:27
448
原创 Oracle Recovery Tools修复ORA-00742、ORA-600 ktbair2: illegal inheritance故障
至此数据库open成功,由于该库有不少坏块(包括system的一些字典),后续使用逻辑方式迁移数据到新库中(其中由于C_OBJ#簇中有坏块,导致迁移过程中大量index丢失,通过一些方法使用obj$,inde$等基表人工生成index.sql对于丢失的index进行弥补),最终客户业务正常运行。接到客户反馈,一套运行在虚拟化平台中的Oracle数据库,由于机房断电,导致数据库无法启动,最初启动报错。1.在需要实例恢复的block中有坏块,而且主要集中在3号文件(sysaux)上。
2025-04-25 13:09:08
760
原创 Oracle Recovery Tools修复ORA-600 6101/kdxlin:psno out of range故障
发现2号数据文件异常,报ORA-600 6101和ORA-600 kdxlin:psno out of range错误,出现该错误的原因主要是由于数据文件的bock和redo中信息不匹配导致,对于这种情况,我这边选择使用。数据库异常断电,然后启动异常,我接手该库,尝试recover恢复。逻辑方法导出该库,完成该库的恢复工作。再次recover并且直接打开库。
2025-04-19 22:06:24
494
原创 VMware勒索加密恢复(vmdk勒索恢复)---惜分飞
客户运行VMware Esxi由于被黑客攻破,导致所有的vmdk文件均被加密,其中包含大量的数据库虚拟机,这段时间,客户找了不少人进行分析恢复,要不就是恢复效果不好,要不就是要加太高,通过底层分析,确认可以比较完美的恢复,包括虚拟机直接运行的mysql、oracle数据库,docker中运行的mysql数据库,那其中一个恢复case来说明,被加密的虚拟机文件是一个500G的vmkd文件(.vmdk.{74C1B740-FEC0-01BD-914B-5F2CBAAA094E}.tianrui)
2025-03-31 18:06:14
353
原创 虚拟化加密恢复---惜分飞
通过底层分析,确认vmdk文件可以通过找出来分区信息,确认当时运行的是一个win操作系统。README.TXT文件内容如下,预留邮箱为:tianrui@mailum.com。有客户的vm虚拟化平台被勒索病毒加密,扩展名为:.tianrui。查看对应分区中数据情况。
2025-03-20 23:35:15
227
原创 ora-600 ktugct: corruption detected---惜分飞
基于上述信息基本上可以确认是由于我们修复的undo文件和seq$中的file#=1 block#=1161不匹配导致该问题,对其进行处理之后,数据库open成功。脚本检测之后,发现undo文件offline之后,做了resetlogs操作,导致该文件目前处于WRONG RESETLOGS状态。对于该错误,可以通过rectl进行解决,但是由于undo文件的resetlog 信息不对,无法直接重建ctl,这种情况下,通过。所幸客户需要的数据直接在cdb中,直接使用expdp导出客户需要的数据,完成本次恢复。
2025-03-18 22:30:53
1017
原创 .[OnlyBuy@cyberfear.com].REVRAC勒索mysql恢复---惜分飞
当然前提需要有表创建语句,这个客户有昨天的备份的被的.sql备份,通过技术手段分析,确认只有3个表的创建语句丢失,对于丢失的ddl语句,通过直接对ibdata文件解析获取,基于这些信息结合,实现数据的完美恢复。对于类似这种被加密的勒索的数据文件,我们可以实现比较好的恢复效果,如果此类的数据库(oracle,mysql,sql server)等被加密,可以联系专业恢复技术支持。8.对不熟悉的软件，如果已经被杀毒软件拦截查杀，不要添加信任继续运行。9.保存良好的备份习惯，尽量做到每日备份，异地备份。
2025-03-18 22:28:38
439
转载 ora-600 ktugct: corruption detected--故障处理---惜分飞
ORA-00600: 内部错误代码, 参数: [ktugct: corruption detected], [], [], [], [], [], [], [], [], [], [], []ORA-00600: 内部错误代码, 参数: [ktugct: corruption detected], [], [], [], [], [], [], [], [], [], [], []所幸客户需要的数据直接在cdb中,直接使用expdp导出客户需要的数据,完成本次恢复。进一步分析trace信息。
2025-03-12 21:45:02
68
转载 aix磁盘损坏oracle数据库恢复---惜分飞
客户aix环境硬盘异常导致系统无法启动,初步判断是数据文件存放在本地磁盘的空间中(本地两个盘都异常,系统无法启动),通过硬件恢复厂商镜像出来,但是通过aix文件系统直接挂载提示需要fsck,但是做fsck之后,提示大量文件丢失(最关键的数据文件和备份文件都被自动删除)基于这种情况,采用镜像主机挂载的方式肯定不行,考虑直接采用软件直接解析,能够看到软件,可惜由于大量的文件系统元数据损坏,解析出来的数据文件和dmp也不可用(大量损坏和空块)对于数据库级别恢复,这个是理论上的终极恢复方法。
2025-03-08 22:38:48
34
转载 pg误删除数据恢复（PostgreSQL delete数据恢复）---惜分飞
应用维护人员通过应用程序误删除了一些数据,希望对其进行恢复.通过咨询确认是PostgreSQL数据,wal和arch文件都在,取客户删除数据时间点相关wal文件。如果此类的数据库(oracle,mysql,sql server,PostgreSQL)等恢复请求,需要专业恢复技术支持。通过工具解析wal日志,比较顺利的获取到了undo sql语句。然后把这些sql语句反向插入到生产库,完成这些误操作数据的恢复。然后让客户提供具体涉及误删除的相关的库和表信息。
2025-03-08 22:37:56
194
转载 linux rm -rf 删除数据文件恢复---惜分飞
在这个恢复过程中,由于客户linux是物理机,而且本地空间不足,无法对其进行镜像,采用dd命令直接写镜像到其他的linux机器上（通过nfs方式),然后在win机器上直接挂载该nfs,记录下win上挂载nfs操作。有客户由于误操作删除了oracle的部分数据文件(rm -rf 方式删除),然后自己尝试进行恢复操作,对部分文件执行了offline,导致比较麻烦的后果。
2025-03-08 22:36:14
55
转载 断电引起的ORA-08102: 未找到索引关键字, 对象号 39故障处理---惜分飞
最近有客户在虚拟化平台运行oracle,由于机房掉电,导致oracle数据库无法正常启动,通过第三方恢复,oracle被强制拉起,但是无法进行ddl操作,比如创建表报ORA-08102: 未找到索引关键字, 对象号 39, 文件 1, 块 122448 (2) 错误。处理完上述两个明显故障之后,然后使用expdp不落地方式把客户数据迁移到新库,完成本次恢复任务。这个问题解决之后,该客户还有另外一个问题需要解决（不然数据库运行一段时间之后就会crash）
2024-12-24 20:12:30
197
转载 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
135
转载 解决oracle数据文件路径有回车故障---惜分飞
最近遇到一个硬件恢复朋友的请求,oracle数据库文件恢复出来了,但是在linux上面启动的时候,有两个文件无法检测到,dbv检测正常.2.操作系统层面查看文件（在我的ssh工具中,可以看到带回车键文件和不带回车文件不一样,使用的是crt工具,其他工具是否显示不确定）3. 数据库层面重启看文件情况,发现文件不能被正常发现(当然不能,文件被os层面mv了)进一步检查发现原库这两个文件结尾带有回车,但是恢复出来的文件不带回车。4. 解决控制文件和数据文件实际名称不一致问题。通过分析是由于文件无法找到原因导致。
2024-12-14 08:50:21
58
原创 .wstop扩展名勒索数据库恢复---惜分飞
通过定期的网络安全培训和教育，向用户传达有关勒索病毒及其传播方式的知识，让他们能够警惕潜在的威胁，并学会如何正确应对可疑的电子邮件、链接和附件。5. 访问控制：实施严格的访问控制措施，限制用户对系统和文件的访问权限，避免使用管理员权限进行日常操作，以减少恶意软件感染的风险。此外，定期进行系统维护和检查，确保系统的安全配置和设置。6. 应急响应计划：制定和实施应急响应计划，明确团队成员的责任和任务，建立应对勒索病毒和其他安全事件的应急响应流程，以最大程度地减少损失并快速恢复业务正常运营。
2024-12-08 10:11:41
2095
4
原创 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
482
原创 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
491
原创 删除asmlib磁盘导致磁盘组故障恢复---惜分飞
有客户执行drop disk磁盘组操作之后,然后立刻从oracle asmlib层面执行了oracleasm deletedisk,并且在操作系统层面delete partition(删除磁盘分区),导致磁盘组直接dismount。通过重新分区,并且kfed repair修复磁盘头操作之后,重新mount磁盘组报错。1. 直接恢复出来该磁盘组数据然后打开该库。2. 直接提取客户需要的核心表数据。
2024-12-06 20:47:03
326
原创 ntfs MFT损坏(ntfs文件系统故障)导致oracle异常恢复---惜分飞
通过对该文件底层block分析,确认最终丢失block就是最后20M(直接的数据文件的block的rdba均正确),对于这种故障,通过填补数据文件尾部,欺骗数据库完成该文件的恢复(最后20M中如果写入了业务数据,可能会丢失),做好该文件修复工作之后,尝试打开数据库,结果很不乐观,redo也损坏。客户虚拟化环境,由于断电,启动数据库报ORA-01157错误,通过操作系统层面查看,发现文件是存在的,但是dbv检测报不可访问。感觉是文件系统损坏了,尝试把该文件拷贝到其他磁盘。屏蔽一致性,强制打开库成功。
2024-10-19 22:03:30
592
原创 清空redo导致oracle故障恢复---惜分飞
这种情况下,所有redo全部被清空(包含current,active的redo),只能强制拉库,运气不错,拉库成功.客户由于空间不足,使用> redo命令清空了oracle的redo文件。数据库挂掉之后,启动报错。
2024-10-16 22:23:32
590
原创 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
734
原创 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
1322
原创 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
1624
原创 ORA-600 16703故障再现---惜分飞
由于此类故障出现较多,破坏性加大,对其进行了深入的研究,在没有破坏现场的情况下,通过对tab$进行直接重建,实现数据库完美恢复(数据0丢失,数据库无需逻辑迁移[原库直接可用])尽可能不要从互联网下载Oracle安装介质和Patch,避免被注入恶意脚本,并检查已经存在的安装介质的sha256码。)至今已经7年多时间了,最近依旧有客户中招。从第一次发现ORA-600 16703(
2024-09-16 09:41:50
600
原创 .[metro777@cock.li].Elbie勒索病毒加密数据库恢复---惜分飞
通过定期的网络安全培训和教育，向用户传达有关勒索病毒及其传播方式的知识，让他们能够警惕潜在的威胁，并学会如何正确应对可疑的电子邮件、链接和附件。5. 访问控制：实施严格的访问控制措施，限制用户对系统和文件的访问权限，避免使用管理员权限进行日常操作，以减少恶意软件感染的风险。此外，定期进行系统维护和检查，确保系统的安全配置和设置。6. 应急响应计划：制定和实施应急响应计划，明确团队成员的责任和任务，建立应对勒索病毒和其他安全事件的应急响应流程，以最大程度地减少损失并快速恢复业务正常运营。
2024-09-13 20:59:52
414
原创 应用连接错误,初始化mysql数据库恢复---惜分飞
登录操作系统查看,发现数据库文件在根分区,创建了新库,写入了数据之外,还有几个G的binlog.全部恢复不太可能,最后客户决定需要恢复的2个核心表数据,估计也就几十M的数据.通过os层面进行分析,发现操作系统的反删除恢复无法实现这类数据恢复.最后决定从mysql innodb的的碎片级别记性扫描恢复,通过扫描发现较多碎片。有人在部署一个新网站的时候,写错了配置信息,直接导致原有数据库被清掉,并创建了新库和写入了数据(其实本质就是drop table恢复)
2024-09-10 20:24:13
488
原创 drop tablespace xxx including contents恢复---惜分飞
所以这个恢复相对比较简单,直接使用dul之类工具扫描数据文件获取到实际数据.结合客户导出的元数据和通过一些途径恢复出来的dataobj#信息,进行整合,实现数据接近完美恢复,可以业务直接启动成功,其中几个大表的lbo字段数据恢复情况。客户在咨询我的同时,也咨询了其他人,有人给客户答复是可以通过修改字典(以为有导出的元数据就可以逆向想改文件回去),然后把数据文件拷贝过去,实现恢复,成功概率65%[只能说是真牛]4)数据文件复制到新库,完全不是同一个库的,要大量修改文件头信息,我估计他们在这一步都不能成功。
2024-09-05 13:24:31
561
原创 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
780
原创 redo写丢失导致ORA-600 kcrf_resilver_log_1故障---惜分飞
有一个客户硬件故障,做完硬件恢复之后,数据库启动报ORA-600 kcrf_resilver_log_1错误.查询mos出现该问题的原因一般是由于redo log write lost导致。
2024-08-26 12:27:18
275
原创 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
720
原创 200T 数据库非归档无备份恢复---惜分飞
一套近200T的,6个节点的RAC,由于存储管线链路不稳定,导致服务器经常性掉盘,引起asm 磁盘组频繁dismount/mount,数据库集群节点不停的重启,修复好链路问题之后,数据库启动报ORA-01113,ORA-01110。由于数据库是非归档模式,该库无法通过应用归档日志来实现对这些文件进行恢复,对于这种情况,直接使用dbms_diskgroup把数据文件头拷贝到文件系统中,类似操作。通过上述操作,确认bbed修改文件头成功,后续类似方法对其他9个文件进行修改,并打开数据库。
2024-08-15 21:18:30
999
原创 [comingback2022@cock.li].eking和[tsai.shen@mailfence.com].faust扩展名勒索病毒数据库可以完美恢复---惜分飞
最近接到两个由于操作系统文件被加密,其中的Oracle数据库文件被勒索病毒加密恢复的请求,通过底层分析,确认这两种勒索病毒加密的数据库能够非常好的恢复（可以通过修复,直接open库,然后导出数据,业务直接使用）通过定期的网络安全培训和教育，向用户传达有关勒索病毒及其传播方式的知识，让他们能够警惕潜在的威胁，并学会如何正确应对可疑的电子邮件、链接和附件。5. 访问控制：实施严格的访问控制措施，限制用户对系统和文件的访问权限，避免使用管理员权限进行日常操作，以减少恶意软件感染的风险。
2024-08-08 11:47:20
557
原创 断电引起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
858
原创 存储宕机导致Oracle异常故障处理---惜分飞
操作到这里,后续问题就比较麻烦了,因为在asm磁盘组中数据文件重建ctl的时候遗漏3个并且还被resetlogs操作过,导致这三个文件的resetlogs scn和其他数据文件不一致,对于这个问题,解决办法通过。客户尝试重建ctl进行恢复,结果由于分析不正确,导致在重建ctl的时候,遗漏了3个数据文件,并且在屏蔽一致性的情况下,强制resetlogs操作,结果数据库没有被正常打开,而是报ORA-600 2662错误。工具或者bbed修改相关resetlogs scn,然后重建ctl。
2024-07-28 22:37:11
669
Oracle Recovery Tools-最新版（202501）
2023-04-10
oracle scn修改利器-Patch SCN最新版-202501
2024-07-05
12c – 使用跨平台增量备份来减少传输表空间的停机时间 (Doc ID 2102859.1).pdf
2020-08-15
Patch-SCN 小工具使用说明
2024-07-05
修改oracle scn小工具(patch scn)
2022-06-18
Oracle Recovery Tools-202208版本
2021-10-19
Oracle Recovery Tools-202207版
2022-06-26
ORA-702_Recovery使用说明
2022-07-21
oracle patch scn--修改oracle scn工具（oracle异常恢复利器）
2022-06-18
silverlight访问数据库汇总
2009-08-19
html+ashx论坛
2009-06-29
rman_xttconvert_VER4.3.zip.7z
2020-08-15
Oracle Recovery Tools 使用说明
2021-10-06
基于odp.net的oraclehelper
2010-04-16
ufsxpci64.zip
2020-03-08
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人