恢复drop后的表空间

SQL> alter database backup controlfile to ‘/home/oracle/con.ctl‘;  #备份控制文件

Database altered.

#删除后会记录到当前的控制文件中，恢复的时候不可以使用当前的控制文件
SQL> drop tablespace tbs10 including  contents and datafiles;
SQL> drop tablespace tbs11 including  contents and datafiles;

SQL> select file_id,file_name from dba_data_files;

   FILE_ID FILE_NAME
---------- ------------------------------------------------------------------------------------------
         4 +DATA/orcl/datafile/users.272.1033601261
         3 +DATA/orcl/datafile/undotbs1.271.1033601261
         2 +DATA/orcl/datafile/sysaux.270.1033601259
         1 +DATA/orcl/datafile/system.269.1033601257
         5 +DATA/orcl/datafile/example.277.1033601505
         6 +DATA/orcl/datafile/undotbs2.278.1033601957
        10 +DATA/orcl/datafile/gg.293.1036275463
        11 +DATA/orcl/datafile/ogg_2020.259.1033961107

8 rows selected.

SQL> drop tablespace gg including  contents and datafiles;

Tablespace dropped.

SQL> select file_id,file_name from dba_data_files;

   FILE_ID FILE_NAME
---------- ------------------------------------------------------------------------------------------
         4 +DATA/orcl/datafile/users.272.1033601261
         3 +DATA/orcl/datafile/undotbs1.271.1033601261
         2 +DATA/orcl/datafile/sysaux.270.1033601259
         1 +DATA/orcl/datafile/system.269.1033601257
         5 +DATA/orcl/datafile/example.277.1033601505
         6 +DATA/orcl/datafile/undotbs2.278.1033601957
        11 +DATA/orcl/datafile/ogg_2020.259.1033961107

7 rows selected.

SQL>

[[email protected] ~]$ rman target /

Recovery Manager: Release 11.2.0.1.0 - Production on Sat Mar 28 22:42:56 2020

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

connected to target database (not started)

RMAN> 

RMAN> 

RMAN> startup nomount

Oracle instance started

Total System Global Area     835104768 bytes

Fixed Size                     2217952 bytes
Variable Size                809502752 bytes
Database Buffers              20971520 bytes
Redo Buffers                   2412544 bytes

RMAN> restore controlfile from ‘/home/oracle/con.ctl‘;  #利用备份的控制文件进行恢复。
Starting restore at 2020/03/28 22:44:04
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=33 instance=orcl1 device type=DISK
channel ORA_DISK_1: copied control file copy
output file name=+DATA/orcl/controlfile/current.273.1033601477
Finished restore at 2020/03/28 22:44:09

RMAN> restore database;

RMAN> alter database mount;
database mounted
released channel: ORA_DISK_1

RMAN> restore database;
Starting restore at 2020/03/28 22:44:52
Starting implicit crosscheck backup at 2020/03/28 22:44:52
allocated channel: ORA_DISK_1
Crosschecked 7 objects
Finished implicit crosscheck backup at 2020/03/28 22:44:56
Starting implicit crosscheck copy at 2020/03/28 22:44:56
using channel ORA_DISK_1
Finished implicit crosscheck copy at 2020/03/28 22:44:56
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 00001 to +DATA/orcl/datafile/system.269.1033601257
channel ORA_DISK_1: restoring datafile 00002 to +DATA/orcl/datafile/sysaux.270.1033601259
channel ORA_DISK_1: restoring datafile 00003 to +DATA/orcl/datafile/undotbs1.271.1033601261
channel ORA_DISK_1: restoring datafile 00004 to +DATA/orcl/datafile/users.272.1033601261
channel ORA_DISK_1: restoring datafile 00005 to +DATA/orcl/datafile/example.277.1033601505
channel ORA_DISK_1: restoring datafile 00006 to +DATA/orcl/datafile/undotbs2.278.1033601957
channel ORA_DISK_1: restoring datafile 00008 to +DATA/orcl/datafile/tbs10.294.1036253653
channel ORA_DISK_1: restoring datafile 00009 to +DATA/orcl/datafile/tbs11.283.1036253831
channel ORA_DISK_1: restoring datafile 00010 to +DATA/orcl/datafile/gg.293.1036275463
channel ORA_DISK_1: restoring datafile 00011 to +DATA/orcl/datafile/ogg_2020.259.1033961107
channel ORA_DISK_1: reading from backup piece +DATA/orcl/backupset/2020_03_28/nnndf0_tag20200328t222242_0.265.1036275763
channel ORA_DISK_1: piece handle=+DATA/orcl/backupset/2020_03_28/nnndf0_tag20200328t222242_0.265.1036275763 tag=TAG20200328T222242
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:02:25
Finished restore at 2020/03/28 22:47:27

