RMAN备份恢复 ORA-15005

今天搭建ADG环境时,在restore数据文件环节,给数据库文件的重命名错误,导致产生了两个相同的数据文件名,因此在恢复时产生生了报错,下面是我的处理思路:

查看恢复报错日志,定位是哪个数据文件出现了异常:

channel c3: restoring datafile 00039 to +DATA/crmdb/system02.dbf
channel c3: restoring datafile 00043 to +DATA/crmdb/hswealth_data01.dbf
channel c3: reading from backup piece /home/oracle/rmanbak/db_CRMDB_20221111_0b1ciqqk_1_1
channel c4: starting datafile backup set restore
channel c4: specifying datafile(s) to restore from backup set
channel c4: restoring datafile 00018 to +DATA/crmdb/message_hindex01.dbf
channel c4: restoring datafile 00025 to +DATA/crmdb/crm_table02.dbf
channel c4: restoring datafile 00034 to +DATA/crmdb/fund_table06.dbf
channel c4: restoring datafile 00038 to +DATA/crmdb/fund_index04.dbf
channel c4: reading from backup piece /home/oracle/rmanbak/db_CRMDB_20221111_0c1ciqqk_1_1
channel c2: ORA-19870: error while restoring backup piece /backup/rmanbak/db_CRMDB_20221111_0e1ciqtt_1_1
ORA-19504: failed to create file "+DATA/crmdb/fund_table04.dbf"
ORA-17502: ksfdcre:4 Failed to create file +DATA/crmdb/fund_table04.dbf
ORA-15005: name "crmdb/fund_table04.dbf" is already used by an existing alias

....

failover to previous backup

released channel: c1
released channel: c2
released channel: c3
released channel: c4
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 11/11/2022 18:17:48
RMAN-06026: some targets not found - aborting restore
RMAN-06100: no channel to restore a backup or copy of datafile 42
RMAN-06100: no channel to restore a backup or copy of datafile 37
RMAN-06100: no channel to restore a backup or copy of datafile 33
RMAN-06100: no channel to restore a backup or copy of datafile 16
 

已经数据文件‘+DATA/crmdb/fund_table04.dbf’ 无法再继续创建,可知有两个重复的数据文件名,并且得知该四个数据文件都没有恢复成功。

先通过查看restore脚本cat restore.sh | grep 04  发现确实有两句相同的sql。

已经恢复失败的数据文件的名字,现在去定位该数据文件在哪个备份片当中:

RMAN> list backupset;

BS Key  Type LV Size
------- ---- -- ----------
13277   Full    813.16M
  List of Datafiles in backup set 13277
  File LV Type Ckp SCN    Ckp Time  Name
  ---- -- ---- ---------- --------- ----
  16      Full 14961414035 11-NOV-22 +DATADG/crmdb/datafile/fund_index.308.1039080835
  33      Full 14961414035 11-NOV-22 +DATADG/crmdb/datafile/fund_table.332.1039093283
  37      Full 14961414035 11-NOV-22 +DATADG/crmdb/datafile/fund_index.336.1039093313
  42      Full 14961414035 11-NOV-22 +DATADG/crmdb/datafile/undotbs2.347.1039094345

  Backup Set Copy #1 of backup set 13277
  Device Type Elapsed Time Completion Time Compressed Tag
  ----------- ------------ --------------- ---------- ---
  DISK        00:01:27     11-NOV-22       YES        TAG20221111T170107

    List of Backup Pieces for backup set 13277 Copy #1
    BP Key  Pc# Status      Piece Name
    ------- --- ----------- ----------
    13277   1   AVAILABLE   /home/oracle/rmanbak/db_CRMDB_20221111_0e1ciqtt_1_1

  Backup Set Copy #2 of backup set 13277
  Device Type Elapsed Time Completion Time Compressed Tag
  ----------- ------------ --------------- ---------- ---
  DISK        00:01:27     11-NOV-22       YES        TAG20221111T170107

    List of Backup Pieces for backup set 13277 Copy #2
    BP Key  Pc# Status      Piece Name
    ------- --- ----------- ----------
    13295   1   AVAILABLE   /backup/rmanbak/db_CRMDB_20221111_0e1ciqtt_1_1

