自定义博客皮肤VIP专享

*博客头图：

格式为PNG、JPG，宽度*高度大于1920*100像素，不超过2MB，主视觉建议放在右侧，请参照线上博客头图

请上传大于1920*100像素的图片！

博客底图：

图片格式为PNG、JPG，不超过1MB，可上下左右平铺至整个背景

栏目图：

图片格式为PNG、JPG，图片宽度*高度为300*38像素，不超过0.5MB

主标题颜色：

RGB颜色，例如：#AFAFAF

Hover：

RGB颜色，例如：#AFAFAF

副标题颜色：

RGB颜色，例如：#AFAFAF

预览 取消 提交

自定义博客皮肤

-+
上一步保存

  • 博客(233)
  • 资源 (21)
  • 收藏
  • 关注
排序：
按最后发布时间
按访问量
RSS订阅

原创 .bres勒索病毒加密数据库dmp文件可恢复---惜分飞

1. 对于dbf/ora类型文件破坏比例非常大,达到1/3左右,而且还是间隔加密,对于这种情况,基于数据库文件基本上没有太大恢复价值,但是我们也遇到一些客户,由于某些原因导致这类病毒加密文件没有全部完成(数据文件被加密中途终止),这样的情况下，可以恢复没有被破坏的block中数据.2.对于exp/expdp备份出来的dmp文件,该病毒一般只是加密前面30M的block,后续其他block全部是完整的,可以恢复出来后续数据,整体数据丢失较少,如果有历史完整的备份,可以实现较为完整的恢复效果。

2026-10-05 22:57:29 199

原创 ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch---惜分飞

分析alert日志,是由于归档无法被正常创建导致该问题,对/u19/dbs/arch/进行创建并授权之后,再次尝试打开数据库,数据库报ORA-600 kcbzib_kcrsds_1错误。客户由于断电,导致一个19c数据库无法正常启动,接手时候报错为：ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch。接手故障开始处理,尝试open库,重现ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch错误。

2026-09-22 21:37:51 250

原创 记录一次0丢失的ORA-00354: 损坏重做日志块标头故障恢复---惜分飞

数据库因服务器断电导致启动时实例恢复失败，报错ORA-00354/ORA-00353，指出REDO05.LOG日志块损坏，且损坏时间点为2026-09-07 10:35:04。检查发现控制文件中ThreadCheckpointRBA记录错误，实际需用REDO01.LOG（sequence 19001）而非损坏的REDO05.LOG。由于数据库处于归档模式，需先清除损坏的日志组，再重建控制文件，并执行全库备份以确保数据安全。

2026-09-12 23:22:56 199

原创 obet快速修复oracle 位图损坏块

使用obet快速修复oracle位图坏块

2026-09-06 22:06:04 216

原创 不太常见的10.2.0.1的oracle redo损坏恢复---惜分飞

曾经恢复过大量10g的库,现在一年也恢复不了几个10g的了,而10.2.0.1的64位库更是少之又少了.近期有幸处理过一个这样的case,重温了当年的感觉。直接使用_minimum_giga_scn修改scn,数据库open成功,并使用expdp成功导出数据,完成本次恢复工作。这种错误基本上要不bbed/obet修改文件头,要不直接屏蔽一致性强制打开,我直接选择了强制拉库,先做不完全恢复。然后强制拉库报ORA-600 2662错误。接手之后再次验证了该错误。

2026-08-28 17:51:01 197

原创 obet forcecopy功能抢救硬件故障中的数据文件

客户raid5发现有盘离线,并且其他盘有坏道,进行了多次换盘操作替换了大部分有坏道磁盘,但是部分文件访问依旧会报io错误。虽然recover database成功,但是不幸open 库报ORA-600 kcbzib_kcrsds_1错误。对于这样的情况,使用obet的forcecopy功能直接强制拷贝文件,可以最大限度求救数据。运气不错,整体坏块非常少,而且没有涉及数据库字典文件,然后尝试恢复。把所有损坏文件拷贝出来之后传输到其他机器上,检查所有文件坏块情况。顺利打开数据库,并导出数据。

2026-08-27 22:32:45 160

原创 kcratr_nab_less_than_odr和system坏块故障处理

现场恢复人员上来之后,直接尝试做强制resetlogs操作,数据库报ORA-600 ORA-600 krsi_al_hdr_update.15错误,主要是由于redo写丢失导致无法resetlogs成功,具体参考：Alter Database Open Resetlogs returns error ORA-00600: [krsi_al_hdr_update.15], (Doc ID 2026541.1)到这一步,现场停止了继续尝试,我接手故障处理.先dbv检测坏块,发现system有两个坏块。

2026-08-27 21:48:42 228

原创 虚拟机强制断电，导致oracle数据库故障恢复---惜分飞

客户由于误操作直接在虚拟化平台点击电源键,强制关闭了正在运行的数据库服务器虚机,导致数据库无法正常启动,检查发现ntfs文件系统损坏,system发现坏块等故障处理

2026-08-25 09:38:33 183

原创 obet dbv功能完整说明

大量的恢复经验和实战总结,逐步了完善obet(Oracle Block Edit Tool)功能和实现恢复的便利性.对于数据库恢复其中一个重要功能就是检测数据块的损坏情况(这个直接关系到恢复的实际效果),Oracle本身提供的dbv功能有一些不足,obet工具的dbv功能是对oracle本身的dbv功能的深度完善,弥补其本身的几个功能不足点

2026-08-17 21:40:28 219

原创 分享一例运行在aix上的sap系统数据库恢复过程

