Oracle 数据文件误删除的不完全恢复

应用环境: 我的一个表被人不小心误删除了,这时候,我不可以把整个库都恢复回去,那样太麻烦了。

所以现在我就从新到一个新库,只将这一个数据文件拷贝过来恢复。

那我们Oracle在恢复文件的时候是不可以只恢复一部分数据文件的,因为oracle  要保证数据文件块头信息一致,所以如果我们要恢复部分文件的话,就得采取以下这种方法:


可以另起一个库,再把要恢复的数据文件拷贝过来,恢复。(当然不单单是该数据文件,还要包括system表空间,undo表空间)

1)另起一个库很简单,可以搞出参数文件,在参数文件中添加一行*.db_unique_name=‘rt‘和修改控制文件路径。

$ORACLE_SID=rt
sqlplus / as sysdba
>startup nomount pfile=‘/tmp/pfile.ora‘

接着控制文件怎么办呢,

2)当然我们可以将之前备份的数据文件直接恢复到我们配置的参数文件中控制文件的路径。

恢复控制文件:

rman target >  restore controlfile to ‘/u01/app/oracle/oradata/test/rt_con01.ctl‘ from ‘/tmp/FULL_04pe7jue_1_1.bak‘;

那现在可以mount了。

现在是不可以open的,如果你现在open,他就会把原来的logfile 覆盖,那肯定原来的那个库会出问题。

3)我们这里要做的就是先恢复数据文件:

在rman中用到一个newname,首先确定原来的system,undo,还有要恢复的表空间文件号。

run {
allocate channel di type disk;
set newname for datafile 1 to ‘/tmp/disk1/system01.dbf‘;
set newname for datafile 3 to ‘/tmp/disk1/undotbs01.dbf‘;
set newname for datafile 9 to ‘/tmp/disk1/test_01.dbf‘;
restore datafile 1,3,9;
}

当然你执行上面会报错,因为我们是新创建的控制文件,所以要注册一下:

rman >catalog start with ‘/tmp/FULL_04pe7jue_1_1.bak‘

4) 然后在主库更改redo日志:

select * from v$log;
    GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME NEXT_CHANGE#
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------------- ------------
NEXT_TIME
-------------------
         1 1 75 52428800 512 2 YES INACTIVE 4215102 2014-07-26:22:18:25 4215195
2014-07-26:22:19:55
         2 1 74 52428800 512 2 YES INACTIVE 4211699 2014-07-26:20:55:55 4215102
2014-07-26:22:18:25
         3 1 76 52428800 512 2 NO CURRENT 4215195 2014-07-26:22:19:55 2.8147E+14

当前正在用的是group  3,那我们可以删除group1;

[email protected]_connect_identifier>alter database drop logfile group 1; 数据库已更改。
[email protected]_connect_identifier>alter database add logfile group 1(‘/u01/app/oracle/oradata/test/mredo01.log‘) size 60m reuse; 数据库已更改。

跟着删除group 2 :

[email protected]_connect_identifier
>
alter database drop logfile group 2; 
数据库已更改。 
[email protected]_connect_identifier
>
alter database add logfile group 2(‘/u01/app/oracle/oradata/test/mredo02.log‘) size 60m reuse; 
数据库已更改。

那3就要跟着切换日志,做完全检查点了:

[email protected]_connect_identifier>select * from v$log;
 GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# ---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------------- ------------ NEXT_TIME ------------------- 1 1 0 62914560 512 1 YES UNUSED 0 0 2 1 
 0 62914560 512 1 YES UNUSED 0 0 3 1 
 76 52428800 512 2 NO CURRENT 4215195 2014-07-26:22:19:55 2.8147E+14

 [email protected]_connect_identifier>alter system switch logfile; 
系统已更改。 
[email protected]_connect_identifier>alter system checkpoint; 
系统已更改。 
[email protected]_connect_identifier>alter database drop logfile group 3; 
数据库已更改。 
[email protected]_connect_identifier>alter database add logfile group 3(‘/u01/app/oracle/oradata/test/mredo03.log‘)size 60m reuse;
 数据库已更改。

