- 博客(190)
- 资源 (21)
- 收藏
- 关注
RSS订阅原创 ORA-39246: 无法在提供的转储文件中定位主表--惜分飞
分析当时当初的dmp日志,由于expdp的job表所在表空间不足导致expdp导出失败。)把所有表数据出来,经过这两者组合,顺利完成数恢复,可以测试业务完全正常。通过这个dmp导入业务字典信息,然后再利用expdp dmp解析工具(
2025-12-03 23:47:14
226
原创 mysql drop database 无有效备份恢复思路--惜分飞
今天有一个客户在在虚拟机环境中使用drop database删除一个业务mysql的库,删除之后,第一时间关闭了该虚拟机系统.接到该case请求之后,让客户提供了虚拟机文件(vmdk),通过工具分析,mysql数据库是放在/分区下面的/data里面(lvm结构，xfs文件系统),但是已经看不到他们删除的数据库(mysql一个库对应一个目录)对于这种情况,我们第一步尝试文件系统层面反删除恢复(对数据库所在分区进行文件系统层面扫描,尝试恢复被删除的mysql表文件),运气不错,找到了一些被删除库的ibd文件。
2025-12-01 18:54:39
184
原创 obet(Oracle Block Editor Tool)第二版发布
1) repair [block x] 命令对于坏块的自动修复,主要包括checksum,tailchk,seq_kcbh等。2）增加copy chkscn 命令主要用于对文件头的checkpoint scn相关信息修复。3）增加copy resetlogscn命令主要用于对文件头的resetlogs相关信息修复。随便把一个block拷贝到文件的另外位置,也可以拷贝到不同文件的其他位置,根据需要调整。5）增加copy block命令主要用于数据文件之间的数据块直接拷贝。
2025-11-16 21:28:20
658
原创 OBET工具使用说明
OBET(Oracle Block Editor Tool)是惜分飞()开发的使用于Oracle数据块查看和编辑小工具主要功能16进制格式查看Oracle数据块(可以指定block/offset，不受4G大小限制)16进制格式编辑Oracle数据块(可以指定block/offset，不受4G大小限制)标记数据块为坏块功能自动修复tailchk自动修复checksum。
2025-11-12 22:30:20
574
原创 Oracle数据块编辑工具( Oracle Block Editor Tool)-obet
由于oracle后续版本对于bbed的支持不是太友好(从10g之后无法直接编译使用,win版本偏移量错误等),基于这些情况,结合当前ai的便利,自己动手写了一个基础版的obet(Oracle Block Editor Tool)【由于该工具直接编辑Oracle 底层数据块操作具有一定的破坏性和风险性,所以在没有授权的情况下无法对数据块进行修改(只能查看),具体授权操作。一般情况下文件之间的拷贝就是数据号不一样,比如修改checkpoint,resetlog信息等,这里支持不一样偏移量,不一样数据块的拷贝。
2025-11-10 20:09:09
870
原创 C_OBJ#_INTCOL#坏块导致数据库无法open故障处理---惜分飞
摘要：客户在恢复非归档模式Oracle数据库时遇到问题，检测发现文件3需要已覆盖的3200号日志。通过自研工具修改SCN后，仍因system01.dbf文件中的坏块（C_OBJ#_INTCOL#集群对象）导致数据库无法启动。最终采用跳过损坏对象方式打开数据库，重建histgrm$表数据后完成恢复。整个过程涉及日志序列不匹配、非归档模式限制、数据文件坏块处理等典型恢复场景。（149字）
2025-10-25 15:58:56
865
原创 ORA-600 kkkicreatecgmap:!efn3---惜分飞
摘要： 数据库在RAID故障恢复后出现ORA-03113通信错误，伴随ORA-600[kkkicreatecgmap:!efn3]内部错误。检查发现redo日志损坏（ORA-00353/ORA-00354）和undo异常，处理后成功打开数据库。该罕见错误可能与硬件故障导致的数据文件损坏有关，最终通过重建undo表空间完成数据恢复。MOS文档Bug 28167557显示类似错误可能与关键对象检查失败相关，但因硬件问题导致非常规错误，分析重点应放在快速恢复而非根因排查。（149字）
2025-10-24 12:09:32
229
原创 raid恢复之后数据库故障处理(ora-01200,ORA-26101,ORA-600)---惜分飞
文章摘要：客户在RAID恢复后遭遇Oracle数据库启动异常，先后出现ORA-01200（文件大小不符）、ORA-26101（控制文件与数据文件头不一致）和ORA-600系列错误。技术人员通过bbed工具修复文件大小、重建控制文件、处理坏块（如block 675和3339）等操作，最终成功打开数据库并恢复业务数据。整个恢复过程涉及控制文件损坏验证、日志应用失败处理、强制开库尝试等复杂操作，最终在非归档模式下实现了最大限度的数据恢复。
2025-10-23 22:18:27
837
原创 ORA-600 kokasgi1故障处理(sys被重命名)---惜分飞
摘要：客户数据库因ORA-600[kokasgi1]错误无法启动，该错误通常与SYS用户检查有关。通过启动到mount状态后，手动更新user$表将USER#=0的用户名改为'SYS'，提交变更并执行检查点后重启数据库。最终成功恢复数据库，实现零数据丢失和业务快速恢复。此案例验证了该故障的标准处理方法，在Oracle 11.2.0.4环境下有效。
2025-10-21 20:13:06
338
原创 Patch_SCN for Linux 功能完善---惜分飞
软件支持自动发现内存地址和手工输入内存地址两种模式(当某些情况无法软件自动发现地址时,可以考虑人工输入地址方式进行)3. 无需输入内存地址,程序一般情况下可以直接获取地址并修改。授权成功之后,后续使用软件无需注册。1. 整个代码全部通过C代码实现。第一次使用要求输入注册码。2. 完善了注册机制。确保执行用户有x权限。
2025-10-14 15:00:58
178
原创 system表空间丢失部分文件恢复---惜分飞
摘要： Oracle数据库因system表空间数据文件丢失导致启动失败，报错ORA-01157/01147。通过m_scn工具修复丢失的11号数据文件后，发现该文件仅包含少量非核心对象。尝试expdp导出数据时出现ORA-00600错误，分析发现是由于master表写入损坏的system表空间导致。最终通过修改expdp配置使master表不存储在system表空间，成功完成数据导出和恢复。此次恢复展示了system表空间文件损坏时的特殊处理方法和expdp故障的排查思路。
2025-10-10 20:54:36
573
原创 arm环境vg损坏mysql数据库恢复---惜分飞
摘要：国庆期间处理了一起因误操作导致MySQL数据库恢复的案例。原500G的vdb1磁盘被重新分区为1000G，并执行了pvcreate等操作导致原有LVM配置丢失。通过分析history日志发现操作者尝试了多次pvresize、pvcreate和lvextend操作均未成功。最终通过将磁盘挂载到x86环境，使用专业工具成功解析并恢复了磁盘数据，MySQL数据库完整恢复，业务测试正常。整个恢复过程历时一周，最终在10月5日完成数据迁移和验证工作。
2025-10-10 09:20:23
345
原创 docker回收和mysql备份导入导致数据丢失恢复---惜分飞
MySQL误删数据恢复方案：针对docker删除、备份导入覆盖等场景，需立即停止写入并保护现场。通过分区快照、反删除工具恢复ibd/frm文件，结合DISCARD/IMPORT TABLESPACE或碎片扫描解析技术，可有效恢复drop/truncate/rm等操作丢失的数据。专业团队可提供完整数据抢救支持。
2025-09-17 14:23:46
240
原创 服务器断电引起的一例ORA-01207故障处理----惜分飞
摘要：客户服务器异常断电导致Oracle数据库启动失败，出现ORA-01207错误，显示数据文件比控制文件新。经检查发现底层NTFS文件系统损坏，多个磁盘存在异常。在成功备份数据后，尝试强制打开数据库时遭遇ORA-6004194错误。解决undo异常后数据库成功打开，但后续导出数据时又出现ORA-6002662/2663错误，表明数据块存在SCN不一致问题。最终通过Patch SCN工具修正Oracle SCN解决了该问题。整个案例体现了非归档模式下数据库异常断电恢复的复杂性。
2025-09-07 10:33:14
315
原创 存储掉电强制拉库引起ORA-01555和ORA-01189/ORA-01190故障处理---惜分飞
摘要：Oracle数据库因机房断电导致存储异常，出现大量I/O错误和实例崩溃。恢复后尝试open数据库报ORA-00333错误（redo日志丢失），使用隐含参数恢复时又出现ORA-00704和ORA-01555错误，导致恢复失败。最终通过Oracle Recovery Tools工具检测发现WRONG RESETLOGS异常，重建控制文件并修改SCN信息后成功打开数据库。建议客户后续进行逻辑迁移以避免类似问题。
2025-09-01 22:24:15
807
原创 ORA-600 kcratr_nab_less_than_odr和ORA-600 2662故障处理---惜分飞
摘要：Oracle数据库在异常断电后启动时遭遇ORA-600 kcratr_nab_less_than_odr错误，尝试通过重建控制文件和使用备份控制文件恢复未果，随后出现ORA-600 2662错误。最终采用Patch_SCN工具修改SCN值后成功打开数据库，但发现临时表空间TEMP缺少数据文件。经过添加tempfile并完成数据导出后，最终实现数据库恢复。整个恢复过程涉及多个内部错误处理，包括介质恢复、崩溃恢复等操作，耗时约30分钟完成。
2025-08-21 09:36:22
411
原创 win环境断电强制拉库报ORA-600 kcbzib_kcrsds_1故障处理---惜分飞
摘要：客户环境异常断电导致Oracle 19c数据库无法启动，执行恢复时提示缺少归档日志(ORA-00279/289/280错误)。由于是非归档模式且缺失关键日志(15080)，只能先恢复部分数据文件后尝试强制打开数据库。在执行alter database open resetlogs时出现ORA-600 kcbzib_kcrsds_1内部错误。最终使用自研的Patch_SCN工具修复SCN问题，成功完成介质恢复并打开数据库，随后安排数据导出完成恢复任务。该案例展示了非归档环境断电后数据库恢复的典型挑战及解
2025-08-18 22:24:05
367
原创 RAC环境redo在各节点本地导致数据库故障恢复---惜分飞
摘要：某Windows平台RAC集群因断电故障导致两节点无法启动，出现ORA-600kclchkblk_4错误。分析发现节点间redo日志序列号不一致（节点1线程2的group11需要147717但实际147541，节点2线程1的group1需要67782但实际60818）。客户错误使用_allow_resetlogs_corruption强制恢复失败。经介入处理，通过PatchSCN工具解决SCN问题，成功打开数据库后遇到ORA-600 4137/6006错误，最终通过重建undo表空间使数据库恢复稳定运
2025-08-17 23:31:35
905
原创 ORA-600 kcratr_nab_less_than_odr和ORA-600 4194故障处理---惜分飞
摘要：Oracle 11.2.0.1数据库因断电导致ORA-600 kcratr_nab_less_than_odr错误，恢复过程中出现异常。在尝试打开数据库时遭遇ORA-600 4194错误，后发现undo表空间损坏。通过创建新的undo表空间(undotbs2)并删除原表空间(UNDOTBS1)解决问题。但随后出现大量ORA-600 kdsgrp1错误，经分析为索引与表记录不匹配所致，最终通过重建索引完成修复。整个过程涉及断电恢复、undo表空间重建和索引修复等关键操作。
2025-08-09 13:45:03
487
原创 由于空间满导致PostgreSQL数据库异常处理---惜分飞
PostgreSQL数据库因磁盘空间不足导致表文件损坏。最初报错显示磁盘空间不足，清理空间后出现权限拒绝和文件写入错误。通过查询系统表确认损坏表为xifenfei01_log日志表。由于是日志表，直接清理后恢复正常。若损坏的是业务表，建议使用pdu工具进行恢复。该案例提醒需定期检查磁盘空间，避免因空间不足导致数据损坏。
2025-08-09 13:42:31
359
原创 文件系统格式化MySQL数据库恢复---惜分飞
有客户在做迁移的时候,不慎把存放mysql数据库的硬盘进行了重新分区格式化,重新初始化mysql,并且导入了部分历史数据,不能满足客户需求,希望我们帮忙进行数据恢复.里面大概有100套左右mysql数据库,每个库里面表结构相同,数据不一样.接手这个故障,第一操作就是对磁盘进行镜像,然后使用恢复工具进行底层分析,尝试从文件系统层面恢复出来被格式化之前的数据库文件(需要有对应库目录,不然也没有意义,因为每个库里面表结构一样的,没有正确的库名字无法做到有效的区分),通过底层扫描分析,没有发现一个有效数据文件。
2025-07-27 23:17:16
394
原创 一次非常幸运的ORA-600 16703(tab$被清空)故障恢复---惜分飞
摘要：一套运行5年多的Oracle RAC集群因异常导致节点2重启，触发了tab$表被清空，节点1出现大量ORA-600错误。分析发现节点2首次重启后数据库开始报错，第二次重启时出现ORA-60016703错误，确认是tab$表被恶意脚本清空所致。由于节点1保持open状态，恢复工作较为简单：从备份表中恢复tab$数据，清理恶意脚本后重启两个节点。这次成功恢复的关键在于故障发生后及时保留现场，未重启仍运行的节点1，为数据恢复创造了有利条件。该案例展示了在数据库故障中保持冷静判断的重要性。
2025-07-27 23:14:36
743
原创 恢复 Oracle 8.0.5 ---惜分飞
对于这种错误,可以按照行的方式使用plsql进行逐行抽取,但是由于涉及的表比较多,比较麻烦,我这里直接使用dul对其进行抽取异常表。报ORA-01200错误,比较明显29号文件本身大小应该是2048000个block,但是现在只有974848个。把数据文件发给了我,准备win xp环境的虚拟机并安装8.0.5的库(安装版本要和数据库文件版本一致)然后把导出来的dmp,结合dul恢复出来的异常表数据,整合到一起,完成本次8.0.5的数据库恢复。由于29号文件部分丢失,导出数据遭遇ORA-08103错误。
2025-07-13 12:07:10
532
原创 ORA-600 kokiasg1故障分析---惜分飞
客户正常关闭数据库,然后启动报ORA-600 kokiasg1错误,通过对启动分析确认是由于IDGEN1$序列丢失导致,修复该故障之后,数据库启动成功,但是后台大量报ORA-600 12803,ORA-600 15264等错误,业务用户无法登录.经过深入分析,发现数据库字典obj$中所有核心字典的序列全部被删除,但是在seq$中这些对象的obj#记录还存在.初步怀疑是有人恶意删除了obj$中字典核心序列对象导致.
2025-07-08 22:59:01
648
原创 Oracle数据库文件变成32k故障恢复--惜分飞
这里有一个问题,由于磁盘空间不足,导致部分备份不成功,但是系统级别删除操作依旧正常进行,导致以前有效的备份被删除,后面的备份又没有成功（这个是本次该文件无法还原的主要原因）,慎重提醒,rman备份尽量使用rman本身的策略来管理不要使用系统命令来维护备份策略,基于这样的情况,可以使用反删除命令找出来了一些该文件的备份集,并注册到控制文件中。基于当前情况,可以确认该文件异常,而且没有有效的rman备份.通过分析备份脚本,发现每个备份集1个数据文件,而且没有压缩，并按照10g进行分割为多个文件。
2025-06-27 23:35:15
502
原创 文件系统格式化MySQL数据库恢复---惜分飞
有客户在做迁移的时候,不慎把存放mysql数据库的硬盘进行了重新分区格式化,重新初始化mysql,并且导入了部分历史数据,不能满足客户需求,希望我们帮忙进行数据恢复.里面大概有100套左右mysql数据库,每个库里面表结构相同,数据不一样.接手这个故障,第一操作就是对磁盘进行镜像,然后使用恢复工具进行底层分析,尝试从文件系统层面恢复出来被格式化之前的数据库文件(需要有对应库目录,不然也没有意义,因为每个库里面表结构一样的,没有正确的库名字无法做到有效的区分),通过底层扫描分析,没有发现一个有效数据文件。
2025-06-19 22:28:36
307
原创 一次硬件恢复之后数据文件0kb的故障恢复---惜分飞
导出需要的业务用户字典信息,然后把客户那边提供的users01.dbf文件(users02.dbf是客户在21年之后增加的,原则上客户要的数据都在users01.dbf中)中的数据恢复到导出的字典中,完成本次数据恢复,客户远程验证业务,运行正常,客户需要的配置信息都在其中.基于这种情况,我这边在客户恢复的整个目录文件中,再三查找,发现了一个类似rman备份的文件(是21年的),对其进行还原尝试。客户一个比较久远系统,由于长期没有人维护,导致硬件故障,客户找人进行了硬件恢复之后,发现大量数据文件为0kb。
2025-06-16 23:10:14
865
原创 .sstop勒索加密数据库恢复---惜分飞
数据库文件被加密,扩展名类似:.[[dataserver@airmail.cc]].sstop,通过工具进行坏块检测确认破坏数据文件三段,每段8个block。根据经验可以确认,数据文件前面8个block肯定没有业务数据(主要是文件头信息和位图信息),可以使用Oracle数据文件勒索加密恢复工具对其文件头进行构造。8.对不熟悉的软件，如果已经被杀毒软件拦截查杀，不要添加信任继续运行。9.保存良好的备份习惯，尽量做到每日备份，异地备份。4.定期检测系统和软件中的安全漏洞，及时打上补丁。
2025-06-16 23:08:10
355
原创 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
435
原创 记录一次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
482
原创 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
843
原创 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
536
原创 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
403
原创 虚拟化加密恢复---惜分飞
通过底层分析,确认vmdk文件可以通过找出来分区信息,确认当时运行的是一个win操作系统。README.TXT文件内容如下,预留邮箱为:tianrui@mailum.com。有客户的vm虚拟化平台被勒索病毒加密,扩展名为:.tianrui。查看对应分区中数据情况。
2025-03-20 23:35:15
253
原创 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
1059
原创 .[OnlyBuy@cyberfear.com].REVRAC勒索mysql恢复---惜分飞
当然前提需要有表创建语句,这个客户有昨天的备份的被的.sql备份,通过技术手段分析,确认只有3个表的创建语句丢失,对于丢失的ddl语句,通过直接对ibdata文件解析获取,基于这些信息结合,实现数据的完美恢复。对于类似这种被加密的勒索的数据文件,我们可以实现比较好的恢复效果,如果此类的数据库(oracle,mysql,sql server)等被加密,可以联系专业恢复技术支持。8.对不熟悉的软件，如果已经被杀毒软件拦截查杀，不要添加信任继续运行。9.保存良好的备份习惯，尽量做到每日备份，异地备份。
2025-03-18 22:28:38
614
转载 ora-600 ktugct: corruption detected--故障处理---惜分飞
ORA-00600: 内部错误代码, 参数: [ktugct: corruption detected], [], [], [], [], [], [], [], [], [], [], []ORA-00600: 内部错误代码, 参数: [ktugct: corruption detected], [], [], [], [], [], [], [], [], [], [], []所幸客户需要的数据直接在cdb中,直接使用expdp导出客户需要的数据,完成本次恢复。进一步分析trace信息。
2025-03-12 21:45:02
125
转载 aix磁盘损坏oracle数据库恢复---惜分飞
客户aix环境硬盘异常导致系统无法启动,初步判断是数据文件存放在本地磁盘的空间中(本地两个盘都异常,系统无法启动),通过硬件恢复厂商镜像出来,但是通过aix文件系统直接挂载提示需要fsck,但是做fsck之后,提示大量文件丢失(最关键的数据文件和备份文件都被自动删除)基于这种情况,采用镜像主机挂载的方式肯定不行,考虑直接采用软件直接解析,能够看到软件,可惜由于大量的文件系统元数据损坏,解析出来的数据文件和dmp也不可用(大量损坏和空块)对于数据库级别恢复,这个是理论上的终极恢复方法。
2025-03-08 22:38:48
72
转载 pg误删除数据恢复（PostgreSQL delete数据恢复）---惜分飞
应用维护人员通过应用程序误删除了一些数据,希望对其进行恢复.通过咨询确认是PostgreSQL数据,wal和arch文件都在,取客户删除数据时间点相关wal文件。如果此类的数据库(oracle,mysql,sql server,PostgreSQL)等恢复请求,需要专业恢复技术支持。通过工具解析wal日志,比较顺利的获取到了undo sql语句。然后把这些sql语句反向插入到生产库,完成这些误操作数据的恢复。然后让客户提供具体涉及误删除的相关的库和表信息。
2025-03-08 22:37:56
301
12c – 使用跨平台增量备份来减少传输表空间的停机时间 (Doc ID 2102859.1).pdf
2020-08-15
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
OBET-2025.11.02版本下载
2025-11-16
【数据库维护】基于十六进制编辑的Oracle数据块修复工具：OBET在坏块处理与文件头结构恢复中的应用
2025-11-16
OBET(Oracle Block Editor Tool)
2025-11-12
Patch SCN使用说明(for 202511)
2025-11-02
oracle scn修改利器-Patch SCN最新版-202510
2025-10-13
Oracle Recovery Tools-202511版本
2025-10-31
Oracle Recovery Tools-最新版（202501）
2023-04-10
oracle scn修改利器-Patch SCN最新版-202501
2024-07-05
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
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人