• oracle中truncate table后的数据恢复


    原文地址:http://steve-111.iteye.com/blog/750326

    前几天在工作中不小心truncate了一个表, 而该表中的数据又是很重要的数据。并且该表数据又没有备份的,有备份的也不是最新的,一时之间不知如何是好。在网上找了很多资料,但没有一个很适合的,有适合的但又没详细说明,很无奈。经过多方面的查找,以下是我综合网上的资料,成功恢复表数据的详细步骤,供大家参考。以便遇到同样的问题,可以很好的恢复。

    1、首先下载odu数据恢复工具,然后解压。(odu工具见附件)
    2、查询数据文件路径相关信息:select ts#,file#,rfile#,name,BLOCK_SIZE from v$datafile;
       将其结构填入odu目录下的control.txt文件中
       格式如下:
    #ts #fno   #rfno     filename                                          block_size
             0          1          1 /bbdata/hzdb/system01.dbf                                                              8192
             1          2          2 /bbidx/hzdb/undotbs01.dbf                                                              8192
             3          3          3 /bbidx/hzdb/indx01.dbf                                                                 8192
             4          4          4 /bbdata/hzdb/tools01.dbf                                                               8192
             5          5          5 /bbdata/hzdb/users01.dbf                                                               8192
             6          6          6 /bbdata/hzdb/REPORT.dbf                                                                8192
             7          7          7 /bbdata/hzdb/RESERVE.dbf                                                               8192
             8          8          8 /bbdata/hzdb/WZHTBS.dbf                                                                8192
             9          9          9 /bbdata/hzdb/perfstat01.dbf                                                            8192
    3、打开oud
    4、执行命令:unload dict
    5、执行命令:scan extent (需等一会儿时间)
    6、执行命令:desc [用户名].[被删除数据的表名]
    Object ID:33547
      Storage(Obj#=33547 DataObj#=33549 TS#=11 File#=10 Block#=1400 Cluster=0)
      NO. SEG INT Column Name Null? Type
      --- --- --- ------------------------------ --------- ------------------------------
      1 1 1 OWNER VARCHAR2(30)
      2 2 2 OBJECT_NAME VARCHAR2(128)
      3 3 3 SUBOBJECT_NAME VARCHAR2(30)
      4 4 4 OBJECT_ID NUMBER
      5 5 5 DATA_OBJECT_ID NUMBER
      6 6 6 OBJECT_TYPE VARCHAR2(18)
      7 7 7 CREATED DATE
      8 8 8 LAST_DDL_TIME DATE
      9 9 9 TIMESTAMP VARCHAR2(19)
      10 10 10 STATUS VARCHAR2(7)
      11 11 11 TEMPORARY VARCHAR2(1)
      12 12 12 GENERATED VARCHAR2(1)
      13 13 13 SECONDARY VARCHAR2(1)
    从上面的输出中,我们可以看到,TEST.T1表所在的表空间号为11,数据段头部为10号文件的1400号块。

    我们使用ODU来确定T1表原来的data object id。一般来说,数据段的数据块,一般是在段头后面相邻的块中。但是我们可以从段头来确认:
      ODU> dump datafile 10 block 1400
      Block Header:
      block type=0×23 (ASSM segment header block)
      block format=0×02 (oracle 8 or 9)
      block rdba=0×02800578 (file#=10, block#=1400)
      scn=0×0000.00286f2d, seq=4, tail=0×6f2d2304
      block checksum value=0×0=0, flag=0
      Data Segment Header:
      Extent Control Header
      -------------------------------------------------------------
      Extent Header:: extents: 1 blocks: 5
      last map: 0×00000000 #maps: 0 offset: 668
      Highwater:: 0×02800579 (rfile#=10,block#=1401)
      ext#: 0 blk#: 3 ext size:5
      #blocks in seg. hdr’s freelists: 0
      #blocks below: 0
      mapblk: 0×00000000 offset: 0
      --------------------------------------------------------
      Low HighWater Mark :
      Highwater:: 0×02800579 ext#: 0 blk#: 3 ext size: 5
      #blocks in seg. hdr’s freelists: 0
      #blocks below: 0
      mapblk 0×00000000 offset: 0
      Level 1 BMB for High HWM block: 0×02800576
      Level 1 BMB for Low HWM block: 0×02800576
      --------------------------------------------------------
      Segment Type: 1 nl2: 1 blksz: 2048 fbsz: 0
      L2 Array start offset: 0×00000434
      First Level 3 BMB: 0×00000000
      L2 Hint for inserts: 0×02800577
      Last Level 1 BMB: 0×02800576
      Last Level 1I BMB: 0×02800577
      Last Level 1II BMB: 0×00000000
      Map Header:: next 0×00000000 #extents: 1 obj#: 33549 flag: 0×220000000
      Extent Map
      -------------------------------------------------------------
      0×02800576 length: 5
      Auxillary Map
      -------------------------------------------------------------
      Extent 0 : L1 dba: 0×02800576 Data dba: 0×02800579
      -------------------------------------------------------------
      Second Level Bitmap block DBAs
      -------------------------------------------------------------
      DBA 1: 0×02800577
      从上面的输出中的“Extent 0 : L1 dba: 0×02800576 Data dba: 0×02800579”可以看到,段的第1个数据块的RDBA为0×02800579,也就是10号文件的1401块。
      我们dump第10号文件的1401块头,来得到表T1原来的data object id:
      ODU> dump datafile 10 block 1401 header
      Block Header:
      block type=0×06 (table/index/cluster segment data block)
      block format=0×02 (oracle 8 or 9)
      block rdba=0×02800579 (file#=10, block#=1401)
      scn=0×0000.00285f2b, seq=2, tail=0×5f2b0602
      block checksum value=0×0=0, flag=0
      Data Block Header Dump:
      Object id on Block? Y
      seg/obj: 0×830b=33547 csc: 0×00.285f21 itc: 3 flg: E typ: 1 (data)
      brn: 0 bdba: 0×2800576 ver: 0×01
      Itl Xid Uba Flag Lck Scn/Fsc
      0×01 0xffff.000.00000000 0×00000000.0000.00 C--- 0 scn 0×0000.00285f21
      0×02 0×0000.000.00000000 0×00000000.0000.00 ---- 0 fsc 0×0000.00000000
      0×03 0×0000.000.00000000 0×00000000.0000.00 ---- 0 fsc 0×0000.00000000
      Data Block Dump:
      ================
      flag=0×0 --------
      ntab=1
      nrow=16
      frre=-1
      fsbo=0×32
      ffeo=0×145
      avsp=0×113
      tosp=0×113
      可以看到,T1表原来的data object id就是33547。
     7. 使用ODU来unload数据:
      ODU> unload table test.t1 object 33547
       8、使用sqlldr导入我们恢复的数据:打开cmd命令,执行E:\ODU\data>sqlldr 用户名/密码@数据库id control=TEST_T1.ctl

    附件:odu

  • 相关阅读:
    DNS解析过程和DNS挟持
    TCP的流量控制和拥塞控制
    tcp连接的建立与释放
    DRBD分布式块设备复制
    rsync+inotify实现数据的实时备份
    nginx+tomcat网页动静分离配置
    基于mysql数据库集群的360度水平切割
    基于主从复制的Mysql双机热备+amoeba实现读写分离、均衡负载
    hexo安装
    centos7-minimal升级内核
  • 原文地址:https://www.cnblogs.com/solooo/p/2546437.html
Copyright © 2020-2023  润新知