将备库中不用数据文件更改掉

alter database datafile 2 offline drop;

alter database datafile 4 offline drop;

alter database datafile 5 offline drop;

alter database datafile 6 offline drop;

alter database datafile 8 offline drop;

alter database datafile 10 offline drop;

6)备库更改数据文件路径和归档日志文件路径:

[email protected]_connect_identifier>alter database rename file ‘/u01/app/oracle/oradata/test/system01.dbf‘ to ‘/tmp/disk1/system01.dbf‘ 2 ; 
数据库已更改。 

[email protected]_connect_identifier>alter database rename file ‘/u01/app/oracle/oradata/test/undotbs01.dbf‘ to ‘/tmp/disk1/undotbs01.dbf‘;
 数据库已更改。 
 
 [email protected]_connect_identifier>alter database rename file ‘/u01/app/oracle/oradata/test/test_01‘ to ‘/tmp/disk1/test_01.dbf‘; 
 数据库已更改。

 [email protected]_connect_identifier>set LOGSOURCE ‘/tmp/disk1/arch‘;

7)恢复日志文件

[email protected]_connect_identifier
>recover database using BACKUP controlfile until cancel; 
ORA-00279: 更改 4203853 (在 07/24/2014 19:57:38 生成) 对于线程 1 是必需的 ORA-00289: 
建议: /tmp/disk1/arch/1_73_831746264.dbf 
ORA-00280: 更改 4203853 (用于线程 1) 在序列 #73 中

检查数据文件路径,日志文件路径:

[email protected]_connect_identifier
>select * from v$dbfile; 
FILE# NAME 
---------- ---------------------------------------- 
10 /u01/app/oracle/oradata/test/rman01.dbf 
9 /tmp/disk1/test_01.dbf 
8 /tmp/perstat.ora 
6 /home/oracle/trans.dbf 
5 /u01/app/oracle/oradata/test/example01.d 
bf 
4 /u01/app/oracle/oradata/test/users01.dbf 
3 /tmp/disk1/undotbs01.dbf 
2 /u01/app/oracle/oradata/test/sysaux01.db 
f 
FILE# NAME 
---------- ---------------------------------------- 
1 /tmp/disk1/system01.dbf 
已选择9行。

8)打开数据库,任务结束:

[email protected]_connect_identifier
>
alter database open resetlogs; 
数据库已更改。 
[email protected]_connect_identifier
>select * from v$log; 
GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# 
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------------- ------------ 
NEXT_TIME 
------------------- 
1 1 1 52428800 512 2 NO CURRENT 4203854 2014-07-27:12:39:11 2.8147E+14 
2 1 0 52428800 512 2 YES UNUSED 0 0 
3 1 0 52428800 512 2 YES UNUSED 0 0 
[email protected]_connect_identifier
>

Oracle 数据文件误删除的不完全恢复

时间: 2024-10-22 14:39:48

Oracle 数据文件误删除的不完全恢复的相关文章

oracle恢复案例:rename一个数据文件后做不完全恢复

案例:rename一个数据文件后做不完全恢复 SQL>startup mount:   //启动到mount状态 SQL> show parameter control_files    //查看控制文件的位置信息 NAME                                 TYPE        VALUE ------------------------------------ ----------- ------------------------------ contro

收缩Oracle数据文件

最近有网友提到收缩Oracle数据文件的问题,这是DBA经常碰到的一个常见问题.通常我们需要收缩相应的数据文件以减少来自磁盘空间的压力以及提高数据库的整体性能.但这并非对于所有情形都是适用的,尤其是生产环境.因为生产环境数据清洗相当较少,因此空间浪费也比较小,而且一旦收缩之后又要重新自动扩展数据文件,浪费系统资源.对于UAT,DEV环境,多DB,磁盘空间压力大的情形,收缩一下非常有必要.勒紧裤带过日子也是常有的事情,哈哈.总之收缩数据文件会使得磁盘空间得以释放以及加快数据迁移,RMAN备份等.本

