oracle drop/truncate table 恢复

最新推荐文章于 2024-08-22 09:11:34 发布
最新推荐文章于 2024-08-22 09:11:34 发布
阅读量3.8k 收藏 1
点赞数
分类专栏： 特殊恢复 文章标签： drop table 恢复 truncate table恢复
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/zhengwei125/article/details/50728576
版权

drop table 并且回收站已经被情况了，如何恢复？
前提：数据库开规档，并且删除之前的归档没有被删掉。
思路：rman备份、创建pfile、 创建一个辅助实例恢复之后，再导入到原来实例;

1.  如果开了闪回，可闪回

2.  利用备份加archivelog 进行不完全恢复(该方法同样适用于truncate的恢复)

++++Session 1

SQL> conn zw/zw 
Connected.
SQL> create table t1 as select * from dba_tables;

Table created.

SQL> select count(*) from t1;

  COUNT(*)
----------
      1204


+++++Session 2

run
{
allocate channel c1 type disk;
allocate channel c2 type disk;
backup  database format '/oradata/backup/full_%d_%T_%s_%p';
sql 'alter system archive log current';
sql 'alter system archive log current';
sql 'alter system archive log current';
backup archivelog all format '/oradata/backup/arch_%d_%T_%s_%p';
backup current controlfile format '/oradata/backup/ctl_%d_%T_%s_%p';
}

+++++drop table

SQL> show user
USER is "ZW"
SQL> alter system switch logfile;

System altered.

SQL> drop table t1 purge;

Table dropped.

SQL> alter system checkpoint;

System altered.

3.创建一个pfile

SQL> conn /as sysdba
Connected.
SQL> create pfile='/tmp/zw.ora' from spfile;

File created.

SQL>

4. 修改pfile

node1new.__db_cache_size=335544320
node1new.__java_pool_size=4194304
node1new.__large_pool_size=4194304
node1new.__oracle_base='/u01/app/oracle'#ORACLE_BASE set from environment
node1new.__pga_aggregate_target=339738624
node1new.__sga_target=503316480
node1new.__shared_io_pool_size=0
node1new.__shared_pool_size=150994944
node1new.__streams_pool_size=0
*.audit_file_dest='/u01/app/oracle/admin/node1new/adump'
*.audit_trail='db'
*.compatible='11.2.0.4.0'
*.control_files='/oradata/node1new/control01.ctl','/u01/app/oracle/fast_recovery_area/node1new/control02.ctl'
*.db_block_size=8192
*.db_domain=''
*.db_file_name_convert='/oradata/node1new','/oradata/node2'
*.db_name='node1'
*.db_unique_name='node1new'
*.db_recovery_file_dest='/u01/app/oracle/fast_recovery_area'
*.db_recovery_file_dest_size=5218762752
*.diagnostic_dest='/u01/app/oracle'
*.java_pool_size=0
*.log_archive_dest_1='location=/oradata/arch1'
*.memory_target=842006528
*.open_cursors=300
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.undo_tablespace='UNDOTBS1'



5. 创建各种dump目录
-----------------------------------------------------
[oracle@node1 tmp]$ export ORACLE_SID=node1new
[oracle@node1 tmp]$ echo $ORACLE_SID
node1new

11g要创建这些目录

rm -rf $ORACLE_BASE/admin/$ORACLE_SID
mkdir -p $ORACLE_BASE/admin/$ORACLE_SID/adump
mkdir -p $ORACLE_BASE/admin/$ORACLE_SID/dpdump
mkdir -p $ORACLE_BASE/admin/$ORACLE_SID/pfile
mkdir -p $ORACLE_BASE/admin/$ORACLE_SID/scripts
chmod -R 750 $ORACLE_BASE/admin

