冷备
如果条件允许的情况下,可以使用传统冷备操作,步骤十分简单,停止数据库后,将需要备份的数据文件、控制文件、日志文件等拷贝一份即可。
热备
前提开启归档模式
查询一下用户对应关系,我们用SCOTT测试,所在表空间为USERS
oracle 查看用户所在的表空间:
select username,default_tablespace from dba_users order by username;
如图所示:
然后执行
alter tablespace users begin backup;
进行文件拷贝操作,可以是脚本,也可以手动复制
alter tablespace users end backup;
最后一定要end backup,否则会出现问题
如此一来就完成了对users表空间的热备操作。
如果想完整备份,热备生成语句如下:
select 'alter tablespace '||tablespace_name||' begin backup;' from dba_tablespaces where logging='LOGGING';
以DBA语句执行后,生成如下语句
alter tablespace SYSTEM begin backup;
alter tablespace SYSAUX begin backup;
alter tablespace UNDOTBS1 begin backup;
alter tablespace USERS begin backup;
此时在任意地点新建一个文件夹,将热备对应的DBF文件复制一份,如图:
复制完毕后,进行end backup操作,语句如下:
alter tablespace SYSTEM end backup;
alter tablespace SYSAUX end backup;
alter tablespace UNDOTBS1 end backup;
alter tablespace USERS end backup;
查看log日志,可以看到相关操作已经完成了。
如此,便完成了一次完整的热备操作。
恢复测试
(1)数据库打开状态,普通数据文件损坏的情况。
手动破坏相关dbf物理文件,用任何方式。
dba用户做全局检查点,发现已经无法访问表了。
alter system checkpoint;
恢复过程:
在offline immediate之后,我们从热备份中找到对应的文件还原。
然后进行recover。
恢复后将表空间设置为online。
经测试,表空间恢复成功,可以正常使用。
TIPS:实践过程中发现的ORA-32004警告
[oracle@node2 ~]$ oerr ora 32004
32004, 00000, "obsolete or deprecated parameter(s) specified for %s instance"
// *Cause: Obsolete or deprecated parameters for this instance type
// were specified in the SPFILE or the PFILE on the server side.
// *Action: See alert log for a list of parameters that are obsolete
// or deprecated. Remove them from the SPFILE or the server
// side PFILE.
---------------------
查看日志,发现一个不推荐的参数
在mount或open下重置该参数
alter system reset log_archive_start
重启问题即可消除
(2)数据库关闭的状态下,系统文件、undo表空间之类的文件损坏。
首先了解以下dbf种类
系统dbf文件:system01.dbf,sysaux01.dbf,undotbs01.dbf
数据dbf文件:users.dbf等
数据库关闭后,删除数据dbf文件,尝试启动数据库,发现以下问题:
将热备文件最新版复制一份过来,然后执行恢复,过程如下:
RMAN> shutdown immediate
database dismounted
Oracle instance shut down
RMAN> startup
connected to target database (not started)
Oracle instance started
database mounted
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of startup command at 08/26/2019 11:21:44
ORA-01113: file 4 needs media recovery
ORA-01110: data file 4: '/U01/app/oracle/oradata/orcl/users01.dbf'
RMAN> recover tablespace users;
Starting recover at 2019-08-26 11:25:04
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=10 device type=DISK
starting media recovery
media recovery complete, elapsed time: 00:00:00
Finished recover at 2019-08-26 11:25:05
RMAN> alter database open;
database opened
RMAN>
RMAN不完全恢复
RMAN是oracle非常强大的备份恢复工具,可以进行完全和增量备份/恢复等操作,这里只介绍最简单实用的全备份操作。
RMAN常用命令操作步骤
[oracle@bogon ~]$ rman target /
Recovery Manager: Release 11.2.0.1.0 - Production on Tue Sep 10 17:20:12 2019
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: ORCL (DBID=1533443989)
RMAN> list backup
2> ;
using target database control file instead of recovery catalog
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
1 Full 1.05G DISK 00:00:28 2019-08-27 14:27:11
BP Key: 1 Status: AVAILABLE Compressed: NO Tag: TAG20190827T142643
Piece Name: /U01/app/oracle/flash_recovery_area/ORCL/backupset/2019_08_27/o1_mf_nnndf_TAG20190827T142643_gp9m93s1_.bkp
List of Datafiles in backup set 1
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- ------------------- ----
1 Full 1283459 2019-08-27 14:26:43 /U01/app/oracle/oradata/orcl/system01.dbf
2 Full 1283459 2019-08-27 14:26:43 /U01/app/oracle/oradata/orcl/sysaux01.dbf
3 Full 1283459 2019-08-27 14:26:43 /U01/app/oracle/oradata/orcl/undotbs01.dbf
4 Full 1283459 2019-08-27 14:26:43 /U01/app/oracle/oradata/orcl/users01.dbf
5 Full 1283459 2019-08-27 14:26:43 /U01/app/oracle/oradata/orcl/example01.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
2 Full 9.36M DISK 00:00:01 2019-08-27 14:27:19
BP Key: 2 Status: AVAILABLE Compressed: NO Tag: TAG20190827T142643
Piece Name: /U01/app/oracle/flash_recovery_area/ORCL/backupset/2019_08_27/o1_mf_ncsnf_TAG20190827T142643_gp9mb7y7_.bkp
SPFILE Included: Modification time: 2019-08-26 15:49:31
SPFILE db_unique_name: ORCL
Control File Included: Ckp SCN: 1283481 Ckp time: 2019-08-27 14:27:18
删除备份集
delete backupset 1; --1代表备份集序号
恢复脚本:
run
{
set until time "to_date('2019-08-27 14:27:11','YYYY-MM-DD HH24:MI:SS')";
restore database;
recover database;
}
一次生产环境的实际操作
一个老项目,多年来无人运维,需要检查一下备份情况,以备不时之需。
查看列表,发现没有备份,尝试一次全备份,发现没有在归档模式
为了保险起见,先做一次物理文件全备份,冷备或热备均可。
查询一下归档模式状态,果然是非归档,由于更改模式需要在mount下,所以需要重启数据库,更改后,打开数据库。
接下来,进入RMAN尝试备份,这次备份成功。
关于备份文件的位置:
备份语句中指定的format > rman 中显现的configure channel device type disk format '/oracle/orclarch/%U_%d'的路径 > 闪回恢复区(如果开启闪回,则保存在$ORACLE_HOME /flash_recovery_area文件夹中>$ORACLE_HOME/dbs(如果都没有设置,则保存在这里)