自定义博客皮肤VIP专享

*博客头图:

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

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

博客底图:

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

栏目图:

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

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+

  • 博客(111)
  • 资源 (21)
  • 收藏
  • 关注

原创 ORA-600 ktsiseginfo1故障---惜分飞

从上述信息看,由于ora-600 kcbnew_3错误导致70/73号回滚段异常,smon无法正常对其进行扩展,关于ora-600 kcbnew_3报错描述。客户尝试关闭数据库重启,数据库报ora-600 ktsiseginfo1错误,无法正常启动。oracle 9i的库在运行途中突然报ORA-600 kcbnew_3错误。

2024-04-15 11:45:46 613

原创 数据库open成功后报ORA-00353 ORA-00354错误引起的一系列问题(本质ntfs文件系统异常)---惜分飞

因为这个库有ctl备份,通过rman还原ctl备份,然后尝试recover库,结果报ORA-00310 ORA-00334(由于需要的redo无法正常应用导致)服务器异常断电之后,开机启动数据库启动成功,但是报ORA-00353 ORA-00354以及ORA-600 kdsgrp1错误。对于正常open的库,出现此类问题属于反常现象,通过分析系统事件确定是由于ntfs文件系统本身有问题导致。数据报ORA-600 2662错误,此类错误比较简单,使用patch scn工具一键搞定(

2024-04-15 11:44:47 258

原创 ORA-00742 ORA-00312 恢复---惜分飞

有客户反馈,断电之后数据库启动报ORA-00742和ORA-00312,无法正常open。因为recover已经成功,但是依旧报ORA-742错误,尝试查询scn相关信息。后面比较不幸,数据库报ORA-600 4194错误导致数据库异常。基于这样的情况,我们判断数据库直接open成功。我们远程上去尝试open库结果也报同样错误。报错比较明显,对undo进行处理即可.

2024-04-15 11:44:04 397

原创 ORA-00600: internal error code, arguments: [16703], [1403], [4] 原因---惜分飞

其实ORA-600 16703 1403 N的错误,表示数据库在检索tab$表的时候,N为发现异常的obj#的值,这里的报错表示数据库在启动过程中无法检索到tab$中的tab$对象,应该是恢复过程中缺少该记录导致,解决问题的思路就是把该记录回写到tab$表中即可。

2024-03-22 10:37:41 307

原创 ORA-600 2662快速恢复之Patch scn工具---惜分飞

通过自研开发的patch scn工具,修改数据库scn值。对于这类故障,patch scn工具是最快速的解决方案。有客户数据库启动报ORA-600 2662错误。然后open数据库成功。

2024-03-21 00:36:27 168

原创 断电引起文件scn异常数据库恢复---惜分飞

检查发现/data2挂载点所有数据文件异常,由于以前的操作日志已经被清空无法判断原因,初步怀疑和这个挂载点本身有关系。这种情况直接使用bbed修改文件头,然后open库,再逻辑导出数据,完成本次数据恢复工作,参考类似文档。接手现场之后,尝试单个文件recover操作。经过应用厂商一系列操作,主要是如下操作。由于异常断电,数据库最初启动报错。基于这样的情况,通过。

2024-03-03 16:35:00 727

原创 .[[email protected]].mkp勒索加密数据库完美恢复---惜分飞

通过定期的网络安全培训和教育,向用户传达有关勒索病毒及其传播方式的知识,让他们能够警惕潜在的威胁,并学会如何正确应对可疑的电子邮件、链接和附件。5. 访问控制:实施严格的访问控制措施,限制用户对系统和文件的访问权限,避免使用管理员权限进行日常操作,以减少恶意软件感染的风险。此外,定期进行系统维护和检查,确保系统的安全配置和设置。6. 应急响应计划:制定和实施应急响应计划,明确团队成员的责任和任务,建立应对勒索病毒和其他安全事件的应急响应流程,以最大程度地减少损失并快速恢复业务正常运营。

2024-02-26 23:21:04 466

原创 Oracle误删除数据文件恢复---惜分飞

由于涉及system表空间数据文件被删除,无法在open情况下直接操作,直接关闭数据库,启动到mount状态,重命名数据文件路径,recover数据文件,open库,恢复完成。有客户通过sftp误删除oracle数据文件,咨询我们是否可以恢复,通过远程上去检查,发现运气不错,数据库还没有crash,通过句柄找到被删除文件。查询数据文件大小(被删除的文件文件大小通过v$datafile查询为0)

2024-02-21 22:07:30 522

原创 ORA-600 kclchkblk_4和2662故障---惜分飞

有客户恢复请求:由于未知原因导致aix环境的rac两台主机同时重启之后数据库无法正常启动,初步判断是由于写丢失导致故障(ORA-00742 ORA-00353)后续检查发现obj$中的index异常(ORA-08102: index key not found, obj# 39)尝试屏蔽一致性强制拉库后数据库报ORA-600 kclchkblk_4。后续处理中出现和这个错误类似的ORA-600 2662错误。通过对oracle scn进行修改,数据库open成功。

2024-02-21 22:06:46 440

原创 从ORA-00283 ORA-16433报错开始恢复---惜分飞

接手一个客户无法正常启动的故障数据库,尝试recover 报ORA-00283 ORA-16433错误。由于redo和数据文件不匹配,无法正常recover库,尝试强制打开库报ORA-600 2662错误。第一次通过其他方法处理,由于计算失误导致数据库启动报ORA-600 2252错误。处理正确的scn值之后,数据库open成功,然后逻辑方式导出数据,恢复工作完成。通过对控制文件进行处理,再次尝试recover库。基于这种错误,尝试oradebug修改scn。

2024-02-03 22:13:26 356

原创 近期又遇到ORA-600 16703和ORA-702故障---惜分飞

比较常见的由于软件注入恶意代码或者被人恶意破坏的常见故障ORA-600 16703和ORA-702故障。

2024-01-30 15:17:06 273

原创 ORA-01033: ORACLE initialization or shutdown in progress---惜分飞

客户反馈数据库使用plsql dev登录报ORA-01033: ORACLE initialization or shutdown in progress的错误。在恢复过程中中还遇到了ORA-00700 kcrf_split_brain_error错误,但是没有影响数据库open。出现该错误一般是由于数据库没有正常open成功,查看oracle 告警日志发现。至此数据库open成功但是dbv检测system有很多坏块需要分析处理。通过分析aud$的extent,确认这些坏块全部属于该对象。

2024-01-22 21:36:18 1122

原创 存储故障,强制拉库报ORA-600 kcbzib_kcrsds_1处理---惜分飞

这个相对比较简单,对异常undo进行处理,cdb和pdb都open成功,使用数据泵把数据迁移到新库,完成本次恢复(比较幸运,硬件故障的库直接迁移成功,没有报其他错误)硬件故障,客户自行强制resetlogs库,报ORA-600 kcbzib_kcrsds_1错误。处理好该错误之后,数据库在open pdb的时候报ORA-600 4193错误。这个错误处理过多次一般是由于scn异常导致,以前部分类似文章。

2024-01-19 21:12:50 816

原创 mysql数据库被黑恢复—应用层面delete删除---惜分飞

确认这类的业务破坏是通过delete操作实现的,客户那边不太幸,客户找了多人进行恢复,现场严重破坏,老库被删除,并且还原了历史的备份文件(非故障第一现场),通过底层扫描恢复出来ibd和page文件,然后解析对应的文件,运气不错,恢复出来客户需要的数据。客户的mysql被人从应用层面攻击,并且删除了一些数据,导致业务无法正常使用,通过底层分析binlog确认类似恢复操作。

2024-01-12 16:11:25 1067

原创 记录一次ORA-01200完美恢复---惜分飞

报错比较明显system01.dbf文件本来大小应该为1131521个block,但是实际上只有1122561个block,因此无法正常启动,通过修改数据文件欺骗数据库。客户虚拟化平台断电,导致oracle其数据库启动ORA-01200错误。然后对异常的system文件进行处理,把人工构造的部分除掉。rman检测system文件正常。对应的alert日志如下。

2024-01-12 12:53:50 1046

原创 resetlogs失败故障恢复-ORA-01555---惜分飞

这个库由于客户在resetlogs之前offline了数据文件,导致一些麻烦,先使用Oracle Recovery Tools修改resetlogs scn。3. 在resetlogs之前,先offline了83号文件,这个将导致该文件的reseltogs scn和其他文件不一致,通过。2. 数据库在强制拉库的时候,很可能是屏蔽了一致性,导致文件头scn过小。然后增加temp,导出数据数据,完成本次数据库救援。然后重建ctl,修改scn,打开数据库。hcheck检测字典一切正常。

2024-01-03 18:08:54 1232

原创 在线mv方式迁移数据文件导致数据库无法正常启动---惜分飞

此类故障是由于在线拷贝数据文件,可能有不少最新写入的数据都有数据文件和redo不一致的风险,引起这里的ORA-600 3020最好不要通过allow N corruption的方式跳过,因为可能导致大量数据文件坏块,这样就不光丢失了redo数据,可能数据文件中好的block中的很多数据也丢失.对于这种情况,我们为了减少客户的数据丢失,选择了最少数据丢失的方法:通过bbed修改文件头,然后直接recover 数据文件,open库。alert日志报ORA-600 3020错误。sqlplus恢复数据库报错。

2024-01-03 18:08:08 602

原创 kettle导致MySQL数据丢失恢复---惜分飞

通过分析(相关文件的时间),判断kettle应该是在插入数据之前触发了truncate操作导致数据丢失,而且还插入了部分数据。有客户通过kettle 插入数据,由于配置不当导致原数据丢失,希望能够恢复之前数据(mysql数据库)遇到此类误操作,最重要的是保护现场,尽可能减少对数据文件所在分区的写入操作,可以实现最大限度数据恢复.通过数据块层面扫描分析,找出来需要恢复表对应的page文件。解析这些page文件恢复出来客户需要数据。

2023-12-21 11:16:45 323

原创 mysql数据库文件丢失恢复---惜分飞

这个客户出现该故障的原因大概率是由于文件系统损坏导致.最终可以比较好的恢复,主要是故障之后第一时间保护了现场,没进行任何的写入覆盖,如果覆盖了神仙也没有办法.如果此类问题无法自行解决或者恢复效果不好,可以联系“惜分飞”进行技术支持,最大限度抢救和数据,减少损失。通过底层工具进行分析,无法正确恢复数据库名字,一个个单个ibd文件(而且很多本身是错误的)对于这种情况,通过mysql block扫描恢复出来page文件。客户服务器重启,mysql相关数据文件丢失。恢复出来客户需要数据。

2023-12-10 22:49:22 135

原创 ORA-600 kcbzib_kcrsds_1一键恢复

一个19c库由于某种原因redo损坏强制打开库报ORA-600 kcbzib_kcrsds_1错误。工具快速修改数据库scn。

2023-12-07 22:30:48 163

原创 勒索解密后oracle无法启动故障处理----惜分飞

勒索解密oracle恢复

2023-11-27 22:28:40 398

原创 A____Z____RECOVER____DATA勒索恢复---惜分飞

对于类似这种A____Z____RECOVER____DATA勒索恢复,建议先对系统进行镜像或者快照,然后按照先os层面恢复,在block级别恢复的方法处理,如果无法自行解决,可以联系我们进行技术支持,最大限度抢救和数据,减少损失,对于这种情况,本质就是mysql drop 库或者drop表级别的恢复,通过反删除软件恢复,可惜恢复效果很差(底层发生了大量的覆盖)另外建议加强系统和mysql安全加固,数据库尽量不要暴露在公网上。对于这种情况,只能采用底层block级别恢复,通过底层扫描分析。

2023-11-21 21:28:08 2091

原创 再现ORA-600 4000故障处理---惜分飞

resetlogs失败,报ora-600 4000错误,查看相关trace文件。有一个10g的库,由于redo损坏导致无法正常recover成功。正常途径无法open成功,尝试强制打开库。

2023-10-18 15:25:47 166

原创 ORA-07445: exception encountered: core dump [kdxlin()+4088]---惜分飞

出现这种情况是由于redo和数据文件块不一致导致无法正常应用日志,人工对于异常的block进行处理,数据库open成功,然后遭遇undo回滚段异常,对其进行规避,数据库open并且稳定运行。重建ctl之后,尝试recover数据库报错ORA-600 3020和ORA-07445 kdxlin等错误。尝试随机恢复文件,也遭遇ORA-07445 kdxlin异常。abort方式关闭数据库,启动报错。

2023-09-23 22:55:54 597

原创 bbed解决ORA-01578---惜分飞

业务报ORA-01578坏块,无法正常使用,alert日志报错如下。通过dbv检查数据文件,发现只有这一个坏块。业务测试正常,数据完美恢复。通过bbed进入进行修复。

2023-09-15 09:52:18 344

原创 asm disk被加入到另外一个磁盘组故障恢复---惜分飞

通过lscfg 命令确认两套rac使用了同一块盘导致一个磁盘组异常,在新加的机器上查询确认新盘被破坏情况(新加入的磁盘由于reblance操作,已经被写入了380G左右数据[也就意味着这个磁盘在老磁盘组中最少会丢失380G数据]怀疑把报错这个磁盘组的rhdisk37加入到另外一套rac的asm中了(也就是说两套asm使用了同一块磁盘),aix操作系统层面分析确认。有朋友在aix环境对其中一个rac的asm磁盘组进行扩容。之后另外一套rac的磁盘组直接dismount。

2023-09-05 14:21:55 131

原创 ORA-600 ksuloget2 恢复----惜分飞

由于是应用日志失败,屏蔽日志一致性,强制打开数据库,检查数据ok,业务可以直接使用,对于这类问题,官方建议:ORA-600: [Ksuloget2] Hit on Windows When SGA Greater Than 1G (Doc ID 836109.1)客户在win 32位的操作系统上调至sga超过2G,数据库运行过程中报ORA-600 ksuloget2错误。重启数据库,进行尝试恢复继续报ORA-600 ksuloget2。

2023-08-19 21:58:13 177

原创 Patch SCN一键解决ORA-600 2662故障---惜分飞

客户强制重启库之后,数据库启动报ORA-600 2037,ORA-745 kcbs_reset_pool/kcbzre1等错误。屏蔽数据库一致性,强制拉库报ORA-600 2662错误。这种ORA-600 2662的错误比较常见,通过。实现数据库open成功,并顺利导出数据。

2023-08-13 00:19:46 996

原创 Oracle 19c 报ORA-704 ORA-01555故障处理---惜分飞

异常断电导致数据库无法启动,尝试对数据文件进行recover操作,报ORA-00283 ORA-00742 ORA-00312错误,由于redo写丢失无法正常应用。屏蔽数据一致性,尝试强制打开库,报ORA-00604,ORA-00704,ORA-01555错误。alert日志对应错误。

2023-07-30 16:14:53 654

原创 Exadata磁盘损坏导致磁盘组无法mount恢复(oracle一体机磁盘组异常恢复)---惜分飞

在实际恢复过程中由于客户进行了各种尝试,直接新镜像盘然后插入新盘,强制拉磁盘组drop异常disk操作等,导致第一现场发生一些破坏,增加了恢复难道,但是最终通过各种方法弥补,实现了预期的恢复效果(业务数据0丢失)故障原因是由于asm disk 32还已经损坏在换盘过程中(数据没有reblance完成),又损坏了asm disk 39,而这两份磁盘中有数据互为镜像,因此磁盘组无法正常mount起来.),然后比较顺利恢复数据,实现业务数据0丢失。多套库顺利open成功。

2023-07-28 13:24:13 686

原创 .faust加密勒索数据库恢复---惜分飞

然后直接open数据库,并且导出数据,实现数据库非常完美的恢复(这个是目前除直接解密之外最好的恢复效果,没有之一)对于这种级别的损坏,可以通过我开发的Oracle数据文件勒索加密恢复工具直接重构文件头。8.对不熟悉的软件,如果已经被杀毒软件拦截查杀,不要添加信任继续运行。对于类似这种被加密的勒索的数据文件,我们可以实现比较好的恢复效果。2.登录口令要有足够的长度和复杂性,并定期更换登录口令。9.保存良好的备份习惯,尽量做到每日备份,异地备份。4.定期检测系统和软件中的安全漏洞,及时打上补丁。

2023-07-25 21:56:35 459

原创 ORA-01122 ORA-01208 故障处理---惜分飞

确认数据库恢复需要sequence为254986的日志,但是数据库为非归档模式,redo已经被覆盖,因此常规方法无法正常open库,通过。数据库突然故障ORA-01122 ORA-01208,导致实例crash。工具快速修改文件头实现数据库文件头一致,open数据库成功。重启实例无法open。

2023-07-15 20:18:16 844

原创 硬件故障恢复出文件之后数据库故障处理---惜分飞

客户那边硬件故障(raid损坏磁盘超过了极限,导致raid offline),通过硬件恢复出来数据文件,然后尝试自行恢复,我接手的时候大量数据文件resetlogs scn异常.对于这种硬件恢复之后文件上次到服务器上进行恢复的,一定要确认上传文件和原文件一致,不然做无用功或者恢复效果差很多。通过修改文件头然后重建控制文件,可以通过bbed,或者我的小工具。解决好该问题之后,数据库open成功,实现了最大限度抢救数据.通过对比发现是由于客户上传恢复文件异常导致。然后继续重建ctl发现以下错误。

2023-07-13 00:30:05 224

原创 win系统删除oracle数据文件恢复---惜分飞

有客户联系我们,说win平台下的数据库,在由于空间紧张,在关闭数据库的情况下删除的两个数据文件,导致数据库无法正常访问很多业务表,需要对其进行恢复,查看alert日志发现大概操作,删除文件之后,启动数据库失败。另外一个数据文件,从os层面无法恢复,对于这种情况,只能基于底层的block层面进行恢复(恢复没有覆盖的block)接手现场之后,关闭数据库,使用操作系统层面反删除工具进行扫描恢复,发现其中一个文件(另外一个文件os层面无法恢复)offline相关数据文件,启动库成功,但是job开始报错。

2023-07-07 15:11:16 843

原创 ORA-01122 ORA-01200故障处理---惜分飞

让客户把system01.dbf文件发给我进行分析,发现system01.dbf文件大于32G(在8k的blocksize库中,默认情况system01.dbf文件不会超过32G),这个明显异常。通过bbed修改合适的值,并且把文件截取到适当大小,提供system文件给客户,直接启动库成功,实现数据库完美恢复。由于某种原因客户的数据库启动报ORA-01122 ORA-01200错误。检测坏块情况发现4096000之后的block全部为全0块。通过bbed分析文件头记录文件大小。

2023-07-04 16:59:18 549

原创 asm磁盘加入vg恢复---惜分飞

这个客户做了上述操作之后,没有对lv进行写入其他数据,所以破坏较少(主要的破坏就是ext4的每个一段就会置空一部分block预留给文件系统写入元数据使用),通过winhex查看被破坏磁盘发现lvm信息。然后直接恢复dbf中数据文件(对于异常的主要是segment header被置空的tab使用dul单独扫描处理),实现客户数据的最大限度恢复。对于这种情况,通过对文件头进行修复,结合工具直接拷贝出来数据文件(个别文件元数据损坏通过基于block的方式恢复dbf)

2023-06-25 22:36:14 68

原创 Oracle Recovery Tools恢复csc higher than block scn---惜分飞

有客户强制关闭数据库,结果有数据块报坏块,dbv检查为:csc higher than block scn问题。通过OraRecovery工具快速解决csc higher than block scn故障。dbv再次验证数据块ok,Oracle Recovery完美代替bbed解决该问题。该问题主要是由于scn异常导致通过Oracle Recovery工具进行修复。

2023-06-22 23:16:18 157

原创 .mdf.locked加密sql server完美恢复---惜分飞

对于类似这种被加密的勒索的数据文件,我们可以实现比较好的恢复效果,如果此类的数据库(oracle,mysql,sql server)等被加密,需要专业支持。有可能用友ERP软件的sql server 数据库所在机器被勒索病毒加密,扩展名为.locked和昨天恢复的基本类似(8.对不熟悉的软件,如果已经被杀毒软件拦截查杀,不要添加信任继续运行。2.登录口令要有足够的长度和复杂性,并定期更换登录口令。9.保存良好的备份习惯,尽量做到每日备份,异地备份。4.定期检测系统和软件中的安全漏洞,及时打上补丁。

2023-06-12 00:09:57 1148

原创 .locked加密勒索数据库级别恢复---惜分飞

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

2023-06-10 18:56:12 1175

原创 ORA-16038 ORA-00354故障处理---惜分飞

由于25号文件属于offline状态,导致联机日志无法正常被clear,报ORA-00393 ORA-00312等错误.通过试验重现该问题.由于inactive 状态的redo损坏,无法被arch进程归档导致数据库无法正常open,尝试强制clear联机日志。客户的问题也是通过unrecoverable datafile 方式强制clear联机日志成功,数据库open成功。遇到一个案例,数据库open报ORA-16038,ORA-00354等错误。脚本收集),确认为inactive。

2023-05-24 21:58:24 171

percona-xtrabackup-8.0.35

percona-xtrabackup-8.0.35

2023-12-19

Oracle Recovery Tools-最新版

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

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

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 scn小工具(patch scn)

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

2022-06-18

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

Oracle Recovery Tools-202208版本

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

2021-10-19

Oracle Recovery Tools 使用说明

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

2021-10-06

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

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

ufsxpci64.zip

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

2020-03-08

dd.rar 工具下载---解压直接使用

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

2020-03-03

aix平台的unzip 的rpm包

unzip-6.0-3.aix6.1.ppc.rpm

2019-11-18

win 平台类似linux的tail 工具

win 平台类似linux的tail 工具

2019-11-18

基于odp.net的oraclehelper

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

2010-04-16

accesshelper

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

2009-10-25

silverlight精彩实例

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

2009-08-19

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

AspNetPager

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

2009-06-16

微软的sqlHelper

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

2009-06-16

OracleHelper

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

2009-06-16

计算机操作系统(汤子瀛)习题答案

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

2009-01-11

空空如也

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

TA关注的人

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