rm -rf $ORACLE_BASE/diag/rdbms/$ORACLE_SID
mkdir -p $ORACLE_BASE/diag/rdbms/$ORACLE_SID/$ORACLE_SID/alert 
mkdir -p $ORACLE_BASE/diag/rdbms/$ORACLE_SID/$ORACLE_SID/cdump 
mkdir -p $ORACLE_BASE/diag/rdbms/$ORACLE_SID/$ORACLE_SID/hm    
mkdir -p $ORACLE_BASE/diag/rdbms/$ORACLE_SID/$ORACLE_SID/incident
mkdir -p $ORACLE_BASE/diag/rdbms/$ORACLE_SID/$ORACLE_SID/incpkg
mkdir -p $ORACLE_BASE/diag/rdbms/$ORACLE_SID/$ORACLE_SID/ir    
mkdir -p $ORACLE_BASE/diag/rdbms/$ORACLE_SID/$ORACLE_SID/lck   
mkdir -p $ORACLE_BASE/diag/rdbms/$ORACLE_SID/$ORACLE_SID/metadata
mkdir -p $ORACLE_BASE/diag/rdbms/$ORACLE_SID/$ORACLE_SID/stage 
mkdir -p $ORACLE_BASE/diag/rdbms/$ORACLE_SID/$ORACLE_SID/sweep 
mkdir -p $ORACLE_BASE/diag/rdbms/$ORACLE_SID/$ORACLE_SID/trace
chmod -R 750 $ORACLE_BASE/diag/rdbms/$ORACLE_SID 
    
    

6.恢复controlfile
RMAN> startup nomount pfile='/tmp/pfile.ora';

Oracle instance started

Total System Global Area     167772160 bytes

Fixed Size                     1272600 bytes
Variable Size                 62915816 bytes
Database Buffers             100663296 bytes
Redo Buffers                   2920448 bytes

RMAN> restore controlfile from '/oradata/backup/ctl_NODE1_20160123_18_1';

Starting restore at 23-JAN-16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1 device type=DISK

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
output file name=/oradata/node1new/control01.ctl
output file name=/u01/app/oracle/fast_recovery_area/node1new/control02.ctl
Finished restore at 23-JAN-16

SQL> alter database mount;
Database altered.


---restore datafile
RMAN>
run
{
set newname for datafile '/oradata/node1/system01.dbf'  to '/oradata/node1new/system01.dbf';
set newname for datafile '/oradata/node1/sysaux01.dbf'  to '/oradata/node1new/sysaux01.dbf';
set newname for datafile '/oradata/node1/undotbs01.dbf' to '/oradata/node1new/undotbs01.dbf';
set newname for datafile '/oradata/node1/users01.dbf'   to '/oradata/node1new/users01.dbf';
restore database ;
switch datafile all;
}

executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME

Starting restore at 23-JAN-16
Starting implicit crosscheck backup at 23-JAN-16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=19 device type=DISK
Crosschecked 7 objects
Finished implicit crosscheck backup at 23-JAN-16

Starting implicit crosscheck copy at 23-JAN-16
using channel ORA_DISK_1
Finished implicit crosscheck copy at 23-JAN-16

searching for all files in the recovery area
cataloging files...
no files cataloged

using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00002 to /oradata/node1new/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00004 to /oradata/node1new/users01.dbf
channel ORA_DISK_1: reading from backup piece /oradata/backup/full_NODE1_20160123_11_1
channel ORA_DISK_1: piece handle=/oradata/backup/full_NODE1_20160123_11_1 tag=TAG20160123T140220
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:25
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /oradata/node1new/system01.dbf
channel ORA_DISK_1: restoring datafile 00003 to /oradata/node1new/undotbs01.dbf
channel ORA_DISK_1: reading from backup piece /oradata/backup/full_NODE1_20160123_10_1
channel ORA_DISK_1: piece handle=/oradata/backup/full_NODE1_20160123_10_1 tag=TAG20160123T140220
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:45
Finished restore at 23-JAN-16

datafile 1 switched to datafile copy
input datafile copy RECID=5 STAMP=901898007 file name=/oradata/node1new/system01.dbf
datafile 2 switched to datafile copy
input datafile copy RECID=6 STAMP=901898007 file name=/oradata/node1new/sysaux01.dbf
datafile 3 switched to datafile copy
input datafile copy RECID=7 STAMP=901898007 file name=/oradata/node1new/undotbs01.dbf
datafile 4 switched to datafile copy
input datafile copy RECID=8 STAMP=901898007 file name=/oradata/node1new/users01.dbf



