这篇文章主要介绍RMAN如何恢复drop purge的表，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！
十载的任丘网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。
全网营销推广的优势是能够根据用户设备显示端的尺寸不同，自动调整任丘建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。
成都创新互联公司从事“
任丘网站设计”,“
任丘网站推广”以来，每个客户项目都认真落实执行。@ORA12C> alter session set nls_date_format='yyyy-mm-dd hh34:mi:ss';
Session altered.
SYS@ORA12C> create table t_0920 as select * from dba_objects;
Table created.
SYS@ORA12C> select count(*) from t_0920;
COUNT(*)
-----------------
91691
1 row selected.
SYS@ORA12C> select sysdate from dual;
SYSDATE
-------------------
2015-09-20 14:17:49
1 row selected.
SYS@ORA12C> drop table t_0920 purge;
Table dropped.
SYS@ORA12C> desc t_0920;
ERROR:
ORA-04043: object t_0920 does not exist
SYS@ORA12C> create table t_09201 as select * from dba_objects;
Table created.
SYS@ORA12C> select count(*) from t_09201;
COUNT(*)
-----------------
91691
1 row selected.
SYS@ORA12C> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SYS@ORA12C> startup mount;
ORACLE instance started.
Total System Global Area 729808896 bytes
Fixed Size 2928680 bytes
Variable Size 570429400 bytes
Database Buffers 150994944 bytes
Redo Buffers 5455872 bytes
Database mounted.
现在需要把t_0920表恢复过来：
run{
sql "alter session set nls_date_format=''yyyy-mm-dd hh34:mi:ss''";
set until time '2015-09-20 14:17:49';
restore database;
recover database;
6> }
using target database control file instead of recovery catalog
sql statement: alter session set nls_date_format=''yyyy-mm-dd hh34:mi:ss''
executing command: SET until clause
Starting restore at 20-SEP-15
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=355 device type=DISK
creating datafile file number=2 name=/u01/app/oracle/oradata/ORA12C/t2.dbf
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 /u01/app/oracle/oradata/ORA12C/system01.dbf
channel ORA_DISK_1: restoring datafile 00003 to /u01/app/oracle/oradata/ORA12C/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00004 to /u01/app/oracle/oradata/ORA12C/undotbs01.dbf
channel ORA_DISK_1: restoring datafile 00005 to /u01/app/oracle/oradata/ORA12C/example01.dbf
channel ORA_DISK_1: restoring datafile 00006 to /u01/app/oracle/oradata/ORA12C/users01.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/fast_recovery_area/ORA12C/backupset/2015_09_20/o1_mf_nnndf_TAG20150920T120820_bzwd9ntd_.bkp
channel ORA_DISK_1: piece handle=/u01/app/oracle/fast_recovery_area/ORA12C/backupset/2015_09_20/o1_mf_nnndf_TAG20150920T120820_bzwd9ntd_.bkp tag=TAG20150920T120820
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:01:56
Finished restore at 20-SEP-15
Starting recover at 20-SEP-15
using channel ORA_DISK_1
starting media recovery
archived log for thread 1 with sequence 18 is already on disk as file /u01/app/oracle/fast_recovery_area/ORA12C/archivelog/2015_09_20/o1_mf_1_18_bzwh058r_.arc
archived log for thread 1 with sequence 19 is already on disk as file /u01/app/oracle/fast_recovery_area/ORA12C/archivelog/2015_09_20/o1_mf_1_19_bzwhh60d_.arc
archived log for thread 1 with sequence 20 is already on disk as file /u01/app/oracle/fast_recovery_area/ORA12C/archivelog/2015_09_20/o1_mf_1_20_bzwhzsts_.arc
archived log for thread 1 with sequence 1 is already on disk as file /u01/app/oracle/fast_recovery_area/ORA12C/archivelog/2015_09_20/o1_mf_1_1_bzwmprks_.arc
archived log file name=/u01/app/oracle/fast_recovery_area/ORA12C/archivelog/2015_09_20/o1_mf_1_18_bzwh058r_.arc thread=1 sequence=18
archived log file name=/u01/app/oracle/fast_recovery_area/ORA12C/archivelog/2015_09_20/o1_mf_1_19_bzwhh60d_.arc thread=1 sequence=19
archived log file name=/u01/app/oracle/fast_recovery_area/ORA12C/archivelog/2015_09_20/o1_mf_1_20_bzwhzsts_.arc thread=1 sequence=20
archived log file name=/u01/app/oracle/fast_recovery_area/ORA12C/archivelog/2015_09_20/o1_mf_1_1_bzwm5k1c_.arc thread=1 sequence=1
archived log file name=/u01/app/oracle/fast_recovery_area/ORA12C/archivelog/2015_09_20/o1_mf_1_1_bzwmprks_.arc thread=1 sequence=1
media recovery complete, elapsed time: 00:00:07
Finished recover at 20-SEP-15
RMAN> alter database open resetlogs;
Statement processed
验证：t_0920 表已经恢复了，t_09201表不存在了。
SYS@ORA12C> select count(*) from t_0920;
COUNT(*)
-----------------
91691
1 row selected.
SYS@ORA12C> select count(*) from t_09201;
select count(*) from t_09201
*
ERROR at line 1:
ORA-00942: table or view does not exist
以上是“RMAN如何恢复drop purge的表”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注创新互联行业资讯频道！
另外有需要云服务器可以了解下创新互联cdcxhl.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。
文章标题：RMAN如何恢复droppurge的表-创新互联
文章出自：
http://cdkjz.cn/article/dspddc.html