SAP软件的Oracle数据库运行在aix系统上，使用v7000存储，由于断电导致vg的部分lun丢失，通过硬件公司恢复之后，部分数据文件损坏的故障处理案例分享，整体恢复效果良好

2026-08-15 15:06:11 216

原创 几乎动用了所有手段的Oracle故障恢复---惜分飞

最近处理了一个比较复杂的恢复,使用了十八般武艺基本上完成了恢复,最大限度恢复客户的数据

2026-08-03 08:36:37 247

原创 Oracle Block Edit Tool (obet) 功能增强–2026.07

parse_ctl这个是直接解析control，并且生成创建控制文件语句，主要为了解决在oracle数据库无法mount的情况下，重建控制文件容易遗漏数据文件导致oracle后续open之后缺失部分数据文件而引起的各种故障风险。dump_undo这个主要是在数据库open的过程中遭遇到undo回滚段异常，需要屏蔽回滚段时候，需要知道回滚段名称，这个命令可以直接获取。， 基于ai编程的强大，根据近期恢复的需求情况，我对一些功能进行了升级，整体功能。将来根据需求和客户实战情况，会进一步完善功能和修复bug。

2026-08-02 12:23:09 216

原创 Oracle Block Editor Tool---obet

面向 Oracle 数据块的可视化 / 编辑 / 修复工具，覆盖十六进制查看、内部结构解析、tailchk 与 checksum 自动修复、坏块跨文件合并、SCN 信息修复等场景。

2026-07-26 23:48:19 363

原创 记录block 0损坏,数据文件大量坏块,使用不当数据库版本恢复等各种操作之后的故障处理---惜分飞

