数据库的冷备份指的是数据库处于关闭或者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
