这篇文章主要介绍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://lszwz.com/article/dspddc.html