RMAN> recover database 

#通过查询alert.log日志得到drop tablespace 。。。语句的时间
RMAN> recover database until time "to_date(‘2020-03-28 22:39:43‘,‘yyyy-mm-dd hh24:mi:ss‘)";

Starting recover at 2020/03/28 22:49:30
using channel ORA_DISK_1
starting media recovery
archived log for thread 1 with sequence 53 is already on disk as file +ARCH/orcl/archivelog/2020_03_28/thread_1_seq_53.312.1036276683
archived log for thread 1 with sequence 54 is already on disk as file +DATA/orcl/onlinelog/group_2.275.1033601485
archived log for thread 1 with sequence 55 is already on disk as file +DATA/orcl/onlinelog/group_1.274.1033601481
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=52
channel ORA_DISK_1: reading from backup piece +DATA/orcl/backupset/2020_03_28/annnf0_tag20200328t222450_0.256.1036275891
channel ORA_DISK_1: piece handle=+DATA/orcl/backupset/2020_03_28/annnf0_tag20200328t222450_0.256.1036275891 tag=TAG20200328T222450
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archived log file name=+ARCH/orcl/archivelog/2020_03_28/thread_1_seq_52.313.1036277389 thread=1 sequence=52
archived log file name=+ARCH/orcl/archivelog/2020_03_28/thread_1_seq_53.312.1036276683 thread=1 sequence=53
archived log file name=+DATA/orcl/onlinelog/group_2.275.1033601485 thread=1 sequence=54
archived log file name=+DATA/orcl/onlinelog/group_1.274.1033601481 thread=1 sequence=55
media recovery complete, elapsed time: 00:00:03
Finished recover at 2020/03/28 22:49:55

RMAN> sql ‘alter database open resetlogs‘;
sql statement: alter database open resetlogs
RMAN> 

#恢复后查看表空间数据库
SQL> select file_id,file_name from dba_data_files;

   FILE_ID FILE_NAME
---------- ------------------------------------------------------------------------------------------
         1 +DATA/orcl/datafile/system.269.1033601257
         2 +DATA/orcl/datafile/sysaux.270.1033601259
         3 +DATA/orcl/datafile/undotbs1.271.1033601261
         4 +DATA/orcl/datafile/users.272.1033601261
         5 +DATA/orcl/datafile/example.277.1033601505
         6 +DATA/orcl/datafile/undotbs2.278.1033601957
         8 +DATA/orcl/datafile/tbs10.283.1036277119
         9 +DATA/orcl/datafile/tbs11.294.1036277119
        10 +DATA/orcl/datafile/gg.293.1036277103
        11 +DATA/orcl/datafile/ogg_2020.259.1033961107

10 rows selected.

SQL>

原文地址：https://www.cnblogs.com/vmsysjack/p/12584950.html

时间： 2024-10-04 06:00:15

恢复drop后的表空间的相关文章

Oracle中恢复drop掉的表中的数据

今天同事不小心把生产上的一张表直接drop掉了,没有做备份,哥们慌的一匹,来找我这个小白来帮忙解决,于是心血来潮简单总结一下. 其实在oralce中,用drop删掉一张表,其实不会真正的删除,只是把表放到了回收站中,可以通过flashback命令来恢复drop掉的表. 例如: 1.创建一张表,删除:再创建一张同名表,字段不同,再删除 在 select original_name,dropscn from recyclebin时候,两个表的dropscn是不同的,在利用闪回恢复时 flashbac

Oracle恢复drop误删除的表

一.表的恢复 对误删的表,只要没有使用PURGE永久删除选项,那么从flash back区恢复回来希望是挺大的.一般步骤有: 1.从flash back里查询被删除的表 select * from recyclebin 2.执行表的恢复 flashback table tbName to before drop; 这里的tbName代表你要恢复的表的名称.二.表数据恢复 对误删的表记录,只要没有truncate语句,就可以根据事务的提交时间进行选择恢复,一般步骤有: 1.先从flashback_