此时定位完毕,从恢复脚本中找到这四个数据文件相关的语句,进行重新恢复:

RMAN >

run { 
2> set newname for datafile 33 to '+DATA/crmdb/fund_table05.dbf';
3> set newname for datafile 16 to '+DATA/crmdb/fund_index01.dbf';
4> set newname for datafile 37 to '+DATA/crmdb/fund_index03.dbf';
5> set newname for datafile 42 to '+DATA/crmdb/undotbs2_02.dbf';
6> restore datafile 33;
7> restore datafile 16;
8> restore datafile 37;
9> restore datafile 42;
10> switch datafile all;
11> } 

恢复完成后

查看alert日志发现,数据文件的路径并没有修改,因为在第一次恢复restore脚本执行的恢复失败后,并没有进行switch datafile  all 的操作,因此手动执行一遍,此时控制文件中数据文件的路径都已经更新了。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
RMAN学习测试整理1 20121219 by Apollo 一、 Oracle数据库备份分为物理备份和逻辑备份。今天测试整理下物理备份Rman,也就是oracle恢复管理器(Recovery Manager)。 毕竟逻辑备份是不能实现时间点恢复的,所以生产数据库肯定用物理备份来保证灾难时能够恢复。 二、 Rman备份的前提条件:数据库需要运行在归档模式下 (1) 查看oracle数据库的archivelog mode的方式 sqlplus / as sysdba ##需要as sysdba登录,不然即使有dba权限也fail archive log list ##方式一 select name,log_mode from v$database; ##方式二 (2) 由非归档切换到归档模式 shutdown immediate startup mount alter database archivelog; alter database open; (3) 反之由归档切换到非归档模式 shutdown immediate startup mount alter database noarchivelog; ##切换到非归档 alter database open; (4) 其实oracle安装好后会默认运行在非归档模式下(安装时有开关勾选),其配置文件为init.ora,可以通过修改init.ora来调整。 sqlplus oracle/oracle show parameter spfile ##spfile和init.ora一般在一个路径下 exit cd $ORACLE_HOME/dbs vi init.ora (5) init.ora关于archive的参数 log_archive_start = true 启动自动归档 log_archive_dest = disk$rdbms:[oracle.archive] 归档日志路径 log_archive_format = “T%TS%S.ARC” 归档日志格式 三、 启用数据库备份模式 (1) 查看当前情况 select * from v$backup; select * from v$log select * from v$datafile_header (2) 整库开启备份模式alter database begin backup; 哦,忘记开启归档了。奔3的人老了呀。(非一致性备份必须开启归档) (3) 指定某个表空间开启备份模式 alter tablespace tablespace_name begin backup; 先建个tbs_apollo_backup的表空间吧: 靠,/opt下剩余只有649M,先给个200M吧,回头再从根目录划分一些出来。 create tablespace tbs_apollo_backup datafile '/opt/oracle/oradata/orcl/tbs_apollo_backup.dbf' size 200M 因为之前做了database begin backup,所有表空间都处于backup状态了。将database的backup停掉重新指定tablespace备份。 再次查看各个tablespace的backup情况 select a.tablespace_name,b.status as backup_status,a.file#, a. ts#,a.recover,a.status as on_off_status,a.name from v$datafile_header a ,v$backup b where a.file# = b.file# 四、 RMAN相关使用 1、 RMAN连接到Target Database (1) 分步进行 rman nocatlog(nocatalog会将相关备份信息即元数据放在Contronfile里面) connect target / (不像DB2那样connect to,就connect就OK了) (2) 一步到位 rman nocatlog target system/manger 权限不足,使用rman连接target的话需要sysdba权限而不是dba。 I 查看是否拥有sysdba权限 select * from v$pwfile_users; 备注:常用的查看权限视图 select * from dba_users where username='SYSTEM' select * from dba_role_privs where grantee='SYSTEM'; select * from v$pwfile_users; ii 用sys用户授予system用户sysdba权限(其实是一个角色) iii 用system用户再次连接target database (3) 可以在rman里面停起数据库(停库状态需要隐式登录,不能带网络服务名) (4) DataFile tbs_apollo_backup.dbf异常了,先解决下 alter database datafile ‘datafile_name’ offline; recover datafile ‘datafile_name’ alter database datafile ‘datafile_name’ online; alter database open; 再次在Rman里面操作停起数据库(sql_statement用单引号或双引号括起) 2、 List命令查看备份集(在数据库控制文件或恢复目录中查询备份的历史信息的方法) (1) 查看数据库所有的备份集合 list backupset; (2) 查看指定TableSpace的备份 list copy of tablespace “TBS_APOLLO_BACKUP” list backupset of tablespace "TBS_APOLLO_BACKUP"; (3) 查看指定DataFile的备份 list backupset of datafile "/opt/oracle/oradata/orcl/users01.dbf"; (4) 查看备份汇总 list backup summary; (5) 3、 Report命令报告备份情况(判断数据库当前可恢复状态和提供数据库备份的信息) (1) report schema;(报告数据库结构) (2) report need backup;(报告需要备份的内容) (3) report obsolete(Which backups can be deleted ?)报告过期备份 (4) report unrecoberable(Which files are unrecoverable ?) 4、 CONFIGURE配置Rman参数 (1) show all命令查看所有配置 (2) CONFIGURE命令修改配置 ControlFile太重要了,一般都设置备份它 五、 准备下数据库对象 1、 临时表空间 create temporary tablespace apollo_temp tempfile ‘/opt/app/oracle/oradata/orcl_apollo/Apollo_temp.dbf’ size 200m autoextend on next 50m maxsize 2048m extent management local; 2、 创建数据表空间 create tablespace apollo_data logging datafile ‘/opt/app/oracle/oradata/orcl_apollo/apollo_data.dbf’ size 1g autoextend on next 50m maxsize 4096m extent management local; 备注:引用的字符串如这里的单引号在copy时异常。 3、 创建用户并指定表空间 create user rman identified by rman default tablespace apollo_data temporary tablespace apollo_temp; 4、 给用户授权 grant connect ,resource to rman; 5、 其他如table、index、function、procedure、view、sequence等。 六、 Rman备份的对象(主要包括Database、Tablespace、Datafile、Controlfile和Archivelog) Rman不能备份口令文件和初始化参数文件(也就是前面提到的init.ora)。 1、 备份DataBase backup database; backup database是一次全备份,其实省略的很多参数,相当于用的默认的。而备份好的备份集放在哪里呢? 在sqlplus里面执行show parameter db_recovery_file_dest; 查看备份后情况: list backupset; 2、 备份Tablespace backup tablespace apollo_data; RMAN-06554: WARNING: file 5 is in backup mode 该警告提示file5也就是这个表空间的备份其实已经存在了,因为刚做过full backup了嘛。 查看备份集合新增了3和4两个备份集 3、 备份Datafile backup datafile '/opt/app/oracle/oradata/orcl_apollo/system01.dbf'; 也可backup datafile 4 这里的4对应第四个datafile,可由report schema报告得知是:user01.dbf 测试备份的有点多,那么可以删除一些过期的备份。 (1) 通过删除备份集删除 (2) 通过删除备份片删除 (3) 当然直接删除全部过期更加直接 delete obsolete; (4) 删除后无过期备份存在 4、 备份Controlfile (1) 自动备份控制文件如前面示例show all后修改的参数 CONFIGURE CONTROLFILE AUTOBACKUP ON; 那么每次备份会自动备份控制文件。 (2) 手动备份控制文件 backup current controlfile; (3) 列出备份过的controlfile list backup of controlfile; 有14、15、16三个备份集里面有,那么肯定有过期的了,再验证下 report obsolete; 14和15作为过期的报告出来,16为最新的备份。 5、 备份Archivelog (1) 备份数据库时使用参数plus archivelog自动备份 backup database plus archivelog;(我们清空所有备份delete backup后重头来) (2) 手工备份 backup archivelog all; 6、 备份spfile (1) 备份时自动备份spfile CONFIGURE CONTROLFILE AUTOBACKUP ON在备份控制文件时页备份spfile (2) 手动备份 备份的spfile同样放到backupset目录下面 7、 七、 恢复数据库 1、 模拟datafile丢失或损坏进行恢复 cd $ORACLE_BASE/oradata/orcl_apollo mv ./apollo_data.dbf /home/oracle/backup/apollo_data.dbf 重启数据库看看 看来破坏了datafile正常停库都不行,需要abort才行。 起库就更不用说了 那么开始真正恢复吧,思路是这样的:由报错可见起库的实例nomount和控制文件的mount都成功了,但是在open database时报错,就需要在mount和open之间恢复。先将datafile置于offline状态,restore和recover后在online,最后在open database就OK了。 (1) 将数据库处于mount模式 (2) 将datafile 1 (即system01.dbf)置于offline (3) restore和recover(所有的铺垫都是为了这两步) restore datafile 1; recover datafile 1; (4) 将datafile 1 置于online (5) alter database open; alter database datafile 2 offline; 2、 模拟tablespace丢失或损坏进行恢复 (1) backup tablespace apollo_data (2) drop tablespace apollo_data 提示表空间非空,查看下里面的内容,是建的一些测试表。 select * from dba_segments where tablespace_name='APOLLO_DATA' and segment_name=’ AMIS_IC_MEMBER’ ; 没关系那就加上including contents选项删除吧 (3) 停库起到mount模式 (4) 进入sqplus将表空间offline alter tablespace apollo_data offline; (5) 进入rman使用restore和recover恢复表空间 restore tablespace apollo_data; recover tablespace apollo_data; 备注:从(4)、(5)开始的执行都没有成功,因为drop表空间后即使在系统表里 面也不再有改表空间的信息,模拟失败待后续研究! (1) 在rman里面备份表空间apollo_data (2) 模拟表空间里面的对象破坏进行恢复吧 select * from dba_segments where tablespace_name='APOLLO_DATA' and (3) alter tablespace apollo_data offline; (4) restore tablespace apollo_data; (5) recover tablespace apollo_data (6) alter tablespace apollo_data online; (7) apollo_data.已经恢复 备注:其实datafile和tablespace的恢复步骤是一样的。 3、 模拟controlfile丢失或损坏进行恢复 (1) 丢失controlfile (2) startup nomount; (3) restore controlfile from $BACKUP_CONTROLFILE_PATH; 如果开启CONFIGURE CONTROLFILE AUTOBACKUP ON;就可以 restore controlfile from autobackup; (4) alter database mount; (5) recover database; (6) alter database open resetlog; 4、 模拟spfile丢失或损坏进行恢复 (1) startup nomount; (2) set dbid 1330128391; (3) store spfile from autobackup; (4) shutdown immediate; (5) set dbid 1330128391; (6) startup; 5、 模拟整个database恢复 (1) startup nomount; (2) restore controlfile form autobakcup; (3) alter database mount; (4) restore database; (5) recover database; (6) alter database open resetlogs 6、 模拟redolog file恢复(其实下面操作在sqlplus里面,不在rman执行) (1) shutdown immediate; (2) startup mount; (3) recover database until cancel; (4) alter database resetlog;
不小心Truncate表的事情也是有的, 其中大部份时因为工具连错了库, 从儿跑错了角本. 遇到这种事情而没有备份时怎么办呢? 首先要停止数据库, 将这个表所在的表空间的文件拷贝出来, 因为Oracle在Truncate只时将相应Segment的第一个块格式化掉了, 而后面的都还存在, 到下次用时到才真正地重新格式化. 下面来讲一个Truncate表后进行恢复的例子: SQL> CREATE TABLE T_TRUNCATE AS SELECT * FROM TAB; Table created. SQL> SELECT COUNT(*) FROM T_TRUNCATE; COUNT(*) ---------- 14 SQL> ALTER SYSTEM CHECKPOINT; System altered. SQL> TRUNCATE TABLE T_TRUNCATE; Table truncated. SQL> ALTER SYSTEM CHECKPOINT; System altered. 在Truncate时只是Segment Header格式化了, 并将Data Object ID换成一个新的值, 我们可以在AUL中用DESC命令来查看: AUL> desc anysql.t_truncate Storage(OBJ#=9976 OBJD=9977 TS=4 FILE=4 BLOCK=5235 CLUSTER=0) No. SEQ INT Column Name Type --- --- --- ----------------------------- ---------------- 1 1 1 TNAME VARCHAR2(30) NOT NULL 2 2 2 TABTYPE VARCHAR2(7) 3 3 3 CLUSTERID NUMBER 要恢复这个表的数据, 首先要在AUL中运行SCAN EXTENT命令, 因为Segment Header被格式化了, 所以Extent Map也可能丢失, 而Scan Extent则将扫描整个数据文件并将Extent分配信息写入AULEXT.TXT文件: AUL> SCAN EXTENT FILE 4 2006-12-18 21:32:10 2006-12-18 21:32:24 恢复的关键是要获得这个表原来的Data Object ID, 在这个例子中我在Truncate表后什么也没有做就关闭数据库进行恢复了. 从上面的DESC命令可以看出表的Segment Header是(4,5235), 而新的Data Object ID是9977, 老的Data Object ID我们可以从Segment Header的后面一个数据块中得到, 如果这个表有几个Free List Group, 则可能还要再后面几个块. 用AUL的ORADUMP命令来看一下后面一个块: AUL> ORADUMP FILE 4 BLOCK 5236 RDBA=0x01001474(4/5236)=16782452,type=0x06,fmt=0xa2,seq=0x02,flag=0x04 seg/obj=0x000026f8=9976,csc=0x0000.0006caf5,itc=3,typ=1 - DATA FLG=0x32, fls=0, nxt=0x01001471(4/5233)=16782449 ...... 可以看到原来的Data Object ID是9976, 现在可以恢复了, 先不指定原来的Data Object ID试试? AUL> unload table anysql.t_truncate; 2006-12-18 21:33:37 Unload OBJD=9977 FILE=4 BLOCK=5235 CLUSTER=0 ... 2006-12-18 21:33:37 接下来指定原来的Data Object ID, 再试试? AUL> unload table anysql.t_truncate object 9976; 2006-12-18 21:33:45 Unload OBJD=9976 FILE=4 BLOCK=5235 CLUSTER=0 ... P_MV_FACT_SALES|TABLE TIME_DIM|TABLE FACT_SALES|TABLE MV_FACT_SALES|TABLE SEG$|TABLE NUMTEST|TABLE T_OBJECTS|TABLE T_LOBTEST|TABLE T_INCLOB|TABLE CF_XXK|TABLE T_TESTDMP|TABLE T_CLOBDEMO|TABLE T_BLOBDEMO|TABLE T_TRUNCATE|TABLE 2006-12-18 21:33:45 可以看到14条数据全回来了, 当然数据库是复杂的, 如果是一个很大的表, 还是不能保证可以100%恢复的. 最近至少看到二次错误地截断(Truncate)表的例子, 并在网上询问如何恢复, 在这儿我给出AUL/MyDUL的解决方案, 下面是我用的一个测试表: ASQL> DESC TRUNCDEMO NO# NAME NULLABLE TYPE --- ----------------- -------- ------------ 1 COL1 VARCHAR2(20) ASQL> SELECT * FROM TRUNCDEMO; COL1 ----- ROW 1 ROW 2 2 rows returned. 接下来我们来截断表, 其实这个操作只是重新格式化了段头块(Segment Header), 并分配一个新的数据对象号(Data Object ID), 当然空间分配信息也改了, 除非加了重用空间选项(Reuse Storage). 来看一下这个操作的前后变化: ASQL> SELECT DATA_OBJECT_ID, OBJECT_NAME FROM USER_OBJECTS; DATA_OBJECT_ID OBJECT_NAME -------------- ----------- 13676 TRUNCDEMO 1 rows returned. ASQL> truncate table truncdemo; Truncate Table Succeed. ASQL> SELECT DATA_OBJECT_ID, OBJECT_NAME FROM USER_OBJECTS; DATA_OBJECT_ID OBJECT_NAME -------------- ----------- 13677 TRUNCDEMO 1 rows returned. 由于在System表空间中已经记录了新的信息, 因此用当前的System信息是不能恢复过来的,在AUL/MyDUL中可以当作没有System时的情况来处理,在下面的命令中, 我们用Truncate后的数据对象号就不能进行恢复, 而使用Truncate以前的就可以, 当然空间不能被重新利用了是恢复的前提. AUL> unload object 13676 column varchar file 4; 2006-09-18 22:38:58 ROW 1 ROW 2 2006-09-18 22:39:04 AUL> unload object 13677 column varchar file 4; 2006-09-18 22:39:10 2006-09-18 22:39:10 AUL> 因此在意外发生Truncate后, 如果没有备份可以恢复, 首先要做的事是备份一下当前的文件, 免得空间被重用. 而Truncate之前的数据对象号在AUL/MyDUL中是很容易找出来的. 到此已经说明了如何恢复Truncate表了. 跟据原理可以创建一个恢复包Recover_Truncate_Data,然后我们可以做个实验进行验证恢复效果如何: 第一步:创建表 create table truntab1 as select * from dba_objects; 第二步:查询表中记录数 select count(*) from truntab1; --72622 第三步:truncate表中业务数据 truncate table truntab1; 第四步:确认表中记录数为零 select count(*) from truntab1; -- 0 第五步:设置恢复前环境变量 set serveroutput on size 10000000 --//设置大点,默认为2000 bytes exec dbms_output.enable(999999999999999999999); --//默认为2000 bytes 注意:如果不不进行设置,为报PLSQL ORA-20000: ORU-10027: buffer overflow, limit of 10000 第六步:实施truncate表中数据恢复 declare tgtowner varchar2(30); tgttable varchar2(30); datapath varchar2(4000); datadir varchar2(30); rects varchar2(30); recfile varchar2(30); rstts varchar2(30); rstfile varchar2(30); blksz number; rectab varchar2(30); rsttab varchar2(30); copyfile varchar2(30); begin tgtowner := 'SYS'; --指定表名的属用户 tgttable := 'TRUNTAB1'; --指定需要恢复的表名 datapath := 'D:\app\Administrator\oradata\lmis\'; --数据文件所在位置 datadir := 'FY_DATA_DIR'; Recover_Truncate_data.prepare_files(tgtowner, tgttable, datapath, datadir, rects, recfile, rstts, rstfile, blksz); Recover_Truncate_data.fill_blocks(tgtowner, tgttable, datadir, rects, recfile, rstts, 8, tgtowner, tgtowner, rectab, rsttab, copyfile); Recover_Truncate_data.recover_table(tgtowner, tgttable, tgtowner, rectab, tgtowner, rsttab, datadir, datadir, recfile,datadir, copyfile, blksz); end; 第七步:查看输出内容和构造表名: 15:32:44: Directory Name: FY_DATA_DIR4 15:32:45: Recover Tablespace: FY_REC_DATA4; Data File: FY_REC_DATA4.DAT 15:32:46: Restore Tablespace: FY_RST_DATA4; Data File: FY_RST_DATA4.DAT 15:32:48: Recover Table: SYS.TRUNTAB1$2 15:32:48: Restore Table: SYS.TRUNTAB1$$2 15:33:04: [fill_blocks] Data Blocks formatted. 15:33:05: [copy_file] begin copy file: FY_DATA_DIR4\FY_REC_DATA4.DAT => FY_DATA_DIR4\FY_REC_DATA_COPY.DAT 15:33:05: [copy_file] completed. 15:33:05: Copy file of Recover Tablespace: FY_REC_DATA_COPY.DAT 15:33:05: begin to recover table SYS.TRUNTAB1 15:33:19: [restore_table] Trying to restore data to SYS.TRUNTAB1$$2 15:33:20: [restore_table] Expected Records in this round: 411 15:33:20: [restore_table] 411 records recovered 此处省略N行输出............................................ 15:33:44: [restore_table] Expected Records in this round: 0 15:33:44: [restore_table] 0 records recovered 15:33:44: 1033 truncated data blocks found. 15:33:44: 72622 records recovered in backup table SYS.TRUNTAB1$$2 15:33:44: Recovery completed. PL/SQL procedure successfully completed 从红色字体可以看出,恢复72622条,刚好是truncate前业务表中记录数,恢复临时表为:SYS.TRUNTAB1$$2 第七步:查看输出内容和构造表名: insert into truntab1 select * from SYS.TRUNTAB1$$2 第八步:验证数据是否完全恢复 select count(*) from truntab1; --72622 至此,truncate掉的数据成功恢复,并且此方法也可以恢复drop table tablename purge删除的数据, 第九步:清理恢复产生的表空间和数据文件 特别提醒:恢复完成后,该方法会在数据库中产生一个表空间:FY_RST_DATA*,恢复一次产生一个,记得及时清理!否则会导致服务器RMAN备份失败ORA-19566 超出损坏块限制(切记) truncate原理: ? ? ? ?TRUNCATE不会逐个清除用户数据块上的数据,而仅仅重置数据字典和元数据块上的元数据(如存储段头和扩展段图)。也就是说,此时,其基本数据并未被破坏,而是被系统回收、等待被重新分配————因此,要恢复被TRUNCATE的数据,需要及时备份其所在的数据文件。 ? ? 方法:用存储过程包Fy_Recover_Data ? ? 它是利用Oracle表扫描机制、数据嫁接机制恢复TRUNCATE或者损坏数据的工具包,这个包是由行内有影响力的DBA大师黄炜先生通过PLSQL编写的,再这里再次感谢他的无私技术分享。Fy_Recover_Data去本文附近中下载 好了,闲话少说,下面通过oracle数据库中scott用户自带的emp表做测试: 步骤1:先把Fy_Recover_Data包拷贝到oracle相关目录下 步骤2:在scott用户下创建test_emp表: SQL> conn scott/tiger; Connected. SQL> select * from tab; TNAME ? ? ? TABTYPE CLUSTERID ------------------------------ ------- ---------- BONUS ? ? ? TABLE DEPT ? ? ? TABLE EMP ? ? ? ? ? ? ? ?TABLE SALGRADE ? ? ? TABLE SQL> select count(*) from emp; ? COUNT(*) ---------- 14 SQL> create table test_emp ?as select * from emp; Table created. SQL> select count(*) from test_emp; ? COUNT(*) ---------- 14 步骤3:用truncate删除test_emp表: SQL> truncate table test_emp; Table truncated. SQL> select count(*) from test_emp; ? COUNT(*) ---------- 0 步骤4:在linux中的oracle用户下解压FY_Recover_Data.zip包 $ unzip FY_Recover_Data.zip Archive: ?FY_Recover_Data.zip ? inflating: FY_Recover_Data.SQL? 步骤5:恢复 1)在sys用户下执行存储过程 SQL> @/home/oracle/FY_Recover_Data.SQL Package created. Package body created. 2)查看test_emp表在数据文件中的目录 SQL> select file_name from dba_data_files f, dba_tables t where t.owner='SCOTT' and t.table_name='TEST_EMP' and t.tablespace_name = f.tablespace_name; FILE_NAME -------------------------------------------------------------------------------- /u03/oracle/oradata/WUTONG/datafile/o1_mf_users_cx3xt940_.dbf 3)通过脚本恢复,可以用sqlplus命令行或者plsql developer执行 declare ? ? ? tgtowner varchar2(30); ? ? ? tgttable varchar2(30); ? ? ? datapath varchar2(4000); ? ? ? datadir varchar2(30); ? ? ? rects varchar2(30); ? ? ? recfile varchar2(30); ? ? ? rstts varchar2(30); ? ? ? rstfile varchar2(30); ? ? ?blksz number; ? ? ?rectab varchar2(30); ? ? ?rsttab varchar2(30); ? ? ?copyfile varchar2(30); ? ?begin ? ? ?tgtowner := 'SCOTT'; --table owner ? ? ?tgttable := 'TEST_EMP'; ?--table name ? ? ?datapath := '/u03/oracle/oradata/WUTONG/datafile/'; ? ?--必须和test.t1表所在的数据文件的目录相同 ? ? ?datadir := 'FY_DATA_DIR'; ? ? ? ?--oracle中目录的名字,可以修改 ? ? ?Fy_Recover_data.prepare_files(tgtowner, tgttable, datapath, datadir, rects, recfile, rstts, rstfile, blksz); ? ? ?Fy_Recover_data.fill_blocks(tgtowner, tgttable, datadir, rects, recfile, rstts, 8, tgtowner, tgtowner, rectab, rsttab, copyfile); ? ? ?Fy_Recover_data.recover_table(tgtowner, tgttable, tgtowner, rectab, tgtowner, rsttab, datadir, datadir, recfile,datadir, copyfile, blksz); ? ?end; ? ?以上SQL脚本产生2个表空间(2个数据文件),还有1个copy文件。 4)切换到scott用户下查看会发现多了些不一样以test_emp的表,这时找到相关有数据的表,把数据插入原表test_emp SQL> conn scott/tiger Connected. SQL> select * from tab; TNAME ? ? ? TABTYPE CLUSTERID ------------------------------ ------- ---------- BONUS ? ? ? TABLE DEPT ? ? ? TABLE EMP ? ? ? TABLE SALGRADE ? ? ? TABLE TEST_EMP ? ? ? TABLE TEST_EMP$ ? ? ? TABLE TEST_EMP$$ ? ? ? TABLE 7 rows selected. SQL> insert into test_emp select * from TEST_EMP$$; 14 rows created. SQL> commit; Commit complete. SQL> select count(*) from test_emp; ? COUNT(*) ---------- 14 当你看到这一步的时候,说明truncate的表已经完全恢复了,恭喜你数据恢复成功!紧张的压力随之而释放,脸上露出灿烂的笑容和自豪感(做DBA很辛苦,数据库能保持正常运行,DBA在幕后做了大量的工作,有时是不会不被公司其他人理解的。。。。。) 步骤6:恢复数据后,把恢复时产生的2个表空间删除,再删除对应数据文件 SQL> conn / as sysdba Connected. SQL> select name from v$datafile; NAME -------------------------------------------------------------------------------- /u03/oracle/oradata/WUTONG/datafile/o1_mf_system_cx3xt90z_.dbf /u03/oracle/oradata/WUTONG/datafile/o1_mf_sysaux_cx3xt930_.dbf /u03/oracle/oradata/WUTONG/datafile/o1_mf_undotbs1_cx3xt93b_.dbf /u03/oracle/oradata/WUTONG/datafile/o1_mf_users_cx3xt940_.dbf /u03/oracle/oradata/WUTONG/datafile/o1_mf_wutong_cx415lcj_.dbf /u03/oracle/oradata/WUTONG/datafile/FY_REC_DATA.DAT /u03/oracle/oradata/WUTONG/datafile/FY_RST_DATA.DAT 7 rows selected. SQL>?drop tablespace FY_REC_DATA INCLUDING CONTENTS; Tablespace dropped. SQL>?drop tablespace FY_RST_DATA INCLUDING CONTENTS; Tablespace dropped. SQL> select name from v$datafile; NAME -------------------------------------------------------------------------------- /u03/oracle/oradata/WUTONG/datafile/o1_mf_system_cx3xt90z_.dbf /u03/oracle/oradata/WUTONG/datafile/o1_mf_sysaux_cx3xt930_.dbf /u03/oracle/oradata/WUTONG/datafile/o1_mf_undotbs1_cx3xt93b_.dbf /u03/oracle/oradata/WUTONG/datafile/o1_mf_users_cx3xt940_.dbf /u03/oracle/oradata/WUTONG/datafile/o1_mf_wutong_cx415lcj_.dbf 然后去操作系统下把对应的数据文件删除即可 ---------------------

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值