Oracle Truncate恢复教程:关键步骤与注意事项

需积分: 31 6 下载量 24 浏览量 更新于2024-12-19 收藏 6KB TXT 举报
Oracle Truncate 操作是一种在Oracle数据库中删除表中所有行但保留表结构的方法,它不记录事务日志,因此无法直接通过常规的备份恢复被Truncate操作删除的数据。然而,如果在执行Truncate操作后发现有误并希望恢复数据,可以采取以下步骤尝试找回丢失的数据: 1. **理解Truncate操作的特性**: Truncate命令会永久地删除表中的所有数据,仅留下表的元数据。这意味着,一旦数据被Truncate,它们将不会出现在归档日志中,常规的备份也无法恢复这些数据。 2. **检查Oracle环境设置**: 控制文件(control.txt)中包含了Oracle服务器的关键配置信息,包括数据文件路径(data_path)、字符集(charset_name)等。确保控制文件内容正确且完整,这对于后续可能的恢复过程至关重要。 3. **检查数据文件头**: 数据文件(如SYSTEM01.DBF)中通常包含文件头信息,如果文件头未被覆盖,有时可以通过分析这些头信息来确定表的结构,从而推测可能存在的数据范围。文件头的offset可以通过配置文件(config.txt)中的`file_header_offset`参数找到。 4. **利用备份策略**: 如果有应用级的逻辑备份或者闪回数据归档(Flashback Data Archive),你可以尝试使用这些功能恢复被Truncate的数据。Oracle的闪回功能(Flashback Table)可以在特定时间点恢复表数据,但前提是有相应的启用和记录。 5. **日志文件检查**: 尽管Truncate不记录行级别的更改,但归档日志可能会包含某些系统级别的更改,例如表空间状态的更新。仔细检查归档日志可能有助于了解Truncate操作的确切状态。 6. **数据恢复工具**: Oracle提供了Data Recovery Advisor(DBUA或RMAN)工具,可以用来扫描和尝试恢复数据。即使没有明确的Truncate操作记录,DBUA仍可能检测到数据丢失,并尝试恢复。 7. **手动操作**: 如果以上方法都无法实现,考虑在数据文件的物理层面上进行恢复。这通常涉及到数据文件的重命名、重新组织或者使用专业的数据恢复软件,但这通常需要数据库管理员的高级技能,并可能导致数据完整性问题。 Oracle Truncate操作后的数据恢复是一个复杂的过程,需要根据具体情况进行判断和操作。在日常管理中,应谨慎使用Truncate,尤其是在关键业务环境中,以防数据丢失。同时,定期的备份策略和数据保护措施是防止这类问题发生的重要手段。
2016-04-18 上传
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数据的功能,在不到一个小时内就恢复了数十万条数据,虽然我们无法保证不丢失一条数据,但至少帮助用户在最短时间内恢复了主要业务。