运气还不错,从备份里面找一份好的该文件的备份,然后通过使用该文件好的block替换最初损坏的block,实现该文件无坏块(由于这个文件比较靠前,而且已经写满,所以只差3天左右数据可能改变很小,因此可以采用这种替代方法最大限度恢复数据).数据文件检测和明显坏块处理完成,接下来开始打开数据库操作.正常打开的数据库,没有明显坏块,出现这个错误,理论上不太应该,怀疑是客户的版本问题,查询组件版本。这种情况,dbf中的版本信息无法通过重建解决,只能使用obet工具修改,每个文件类似修改(然后尝试打开数据库成功。

2026-07-15 18:48:24 157

原创 Oracle数据库系统回滚段异常处理-ORA-600 4137/4193---惜分飞

对于sysaux文件进行检查，由于重建ctl没有包含异常的sysaux文件，因此无法直接从库中查询到当前各种文件头相关情况,通过obet直接解析文件头获取相关信息(然后通过各方人员一顿操作猛如虎,导致数据库启动报ORA-600 4137和ORA-600 4193错误,数据库无法open成功。最初是由于数据库sysaux文件无法正常恢复,重建ctl抛弃sysaux文件,然后打开数据库,但是无法expdp导出数据。然后重建ctl，包含该sysaux，尝试打开数据库,报ORA-600 4193错误。

2026-06-26 21:54:35 260

原创 硬件故障后数据文件大小不对故障处理—Oracle碎片扫描恢复

摘要：某Oracle数据库在硬件恢复后出现DBV-00102错误，经检查发现USERS02-USERS05数据文件实际应为8G但恢复后仅4G。通过自研OraScan工具扫描提取完整数据块重建文件，替换后尝试打开数据库时遭遇redo日志组异常。经分析alert日志后清除问题日志组（group 3），最终成功打开数据库并使用expdp完成数据导出。本次恢复涉及文件大小异常、redo日志损坏等问题，展示了数据库恢复中的典型故障处理流程。

2026-06-10 07:32:28 259

原创 1.5T MySQL数据库完美恢复---惜分飞

MySQL数据库无法启动问题分析与恢复方案 问题描述： 客户MySQL 5.7.27数据库异常停机后无法启动，错误日志显示"log sequence number is in the future"和索引树损坏（innodb_change_buffer表的CLUST_IND索引），同时存在未完成的TRUNCATE操作（表ID 8714）。 问题分析： 数据库非正常关闭导致事务中断 存在未完成的TRUNCATE操作形成死锁 强制恢复模式（innodb_force_recovery）下因只读

2026-06-08 23:30:31 227

原创 asm dd 10M导致system文件部分坏块修复---惜分飞

dd asm 磁盘10m，导致system文件坏块恢复

2026-05-23 09:38:20 396

原创 一次断电引起的Oracle故障恢复-ora-600 2662故障---惜分飞

接手一个oracle恢复case,由于断电导致oracle数据库异常,现场人员进行了一系列的恢复成功,但是没有成功open库,我接手故障之后尝试做recover 报ORA-16433错误。根据经验这种错误一般是由于强制打开库失败导致,回溯oracle alert日志发现类似操作。为了安全性采用库只读情况下exp进行导出,运气不错所有数据顺利导出,完成本次数据恢复任务。尝试recover database恢复。在expdp导出数据过程中遇到了硬件错误。对于这种情况,先重建控制文件。

2026-05-15 22:13:18 261

原创 Oracle故障第一现场被恢复混乱的数据库恢复---惜分飞

现场被多次恢复破坏,而且无任何有限备份,现场非常混乱的故障处理,通过obet快速找出来该库的所有正确数据文件,Patch_SCN工具迅速解决SCN问题,从而快速且顺利的打开数据库,并导出数据,整体而言非常完美

2026-05-14 23:12:59 269

原创 OraScan （Oracle碎片扫描工具）使用说明

​OraScan 是由惜分飞（官方网址：www.xifenfei.com）自主研发的专业 Oracle 数据库碎片恢复工具，核心作用是扫描磁盘上未被覆盖的 Oracle 数据块，解决多种数据文件无法正常恢复的问题​

2026-04-28 08:31:36 371

原创 imp导入dmp报IMP-00098: INTERNAL ERROR: impgst2故障处理

基本上可以确认是由于修改字符集导致lob数据损坏，然后exp导出dmp中这些损坏的lob破坏了dmp的完整性，使得dmp无法正常导入。接到客户反馈,exp导出来的dmp无法导入到库中,而且原库已经被删除并且创建了新库,希望我们协助把dmp里面几个核心表给恢复出来。分析导出日志，发现”ORA-24801: 在 OCI lob 函数中非法的参数值” 错误。1. 直接使用winhex把损坏的lob表从dmp中剔除掉，然后导入数据。imp导入操作直接终止,无法恢复需要的数据。

2026-04-22 14:15:13 73

原创 Oracle数据文件被勒索加密恢复就这么简单

再次证明OraFHR工具比较成熟，可以在某些情况下快速恢复被勒索加密的Oracle数据库。客户一个12.2的库,被.[[yatesnet@cock.li]].wman加密。）功能,确认每个文件损坏63个block（这个统计包含了block 0））重构文件头的条件，使用OraFHR工具对文件头进行重构。而且数据库版本是12.2符合（通过obet工具分析检测（然后重建控制文件打开数据库。导出数据完成勒索恢复。

2026-04-12 23:31:32 60

原创 记录一次win删除数据文件完美恢复案例---惜分飞

有客户在操作系统层面删除了四个数据文件(数据库在关闭情况下直接删除物理文件),然后offline,启动数据库,结果发现被删除的数据文件是业务表空间的,导致大量业务访问报错。通过底层扫描发现需要恢复的文件头部信息丢失,其他block完整(该文件本身不大,只有100M),扫描出来的数据块类似这样的结果。这里比较幸运,丢失的block为1-3,也就是涉及文件头和一些位图信息,通过以前自研的OraFHR工具(再重建控制文件打开数据库,并完美导出数据,实现数据0丢失恢复。工具进行文件头的一些修复工作。

2026-04-05 06:41:51 60

原创 通过一次fio破坏库故障看达梦的优缺点---惜分飞

 运行在信创平台上的达梦数据库主备库都执行了fio操作导致主备库以及备份全备异常,通过文件系统层面恢复出来数据文件,见证了达梦数据库在异常处理上的一些不足之处

2026-03-24 23:19:18 417

原创 .wman扩展名勒索mysql数据库恢复

有客户mysql数据库被勒索加密,扩展名为.[[9BZyIXRkRaQ1F]].[[dawsones@cock.li]].wman。8.对不熟悉的软件，如果已经被杀毒软件拦截查杀，不要添加信任继续运行。3.重要资料的共享文件夹应设置访问权限控制，并进行定期备份。2.登录口令要有足够的长度和复杂性，并定期更换登录口令。9.保存良好的备份习惯，尽量做到每日备份，异地备份。4.定期检测系统和软件中的安全漏洞，及时打上补丁。6.安装安全防护软件，并确保其正常运行。1.多台机器，不要使用相同的账号和口令。

2026-03-09 22:42:39 114

原创 Oracle数据库被勒索加密一键open工具–OraFHR

OraFHR是由惜分飞自主研发的专业 Oracle 数据库数据文件头重构工具，通过重构文件头直接打开数据库，专为解决由于勒索病毒加密数据文件，导致Oracle数据库正常运行的情况恢复。

2026-03-02 23:06:44 458

原创 通过alert日志回顾其他dba oracle异常恢复故障处理以及后续open数据库操作---惜分飞

2. 尝试recover database报ORA-600 3020、ORA-600 17147、ORA-600 17114、ORA-600 17182等错误,这个报错比较明确是由于redo的block信息和datafile的block不一致,导致实例recover database失败。客户那边还做了各种恢复尝试,最终依旧无法正常open库,让我这边进行恢复支持.由于客户库不大,而且可以提供数据进行恢复,我让客户发生我数据之后,在本地电脑上进行恢复,下载文件之后,重命名相关路径然后尝试open库。

2026-03-02 00:04:18 464

原创 rose双机引起文件系统损坏使得数据库异常故障处理---惜分飞

类似处理该故障之后,由于文件系统故障导致不少文件出现大量连续坏块（全0或者记录了其他文件内容的坏块）,这种是由于文件系统元数据异常导致,通过文件系统层面恢复继续无法正常处理,对于这样的情况,通过碎片扫描工具按照oracle block级别的文件重组(其实就是基于rdba信息进行重组),获取正确的数据块信息然后重新重组成数据文件。初步看这个报错，block差距有点大，文件头中记录为419840个block,现在实际有的block数量为384000,使用。查看文件头记录block number情况。

2026-02-21 21:39:58 443

原创 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 365

原创 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 361

原创 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 94

原创 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 610

原创 不当恢复truncate数据导致数据库不能open处理---惜分飞

有客户误truncate操作干掉了数据库中的几张表,然后尝试通过FY_Recover_Data进行恢复,恢复到一半然后终止了,数据库结果就起不来了(具体什么原因不知道,肯定是各种不合适的操作引起的故障),我接手故障的时候,数据库被强制resetlogs,报ORA-600 2662错误。该报错比较明显是由于undo回滚段异常导致,通过屏蔽回滚段,open库成功.后续对客户truncate的表进行分析,比较悲催由于没有第一时间保护现场而且对所在表空间进行了大量写入操作,导致truncate数据恢复较少.

2026-02-01 08:15:08 330

原创 在生产环境错误执行dd命令破坏asm磁盘故障恢复---惜分飞

摘要：某客户误操作将ASM磁盘13通过dd命令部分覆盖到磁盘11和26上，导致分别损失2G和1G数据。通过分析udev绑定关系和ASM日志确认受损情况。由于破坏数据量较小且非初始写入，恢复可能性较大。技术团队先修复损坏磁盘头信息，使用AMDU工具提取数据文件，成功打开数据库。虽然部分文件存在不可修复的坏块（位于被覆盖区域），但整体恢复效果较好，SYSTEM表空间完好，数据库可直接打开。相比以往类似案例，本次恢复难度较低，未使用ASM磁盘块级扫描即完成主要恢复工作。

2026-01-17 08:00:33 361

原创 Patch_SCN快速解决ORA-600 2663故障

摘要：某测试库因删除active状态的redo日志文件导致无法启动，同时磁盘空间已满。经检查发现，丢失了部分关键redo日志，直接恢复无望。先清理日志释放3G空间后，尝试强制恢复但遇到ORA-6002663错误。最终使用Patch_SCN工具成功修复SCN问题，完成数据库恢复并正常打开。整个过程涉及磁盘空间管理、redo日志恢复和SCN修复等关键操作。

2026-01-17 07:55:52 346

原创 obet 实现dbv功能（obet数据文件坏块检测）

摘要：Oracle数据块编辑工具obet发布了第二版，新增dbv(数据块校验)功能，解决了Oracle原厂dbv工具的多项不足。obet-dbv支持批量检查数据文件、显示检查进度，并能处理文件头损坏等异常情况。使用流程包括配置listfile.txt文件、加载文件后执行dbv命令，工具会自动生成详细检测报告，记录坏块数量和类型(如校验和错误、rdba错误等)。相比Oracle原厂工具，obet-dbv具有更强的容错能力和更便捷的操作体验。

2026-01-11 21:16:26 858

原创 obet处理缺少归档日志故障

44号文件状态是12月1日的,而且resetlogs信息也不对.通过和客户沟通,确认是他们在没有备份44号文件的前提下直接执行了类似alter database create datafile 44的命令,但是在应用了写归档之后,发现提示有归档不存在。基于这种情况(故障数据文件直接被覆盖,归档又出现了多天的连续断档,而且没有有效备份),只能先打开数据库,然后根据情况导出数据,然后导入到新库中.这里我直接使用。分析现存归档,确实发现12月1日之后丢失了部分归档日志(归档不连续)然后重建ctl正常打开数据库。

2026-01-09 23:23:03 796

原创 Oracle Recovery Tools 使用说明

（一）软件简介）自主研发的专业 Oracle 数据库恢复工具，专为解决 Oracle 数据库各类数据损坏、SCN 异常等问题设计，提供高效、精准的数据库修复解决方案，助力数据库管理员快速恢复数据库正常运行。（二）核心功能单个 / 批量坏块修复：支持对数据库单个数据块或批量数据块的损坏修复，覆盖不同场景下的坏块处理需求。单个 Block 坏块标记：可手动将指定数据块标记为坏块，便于后续针对性处理。数据块内容操作：支持查看指定数据块的原始内容，同时允许对数据块中的具体数据进行修改。

2025-12-28 18:32:40 772

原创 ORA-600 ktbair2: illegal inheritance---惜分飞

接到客户一个恢复case咨询,数据库open过程报ORA-00600: 内部错误代码, 参数: [ktbair2: illegal inheritance]错误。这个处理起来比较简单,对于异常的undo进行处理之后,数据库正常导出dmp,完成本次恢复任务。然后比较幸运直接open数据库成功,但是报ORA-600 4194错误。这次的故障相对简单一些,通过一些简单尝试之后数据库正常应用成功。

2025-12-22 09:36:18 256

计算机操作系统(汤子瀛)习题答案
计算机操作系统(汤子瀛)习题答案，我在网上找了很久才找到的，拿出来和大家分享

2009-01-11

12c – 使用跨平台增量备份来减少传输表空间的停机时间 (Doc ID 2102859.1).pdf
适用于: Oracle Database Cloud Schema Service - 版本 N/A 和更高版本 Oracle Database Exadata Cloud Machine - 版本 N/A 和更高版本 Oracle Cloud Infrastructure - Database Service - 版本 N/A 和更高版本 Oracle Database Exadata Express Cloud Service - 版本 N/A 和更高版本 Oracle Database Backup Service - 版本 N/A 和更高版本 Linux x86-64 用途 注意： 考虑使用新release的版本V4的过程。 这个版本极大地简化了相关步骤。 请参考文档：V4 Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup Note 2471245.1 本文档覆盖了在 12c 及更高版本上，使用跨平台传输表空间（XTTS）以及 RMAN 增量备份，以最小的应用停机时间，在不 同 endian 格式的系统间迁移数据的步骤。 第一步是从源系统拷贝一份 full backup 到目标系统。之后，使用一系列的增量备份（每一份都比前一份要小），这样在停 机前可以做到目标系统的数据和源系统“几乎”一致。需要停机的步骤只有最终的增量备份及元数据导出/导入。 这个文档描述了在 12c 下使用跨平台增量备份的步骤，关于 11g 下的步骤，请您参考 Note:1389592.1。 跨平台增量备份特性并不能减少 XTTS 的其它步骤花费的时间，比如元数据导出/导入。因此,如果数据库内有很多元数据 （DDL），比如 Oracle E-Business Suite 和其它打包程序，那么跨平台增量备份特性并不能带来很多好处；对于这样的 环境，迁移花的大部分时间是花在处理元数据上，而不是数据文件的转换及传输。 只有被迁移表空间里物理存储的数据库对象才会被拷贝至目标系统；如果要迁移存储在其它表空间的其它类型的对象 （比如存储在 SYSTEM 表空间内的 pl/sql 对象，sequences 等），你可以使用数据泵来拷贝这些对象至目标系统。 注意： 考虑使用新release的版本V4的过程。 这个版本极大地简化了相关步骤。 请参考文档：V4 Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup Note 2471245.1 跨平台增量备份的主要步骤有： 1. 初始化设置 2. 准备阶段（源库数据仍然在线） 1. 备份要传输的表空间（0级备份） 2020/1/5 Document 2102859.1 https://myaccess.oraclevpn.com/+CSCO+1075676763663A2F2F7A6266727A632E68662E62656E7079722E70627A++/epmos/faces/Document… 3/14 2. 把备份及其它必须的文件发送到目标系统 3. 在目标系统恢复数据文件至目标端的 endian 格式 3. 前滚阶段（源库数据仍然在线 – 要重复这个阶段足够多次，使得目标数据文件拷贝和源库越相近越好） 1. 在源库创建增量备份 2. 把增量备份及其它必须的文件发送到目标系统 3. 把增量备份转换成目标系统的 endian 格式并且把增量备份应用至目标数据文件 4. 为下次增量备份确定 next_scn 5. 重复这些步骤直到已经准备好了操作传输表空间 NOTE: 在版本3，如果一个数据文件被加入到一个表空间或者一个新的表空间名字被加入到xtt.properties文件，会出现 一个Warning并且需要额外的处置 1. 传输阶段（此时源库数据需要置于 READ ONLY 模式） 1. 在源库端把表空间置为 READ ONLY 2. 最后一次执行前滚阶段的步骤 这个步骤会让目标系统的数据文件拷贝和源库数据文件完全一致并且产生必要导出文件。 在数据量非常大的情况下，这个步骤所花费的时间要显著的少于传统的 XTTS 方式，因为增量备份会很 小。 3. 使用数据泵把这个表空间的元数据导入至目标数据库 4. 把目标数据库的相关表空间置为 READ WRITE

2020-08-15

修改oracle scn小工具(patch scn)
在一些情况下(特别是一些数据库非常规恢复场景中),需要修改oracle scn绕过一些错误,让数据库open成功,在以前的版本中我们可以通过event,隐含参数,oradebug等方法进行修改,在一些较新的版本中这些方法都被oracle屏蔽,无法实现oracle scn进行调整,针对这种情况,开发了一个Patch_SCN小程序,实现对oracle数据库的scn进行调整

2022-06-18

Oracle Recovery Tools-202208版本
oracle数据块修复工具 修复单个block 坏块 标记单个block为坏块 查看数据块内容 修改数据块中数据 修复数据文件头SCN信息 修复数据文件头resetlogs 信息 修复数据文件头fuzzy信息 数据块拷贝

2021-10-19

Oracle Recovery Tools-202207版
Oracle Recovery Tools是惜分飞(www.xifenfei.com)开发的使用于Oracle数据库恢复的小工具 主要功能： 1. Oracle 单个/批量坏块修复 2. Oracle 单个block标记为坏块 3. 查看和修改某个block内容 4. 修改文件头scn（checkpoint scn） 5. 修改文件头resetlogs scn 6. 修改文件头fuzzy标记 7. 不同文件之间数据块拷贝 8. 修改oracle进程内存中内容，常见使用于修改oracle scn等

2022-06-26

oracle patch scn--修改oracle scn工具（oracle异常恢复利器）
oracle scn修改工具，可以直接修改oracle scn，在极端情况下恢复使用，比如解决ORA-600 2662等类似错误,使用说明：https://www.xifenfei.com/2022/06/win-oracle-scn-patch.html

2022-06-18

silverlight访问数据库汇总
有webclient、webrequest、web service、linq to sql、ef ado.not data service等一些常见是sl访问数据的方法

2009-08-19

html+ashx论坛
在网上找了很久没有发现有html+ashx做的论坛，被逼无奈，自己动手写了个，共享出来和大家分享 前面的现实部分是html的，后面的是业务处理是ashx，后台管理是aspx实现的微软的updatapanel，数据是用sqlhelper实现的

2009-06-29

rman_xttconvert_VER4.3.zip.7z
适用于: Oracle Database Cloud Schema Service - 版本 N/A 和更高版本 Oracle Database Exadata Cloud Machine - 版本 N/A 和更高版本 Oracle Cloud Infrastructure - Database Service - 版本 N/A 和更高版本 Oracle Database Exadata Express Cloud Service - 版本 N/A 和更高版本 Oracle Database Backup Service - 版本 N/A 和更高版本 Linux x86-64 用途 注意： 考虑使用新release的版本V4的过程。 这个版本极大地简化了相关步骤。 请参考文档：V4 Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup Note 2471245.1 本文档覆盖了在 12c 及更高版本上，使用跨平台传输表空间（XTTS）以及 RMAN 增量备份，以最小的应用停机时间，在不 同 endian 格式的系统间迁移数据的步骤。 第一步是从源系统拷贝一份 full backup 到目标系统。之后，使用一系列的增量备份（每一份都比前一份要小），这样在停 机前可以做到目标系统的数据和源系统“几乎”一致。需要停机的步骤只有最终的增量备份及元数据导出/导入。 这个文档描述了在 12c 下使用跨平台增量备份的步骤，关于 11g 下的步骤，请您参考 Note:1389592.1。 跨平台增量备份特性并不能减少 XTTS 的其它步骤花费的时间，比如元数据导出/导入。因此,如果数据库内有很多元数据 （DDL），比如 Oracle E-Business Suite 和其它打包程序，那么跨平台增量备份特性并不能带来很多好处；对于这样的 环境，迁移花的大部分时间是花在处理元数据上，而不是数据文件的转换及传输。 只有被迁移表空间里物理存储的数据库对象才会被拷贝至目标系统；如果要迁移存储在其它表空间的其它类型的对象 （比如存储在 SYSTEM 表空间内的 pl/sql 对象，sequences 等），你可以使用数据泵来拷贝这些对象至目标系统。 注意： 考虑使用新release的版本V4的过程。 这个版本极大地简化了相关步骤。 请参考文档：V4 Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup Note 2471245.1 跨平台增量备份的主要步骤有： 1. 初始化设置 2. 准备阶段（源库数据仍然在线） 1. 备份要传输的表空间（0级备份） 2020/1/5 Document 2102859.1 https://myaccess.oraclevpn.com/+CSCO+1075676763663A2F2F7A6266727A632E68662E62656E7079722E70627A++/epmos/faces/Document… 3/14 2. 把备份及其它必须的文件发送到目标系统 3. 在目标系统恢复数据文件至目标端的 endian 格式 3. 前滚阶段（源库数据仍然在线 – 要重复这个阶段足够多次，使得目标数据文件拷贝和源库越相近越好） 1. 在源库创建增量备份 2. 把增量备份及其它必须的文件发送到目标系统 3. 把增量备份转换成目标系统的 endian 格式并且把增量备份应用至目标数据文件 4. 为下次增量备份确定 next_scn 5. 重复这些步骤直到已经准备好了操作传输表空间 NOTE: 在版本3，如果一个数据文件被加入到一个表空间或者一个新的表空间名字被加入到xtt.properties文件，会出现 一个Warning并且需要额外的处置 1. 传输阶段（此时源库数据需要置于 READ ONLY 模式） 1. 在源库端把表空间置为 READ ONLY 2. 最后一次执行前滚阶段的步骤 这个步骤会让目标系统的数据文件拷贝和源库数据文件完全一致并且产生必要导出文件。 在数据量非常大的情况下，这个步骤所花费的时间要显著的少于传统的 XTTS 方式，因为增量备份会很 小。 3. 使用数据泵把这个表空间的元数据导入至目标数据库 4. 把目标数据库的相关表空间置为 READ WRITE

2020-08-15

aix平台的unzip 的rpm包
unzip-6.0-3.aix6.1.ppc.rpm

2019-11-18

Oracle Recovery Tools 使用说明
修复单个 block 坏块 ...............................................................................................................1 标记单个 block 为坏块 ............................................................................................................2 查看数据块内容.......................................................................................................................2 修改数据块中数据...................................................................................................................2 修复数据文件头 SCN 信息 ......................................................................................................3 修复数据文件头 resetlogs 信息 .............................................................................................4 修复数据文件头 fuzzy 信息 ....................................................................................................4 数据块拷贝...............................................................................................................................5

2021-10-06

accesshelper
使用过sqlhelper的人，这个东西应该很清晰吧

2009-10-25

基于odp.net的oraclehelper
对于asp.net访问oracle数据库，微软已经再支持data.oraclecliet，意见使用odp.net来访问oracle了哦。比data.oraclecliet访问数据库效率更高的odp.net，使用微软的oraclehelper改写得到

2010-04-16

ufsxpci64.zip
UFS Explorer Standard Recovery是一款绿色安全的u盘数据恢复软件，这款软件提供多种扫描选项，用于快速浅扫描，更长时间深度搜索丢失的数据等

2020-03-08

win 平台类似linux的tail 工具
win 平台类似linux的tail 工具

2019-11-18

dd.rar 工具下载---解压直接使用
win dd 工具下载---解压直接使用，非常方便，不用安装任何其他其他东西 执行命令完整和linux一致

2020-03-03

OracleHelper
对sqlhelper很熟悉的朋友，一定会喜欢上这个的，也是微软写的东西，开源的 不多介绍了哦

2009-06-16

微软的sqlHelper
这个有一定编程经验的人一般都会用的，开源的东西，很好用哦，而且可以让自己少写很多代码，效率也高

2009-06-16

AspNetPager
第三方分页控件，而且效率比微软自带的高的多，而且使用起来很方便的，有需要的朋友自己拿走

2009-06-16

silverlight精彩实例
这个是外国论坛的，评价很好的一个sl实例。好不好，大家下载了，看看就知道了

2009-08-19

Oracle Block Editor Tool（数据块编辑工具 obet）
面向 Oracle 数据块的可视化 / 编辑 / 修复工具，支持十六进制查看编辑、内部结构解析（kcbh / kcvfh* / tailchk）、tailchk 与 checksum 自动修复、块复制、SCN 信息修复、坏块跨文件合并、数据文件扩展、损坏块标记、dbv 校验、undo$ 段内容提取、控制文件解析、RDBA 解析等完整功能

2026-10-06

OBET - Oracle Block Editor Tool 使用手册
面向 Oracle 数据块的可视化 / 编辑 / 修复工具，支持十六进制查看编辑、内部结构解析（kcbh / kcvfh* / tailchk）、tailchk 与 checksum 自动修复、块复制、SCN 信息修复、坏块跨文件合并、数据文件扩展、损坏块标记、dbv 校验、undo$ 段内容提取、控制文件解析、RDBA 解析等完整功能。

2026-08-13

专业 Oracle 数据库碎片恢复工具，核心作用是扫描磁盘上未被覆盖的 Oracle 数据块，解决多种数据文件无法正常恢复的问题
OraScan 是由惜分飞（官方网址：www.xifenfei.com）自主研发的专业 Oracle 数据库碎片恢复工具，核心作用是扫描磁盘上未被覆盖的 Oracle 数据块，解决多种数据文件无法正常恢复的问题，适用于以下场景（不限于此）： • 文件系统损坏，无法正常访问数据文件，且文件系统工具无法恢复； • 误删除数据文件，操作系统层面的反删除工具无法恢复； • 断电、文件系统故障导致数据文件变为 0KB，或文件大小异常； • 小文件覆盖了大数据文件； • 需要扫描磁盘上所有未被覆盖的 Oracle 数据块。 • 对于bigfile文件的解析和提取支持 • 支持数据文件跨多磁盘设备恢复

2026-07-20

专业 Oracle 数据库碎片恢复工具-OraScan
专业 Oracle 数据库碎片恢复工具，核心作用是扫描磁盘上未被覆盖的 Oracle 数据块，解决多种数据文件无法正常恢复的问题，适用于以下场景（不限于此）： • 文件系统损坏，无法正常访问数据文件，且文件系统工具无法恢复； • 误删除数据文件，操作系统层面的反删除工具无法恢复； • 断电、文件系统故障导致数据文件变为 0KB，或文件大小异常； • 小文件覆盖了大数据文件； • 需要扫描磁盘上所有未被覆盖的 Oracle 数据块。 • 对于bigfile文件的解析和提取支持 • 支持数据文件跨多磁盘设备恢复

2026-07-20

Oracle 数据库碎片恢复工具（OraScan）
OraScan 是由惜分飞（官方网址：www.xifenfei.com）自主研发的专业 Oracle 数据库碎片恢复工具，核心作用是扫描磁盘上未被覆盖的 Oracle 数据块，解决多种数据文件无法正常恢复的问题，适用于以下场景（不限于此）： • 文件系统损坏，无法正常访问数据文件，且文件系统工具无法恢复； • 误删除数据文件，操作系统层面的反删除工具无法恢复； • 断电、文件系统故障导致数据文件变为 0KB，或文件大小异常； • 小文件覆盖了大数据文件； • 需要扫描磁盘上所有未被覆盖的 Oracle 数据块

2026-04-28

【数据库恢复】基于OraScan的Oracle数据块扫描与碎片提取：文件系统损坏场景下的数据救援
内容概要：本文介绍了由惜分飞开发的专业Oracle数据库碎片恢复工具OraScan，旨在帮助用户从损坏或丢失的数据文件中恢复未被覆盖的Oracle数据块。软件支持多种异常场景下的数据恢复，如文件系统损坏、误删文件、断电导致的文件异常等。文档详细说明了软件的功能特性、适配环境、使用步骤及注意事项，涵盖从选择扫描对象、执行扫描、解析结果到提取数据文件或碎片的全流程操作，并强调了授权、版本匹配和关键文件保护等要点。; 适合人群：从事数据库运维、数据恢复的技术人员，尤其是熟悉Oracle数据库且具备一定系统操作能力的DBA或IT支持人员。; 使用场景及目标：①在文件系统崩溃或数据文件被误删除后恢复Oracle数据块；②从磁盘或镜像中提取受损的Oracle数据文件碎片；③针对无法通过常规手段恢复的数据文件进行底层扫描与重建。; 阅读建议：初次使用者应重点关注适配环境和操作流程，严格按照步骤执行，避免因版本不匹配或误删关键文件导致操作失败；遇到扫描异常或授权问题时，应及时联系官方技术支持以提升恢复成功率。

2026-04-28

Oracle 数据库数据文件头重构工具-数据文件加密一键恢复
OraFHR是由惜分飞自主研发的专业 Oracle 数据库数据文件头重构工具，通过重构文件头直接打开数据库，专为解决由于勒索病毒加密数据文件，导致Oracle数据库正常运行的情况恢复。

2026-03-02

OBET-2025.11.02版本下载
OBET(Oracle Block Editor Tool)是惜分飞(www.xifenfei.com)开发的使用于Oracle数据块查看和编辑小工具 1. 16进制格式查看Oracle数据块(可以指定block/offset，不受4G大小限制) 2. 16进制格式编辑Oracle数据块(可以指定block/offset，不受4G大小限制) 3. 标记数据块为坏块功能 4. 自动修复tailchk 5. 自动修复checksum 6. 任意另个数据文件之间任意数据块内部任何大小数据的copy(比如把file 1 block 1 offset 32 count 128 拷贝到file 10 block 2 offset 128开始的位置) 7. 支持文件头print/p查看注意一级结构体 8. 坏块修复功能 9. 不同文件之前数据块拷贝功能 10. 增加文件头checkpoint scn修复功能 11. 增加文件头resetlogs 信息修复功能

2025-11-16

【数据库维护】基于十六进制编辑的Oracle数据块修复工具：OBET在坏块处理与文件头结构恢复中的应用
内容概要：本文档介绍了OBET（Oracle Block Editor Tool）工具的使用方法，该工具由惜分飞开发，用于Oracle数据块的查看与编辑。主要功能包括以16进制格式查看和编辑数据块、自动修复tailchk和checksum、在不同数据文件间复制数据、标记和修复坏块、修复文件头SCN及resetlogs信息等。支持Oracle 10g至26ai版本，适用于处理数据库底层块结构问题。文档详细说明了软件启动、配置、命令使用（如dump、modify、copy、repair等）、结构体打印（p/print命令）以及授权方式。; 适合人群：具备Oracle数据库管理或运维经验的技术人员，熟悉数据库存储结构的DBA或数据恢复工程师；有一定技术基础并对数据库底层机制感兴趣的学习者。; 使用场景及目标：①用于诊断和修复Oracle数据文件中的坏块问题；②实现数据文件间的块级数据复制与同步；③手动修复因异常导致的SCN不一致、resetlogs信息错误等问题；④深入理解Oracle数据块内部结构及校验机制。; 阅读建议：使用前需注册授权方可启用编辑功能；操作时应谨慎，避免误改关键数据导致数据库不可用；建议结合实际环境测试验证命令效果，并备份原始文件以防意外。

2025-11-16

OBET(Oracle Block Editor Tool)
OBET(Oracle Block Editor Tool)是惜分飞(www.xifenfei.com)开发的使用于Oracle数据块查看和编辑小工具 主要功能 1. 16进制格式查看Oracle数据块(可以指定block/offset，不受4G大小限制) 2. 16进制格式编辑Oracle数据块(可以指定block/offset，不受4G大小限制) 3. 标记数据块为坏块功能 4. 自动修复tailchk 5. 自动修复checksum 6. 任意另个数据文件之间任意数据块内部任何大小数据的copy(比如把file 1 block 1 offset 32 count 128 拷贝到file 10 block 2 offset 128开始的位置) 7. 支持文件头print/p查看注意一级结构体

2025-11-12

Patch SCN使用说明(for 202511)
该软件是惜分飞（https://www.xifenfei.com）开发，仅用来查看和修改Oracle数据库SCN(System Change Number),主要使用在数据库因为某种原因导致无法正常启动的情况下使用该工具进行解决.特别是Oracle新版本中使用隐含参数,event,oradebug等方法无法推进Oracle SCN的情况下，使用该工具能够快速修改SCN,实现数据库启动成功. 不同.NET Framework对应exe版本说明 Patch_SCN_Net2.exe 为.NET Framework 2.0,3.0,3.5版本支持(比如2008及其以前版本） Patch_SCN_Net4.exe 为.NET Framework 4.0及其以后版本支持(比如2012及其以后版本) Linux平台直接使用Patch_SCN工具进行修改使用参照:软件使用（for Linux）

2025-11-02

oracle scn修改利器-Patch SCN最新版-202510
该软件是惜分飞（https://www.xifenfei.com）开发，仅用来查看和修改Oracle数据库SCN(System Change Number),主要使用在数据库因为某种原因导致无法正常启动的情况下使用该工具进行解决.特别是Oracle新版本中使用隐含参数,event,oradebug等方法无法推进Oracle SCN的情况下，使用该工具能够快速修改SCN,实现数据库启动成功. 本次更新完善了Linux版本功能，至此完全支持Linux和windows平台

2025-10-13

Oracle Recovery Tools-202511版本
Oracle Recovery Tools是惜分飞(www.xifenfei.com)开发的使用于Oracle数据库恢复的小工具 主要功能： 1. Oracle 单个/批量坏块修复 2. Oracle 单个block标记为坏块 3. 查看和修改某个block内容 4. 修改文件头scn（checkpoint scn） 5. 修改文件头resetlogs scn 6. 修改文件头fuzzy标记 7. 不同文件之间数据块拷贝 8. 修改oracle进程内存中内容，常见使用于修改oracle scn等 版本功能说明：新版本优化了一些函数效率，对于文件被占用增加了异常捕获和记录日志，便于问题分析和跟踪

2025-10-31

Oracle Recovery Tools-最新版（202501）
Oracle Recovery Tools是惜分飞(www.xifenfei.com)开发的使用于Oracle数据库恢复的小工具 主要功能： 1. Oracle 单个/批量坏块修复 2. Oracle 单个block标记为坏块 3. 查看和修改某个block内容 4. 修改文件头scn（checkpoint scn） 5. 修改文件头resetlogs scn 6. 修改文件头fuzzy标记 7. 不同文件之间数据块拷贝 8. 修改oracle进程内存中内容，常见使用于修改oracle scn等

2023-04-10

oracle scn修改利器-Patch SCN最新版-202501
该软件是惜分飞（https://www.xifenfei.com）开发，仅用来查看和修改Oracle数据库SCN(System Change Number),主要使用在数据库因为某种原因导致无法正常启动的情况下使用该工具进行解决.特别是Oracle新版本中使用隐含参数,event,oradebug等方法无法推进Oracle SCN的情况下，使用该工具能够快速修改SCN,实现数据库启动成功.

2024-07-05

Patch-SCN 小工具使用说明
惜分飞（https://www.xifenfei.com）开发，仅用来查看和修改Oracle数据库SCN(System Change Number),主要使用在数据库因为某种原因导致无法正常启动的情况下使用该工具进行解决.特别是Oracle新版本中使用隐含参数,event,oradebug等方法无法推进Oracle SCN的情况下，使用该工具能够快速修改SCN,实现数据库启动成功.

2024-07-05

percona-xtrabackup-8.0.35
percona-xtrabackup-8.0.35

2023-12-19

linux下面rar压缩工具
linux下面rar压缩工具

2022-10-02

ORA-702_Recovery使用说明
软件说明 该软件修复bootstrap$故障，最常见的错误ORA-00702，使用该工具能够一键修复,实现数据0丢失. 不同.NET Framework对应exe版本说明 ORA-702_Recovery.Net2.exe 为.NET Framework 2.0,3.0,3.5版本支持(比如2008及其以前版本） ORA-702_Recovery.Net4.exe 为.NET Framework 4.0及其以后版本支持(比如2012及其以后版本)

2022-07-21

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章？
取消 删除