TRUNCATE TABLE恢复-脚本

最新推荐文章于 2023-10-16 08:30:00 发布

数据和云

最新推荐文章于 2023-10-16 08:30:00 发布

阅读量1.3k

点赞数

文章标签：数据库 java python 大数据人工智能

本文链接：https://blog.csdn.net/enmotech/article/details/121689587

版权

本文介绍了在没有备份的情况下，如何通过LogMiner或redodump找到dataobj#变化，利用dbms_rowid.rowid_create恢复TRUNCATE TABLE操作误删除的数据。详细步骤包括查找dataobj#、遍历free block和extent，实现Oracle数据库的特殊恢复。作者李翔宇将在数据技术嘉年华分享更多Oracle内部原理。

摘要由CSDN通过智能技术生成

基于本周二发的文章《TRUNCATE恢复-bbed》（详戳），有些朋友或许对块结构和bbed不熟悉，且bbed的方法也较为复杂，那么大家也可以尝试使用本文的方法来修复。

结合truncate系列一的原理《TRUNCATE TABLE原理解析》（详戳），再加上truncate table还有一个特点，就是所释放的空间会变成free space，这就给没有备份的情况下恢复表数据提供了另外一种思路。

恢复思路如下：

通过LogMiner或者redodump找到dataobj#的变化(用于update obj$里的dataobj#)。
使用dbms_rowid.rowid_create抽取该表空间匹配truncate前dataobj#的block里的数据。

抽取的范围也有两种思路：

truncate bbed修复中介绍的redodump找出的extent map里的block(本文的PL/SQL不采用此方式)。
该表的第一个extent、该表空间的free space、该表空间所有segment的最后一个extent(因为truncate的空间可能已经被其他segment使用，可以抽取LHWM-HHWM之间还未格式化的block)。

环境构造：

SQL&gt; create table rescureora.rescureora_table as select * from dba_objects;
Table created. 
SQL&gt; select count(*) from rescureora.rescureora_table;
  COUNT(*)
----------
     86877   
SQL&gt; truncate table rescureora.rescureora_table;
Table truncated.

1.通过LogMiner或者redodump找到dataobj#的变化。

因为表可能会truncate过多次，原dataobj#不一定就等于obj#，所以需要通过redo来确认，如果最小补充日志没有打开，LogMiner可能会有遗漏。如果遗漏则使用redodump来寻找。