- 博客(204)
- 资源 (21)
- 收藏
- 关注
RSS订阅原创 obet处理ORA-704 ORA-604 ORA-1578故障
由于该库在我接手之前已经做了大量的强制拉库等各种恢复尝试,因此对该库做逻辑导出,导入新库完成本次恢复任务。对system文件进行dbv检测(客户通过asmcmd cp命令拷贝出来system文件)有客户数据库启动报ORA-704 ORA-604 ORA-1578错误,导致启动失败。,使用工具修复操作(其他block类似修改)然后dbv检查数据文件。然后直接顺利打开数据库。
2026-02-10 09:49:52
308
原创 csc higher than block scn类型坏块修复---obet
对于这样的故障,最近把他整合到了obet工具中,执行命令为repair blkscn [block x]进行修复。最近有客户数据库报ORA-01092 ORA-01578错误导致数据库无法open。通过dbv检查确认是csc higher than block scn故障。使用obet修复csc higher than block scn 故障。dbv验证该错误已经修复。
2026-02-08 22:41:37
322
原创 ORA-600 kcratr_nab_less_than_odr和ORA-600 4193故障处理--惜分飞
这个错误相对比较简单,由于undo回滚段异常,处理掉异常undo之后,数据库正常,完成本次恢复任务。这个客户是11.2.0.4的库(在这个版本中该错误相对较少,虽然也遇到过几次)数据库启动报ORA-600 kcratr_nab_less_than_odr。这个错误一般常见的是11.2.0.1的数据库异常关机了容易遇到。分析日志发现是由于之前io比较慢导致写入异常导致。但是后续数据库出现ORA-600 4193错误。处理这个错误相对比较简单,重建控制文件即可。
2026-02-06 23:06:51
65
原创 aix环境10g由于控制器异常导致ORA-600 4000故障处理---惜分飞
2. 报错sql为：select rowcnt,blkcnt,empcnt,avgspc,chncnt,avgrln,nvl(degree,1), nvl(instances,1) from tab$ where obj# = :1。得出报错的ORA-600 2662的block就是我们之前分析和修复的itl块,通过修改该块scn或者修改数据库scn,该库均可open,后续就是安排导出数据导入新库的活。2. itl操上面有一个锁需要提交,通过bbed工具对其进行提交,然后得出dump block信息。
2026-02-02 08:43:31
586
原创 不当恢复truncate数据导致数据库不能open处理---惜分飞
有客户误truncate操作干掉了数据库中的几张表,然后尝试通过FY_Recover_Data进行恢复,恢复到一半然后终止了,数据库结果就起不来了(具体什么原因不知道,肯定是各种不合适的操作引起的故障),我接手故障的时候,数据库被强制resetlogs,报ORA-600 2662错误。该报错比较明显是由于undo回滚段异常导致,通过屏蔽回滚段,open库成功.后续对客户truncate的表进行分析,比较悲催由于没有第一时间保护现场而且对所在表空间进行了大量写入操作,导致truncate数据恢复较少.
2026-02-01 08:15:08
310
原创 在生产环境错误执行dd命令破坏asm磁盘故障恢复---惜分飞
摘要：某客户误操作将ASM磁盘13通过dd命令部分覆盖到磁盘11和26上，导致分别损失2G和1G数据。通过分析udev绑定关系和ASM日志确认受损情况。由于破坏数据量较小且非初始写入，恢复可能性较大。技术团队先修复损坏磁盘头信息，使用AMDU工具提取数据文件，成功打开数据库。虽然部分文件存在不可修复的坏块（位于被覆盖区域），但整体恢复效果较好，SYSTEM表空间完好，数据库可直接打开。相比以往类似案例，本次恢复难度较低，未使用ASM磁盘块级扫描即完成主要恢复工作。
2026-01-17 08:00:33
323
原创 Patch_SCN快速解决ORA-600 2663故障
摘要：某测试库因删除active状态的redo日志文件导致无法启动，同时磁盘空间已满。经检查发现，丢失了部分关键redo日志，直接恢复无望。先清理日志释放3G空间后，尝试强制恢复但遇到ORA-6002663错误。最终使用Patch_SCN工具成功修复SCN问题，完成数据库恢复并正常打开。整个过程涉及磁盘空间管理、redo日志恢复和SCN修复等关键操作。
2026-01-17 07:55:52
320
原创 obet 实现dbv功能（obet数据文件坏块检测）
摘要：Oracle数据块编辑工具obet发布了第二版，新增dbv(数据块校验)功能，解决了Oracle原厂dbv工具的多项不足。obet-dbv支持批量检查数据文件、显示检查进度，并能处理文件头损坏等异常情况。使用流程包括配置listfile.txt文件、加载文件后执行dbv命令，工具会自动生成详细检测报告，记录坏块数量和类型(如校验和错误、rdba错误等)。相比Oracle原厂工具，obet-dbv具有更强的容错能力和更便捷的操作体验。
2026-01-11 21:16:26
822
原创 obet处理缺少归档日志故障
44号文件状态是12月1日的,而且resetlogs信息也不对.通过和客户沟通,确认是他们在没有备份44号文件的前提下直接执行了类似alter database create datafile 44的命令,但是在应用了写归档之后,发现提示有归档不存在。基于这种情况(故障数据文件直接被覆盖,归档又出现了多天的连续断档,而且没有有效备份),只能先打开数据库,然后根据情况导出数据,然后导入到新库中.这里我直接使用。分析现存归档,确实发现12月1日之后丢失了部分归档日志(归档不连续)然后重建ctl正常打开数据库。
2026-01-09 23:23:03
773
原创 Oracle Recovery Tools 使用说明
（一）软件简介）自主研发的专业 Oracle 数据库恢复工具，专为解决 Oracle 数据库各类数据损坏、SCN 异常等问题设计，提供高效、精准的数据库修复解决方案，助力数据库管理员快速恢复数据库正常运行。（二）核心功能单个 / 批量坏块修复：支持对数据库单个数据块或批量数据块的损坏修复，覆盖不同场景下的坏块处理需求。单个 Block 坏块标记：可手动将指定数据块标记为坏块，便于后续针对性处理。数据块内容操作：支持查看指定数据块的原始内容，同时允许对数据块中的具体数据进行修改。
2025-12-28 18:32:40
715
原创 ORA-600 ktbair2: illegal inheritance---惜分飞
接到客户一个恢复case咨询,数据库open过程报ORA-00600: 内部错误代码, 参数: [ktbair2: illegal inheritance]错误。这个处理起来比较简单,对于异常的undo进行处理之后,数据库正常导出dmp,完成本次恢复任务。然后比较幸运直接open数据库成功,但是报ORA-600 4194错误。这次的故障相对简单一些,通过一些简单尝试之后数据库正常应用成功。
2025-12-22 09:36:18
235
原创 sql server 事务日志备份异常恢复案例---惜分飞
基于这样的情况,数据库层面的正常恢复途径只能恢复到11月17日18时左右数据,因为后面的日志发生了损坏,无法继续正常恢复,对于这种情况,我们这边使用日志解析工具对剩余事务日志备份进行解析,生成.sql文件。客户尝试使用全备进行恢复,结果发现只有13日的全备是好的,可以还原出来数据库,其他备份还原直接报错,基于这样的情况,可以希望把数据恢复到11月19日.我接手这个故障之后,先尝试还原13日的备份。客户每天做全库备份,每4小时做事务日志备份,备份类似这样的情况。然后尝试人工应用事务日志备份,类似命令。
2025-12-12 16:48:53
465
原创 win平台挂起Oracle数据库启动进程
对于oracle的有些故障,如果数据库完全open会报错,导致启动失败,这个时候,我们可以尝试在数据库open到一半的过程中把启动过程挂起,然后登录数据库对字典进行修复,然后就可以正常启动数据库。非win平台可以通过gdb挂起数据库启动过程,因为win系统是进程模式,无法通过gdb挂起来实现,通过自己写程序修改oracle内存来实现这个功能。工具中,点击修改内存—>检索Oracle数据库进程—>选择需要操作的数据库进程—>挂起Oracle进程 就可以实现oracle数据库在open的过程中挂住。
2025-12-09 14:22:23
224
原创 ORA-39246: 无法在提供的转储文件中定位主表--惜分飞
分析当时当初的dmp日志,由于expdp的job表所在表空间不足导致expdp导出失败。)把所有表数据出来,经过这两者组合,顺利完成数恢复,可以测试业务完全正常。通过这个dmp导入业务字典信息,然后再利用expdp dmp解析工具(
2025-12-03 23:47:14
279
原创 mysql drop database 无有效备份恢复思路--惜分飞
今天有一个客户在在虚拟机环境中使用drop database删除一个业务mysql的库,删除之后,第一时间关闭了该虚拟机系统.接到该case请求之后,让客户提供了虚拟机文件(vmdk),通过工具分析,mysql数据库是放在/分区下面的/data里面(lvm结构，xfs文件系统),但是已经看不到他们删除的数据库(mysql一个库对应一个目录)对于这种情况,我们第一步尝试文件系统层面反删除恢复(对数据库所在分区进行文件系统层面扫描,尝试恢复被删除的mysql表文件),运气不错,找到了一些被删除库的ibd文件。
2025-12-01 18:54:39
213
原创 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
694
原创 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
637
原创 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
914
原创 C_OBJ#_INTCOL#坏块导致数据库无法open故障处理---惜分飞
摘要：客户在恢复非归档模式Oracle数据库时遇到问题，检测发现文件3需要已覆盖的3200号日志。通过自研工具修改SCN后，仍因system01.dbf文件中的坏块（C_OBJ#_INTCOL#集群对象）导致数据库无法启动。最终采用跳过损坏对象方式打开数据库，重建histgrm$表数据后完成恢复。整个过程涉及日志序列不匹配、非归档模式限制、数据文件坏块处理等典型恢复场景。（149字）
2025-10-25 15:58:56
898
原创 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
251
原创 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
872
原创 ORA-600 kokasgi1故障处理(sys被重命名)---惜分飞
摘要：客户数据库因ORA-600[kokasgi1]错误无法启动，该错误通常与SYS用户检查有关。通过启动到mount状态后，手动更新user$表将USER#=0的用户名改为'SYS'，提交变更并执行检查点后重启数据库。最终成功恢复数据库，实现零数据丢失和业务快速恢复。此案例验证了该故障的标准处理方法，在Oracle 11.2.0.4环境下有效。
2025-10-21 20:13:06
354
原创 Patch_SCN for Linux 功能完善---惜分飞
软件支持自动发现内存地址和手工输入内存地址两种模式(当某些情况无法软件自动发现地址时,可以考虑人工输入地址方式进行)3. 无需输入内存地址,程序一般情况下可以直接获取地址并修改。授权成功之后,后续使用软件无需注册。1. 整个代码全部通过C代码实现。第一次使用要求输入注册码。2. 完善了注册机制。确保执行用户有x权限。
2025-10-14 15:00:58
197
原创 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
590
原创 arm环境vg损坏mysql数据库恢复---惜分飞
摘要：国庆期间处理了一起因误操作导致MySQL数据库恢复的案例。原500G的vdb1磁盘被重新分区为1000G，并执行了pvcreate等操作导致原有LVM配置丢失。通过分析history日志发现操作者尝试了多次pvresize、pvcreate和lvextend操作均未成功。最终通过将磁盘挂载到x86环境，使用专业工具成功解析并恢复了磁盘数据，MySQL数据库完整恢复，业务测试正常。整个恢复过程历时一周，最终在10月5日完成数据迁移和验证工作。
2025-10-10 09:20:23
364
原创 docker回收和mysql备份导入导致数据丢失恢复---惜分飞
MySQL误删数据恢复方案：针对docker删除、备份导入覆盖等场景，需立即停止写入并保护现场。通过分区快照、反删除工具恢复ibd/frm文件，结合DISCARD/IMPORT TABLESPACE或碎片扫描解析技术，可有效恢复drop/truncate/rm等操作丢失的数据。专业团队可提供完整数据抢救支持。
2025-09-17 14:23:46
260
原创 服务器断电引起的一例ORA-01207故障处理----惜分飞
摘要：客户服务器异常断电导致Oracle数据库启动失败，出现ORA-01207错误，显示数据文件比控制文件新。经检查发现底层NTFS文件系统损坏，多个磁盘存在异常。在成功备份数据后，尝试强制打开数据库时遭遇ORA-6004194错误。解决undo异常后数据库成功打开，但后续导出数据时又出现ORA-6002662/2663错误，表明数据块存在SCN不一致问题。最终通过Patch SCN工具修正Oracle SCN解决了该问题。整个案例体现了非归档模式下数据库异常断电恢复的复杂性。
2025-09-07 10:33:14
330
原创 存储掉电强制拉库引起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
827
原创 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
438
原创 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
408
原创 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
931
原创 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
515
原创 由于空间满导致PostgreSQL数据库异常处理---惜分飞
PostgreSQL数据库因磁盘空间不足导致表文件损坏。最初报错显示磁盘空间不足，清理空间后出现权限拒绝和文件写入错误。通过查询系统表确认损坏表为xifenfei01_log日志表。由于是日志表，直接清理后恢复正常。若损坏的是业务表，建议使用pdu工具进行恢复。该案例提醒需定期检查磁盘空间，避免因空间不足导致数据损坏。
2025-08-09 13:42:31
376
原创 文件系统格式化MySQL数据库恢复---惜分飞
有客户在做迁移的时候,不慎把存放mysql数据库的硬盘进行了重新分区格式化,重新初始化mysql,并且导入了部分历史数据,不能满足客户需求,希望我们帮忙进行数据恢复.里面大概有100套左右mysql数据库,每个库里面表结构相同,数据不一样.接手这个故障,第一操作就是对磁盘进行镜像,然后使用恢复工具进行底层分析,尝试从文件系统层面恢复出来被格式化之前的数据库文件(需要有对应库目录,不然也没有意义,因为每个库里面表结构一样的,没有正确的库名字无法做到有效的区分),通过底层扫描分析,没有发现一个有效数据文件。
2025-07-27 23:17:16
402
原创 一次非常幸运的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
761
原创 恢复 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
542
原创 ORA-600 kokiasg1故障分析---惜分飞
客户正常关闭数据库,然后启动报ORA-600 kokiasg1错误,通过对启动分析确认是由于IDGEN1$序列丢失导致,修复该故障之后,数据库启动成功,但是后台大量报ORA-600 12803,ORA-600 15264等错误,业务用户无法登录.经过深入分析,发现数据库字典obj$中所有核心字典的序列全部被删除,但是在seq$中这些对象的obj#记录还存在.初步怀疑是有人恶意删除了obj$中字典核心序列对象导致.
2025-07-08 22:59:01
688
原创 Oracle数据库文件变成32k故障恢复--惜分飞
这里有一个问题,由于磁盘空间不足,导致部分备份不成功,但是系统级别删除操作依旧正常进行,导致以前有效的备份被删除,后面的备份又没有成功（这个是本次该文件无法还原的主要原因）,慎重提醒,rman备份尽量使用rman本身的策略来管理不要使用系统命令来维护备份策略,基于这样的情况,可以使用反删除命令找出来了一些该文件的备份集,并注册到控制文件中。基于当前情况,可以确认该文件异常,而且没有有效的rman备份.通过分析备份脚本,发现每个备份集1个数据文件,而且没有压缩，并按照10g进行分割为多个文件。
2025-06-27 23:35:15
513
原创 文件系统格式化MySQL数据库恢复---惜分飞
有客户在做迁移的时候,不慎把存放mysql数据库的硬盘进行了重新分区格式化,重新初始化mysql,并且导入了部分历史数据,不能满足客户需求,希望我们帮忙进行数据恢复.里面大概有100套左右mysql数据库,每个库里面表结构相同,数据不一样.接手这个故障,第一操作就是对磁盘进行镜像,然后使用恢复工具进行底层分析,尝试从文件系统层面恢复出来被格式化之前的数据库文件(需要有对应库目录,不然也没有意义,因为每个库里面表结构一样的,没有正确的库名字无法做到有效的区分),通过底层扫描分析,没有发现一个有效数据文件。
2025-06-19 22:28:36
321
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关注的人