7.拷贝归档，恢复到最新的时间点

[oracle@node1 arch]$ cp *.dbf  /oradata/arch1/
[oracle@node1 node1new]$ env|grep SID
ORACLE_SID=node1new
[ora10g@killdb ~]$ rman target /

Recovery Manager: Release 10.2.0.5.0 - Production on Tue Aug 6 00:40:26 2013

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

connected to target database: ROGER (DBID=2525832133, not open)

8.注册归档日志
RMAN> catalog start with '/oradata/arch1';

using target database control file instead of recovery catalog
searching for all files that match the pattern /oradata/arch1

List of Files Unknown to the Database
=====================================
File Name: /oradata/arch1/1_27_901846980.dbf
File Name: /oradata/arch1/1_29_901846980.dbf
File Name: /oradata/arch1/1_37_901846980.dbf
File Name: /oradata/arch1/1_16_901846980.dbf
File Name: /oradata/arch1/1_32_901846980.dbf
File Name: /oradata/arch1/1_26_901846980.dbf
File Name: /oradata/arch1/1_24_901846980.dbf
File Name: /oradata/arch1/1_25_901846980.dbf
File Name: /oradata/arch1/1_33_901846980.dbf
File Name: /oradata/arch1/1_38_901846980.dbf
File Name: /oradata/arch1/1_23_901846980.dbf
File Name: /oradata/arch1/1_20_901846980.dbf
File Name: /oradata/arch1/1_31_901846980.dbf
File Name: /oradata/arch1/1_30_901846980.dbf
File Name: /oradata/arch1/1_21_901846980.dbf
File Name: /oradata/arch1/1_34_901846980.dbf
File Name: /oradata/arch1/1_36_901846980.dbf
File Name: /oradata/arch1/1_22_901846980.dbf
File Name: /oradata/arch1/1_28_901846980.dbf
File Name: /oradata/arch1/1_18_901846980.dbf
File Name: /oradata/arch1/1_35_901846980.dbf
File Name: /oradata/arch1/1_19_901846980.dbf
File Name: /oradata/arch1/1_17_901846980.dbf

Do you really want to catalog the above files (enter YES or NO)? yes
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: /oradata/arch1/1_27_901846980.dbf
File Name: /oradata/arch1/1_29_901846980.dbf
File Name: /oradata/arch1/1_37_901846980.dbf
File Name: /oradata/arch1/1_16_901846980.dbf
File Name: /oradata/arch1/1_32_901846980.dbf
File Name: /oradata/arch1/1_26_901846980.dbf
File Name: /oradata/arch1/1_24_901846980.dbf
File Name: /oradata/arch1/1_25_901846980.dbf
File Name: /oradata/arch1/1_33_901846980.dbf
File Name: /oradata/arch1/1_38_901846980.dbf
File Name: /oradata/arch1/1_23_901846980.dbf
File Name: /oradata/arch1/1_20_901846980.dbf
File Name: /oradata/arch1/1_31_901846980.dbf
File Name: /oradata/arch1/1_30_901846980.dbf
File Name: /oradata/arch1/1_21_901846980.dbf
File Name: /oradata/arch1/1_34_901846980.dbf
File Name: /oradata/arch1/1_36_901846980.dbf
File Name: /oradata/arch1/1_22_901846980.dbf
File Name: /oradata/arch1/1_28_901846980.dbf
File Name: /oradata/arch1/1_18_901846980.dbf
File Name: /oradata/arch1/1_35_901846980.dbf
File Name: /oradata/arch1/1_19_901846980.dbf
File Name: /oradata/arch1/1_17_901846980.dbf


9.怎么找到这个点？

col SEQUENCE# format a40;
col name format a70;
SQL> col first_change# clear;
SQL> col next_change# clear;
SQL> select SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE#,name from v$archived_log where name like '/oradata/arch%' order by 2;

SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# NAME
-----------------------------------------------------------------
     16       215824       215997 /oradata/arch/1_16_901846980.dbf
     17       215997       216209 /oradata/arch/1_17_901846980.dbf
     18       216209       216218 /oradata/arch/1_18_901846980.dbf
     19       216218       216227 /oradata/arch/1_19_901846980.dbf
     20       216227       216235 /oradata/arch/1_20_901846980.dbf
     21       216235       216833 /oradata/arch/1_21_901846980.dbf
     22       216833       216930 /oradata/arch/1_22_901846980.dbf
     23       216930       225589 /oradata/arch/1_23_901846980.dbf
     24       225589       226527 /oradata/arch/1_24_901846980.dbf
     25       226527       226530 /oradata/arch/1_25_901846980.dbf
     26       226530       226533 /oradata/arch/1_26_901846980.dbf
     27       226533       226536 /oradata/arch/1_27_901846980.dbf
     28       226536       226539 /oradata/arch/1_28_901846980.dbf
     29       226539       226542 /oradata/arch/1_29_901846980.dbf
     30       226542       226562 /oradata/arch/1_30_901846980.dbf
     31       226562       226860 /oradata/arch/1_31_901846980.dbf
     32       226860       226881 /oradata/arch/1_32_901846980.dbf
     33       226881       249787 /oradata/arch/1_33_901846980.dbf
     34       249787       249883 /oradata/arch/1_34_901846980.dbf
     35       249883       249892 /oradata/arch/1_35_901846980.dbf
     36       249892       249901 /oradata/arch/1_36_901846980.dbf
     37       249901       249909 /oradata/arch/1_37_901846980.dbf
     38       249909       249939 /oradata/arch/1_38_901846980.dbf
    
SQL>

RMAN>  run {
set until scn 249939;
sql 'alter database datafile 1,2,3,4 online';
recover database skip forever tablespace users01;
}
recovery过程中可以临时将某个暂无法恢复出来的tablespace skip掉，先恢复其它部分，
待recovery database完成并open database后，再recover这个被skip掉的表空间;

executing command: SET until clause

sql statement: alter database datafile 1,2,3,4 online

Starting recover at 23-JAN-16
using channel ORA_DISK_1

starting media recovery

archived log for thread 1 with sequence 34 is already on disk as file /oradata/arch1/1_34_901846980.dbf
archived log for thread 1 with sequence 35 is already on disk as file /oradata/arch1/1_35_901846980.dbf
archived log for thread 1 with sequence 36 is already on disk as file /oradata/arch1/1_36_901846980.dbf
archived log for thread 1 with sequence 37 is already on disk as file /oradata/node1/redo01.log
archived log for thread 1 with sequence 38 is already on disk as file /oradata/node1/redo02.log
archived log file name=/oradata/arch1/1_34_901846980.dbf thread=1 sequence=34
archived log file name=/oradata/arch1/1_35_901846980.dbf thread=1 sequence=35
archived log file name=/oradata/arch1/1_36_901846980.dbf thread=1 sequence=36
archived log file name=/oradata/node1/redo01.log thread=1 sequence=37
archived log file name=/oradata/node1/redo02.log thread=1 sequence=38
media recovery complete, elapsed time: 00:00:00
Finished recover at 23-JAN-16



10. 查看logfile路径
SQL> select member from v$logfile;

MEMBER
--------------------------------------------------------------------------------
/oradata/node1/redo01.log
/oradata/node1/redo02.log
/oradata/node1/redo03.log


11.修改logfile路径

SQL> alter database rename file '/oradata/node1/redo01.log' to '/oradata/node1new/redo01.log';

Database altered.

SQL> alter database rename file '/oradata/node1/redo02.log' to '/oradata/node1new/redo02.log';

Database altered.

SQL> alter database rename file '/oradata/node1/redo03.log' to '/oradata/node1new/redo03.log';

Database altered.

12.查看并修改temp的路径

SQL> select name from v$tempfile;

NAME
-----------------------------------
/oradata/node1/temp01.dbf

SQL> alter database rename file '/oradata/node1/temp01.dbf' to '/oradata/node1new/temp01.dbf';

Database altered.

13.打开数据库

SQL> alter database open read only;

Database altered.

