PRM 一个Oracle数据库灾难恢复救护车工具

PRM是一款基于JAVA编写的数据库恢复工具,能在Oracle数据库损坏且标准恢复手段失效的情况下,直接从受损的数据文件中恢复数据。它支持多种Oracle特性如Cluster、LOB、分区表等,并能跨所有操作系统平台使用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在真实世界中相信不少朋友遇到过数据库或者文件系统损坏,突然间珍贵的数据无法访问了,这对于以数据为根本的企业来说太致命了。 在大多数场景中标准的基于RMAN的恢复流程都可以解决此类问题。

在少数场景中常规的恢复手段可能会失败,造成失败的原因往往是备份不可用或者丢失归档或者硬件损坏,这种场景下最终留下的是一堆不一致的数据文件,和无法使用的数据库。 但很多人没有意识到显然数据库或者文件系统中的内容并没有被彻底清空,可能只是无法打开数据库,但绝大多数数据仍是完好的。PRM是这样一个工具,它可以直接读取数据文件中尚完好的数据,而不需要运行Oracle Instance数据库实例;只要数据没有被彻底清空或破坏,那么PRM就还有将数据拯救出来的希望。

PRM可以基于损坏的文件系统、ASM Diskgroup和数据文件工作;如果Oracle数据字典可用,那么它会使用Dictionary来使得恢复变得更简单,即便这个字典来源于以前不一致的SYSTEM.DBF系统表空间的备份的。对于PRM而言大多数Oracle特性都被支持,例如Cluster、LOB、分区表等等。


PRM的主要特性

  • PRM完全使用JAVA编写,是一款绿色软件,只需要一个版本的软件就跨了所有操作系统平台,包括 :AIX、Solaris、HPUX、Linux和Windows
  • 因为是基于JAVA编写,所以是平台独立的,所有平台上的表现基本一致
  • 全程GUI图形化交互界面,完全不需要学任何新的命令。即便是DBA新手也能完全掌控
  • PRM独创了数据搭桥模式的数据拯救,问题数据库中的数据无需导出为其他形式,可以直接传送到新建目标数据库,减少了导出导入耗费的时间和所需的额外磁盘空间
  • PRM程序十分健壮,即便损坏数据库问题百出,PRM也可以从容拯救数据
  • PRM支持几乎所有常规的数据类型,包括LOB:BLOB、CLOB、NCLOB
  • PRM可以直接访问ASM上的数据文件,无需将文件从ASM中拷贝出来
  • PRM可以直接拯救损坏ASM Diskgroup上的数据文件,而且这个功能室完全免费的,在社区版里就可以用
  • PRM特别优化了对Truncate截断掉的表数据的拯救过程,仅仅需要点击鼠标就可以做到

 

 

限制

 

虽然PRM 已经支持众多特性了,但是Oracle技术日新月异,所以仍存在以下的限制:

  • 11g secure file lobs仍不支持,secure file lobs还涉及到其他一些技术例如 encryption加密和compression压缩
  • Label security
  • Encryption
  • Exadata上基于CELL的ASM DISK
  • 一些复杂的数据类型

PRM DUL for oracle恢复被truncate截断掉的表 Oracle DBA神器:PRM灾难恢复工具,Schema级别数据恢复。PRM For Oracle Database – schema级别oracle数据库数据恢复特性 ,PRM即ParnassusData Recovery Manager是企业级别Oracle数据库灾难恢复工具PRM可以在无备份的情况下恢复被truncated/drop掉的表,也可以恢复无法打开的Oracle数据库(Alter Database Open失败)中的数据。 PRM是图形化增强版的Oracle DUL工具,同时具备很多Oracle DUL不具备的特性 情况 当某张表被意外truncated掉了,需要恢复其上的所有数据时。表空间的多个数据文件均存放在ASM上,且没有任何形式的备份。 注意这边文章针对的是PRM在 数据字典模式下的Truncate恢复选项不可用时使用,数据字典模式下的Truncate恢复选项是最简单、易用的一种模式,具体使用见《使用PRM恢复Oracle数据库中误truncate截断的表数据》http://www.parnassusdata.com/zh-hans/node/52 PRM 3.0的下载地址: http://parnassusdata.com/sites/default/files/ParnassusData_PRMForOracle_3002.zip PRM 的官方网站: http://www.parnassusdata.com/ PRM背景 PRM恢复表数据时存在多种模式, PRM需要知道哪些表上的数据块是需要被读取并取出数据的。默认的表现形式是直接从segment header数据段头里获取EXTENT MAP即盘区图,另一种方案就是由PRM自己去构建一个盘区图。 这些盘区图可以通过,PRM的SCAN DATABASE选项来获得: Recovery Wizard => Non-Dictionary Mode,如果是ASM则选择Non-Dictionary Mode(ASM) 执行SCAN Database后会生成SEG$和EXT$的数据到PRM内嵌的数据库中,之后可以选择SCAN TABLES FROM SEGMENTS 或者 SCAN TABLES FROM EXTENTS。 FROM Segments 意味着使用Segment Header中获得的Extent MAP信息,而FROM Extents意味着使用PRM自己扫描获得的EXTENT信息。 请注意当TRUNCATE发生后, 数据表Table的Segment Header中的Extent MAP信息就会被清空了, 但实际存放数据的数据块中的行数据还是在哪里的,除非被其他数据表/索引的增长而覆盖了。 所以当Truncate发生后选择SCAN TABLES FROM SEGMENT 是找不回数据的,必须使用SCAN TABLES FROM EXTENTS, EXTENT的信息是PRM自己去数据文件中扫描获得的,所以只要有数据的地方PRM就会自己去找到。 除了Truncate需要使用到 SCAN TABLES FROM EXTENTS之外对于DROP TABLE的恢复也可以用到SCAN TABLES FROM EXTENTS , 总之当Segment Header找不到(可能存放Segment Header的数据文件丢失了)、或者已损坏(可能Segment Header的数据块被损坏了)、或者其中的Extent Map数据无效(Truncate、DROP或逻辑损坏)时都可以使用SCAN TABLES FROM EXTENTS 。 但是如果不存在上述的问题时,建议用SCAN TABLES FROM SEGMENTS ,因为从Segment Header获取信息更方便也更高效一些。 在PRM中同一个程序实例 同时只能使用SCAN TABLES FROM SEGMENTS 或者 SCAN TABLES FROM EXTENTS 中的一个。 使用SCAN TABLES FROM EXTENTS 后需要找到对应被TRUNCATE掉的表的原始DATA_OBJECT_ID,即左侧属性图中的一个对象,并将其DataBridge 数据搭桥传输到目标数据库中即可。 用户truncate误删 schema下的若干数据表,无法使用flashback query等技术恢复数据,尝试从之前的全备份中恢复,数据库restore速度较快,但是archivelog恢复时由于HP data Protecter的不明原因导致归档恢复十分缓慢,缓慢一个归档往往要几分钟,而需要restore数百个归档,时间上无法接受。 该案例通过PRM-DUL直接在字典模式下恢复truncate数据的功能,在不到一个小时内就恢复了数十万条数据,虽然我们无法保证不丢失一条数据,但至少帮助用户在最短时间内恢复了主要业务。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值