一、oracle表空间、测试表、用户环境准备

创建bocotest表空间
create tablespace bocotest logging datafile '/opt/ora_data/bocotest_01.dbf' size 1G;

image.png

create user lijian identified by lijian default tablespace bocotest;

image.png

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; 

image.png

image.png

我们在这个表空间下,建立一张test_drop表,并且插入测试数据,先insert进去一条数据,如下:

SQL> select * from test_drop;

        ID TEXT
---------- --------------------------------------------------
         1 这是一条原始数据

二、归档日志环境准备

我们先看一下,现在数据库的归档日志情况:
image.png
可以看到,因为我们是自己搭建的测试库,上面也没有业务,所以没有产生归档日志。
image.png
我们手动的让数据库进行一次归档,执行命令:
alter system switch logfile;
image.png
发现产生了一个arc文件,这个就是一个归档日志
image.png
我们再执行一次手动切换命令:
alter system switch logfile;
会发现目录下的文件变成了2个
image.png

有了归档日志之后,我们对数据库用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里面执行的命令导致,主要是为了避免归档日志占用磁盘空间导致其他问题。
image.png

同时多了一个autobackup的文件夹,下面按日期也多了一个bkp文件,这是SPFILE的备份
image.png

我们到/opt/ora_bak下看一下,发现多了3个文件
image.png

可以通过在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文件,我们建的几张测试表,也都在这个数据文件上。
image.png

首先我在test_drop表中,新增一条数据
image.png
注意,新增后我没有手工产生归档日志,归档日志的文件夹下面还是空的,也没有再做备份。

现在我删除 bocotest1.dbf这个数据文件。
image.png

之后我们sqlplus登陆到lijian用户上,再创建一张表:
我们发现提示信息是可以创建出来的,但是在dba_tables里面,查不到这张表,可以判断现在数据库已经存在了问题。
image.png
image.png

现在用rman来恢复这个数据文件
因为我们有全库的0级备份,还有最新的归档日志备份,并且只有这一个数据文件被删除了,所以我们只需要单独恢复这一个数据文件就行了。

rman日志里显示这个数据文件的编号为5
image.png

先强制停止数据库,之后切换到mount状态

shutdown abort
startup mount

在rman里执行

restore datafile 5;
recover datafile 5;

image.png

可以看到这个数据文件回来了
image.png

之后我们把数据库打到open状态
image.png

之后来查一下数据情况:
执行SQL:

select * from test_drop;
select * from table_no;

image.png

可以看到,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级,以及在恢复时间点内的归档日志文件备份:

  1. 搭建一个临时的数据库环境,跟目标库一致
  2. 在临时库用目标库的0级备份以及归档日志备份,控制文件,参数文件进行恢复。
  3. 恢复数据库时通过时间点进行恢复,将整库恢复到数据表被truncate前的时间点。
  4. 在临时库用expdp把数据导出来,再导入到正式库中。

总结

如果是简单的数据文件,控制文件,参数文件丢失,直接就可以用rman恢复。

如果表级别delete,drop的话直接可以通过flashback进行恢复,恢复delete数据的时候注意不要超过undo设置的默认时间(30分钟),否则会出现快照过旧的错误。

对于表级别truncate,建议在备用环境上恢复后导入正式库

另外,表级别truncate、整库基于scn或时间点的恢复,强烈建议不要直接在生产库上直接操作,或者在生产库服务器上随便找个目录就开始做。如果你的归档日志不完整,很大概率会出现:

  1. restore的时候通过备份把数据文件恢复了
  2. 但是恢复逻辑数据的时候,归档缺失,找不到最新的归档,你最后备份了哪个scn或时间的归档,就恢复到哪个归档。
  3. 并且oracle在restore的过程中也不会提示,就会直接覆盖了你所有的数据文件,到时候不但丢失表的数据找不回来,而且生产库其他表的数据也少了。
  4. 通过scn或时间点恢复,再开库的时候涉及到要执行resetlogs,是十分危险的操作,再附上一篇OCM赵靖宇的文章:

    https://www.cnblogs.com/jyzha...

少放香菜
56 声望3 粉丝