第13章 oracle 数据文件

2015-10-23 目录 参考资料 [1] 林树泽.Oracle 11g R2 DBA操作指南[M].北京:清华大学出版社,2013 [2] oracle 数据文件管理 [3] 数据文件管理—oracle管理指南 [4] Oracle控制文件.数据文件.临时文件总结笔记 [5] 修改oracle数据文件大小 [6] Oracle删除数据文件 [7] oracle数据文件迁移 [8] Oracle 数据库/表空间/数据文件之间的关系 [9] Oracle数据文件和临时文件的管理

Oracle数据文件物理删除后的恢复

做系统管理的都是这样,难免会误删文件,某天要是把某个Oracle数据文件删除,那该如何恢复呢?(这里数据库是OPEN的,并且未关闭) 建立测试表空间 创建测试用户 插入测试数据 删除数据文件 恢复数据库文件 建立测试表空间 SQL> select name from v$datafile; NAME -------------------------------------------------------------------------------- /opt/oracle/oradat

Oracle DBA的神器: PRM恢复工具,可脱离Oracle软件运行,直接读取Oracle数据文件中的数据

PRM 全称为ParnassusData Recovery Manager ,由 诗檀软件自主研发,拥有独立的软件著作权. PRM可以独立于Oracle软件运行,直接从Oracle数据文件中抽取表上的数据. 当以下几种场景中,都可以用上PRM: 无备份或者备份不可用情况下,数据表被意外truncate掉或者DROP掉 由于数据库损坏,导致的数据打不开 无法OPEN 数据块存在损坏,Oracle无法读取出数据 数据文件存在损坏,或者数据文件头信息不一致 等等 以上这些问题中,用户均可以考虑使用PR

在线移动oracle 数据文件位置

    在线移动oracle 数据文件 Oracle数据文件可以在数据库OPEN的时候被重命名或移动,但此时表空间必须为只读,这将允许用户从表中查询,但禁止他们这样做的插入,更新和删除,在表空间至于只读状态的时候,冻结数据文件块头.阻止更新数据文件块头,此时才能在线拷贝数据文件 <注:system表空间除外,system 表空间无法offline> 本测试以TEST表空间为例 SQL> select * from v$version; BANNER -------------------

Linux下Oracle 数据文件被物理误删除的恢复

#加深对Linux句柄的理解/紧急情况下Oracle的快速恢复 不同于从Oracle中drop掉数据文件,在某些情况下,可能会遇到数据库在运行时数据文件在操作系统级别被删除,而此时Oracle实例并未崩溃,仍然处于open状态.此时就要求尽量在最小的影响下最高效率地完成恢复.现将恢复过程整理出来,以备不时之需. <<过程模拟>> <STEP 1>模拟删除 [email protected] >select name from v$datafile; NAME --

误删 oracle 数据文件的恢复

虽然一再小心,但是还是发生人为误删除数据库文件.简单步骤,或许关键时刻可以帮大忙.   环境:CENTOS 6.5 模拟误操作: 数据库在正常运行,人工直接rm 掉了数据文件. --1.测试环境情况: $ cat /etc/redhat-release CentOS release 6.5 (Final) select file_name from dba_data_files; /u01/app/oracle/oradata/orcl/test.dbf $ sqlplus / as sysdb

Linux 平台下 误删 oracle 数据文件的恢复方法

1  问题描述 之前写过一篇删除oracle home目录的blog,参考: Linux 平台误删 home oracle 根目录的解决方法 http://blog.csdn.net/tianlesoftware/article/details/43794273 本篇是这边的引深,本来应该是年前整理的,拖到年后了. 模拟现状: 数据库在正常运行,误操作,直接rm 掉了数据文件. 测试环境: [[email protected] trace]$ cat /etc/redhat-release Re