RMAN恢复drop purge的表

@ORA12C>  alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss'; Session altered. [email protected]> create table  t_0920 as select * from dba_objects; Table created. [email protected]> select count(*) from t_0920;   COUNT(*) ----------------

db2   使用重定向方式恢复数据 and 修改表空间大小

Backup a DB2 database and restore redirect it to a different location [[email protected] ~]$ db2 backup db erpdb to /home/db2inst1/backups [[email protected]primarynode-1 ~]$ scp ERPDB.0.db2inst1.NODE0000.CATN0000.20170511104723.001 172.16.0.77:/home

[课]9.2模拟数据库，表空间和数据文件损坏后的恢复操作

1环境准备 对数据库做一次全备份: 验证当前的备份文件: 2数据库损坏的恢复 2.1模拟数据库损坏 尝试重启数据库查看报错: 这里需要重点说明的是因为我们用的是CATLOG数据库作为目录数据库,所以即使控制文件丢失也不影响我们进行恢复. 现在我们查看一下告警文件的报错: 2.2进行数据库恢复 3表空间损坏的恢复 3.1模拟表空间损坏 查看当前库的表空间,现在我们就模拟TEST_MSSM和TEST_ASSM表空间损坏. 删除表空间文件: 重启数据库查看报错信息: 我们查询一下告警文件里的错误信息:

如何使用 RMAN 异机恢复部分表空间

在oracle 数据库的日常维护和使用期间难免会遇到误删数据(drop,delete, truncate)当我们使用常规手段(flashback query ,flashback drop)也无法恢复数据时,我们可以使用最近的逻辑备份,在异机使用dmp 来恢复相应的表,但是如果没有这些逻辑备份,但是有一个最近的rman 全备,那么我们就可以利用这个备份来恢复被误删的表空间,从而实现数据的恢复,这里我以NBU 的备份环境为例简单描述下如何来回复部分 表空间: -------在nomount 状态

Oracle非关键文件恢复，日志成员、临时文件、索引表空间、口令文件（密码文件）

关键性与非关键性 非关键性文件是指数据库和大多数应用程序没有它也能继续运行的文件.例如,如果数据库丢失了一个多路复用重做日志文件,仍可使用其它重做日志文件副本来保持数据库持续运行. 虽然丢失非关键性文件不会导致数据库崩溃,但它会削弱数据库的功能.例如: 丢失索引表空间会导致应用程序和查询的运行速度大幅减慢,或者,如果这些索引用于强制实施约束,则丢失后甚至会导致应用程序无法使用. 丢失联机重做日志组(只要不是当前联机日志组)会导致在 LGWR 下一次尝试写入组时数据库操作被挂起,直到生成新的日志文

Oracle误删除表空间的恢复

对于误删除表空间的恢复,本文通过基于数据库的时间点恢复和基于表空间的时间点恢复分别加以讨论 一 通过基于数据库的时间点恢复被误删除的表空间 1 需要注意的事项 a 基于数据库的时间点恢复将会回退整个数据库. b 误删除表空间,当数据库有之前可用于恢复的全库备份和相关归档,如果对数据库执行不完全恢复,恢复该数据库到删除表空间之前的状态,便可恢复误删除的表空间.但实际上当我们删除表空间,数据库备份中将不存在关于该表空间的的信息,直接进行恢复将会出现问题.如下所示: RMAN> list backup

[转]Oracle DB 执行表空间时间点恢复

• 列出在执行表空间时间点恢复(TSPITR) 时会发生的操作 • 阐释TSPITR 使用的术语的定义 • 确定适合将TSPITR 用作解决方案的情况 • 确定时间点恢复的正确目标时间 • 确定不能使用TSPITR 的情况以及解决方法 • 执行自动TSPITR 表空间时间点恢复(TSPITR):概念 • 通过执行TSPITR 可将一个或多个表空间快速恢复到以前的某个时间. • 执行TSPITR 不会影响数据库中其它表空间或对象的状态. 使用RMAN 自动表空间时间点恢复(TSPITR) 可将Or