一、oracle表空间、测试表、用户环境准备
创建bocotest表空间create tablespace bocotest logging datafile '/opt/ora_data/bocotest_01.dbf' size 1G;
create user lijian identified by lijian default tablespace bocotest;
grant dba to lijian;
grant create session to lijian;
grant unlimited tablespace to lijian;
grant create table,create view,create trigger, create sequence,create procedure,create type to lijian; 
我们在这个表空间下，建立一张test_drop表，并且插入测试数据，先insert进去一条数据，如下：
SQL> select * from test_drop;
ID TEXT
---------- --------------------------------------------------
1 这是一条原始数据二、归档日志环境准备
我们先看一下，现在数据库的归档日志情况：
有了归档日志之后，我们对数据库用Rman做一次!0级备份和归档备份
执行命令如下：
rman target /
run
{
CONFIGURE CONTROLFILE AUTOBACKUP ON;
allocate channel ch00 type disk format '/opt/ora_bak/%U_%d';
backup database plus archivelog delete all input;
release channel ch00;
}分别说明一下，第一行意思是，是否开启控制文件的自动备份，这里选择了ON；第二行意思是开启一个ch00通道，保存备份文件的路径，及文件命名格式，根据实际路径来调整；第三行是备份数据库，并且备份归档日志，然后删除现存的归档日志。
切换到root用户，创建ora_bak并授权
cd /opt
mkdir ora_bak
chown oracle:oinstall -R ora_bak之后切回oracle用户，执行rman相关命令，如图所示：
rman target /
run
{
CONFIGURE CONTROLFILE AUTOBACKUP ON;
allocate channel ch00 type disk format '/opt/ora_bak/%U_%d';
backup database plus archivelog delete all input;
release channel ch00;
}完整日志如下：
[oracle@oraclevm 2020_03_14]$ rman target /
Recovery Manager: Release 11.2.0.4.0 - Production on Sat Mar 14 17:02:25 2020
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: ORCL (DBID=1562284742)
RMAN> run
2> {
3> CONFIGURE CONTROLFILE AUTOBACKUP ON;
4> allocate channel ch00 type disk format '/opt/ora_bak/%U_%d';
5> backup database plus archivelog delete all input;
6> release channel ch00;
7> }
old RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters are successfully stored
released channel: ORA_DISK_1
allocated channel: ch00
channel ch00: SID=134 device type=DISK
Starting backup at 14-MAR-20
current log archived
channel ch00: starting archived log backup set
channel ch00: specifying archived log(s) in backup set
input archived log thread=1 sequence=11 RECID=29 STAMP=1035047283
input archived log thread=1 sequence=12 RECID=30 STAMP=1035047316
input archived log thread=1 sequence=13 RECID=31 STAMP=1035047365
channel ch00: starting piece 1 at 14-MAR-20
channel ch00: finished piece 1 at 14-MAR-20
piece handle=/opt/ora_bak/0qur34e5_1_1_ORCL tag=TAG20200314T170925 comment=NONE
channel ch00: backup set complete, elapsed time: 00:00:01
channel ch00: deleting archived log(s)
archived log file name=/opt/ora_archive/ORCL/archivelog/2020_03_14/o1_mf_1_11_h6s7qmdg_.arc RECID=29 STAMP=1035047283
archived log file name=/opt/ora_archive/ORCL/archivelog/2020_03_14/o1_mf_1_12_h6s7rnlj_.arc RECID=30 STAMP=1035047316
archived log file name=/opt/ora_archive/ORCL/archivelog/2020_03_14/o1_mf_1_13_h6s7t50w_.arc RECID=31 STAMP=1035047365
Finished backup at 14-MAR-20
Starting backup at 14-MAR-20
channel ch00: starting full datafile backup set
channel ch00: specifying datafile(s) in backup set
input datafile file number=00005 name=/opt/ora_data/bocotest_01.dbf
input datafile file number=00001 name=/opt/ora_data/orcl/system01.dbf
input datafile file number=00002 name=/opt/ora_data/orcl/sysaux01.dbf
input datafile file number=00003 name=/opt/ora_data/orcl/undotbs01.dbf
input datafile file number=00004 name=/opt/ora_data/orcl/users01.dbf
channel ch00: starting piece 1 at 14-MAR-20
channel ch00: finished piece 1 at 14-MAR-20
piece handle=/opt/ora_bak/0rur34e6_1_1_ORCL tag=TAG20200314T170926 comment=NONE
channel ch00: backup set complete, elapsed time: 00:00:35
Finished backup at 14-MAR-20
Starting backup at 14-MAR-20
current log archived
channel ch00: starting archived log backup set
channel ch00: specifying archived log(s) in backup set
input archived log thread=1 sequence=14 RECID=32 STAMP=1035047401
channel ch00: starting piece 1 at 14-MAR-20
channel ch00: finished piece 1 at 14-MAR-20
piece handle=/opt/ora_bak/0sur34f9_1_1_ORCL tag=TAG20200314T171001 comment=NONE
channel ch00: backup set complete, elapsed time: 00:00:01
channel ch00: deleting archived log(s)
archived log file name=/opt/ora_archive/ORCL/archivelog/2020_03_14/o1_mf_1_14_h6s7v9jk_.arc RECID=32 STAMP=1035047401
Finished backup at 14-MAR-20
Starting Control File and SPFILE Autobackup at 14-MAR-20
piece handle=/opt/ora_archive/ORCL/autobackup/2020_03_14/o1_mf_s_1035047402_h6s7vc09_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 14-MAR-20
released channel: ch00我们再进入到之前的归档日志路径下，发现归档日志已经不存在了，这是因为我们在rman里面执行的命令导致，主要是为了避免归档日志占用磁盘空间导致其他问题。
同时多了一个autobackup的文件夹，下面按日期也多了一个bkp文件，这是SPFILE的备份
我们到/opt/ora_bak下看一下，发现多了3个文件
可以通过在rman命令行窗口执行list backupset，来看备份的信息。
[oracle@oraclevm ora_bak]$ rman target /
Recovery Manager: Release 11.2.0.4.0 - Production on Sat Mar 14 13:00:39 2020
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: ORCL (DBID=1562284742)
RMAN> list backupset;
using target database control file instead of recovery catalog
List of Backup Sets
===================
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
23 296.00K DISK 00:00:00 14-MAR-20
BP Key: 23 Status: AVAILABLE Compressed: NO Tag: TAG20200314T170925
Piece Name: /opt/ora_bak/0qur34e5_1_1_ORCL
List of Archived Logs in backup set 23
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
1 11 1034794 14-MAR-20 1035228 14-MAR-20
1 12 1035228 14-MAR-20 1035248 14-MAR-20
1 13 1035248 14-MAR-20 1035293 14-MAR-20
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
24 Full 1.10G DISK 00:00:31 14-MAR-20
BP Key: 24 Status: AVAILABLE Compressed: NO Tag: TAG20200314T170926
Piece Name: /opt/ora_bak/0rur34e6_1_1_ORCL
List of Datafiles in backup set 24
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
1 Full 1035301 14-MAR-20 /opt/ora_data/orcl/system01.dbf
2 Full 1035301 14-MAR-20 /opt/ora_data/orcl/sysaux01.dbf
3 Full 1035301 14-MAR-20 /opt/ora_data/orcl/undotbs01.dbf
4 Full 1035301 14-MAR-20 /opt/ora_data/orcl/users01.dbf
5 Full 1035301 14-MAR-20 /opt/ora_data/bocotest_01.dbf
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
25 6.50K DISK 00:00:00 14-MAR-20
BP Key: 25 Status: AVAILABLE Compressed: NO Tag: TAG20200314T171001
Piece Name: /opt/ora_bak/0sur34f9_1_1_ORCL
List of Archived Logs in backup set 25
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
1 14 1035293 14-MAR-20 1035322 14-MAR-20
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
26 Full 9.64M DISK 00:00:01 14-MAR-20
BP Key: 26 Status: AVAILABLE Compressed: NO Tag: TAG20200314T171002
Piece Name: /opt/ora_archive/ORCL/autobackup/2020_03_14/o1_mf_s_1035047402_h6s7vc09_.bkp
SPFILE Included: Modification time: 14-MAR-20
SPFILE db_unique_name: ORCL
Control File Included: Ckp SCN: 1035333 Ckp time: 14-MAR-20三、几个常见的恢复场景
1.数据文件被误删除(.dbf文件)
cd /opt/ora_data
可以看到有一个bocotest_01.dbf文件，我们建的几张测试表，也都在这个数据文件上。
首先我在test_drop表中，新增一条数据
注意，新增后我没有手工产生归档日志，归档日志的文件夹下面还是空的，也没有再做备份。
现在我删除 bocotest1.dbf这个数据文件。
之后我们sqlplus登陆到lijian用户上，再创建一张表：
我们发现提示信息是可以创建出来的，但是在dba_tables里面，查不到这张表，可以判断现在数据库已经存在了问题。
现在用rman来恢复这个数据文件
因为我们有全库的0级备份，还有最新的归档日志备份，并且只有这一个数据文件被删除了，所以我们只需要单独恢复这一个数据文件就行了。
rman日志里显示这个数据文件的编号为5
先强制停止数据库，之后切换到mount状态
shutdown abort
startup mount在rman里执行
restore datafile 5;
recover datafile 5;
可以看到这个数据文件回来了
之后我们把数据库打到open状态
之后来查一下数据情况：
执行SQL:
select * from test_drop;
select * from table_no;
可以看到，test_drop表直接恢复到了最新记录，我们虽然没有在Insert第二条数据的时候做0级和归档备份，但是也恢复到了删除数据文件之前的状态；而table_no表，因为是在数据文件被删除之后建立，虽然不再报找不到表的错误，但dba_tables数据字典里也没有记录这张表的信息。
在这里也放一个OCM赵靖宇关于此类恢复的连接
https://www.cnblogs.com/jyzha...
2.数据表被drop
见我之前发过的公众号，里面有详细讲，用flashbak相关命令即可。
3.数据表被delete
见我之前发过的公众号，里面有详细讲，用flashbak相关命令即可。
4.数据表被truncate
数据表被Truncate的例子比较复杂，网上很多文章误导可以用flashback进行恢复，实际经过测试是不能用flashback进行恢复的。
这种情况可以考虑用rman做不完全恢复，因为我这没有第二个环境，也懒得搭建了，大体思路如下，前提是必须要有0级，以及在恢复时间点内的归档日志文件备份：
- 搭建一个临时的数据库环境，跟目标库一致
- 在临时库用目标库的0级备份以及归档日志备份，控制文件，参数文件进行恢复。
- 恢复数据库时通过时间点进行恢复，将整库恢复到数据表被truncate前的时间点。
- 在临时库用expdp把数据导出来，再导入到正式库中。
总结
如果是简单的数据文件，控制文件，参数文件丢失，直接就可以用rman恢复。
如果表级别delete,drop的话直接可以通过flashback进行恢复，恢复delete数据的时候注意不要超过undo设置的默认时间(30分钟)，否则会出现快照过旧的错误。
对于表级别truncate，建议在备用环境上恢复后导入正式库
另外，表级别truncate、整库基于scn或时间点的恢复，强烈建议不要直接在生产库上直接操作，或者在生产库服务器上随便找个目录就开始做。如果你的归档日志不完整，很大概率会出现：
- restore的时候通过备份把数据文件恢复了
- 但是恢复逻辑数据的时候，归档缺失，找不到最新的归档，你最后备份了哪个scn或时间的归档，就恢复到哪个归档。
- 并且oracle在restore的过程中也不会提示，就会直接覆盖了你所有的数据文件，到时候不但丢失表的数据找不回来，而且生产库其他表的数据也少了。
-
通过scn或时间点恢复，再开库的时候涉及到要执行resetlogs，是十分危险的操作，再附上一篇OCM赵靖宇的文章：
https://www.cnblogs.com/jyzha...