冷备

如果条件允许的情况下，可以使用传统冷备操作，步骤十分简单，停止数据库后，将需要备份的数据文件、控制文件、日志文件等拷贝一份即可。

 

热备

前提开启归档模式

 

查询一下用户对应关系，我们用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警告

[[email protected] ~]$ 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常用命令操作步骤

[[email protected] ~]$ 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（如果都没有设置，则保存在这里）