Oracle数据库如何进行冷备份和恢复
数据库的冷备份指的是数据库处于关闭或者MOUNT状态下的备份,备份文件包括数据文件、日志文件和控制文件。数据库冷备份所用的时间主要受数据库大小和磁盘I/O性能的影响。由于数据库需要关闭才能进行冷备份,所以这种备份技术并不适用7×24小时的系统。尽管冷备份并不需要开启归档模式,但还是建议开启了归档模式后进行冷备份。当数据库发生灾难时,只要归档日志和在线日志存在,归档模式下的冷备份可做到数据不丢失。
9.2.1 冷备份数据库步骤
在关闭数据库之前,可以从数据库视图中查找所需要备份的文件。
- 备份数据文件
可以从视图V D A T A F I L E 中查找所需要备份的数据文件,如下所示: S Q L > s e l e c t n a m e f r o m v DATAFILE中查找所需要备份的数据文件,如下所示: SQL> select name from v DATAFILE中查找所需要备份的数据文件,如下所示:SQL>selectnamefromvdatafile;
NAME
/ora10205/oradata/ora10205/system01.dbf
/ora10205/oradata/ora10205/users02.dbf
/ora10205/oradata/ora10205/sysaux01.dbf
/ora10205/oradata/ora10205/users01.dbf
/ora10205/oradata/ora10205/test01.dbf
/ora10205/oradata/ora10205/manual01.dbf
/oradata/ZHOUL/datafile/o1_mf_zhoul_8cppdlq7_.dbf
/ora10205/oradata/ora10205/undotbs2.dbf
/ora10205/oradata/ora10205/test_lmt01.dbf
9 rows selected.
需要注意的是,由于临时文件是不永久存放业务数据的,所以在冷备份时并不需要备份临时文件。而且临时文件往往被撑得很大,备份临时文件会导致备份时间变长。
2. 备份日志文件
可以从V L O G F I L E 中获取所需要备份的日志文件,如下所示: S Q L > s e l e c t m e m b e r f r o m v LOGFILE中获取所需要备份的日志文件,如下所示: SQL> select member from v LOGFILE中获取所需要备份的日志文件,如下所示:SQL>selectmemberfromvlogfile where type<>‘STANDBY’;
MEMBER
/ora10205/oradata/ora10205/redo02.log
/ora10205/oradata/ora10205/redo01.log
/ora10205/oradata/ora10205/redo05.log
/ora10205/oradata/ora10205/redo04.log
/ora10205/oradata/ora10205/redo03.log
需要注意的是,如果数据库创建有STANDBYREDOLOG,该文件在日常运行的过程中不需要用到,所以在冷备份过程中可以不备份。
3. 备份控制文件
可以从V C O N T R O L F I L E 中获取所需要备份的控制文件,如下所示: S Q L > s e l e c t n a m e f r o m v CONTROLFILE中获取所需要备份的控制文件,如下所示: SQL> select name from v CONTROLFILE中获取所需要备份的控制文件,如下所示:SQL>selectnamefromvcontrolfile;
NAME
/ora10205/oradata/ora10205/control02.ctl
/ora10205/oradata/ora10205/control01.ctl
如果在MOUNT状态使用操作系统命令备份控制文件,则需要注意分裂块。分裂块指的是数据块在更新过程中同时被另外的进程拷贝,以致拷贝出来的数据块一部分是拷贝前的数据,一部分是拷贝后的数据。这些分裂块对Oracle来说就是损坏块。损坏块意味着不可用。由于控制文件的BLOCK SIZE和操作系统的最小I/O单位不同,因此在拷贝控制文件的过程中可能会产生分裂块,所以不建议在数据库MOUNT状态或者OPEN状态中使用操作系统命令拷贝控制文件,虽然拷贝出来的控制文件在绝大多数情况下是可用的。
4. 备份参数文件
参数文件默认位于 O R A C L E H O M E / d b s 下,其名字默认为 i n i t ORACLE_HOME/dbs下,其名字默认为init ORACLEHOME/dbs下,其名字默认为initORACLE_SID.ora或者spfile O R A C L E S I D . o r a 。由于参数文件不存放业务数据,所以理论上来讲,参数文件即使丢失了也可以重建。但参数文件重建需要时间,所以在冷备份的过程中最好也备份参数文件。由于数据库在 N O M O U N T 的过程中会读取参数文件,然后将读取的内容写进警告日志。所以当参数文件丢失且没有备份时,可以从警告日志中获取数据库参数列表重建参数文件。 5. 备份监听相关配置文件监听相关的配置文件指的是 l i s t e n e r . o r a 、 s q l n e t . o r a 、 t n s n a m e s . o r a 等。默认位于 ORACLE_SID.ora。由于参数文件不存放业务数据,所以理论上来讲,参数文件即使丢失了也可以重建。但参数文件重建需要时间,所以在冷备份的过程中最好也备份参数文件。由于数据库在NOMOUNT的过程中会读取参数文件,然后将读取的内容写进警告日志。所以当参数文件丢失且没有备份时,可以从警告日志中获取数据库参数列表重建参数文件。 5. 备份监听相关配置文件 监听相关的配置文件指的是listener.ora、sqlnet.ora、tnsnames.ora等。默认位于 ORACLESID.ora。由于参数文件不存放业务数据,所以理论上来讲,参数文件即使丢失了也可以重建。但参数文件重建需要时间,所以在冷备份的过程中最好也备份参数文件。由于数据库在NOMOUNT的过程中会读取参数文件,然后将读取的内容写进警告日志。所以当参数文件丢失且没有备份时,可以从警告日志中获取数据库参数列表重建参数文件。5.备份监听相关配置文件监听相关的配置文件指的是listener.ora、sqlnet.ora、tnsnames.ora等。默认位于ORACLE_HOME/network/admin中。当Oracle软件不可用时,虽然可以重装Oracle软件来解决,但配置文件中的内容需要重建,尤其是tnsnames.ora配置文件,它往往和数据库中的DBLINK相关。当tnsnames.ora配置文件不存在或者配置有问题时,DBLINK往往也会随之失效(如果建DBLINK时采用tnsnams.ora中的连接串)。tnsnames.ora在分布式事务中起着举足轻重的作用,但在数据库备份过程中很容易被DBA忽视。此外,冷备份数据库时最好也备份/etc/fstab、/etc/filesystems或者/etc/hosts等操作系统配置文件,因为要考虑到操作系统不可用的情况。
9.2.2 冷备份下的数据库恢复
如果数据库的冷备份是在非归档模式下进行的备份。那么当发生灾难时,只要将冷备份中数据文件、控制文件、日志文件拷贝至生产系统的原目录中,就可以打开数据库了。此时的恢复时间取决于数据库的大小和磁盘的I/O速度。如果冷备份放在其他主机或介质中,那么恢复时间还取决于从其他系统中导出的时间和网络带宽。非归档模式下的备份可能会导致数据丢失。
如果数据库的冷备份是在归档模式下进行的备份。那么发生灾难时,只要控制文件、归档日志文件、在线日志文件没损坏,那么就可以只将冷备份的数据文件拷贝至生产系统的原目录中,然后应用归档日志和在线日志,这样就可以做到数据不丢失了。以下为模拟数据库灾难的过程。
(1)假设有一张T1表,建立在zhou1用户下,如下所示:
SQL> select count(*) from zhou1.t1;
COUNT(*)
51732
(2)数据库某个数据文件损坏导致了表zhou1.t1读取异常,如下所示:
SQL> select count() from zhou1.t1;
select count() from zhou1.t1
*
ERROR at line 1:
ORA-00376: file 4 cannot be read at this time
ORA-01110: data file 4: ‘/ora10205/oradata/ora10205/users01.dbf’
(3)如果数据文件有冷备份,只要将备份集拷贝至生产系统原目录中,然后应用归档日志和在线日志就可以恢复数据,如下所示:
SQL> alter database datafile 4 offline;
Database altered.
[ora10205@mcdbatest bak]$ cp users01.dbf …/users01.dbf
SQL> recover datafile 4;
ORA-00279: change 12770129123740 generated at 12/06/2012 14:52:43 needed for
thread 1
ORA-00289: suggestion : /archlog/ora10205/1_19_800383891.dbf
ORA-00280: change 12770129123740 for thread 1 is in sequence #19
Specify log: {=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: change 12770129124885 generated at 12/06/2012 15:02:40 needed for
thread 1
ORA-00289: suggestion : /archlog/ora10205/1_20_800383891.dbf
ORA-00280: change 12770129124885 for thread 1 is in sequence #20
ORA-00278: log file ‘/archlog/ora10205/1_19_800383891.dbf’ no longer needed for
this recovery
…
Log applied.
Media recovery complete.
SQL> alter database datafile 4 online;
Database altered.
SQL> select count(*) from zhou1.t1;
COUNT(*)
51732