一、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 这是一条原始数据
二、归档日志环境准备
我们先看一下,现在数据库的归档日志情况:
可以看到,因为我们是自己搭建的测试库,上面也没有业务,所以没有产生归档日志。
我们手动的让数据库进行一次归档,执行命令:alter system switch logfile;
发现产生了一个arc文件,这个就是一个归档日志
我们再执行一次手动切换命令:alter system switch logfile;
会发现目录下的文件变成了2个
有了归档日志之后,我们对数据库用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...
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。