基于本周二发的文章《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> create table rescureora.rescureora_table as select * from dba_objects;
Table created.
SQL> select count(*) from rescureora.rescureora_table;
COUNT(*)
----------
86877
SQL> truncate table rescureora.rescureora_table;
Table truncated.
1.通过LogMiner或者redodump找到dataobj#的变化。
因为表可能会truncate过多次,原dataobj#不一定就等于obj#,所以需要通过redo来确认,如果最小补充日志没有打开,LogMiner可能会有遗漏。如果遗漏则使用redodump来寻找。