oracle中误truncate 表后的恢复数据方法

最新推荐文章于 2023-10-16 08:30:00 发布
最新推荐文章于 2023-10-16 08:30:00 发布
阅读量835 收藏
点赞数
分类专栏： ORACLE

经测试，只有测试版，只能回复SYSTEM用户下的表做测试用。正式版要￥￥￥

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

　　1、首先下载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


辰影
关注
专栏目录
oracle中truncate table后的数据恢复
07-13
NULL 博文链接：https://steve-111.iteye.com/blog/750326
oracle truncate恢复工具
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数据的功能，在不到一个小时内就恢复了数十万条数据，虽然我们无法保证不丢失一条数据，但至少帮助用户在最短时间内恢复了主要业务。
ORACLE truncate 数据恢复
01-16
因自己前段时间因truncate一张表无法找回，且数据超过60W，平常的企业软件超过1W收费，故整理此内容，希望和我遇到同样问题的新手有帮助
Truncate表恢复(无备份情况下)
07-18
Truncate 不会逐个清除用户数据块上的数据，而仅仅重置数据字典和元数据块上的元数据（如存储断头和扩展段图）。 也就是说，此时，基本数据表并未破坏，而是被系统回收，等待被重新分配—因此，要恢复被truncate的数据，需要及时备份所在的数据文件。
odu.rar odu数据恢复工具
07-24
odu数据恢复工具 1、首先下载odu数据恢复工具，然后解压。(odu工具见附件) 2、查询数据文件路径相关信息：select ts#,file#,rfile#,name,BLOCK_SIZE from v$datafile; 将其结构填入odu目录下的control.txt文件中 3、打开oud 4、执行命令：unload dict 5、执行命令：scan extent （需等一会儿时间） 6、执行命令：desc [用户名].[被删除数据的表名] 　7. 使用ODU来unload数据： 　　ODU> unload table test.t1 object 33547 8、使用sqlldr导入我们恢复的数据：打开cmd命令，执行E:\ODU\data>sqlldr 用户名/密码@数据库id control=TEST_T1.ctl
Oracle中Truncate表的恢复方法.pdf
10-09
Oracle 中 Truncate 表的恢复方法 Oracle 数据库中，Truncate 表是一种高效的删除表操作，但是它不会产生日志记录和回滚段空间的使用，无法使用闪回恢复。因此，需要使用 LogMiner 快速定位 Truncate 表的 SCN，并...
Oracle数据库误删除数据的不同恢复方法整理（超级实用）
02-02
当表被DROP后，如果没有立即被其他数据覆盖，Oracle会将其放置在**回收站**(Recycle Bin)中，这使得用户可以在一定时间内恢复被删除的表。 #### 三、误删除数据的具体恢复方法 ##### 3.1 DELETE误删除的恢复方法 ...
Oracle数据库误删除数据的不同恢复方法整理
最新发布
02-04
### Oracle数据库误删除数据的不同恢复方法 #### 一、引言 在日常的数据库管理工作中，数据误删除是一个常见的问题。对于Oracle数据库来说，它提供了一系列强大的数据恢复工具和技术，帮助管理员快速有效地恢复误...
odu oracle数据库恢复工具
08-16
oracle数据库恢复工具odu,内含使用说明。只适用于windows环境下使用。 场景1. 数据库不能启动，但是SYSTEM表空间中的数据字典是完整的。 场景2. 表被TRUNCATE。 场景3. 表被DROP。 场景4. 系统表空间损坏。 场景5. 表中数据被DELETE。
oracle truncate恢复
07-03
使用ODU恢复Truncate表ODUmanual ODU3月 15th, 2009 意外Truncate表的事情时有发生，ODU提供了方便的恢复Truncate表的功能。被Truncate的表，只要原来的空间没有被重用（即数据被覆盖），则数据都是可以恢复的。 如果发现一个表被意外地Truncate，而需要马上恢复。首先要做的就是关闭数据库，或者OFFLINE那个表所在的表空间，或者关闭所有应用。目的只有一个，确保空间不会被重用，数据不会被覆盖。 下面举例说明如何用ODU恢复被Truncate掉的表。 1. 建立测试的表DB_JJ_INFO_TEMP。 SQL> connect pdata/test 已连接。 SQL> create table DB_JJ_INFO_TEMP as select * from dba_objects; SQL> truncate table DB_JJ_INFO_TEMP; 2. 我们OFFLINE掉DB_JJ_INFO_TEMP表的表空间（实际上在实际的系统中，如果有比较多的活动，则表空间不容易被OFFLINE下来）。然后做一个Checkpoint，让ODU能够读到最新的数据字典数据。 SQL> select tablespace_name from user_tables where table_name='DB_JJ_INFO_TEMP'; TABLESPACE_NAME ------------------------------ PDATA SQL> alter tablespace PDATA offline; 表空间已更改。 SQL> alter system checkpoint; 系统已更改。 22=================================完善字典文件格式如下 control.txt文件中的数据格式为： 表空间号 文件号 相对文件号 文件名 块大小 是否大文件表空间 每列之间用空白分隔，可以只需要前四列，即块大小和是否大文件表空间可省略，块大小省略时，数据文件的默认块大小为config.txt中block_size的大小。下面是一个示例的数据： #ts #fno #rfno filename block_size bigfile 0 1 1 D:\ORACLE\ORADATA\XJ\SYSTEM01.DBF 4096 1 2 2 D:\ORACLE\ORADATA\XJ\UNDOTBS01.DBF 4096 3 3 3 D:\ORACLE\ORADATA\XJ\DRSYS01.DBF 4096 4 4 4 D:\ORACLE\ORADATA\XJ\EXAMPLE01.DBF 4096 5 5 5 D:\ORACLE\ORADATA\XJ\INDX01.DBF 4096 6 6 6 D:\ORACLE\ORADATA\XJ\ODM01.DBF 4096 7 7 7 D:\ORACLE\ORADATA\XJ\TOOLS03.DBF 4096 7 8 8 D:\ORACLE\ORADATA\XJ\TOOLS02.DBF 4096 9 9 9 D:\ORACLE\ORADATA\XJ\XDB01.DBF 4096 11 10 10 D:\ORACLE\ORADATA\XJ\TEST01.DBF 2048 14 11 11 D:\ORACLE\ORADATA\XJ\K16.DBF 16384 如果数据文件头是完好的，则ODU会自动从文件头里面获取表空间号，文件号，相对文件号，文件块大小等。表空间号，文件号和相对文件号可以写为0。 注意：ODU将检查control.txt文件中的第一个数据文件是否为SYSTEM表空间文件，所以要将SYSTEM表空间的第1个文件放在control.txt文件中的第一行。否则将不能自动获得数据字典数据。 3. 运行ODU，并unload数据字典。 ODU> unload dict get_bootstrap_dba: compat header size:12 CLUSTER C_USER# file_no: 1 block_no: 177 TABLE OBJ$ file_no: 1 block_no: 241 CLUSTER C_OBJ# file_no: 1 block_no: 49 CLUSTER C_OBJ# file_no: 1 block_no: 49 found IND$’s obj# 19 found IND$’s dataobj#:2,ts#:0,file#:1,block#:49,tab#:3 found TABPART$’s obj# 230 found TABPART$’s dataobj#:230,ts#:0,file#:1,block#:3313,tab#:0 found INDPART$’s obj# 234 found INDPART$’s dataobj#:234,ts#:0,file#:1,block#:3377,tab#:0 found TABSUBPART$’s obj# 240 found TABSUBPART$’s dataobj#:240,ts#:0,file#:1,block#:3473,tab#:0 found INDSUBPART$’s obj# 245 found INDSUBPART$’s dataobj#:245,ts#:0,file#:1,block#:3553,tab#:0 found IND$’s obj# 19 found IND$’s dataobj#:2,ts#:0,file#:1,block#:49,tab#:3 found LOB$’s obj# 156 found LOB$’s dataobj#:2,ts#:0,file#:1,block#:49,tab#:6 found LOBFRAG$’s obj# 258 found LOBFRAG$’s dataobj#:258,ts#:0,file#:1,block#:3761,tab#:0 4. 获取PDATA用户下的DB_JJ_INFO_TEMP表，也就是我们要恢复的表的信息： ODU> desc PDATA.DB_JJ_INFO_TEMP 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) 从上面的输出中，我们可以看到，PDATA.DB_JJ_INFO_TEMP表所在的表空间号为11，数据段头部为10号文件的1400号块。 5. 接下来用ODU扫描表空间的extent： ODU> scan extent tablespace 11 scanning extent… scanning extent finished. 6. 我们使用ODU来确定DB_JJ_INFO_TEMP表原来的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块头，来得到表DB_JJ_INFO_TEMP原来的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 可以看到，DB_JJ_INFO_TEMP表原来的data object id就是33547。 7. 使用ODU来unload数据： ODU> unload table PDATA.DB_JJ_INFO_TEMP object 33547 Unloading table: DB_JJ_INFO_TEMP,object ID: 33547 Unloading segment,storage(Obj#=33547 DataObj#=33547 TS#=11 File#=10 Block#=1400 Cluster=0) 8. 使用sqlplus将PDATA表空间ONLINE： SQL> alter tablespace test online; 表空间已更改。 9. 使用sqlldr导入我们恢复的数据： E:\ODU\data>sqlldr test/test control=TEST_T1.ctl SQL*Loader: Release 9.2.0.8.0 - Production on 星期日 3月 15 15:13:56 2009 Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. 达到提交点，逻辑记录计数6502 达到提交点，逻辑记录计数13004 达到提交点，逻辑记录计数19506 达到提交点，逻辑记录计数26008 达到提交点，逻辑记录计数30071 至此，恢复数据的步骤已经完成。我们来对比一下数据，看看数据是否和被Truncate前的数据完全一样： SQL> select * from t2 minus select * from DB_JJ_INFO_TEMP; 可以看到，数据已经完全恢复。
oracle数据库恢复工具ODU-Linux版
10-11
oracle数据库恢复工具，不会使用的请看我2017-10-11博客
试用ODU软件恢复corrupt block
bisal的专栏
12-10 874
Oracle的数据恢复处理，有各种方法工具支持，在这方面，我算是一个新手，也是处于不断的学习中。   业界有一些著名的恢复软件，简单罗列一下， 1. Oracle DUL 是 Oracle公司内部的数据库恢复工具，由在荷兰的Oracle Support，Bernard van Duijnen开发，需要注意的是，DUL不是Oracle的一个产品，不是一个受Oracle支持的产品。DUL被严格...
Oracle数据恢复工具-ODU
weixin_33690963的博客
03-14 301
ODU全称为Oracle Database Unloader，偶然在ITPUB看到一款数据小工具，创作者-老熊，网站地址为http://www.laoxiong.net/odu 初试了一下，工具虽小但功能挺强大的，通过直接扫描数据文件来获取误删的数据，在某些情况下合理使用能发挥很不错的效果。 将自己的其中一个测试过程发布在这里： 三、恢复truncate...
oracle容灾之truncate数据恢复
baomw的博客
11-22 2558
在我的另外几篇文章中，介绍了关于数据库闪回的一些内容，对于drop和delete的数据闪回。对于truncate，可能有一些数据库知识的应该会知道，在正常逻辑中，如果我们将表truncate掉了，是找不回来了，TRUNCATE TABLE 是一次性地从表中删除所有的数据并不把单独的删除操作记录记入日志保存，删除行是不能恢复的。并且在删除的过程中不会激活与表有关的删除触发器。执行速度快。 那么问题来...
oracle odu抽数,Oracle数据恢复工具-ODU
weixin_29982199的博客
04-14 572
ODU全称为Oracle Database Unloader，偶然在ITPUB看到一款数据小工具，创作者-老熊，网站地址为http://www.laoxiong.net/odu初试了一下，工具虽小但功能挺强大的，通过直接扫描数据文件来获取误删的数据，在某些情况下合理使用能发挥很不错的效果。将自己的其中一个测试过程发布在这里：三、恢复truncate的表被Truncate的表，只要原来的空间没有被重...
oracle数据库中truncate表后如何快速恢复
热门推荐
DBA的世界
09-12 3万+
在生产中，极有可能遇到不小心truncate表的情况，truncate表后不会产生日志记录和回滚段空间的使用，不能用闪回恢复。尤其是在没有任何备份的情况下所以恢复起来相当麻烦，虽然在有备份的情况下是可以用rman恢复，但是在生产业务库中，一般是不能轻易停库的，而且为了一张表而关库也会对其它正常的数据产生影响 ，所以这在时间上和空间上都是不可取的。那有没有在不影响数据业务正常运行的情况下去快速恢复表
oracle truncate表 恢复操作
ElanJie的博客
04-15 1786
truncate恢复表 1.创建测试用表 conn elan/elan create table haha as select * from dba_users; 2.查询表数据 select count(1) from haha; COUNT(1) ---------- 38 3.清空创建的表 truncate table haha; select cou...
Oracle数据恢复工具-ODU破解记录
zhw309的专栏
05-09 8396
Oracle数据恢复工具-ODU破解 ODU全称为Oracle Database Unloader，是由OracleODU开发的类似于Oracle的DUL（Oracle内部著名的数据库恢复工具）的一款恢复软件，用于直接从Oracle数据库的数据文件中获取表数据。在各种原因造成的数据库不能打开时，用于抢救数据，最大限度地减少数据丢失。ODU已经多次成功应用于产品环境下Oracle数据库的恢复，迄今
Oracle-truncate误删数据恢复
sinat_36757755的博客
10-16 3689
truncate操作误删数据之后想恢复数据通常比较困难，因为truncate操作属于ddl操作无法使用直接undo闪回查询方式恢复数据，并且由于空间大小、备份时间以及变更操作不规范原因，往往在执行操作之前没有对表进行CTAS备份或者其他有效的逻辑备份导致恢复truncate的误删数据困难。
Oracle RMAN 数据恢复教程：如何还原被 truncate 的表
"该资源主要涉及Oracle数据库的RMAN（ Recovery Manager）工具，以及如何在 truncate 表操作后恢复数据。在 truncate 后，通常需要通过时间点恢复来还原数据，因为 truncate 是不可回滚的操作，它会永久删除表中的...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值