自定义博客皮肤VIP专享

*博客头图：

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

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

博客底图：

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

栏目图：

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

主标题颜色：

RGB颜色，例如：#AFAFAF

Hover：

RGB颜色，例如：#AFAFAF

副标题颜色：

RGB颜色，例如：#AFAFAF

预览 取消 提交

自定义博客皮肤

-+
上一步保存

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

原创 Oracle Block Editor Tool---obet

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

2026-07-26 23:48:19 331

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

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

2026-07-15 18:48:24 140

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

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

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

2026-06-10 07:32:28 257

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

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

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

2026-05-23 09:38:20 386

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

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

2026-05-15 22:13:18 255

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

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

2026-05-14 23:12:59 266

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

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

2026-04-28 08:31:36 365

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

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

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

2026-04-12 23:31:32 52

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

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

2026-04-05 06:41:51 57

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

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

2026-03-24 23:19:18 406

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

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

2026-03-09 22:42:39 112

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

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

2026-03-02 23:06:44 449

原创 通过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 450

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

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

2026-02-21 21:39:58 441

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

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

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

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

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

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

2026-02-01 08:15:08 328

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

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

2026-01-17 08:00:33 356

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

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

2026-01-17 07:55:52 345

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

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

2026-01-11 21:16:26 853

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

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

2026-01-09 23:23:03 794

原创 Oracle Recovery Tools 使用说明

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

2025-12-28 18:32:40 765

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

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

2025-12-22 09:36:18 251

原创 sql server 事务日志备份异常恢复案例---惜分飞

基于这样的情况,数据库层面的正常恢复途径只能恢复到11月17日18时左右数据,因为后面的日志发生了损坏,无法继续正常恢复,对于这种情况,我们这边使用日志解析工具对剩余事务日志备份进行解析,生成.sql文件。客户尝试使用全备进行恢复,结果发现只有13日的全备是好的,可以还原出来数据库,其他备份还原直接报错,基于这样的情况,可以希望把数据恢复到11月19日.我接手这个故障之后,先尝试还原13日的备份。客户每天做全库备份,每4小时做事务日志备份,备份类似这样的情况。然后尝试人工应用事务日志备份,类似命令。

2025-12-12 16:48:53 493

原创 win平台挂起Oracle数据库启动进程

对于oracle的有些故障,如果数据库完全open会报错,导致启动失败,这个时候,我们可以尝试在数据库open到一半的过程中把启动过程挂起,然后登录数据库对字典进行修复,然后就可以正常启动数据库。非win平台可以通过gdb挂起数据库启动过程,因为win系统是进程模式,无法通过gdb挂起来实现,通过自己写程序修改oracle内存来实现这个功能。工具中,点击修改内存—>检索Oracle数据库进程—>选择需要操作的数据库进程—>挂起Oracle进程 就可以实现oracle数据库在open的过程中挂住。

2025-12-09 14:22:23 240

原创 ORA-39246: 无法在提供的转储文件中定位主表--惜分飞

分析当时当初的dmp日志,由于expdp的job表所在表空间不足导致expdp导出失败。)把所有表数据出来,经过这两者组合,顺利完成数恢复,可以测试业务完全正常。通过这个dmp导入业务字典信息,然后再利用expdp dmp解析工具(

2025-12-03 23:47:14 351

原创 mysql drop database 无有效备份恢复思路--惜分飞

今天有一个客户在在虚拟机环境中使用drop database删除一个业务mysql的库,删除之后,第一时间关闭了该虚拟机系统.接到该case请求之后,让客户提供了虚拟机文件(vmdk),通过工具分析,mysql数据库是放在/分区下面的/data里面(lvm结构，xfs文件系统),但是已经看不到他们删除的数据库(mysql一个库对应一个目录)对于这种情况,我们第一步尝试文件系统层面反删除恢复(对数据库所在分区进行文件系统层面扫描,尝试恢复被删除的mysql表文件),运气不错,找到了一些被删除库的ibd文件。

2025-12-01 18:54:39 241

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

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

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

原创 C_OBJ#_INTCOL#坏块导致数据库无法open故障处理---惜分飞

摘要：客户在恢复非归档模式Oracle数据库时遇到问题，检测发现文件3需要已覆盖的3200号日志。通过自研工具修改SCN后，仍因system01.dbf文件中的坏块（C_OBJ#_INTCOL#集群对象）导致数据库无法启动。最终采用跳过损坏对象方式打开数据库，重建histgrm$表数据后完成恢复。整个过程涉及日志序列不匹配、非归档模式限制、数据文件坏块处理等典型恢复场景。（149字）

2025-10-25 15:58:56 935

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

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

原创 ORA-600 kokasgi1故障处理(sys被重命名)---惜分飞

摘要：客户数据库因ORA-600[kokasgi1]错误无法启动，该错误通常与SYS用户检查有关。通过启动到mount状态后，手动更新user$表将USER#=0的用户名改为'SYS'，提交变更并执行检查点后重启数据库。最终成功恢复数据库，实现零数据丢失和业务快速恢复。此案例验证了该故障的标准处理方法，在Oracle 11.2.0.4环境下有效。

2025-10-21 20:13:06 373

原创 Patch_SCN for Linux 功能完善---惜分飞

软件支持自动发现内存地址和手工输入内存地址两种模式(当某些情况无法软件自动发现地址时,可以考虑人工输入地址方式进行)3. 无需输入内存地址,程序一般情况下可以直接获取地址并修改。授权成功之后,后续使用软件无需注册。1. 整个代码全部通过C代码实现。第一次使用要求输入注册码。2. 完善了注册机制。确保执行用户有x权限。

2025-10-14 15:00:58 221

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

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 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 数据库碎片恢复工具，核心作用是扫描磁盘上未被覆盖的 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

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

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关注的人

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