SQL> conn zw/zw
Connected.
SQL> select count(*) from t1;

  COUNT(*)
----------
      1204

SQL> exit
可以看到t1表已经恢复出来了

14.导出恢复出来的表数据
[oracle@node1 /]$ exp zw/zw file=/home/oracle/exp_t1.dmp tables=t1 direct=y



15. 查看之前实例的表，可以看到没有t1表
SQL> select count(*) from t1;
select count(*) from t1
                     *
ERROR at line 1:
ORA-00942: table or view does not exist

16.导入数据
[oracle@node1 arch1]$ imp  zw/zw file=/home/oracle/exp_t1.dmp tables=t1;


SQL> conn zw/zw
Connected.
SQL> select count(*) from t1;

  COUNT(*)
----------
      1204
到此为止drop的表已经恢复成功！
zw_hard
关注
专栏目录
oracle rman恢复单表,RMAN恢复单个表空间或被DROP/DELETE/TRUNCATE的表
weixin_33634341的博客
04-07 1253
1、初始化数据JZH@jzh>create table t as select * from dba_objects;Table created.JZH@jzh>select count(*) from t;COUNT(*)----------74756JZH@jzh>select bytes/1024/1024 from dba_segments where segment_n...
oracle truncate 数据恢复 Oracle 数据库误truncate table恢复过程
ORACLE数据库数据恢复、性能优化、故障诊断来问问MACLEAN
08-02 1809
关于如何在Oracle 12c 数据库中，使用RMAN恢复被DROP / TRUNCATE / DELETE的表的方法 可用版本: Oracle Database - Enterprise Edition - Version 12.1.0.1及之后版本目的： 说明12c关于从RMAN备份中恢复表的新特性 示例:  RMAN> recover table pd.t1 OF PLUGG...
oracle中truncate table后的数据恢复
07-13
NULL 博文链接：https://steve-111.iteye.com/blog/750326
Drop、Delete与Trunc 的区别和应用
最新发布
promise524的博客
08-22 898
详解 drop delete trunc 区别及恢复
Oracle-truncate误删数据恢复
sinat_36757755的博客
10-16 3711
truncate操作误删数据之后想恢复数据通常比较困难，因为truncate操作属于ddl操作无法使用直接undo闪回查询方式恢复数据，并且由于空间大小、备份时间以及变更操作不规范原因，往往在执行操作之前没有对表进行CTAS备份或者其他有效的逻辑备份导致恢复truncate的误删数据困难。
Oracle数据库中truncate命令和delete命令的区别
Husc2009的专栏
07-28 1540
首先讲一下，truncate命令： 语法：TRUNCATE  TABLE  table; 表格里的数据被清空，存储空间被释放。 运行后会自动提交，包括之前其它未提交的会话，因而一旦清空无法回退。 只有表格的创建者或者其他拥有删除任意表格权限的用户（如DBA）才能清空表格。 TRUNCATE  TABLE  dept30; Table truncated. --------------
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给用户授权truncatetable的实现方案
09-09
然而，Oracle不支持直接为用户授予针对单个表的`TRUNCATE`权限，而是通常将更广泛的`DROP ANY TABLE`权限赋予用户，但这可能会带来安全隐患。本文将探讨两种实现为用户授权`TRUNCATE TABLE`的方案，以确保安全性和可...
oracle容灾之truncate数据恢复
baomw的博客
11-22 2558
在我的另外几篇文章中，介绍了关于数据库闪回的一些内容，对于drop和delete的数据闪回。对于truncate，可能有一些数据库知识的应该会知道，在正常逻辑中，如果我们将表truncate掉了，是找不回来了，TRUNCATE TABLE 是一次性地从表中删除所有的数据并不把单独的删除操作记录记入日志保存，删除行是不能恢复的。并且在删除的过程中不会激活与表有关的删除触发器。执行速度快。 那么问题来...
ORACLE truncate 数据恢复
01-16
因自己前段时间因truncate一张表无法找回，且数据超过60W，平常的企业软件超过1W收费，故整理此内容，希望和我遇到同样问题的新手有帮助
Truncate表恢复(无备份情况下)
07-18
Truncate 不会逐个清除用户数据块上的数据，而仅仅重置数据字典和元数据块上的元数据（如存储断头和扩展段图）。 也就是说，此时，基本数据表并未破坏，而是被系统回收，等待被重新分配—因此，要恢复被truncate的数据，需要及时备份所在的数据文件。
【数据库数据恢复】oracle数据库执行truncate table的数据恢复案例
beiya123的博客
12-27 1101
数据库恢复环境： 操作系统：windows server； 数据库：win_oracle_x64。 数据库故障&分析： oracle数据库误truncate table，备份无法使用。 oracle数据库误操作导致数据丢失是比较常见的一种故障，如果有备份只需要恢复备份数据即可，我们中心数据恢复工程师接到的case多是无备份或者备份无法使用、还原报错等。
Oracle中truncate删除的数据还能找到？
bisal的专栏
11-14 744
Oracle的truncate删除数据操作，不会写日志，不产生回滚段，因此执行速度快，相当于Windows的shift+del，不经回收站直接删除。如果想找回truncate删除的数据，常规的可以采用这几种方案，（1）使用数据泵导入。操作简单，但是前提必须要有备份可用，并且会有数据的丢失。（2）使用RMAN进行不完全恢复。前提是开启备份，可将数据库恢复到truncate之前的时刻，但是恢复时间较长...
Oracle表被truncate（截断），该如何恢复？
weixin_46007404的博客
06-29 3835
保姆级 Oracle数据库表截断使用PRM恢复，仅需system表空间和被截数据库表所在表空间就可以
oracle truncate表后恢复方法总结
sqlora的专栏
02-15 4523
truncate表后恢复方法总结 1.1 BLOG文档结构图 1.2 前言部分 1.2.1 导读和注意事项 各位技术爱好者，看完本文后，你可以掌握如下的技能，也可以学到一些其它你所不知道的知识，~O(∩_∩)O~： ① truncate操作后的恢复方法（重点） Tips： ① 若文章代码格式有错乱，推荐使用QQ、搜狗或360浏览器，也可以下载pdf格式的文档来查看，pdf文档下载地址：http://yunpan.cn/cdEQedhCs2kFz （提取...
Oracle Truncate表恢复(ODU)
ckth47350的博客
12-29 232
Oracle Truncate表恢复(ODU) 从3.0.7版本开始，恢复Truncate表更方便，只需要执行下面的步骤: · (1)OFFLINE表所在的表空间 ...
在Oracle中，truncate table操作和drop table操作在效率上有区别吗
07-12
在Oracle中，TRUNCATE TABLE和DROP TABLE是两种不同的操作，它们在效率和行为上存在一些区别。 1. 效率方面： - TRUNCATE TABLE操作通常比DROP TABLE操作更快。TRUNCATE TABLE是一种快速删除表中数据的方式，它通过释放表空间来实现删除。它不会写入事务日志，并且不会激活触发器。这使得TRUNCATE TABLE比DELETE或DROP TABLE操作更高效。 - DROP TABLE操作会完全删除整个表及其相关的对象，包括索引、触发器、约束、依赖关系等。删除表及其所有对象可能会涉及较多的I/O操作和元数据更新，因此在处理大型表时可能会比TRUNCATE TABLE操作慢一些。 2. 行为方面： - TRUNCATE TABLE操作仅删除表中的数据，而保留表结构、约束、索引等定义。因此，执行TRUNCATE TABLE后，表结构和相关对象仍然存在，可以直接重新插入数据。 - DROP TABLE操作会完全删除整个表及其相关的对象，包括表结构、约束、索引等。执行DROP TABLE后，表及其相关对象将不再存在，需要重新创建表才能重新插入数据。 根据具体情况，选择TRUNCATE TABLE或DROP TABLE操作取决于你的需求。如果只需要删除表中的数据而保留表结构，TRUNCATE TABLE是更合适的选择。如果需要完全删除表及其相关对象，包括表结构，那么DROP TABLE是必要的。在处理大型表时，TRUNCATE TABLE通常比DROP TABLE更高效。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值