控制文件备份关键是选择备份时机

其实在Oracle数据库中，对控制文件进行备份是很简单的一件事情，只需要通过一些简短的命令即可以完成。根据笔者的经验，在进行控制文件备份作业时其关键的内容在于确定什么时候需要进行备份，即在执行哪些操作后需要对控制文件进行备份。而对于一些基本的备份操作，相对来说对于数据库管理员不会有多的难度。为此笔者这里就倒过来说，先简单的谈谈如果对控制文件进行备份。然后再给家详细的分析一下，在什么情况下应该对控制文件进行备份。
　　一、控制文件备份的方式。
　　在Oracle数据库中，对于控制文件的备份主要有两种方式，分别为二进制文件备份与文本文件备份。这两种备份方式不仅仅在于备份文件格式的不同，而且其作用也有很的差异。如二进制文件备份下的控制文件，数据库系统可以直接拿来使用。即当数据库控制文件发生损坏时，只需要修改初始化参数指向这个备份的控制文件即可。而文本文件备份模式下，这个控制文件是以文本文件的模式保存的，为此数据库不能够直接拿来使用。数据库管理员之所以采用这个文本文件备份模式，主要是为以后手工建立控制文件提供一个参考。对于这两个备份方式的区别，数据库管理员需要清楚，以方便根据自己的用途来选择合适的备份方式。一般情况下，只需要进行二进制文件的备份方式即可。
　　如要对Oracle数据库的控制文件执行备份的话，需要用到alter database backup controlfile to 'e:\controlfile.ctl.bk'命令。后面to指向的是备份文件的保存的路径。在备份时，最好不要更改其扩展名。如上例所示，可以直接在原来控制文件的名字后面加上一个备份的后缀，以示区别。当以后需要用到这个控制文件时，只需要讲后面的后缀去掉即可。另外需要注意的是，如果在Linux 操作系统上进行控制文件的备份，需要注意他们之间路径表达方式上的差异。如alter database backup controlfile to '/home/oracle/controlfile.ctl.bk'这条命令是在Linux系统下对控制文件进行备份的语句。不知道细心的读者有没有发现他们的不同?他们之间只有在路径上的分隔符有所差异。在Windows操作系统中，采用的是反斜杆\符号。而在Linux系统中采用的则是/符号。在其他方面没有丝毫差异。
　　如要对数据库进行文本文件备份(某些专家也将文本文件备份叫做追踪备份)，也是一件比较简单的事情。利用命令alter database backup controlfile to trace就表示启动一个追踪备份。比较两个备份语句的不同，发现在文本文件中，缺少了一个备份文件的路径名以及文件名。这主要是因为采用文本文件备份时，这个备份文件的路径是有参数user_dump_des控制的。文本文件备份完成后，数据库管理员可以使用show parameter user_dump_des命令来查找这个备份文件存储的位置。另外这个备份文件的名字也是自动命名的。其基本的格式为sid_ora_pid.trc。其中这个sid表示创建这个跟踪备份的用户所采用的会话 ID。Pid则表示进程的ID。一般情况下，这个目录中有很多的文本备份文件。数据库管理员需要按创建的时间来排序，以确定自己创建的备份文件。由于这个文件是文本形式存储的，而上面的二进制文件不同，可以直接利用记事本打开查看相关的内容。其实这个文本形式的备份文件并不能够代替二进制形式的控制文件。数据库管理员主要是出于研究的目的才会用到这个文本形式的控制文件。另外就是有时候需要手工创建控制文件时，可以拿这个文件进行参考。
　　总之，除非有特殊的目的，数据库管理员还是直接以二进制文件形式进行备份为好。因为只有二进制文件在数据库控制文件损坏时可以直接拿来使用。而不用像文件文件那样，需要借此进行重建控制文件的控制。
　　二、哪些因素会导致控制文件的更改?
　　要选择一个备份控制文件的时机，首先需要知道哪些因素会导致控制文件的更改。然后再从中分析出备份控制文件的合适时机。通常情况下，导致控制文件更改的因素有很多。或者说，控制文件基本上是时时刻刻都在更改的。若每次更改都备份控制文件的话，显然工作量会很。为此数据库管理员需要抓住的是哪些对数据库的启动与运行具有实质性影响的更改。只抓关键，而不是眉毛胡子一把抓。
　　一般来说，如果发生如下事件的话，则数据库的控制文件会发生改变。如当数据库发生物理变化时，如删除或者添加数据文件时，数据库系统会自动将这个信息反映到控制文件中。如当系统出现检查点时间时，检查点进程会自动修改控制文件，以便数据文件和重做日至文件保持同步。如果数据库采用的是归档模式，则归档进程会自动用归档日至文件名和日至序列号等信息去修改控制文件。使用RMAN备份工具时，RMAN的备份信息会被记录到控制文件中。可见这些因素都在影响着控制文件的更新。特别是检查点进程。因为数据库检查点的时间间隔可能只有1小时，甚至更多。此时每发生一个检查点事件，就会更新控制文件。如果每更新一次就做一次备份的话，那工作量就可想而知了。为此，要从以上这些因素中挑选一些必须要进行控制文件备份的时机。
　　三、选择控制文件备份的合适时机。
　　其实根据笔者的经验，只有第一类事件，即数据库发生物理变化时，对控制文件进行备份就可以了。因为只有这个事件对控制文件造成的影响，才会影响到数据库的启动与稳定运行。其他对控制文件的更改，只要下一次事件发生后，就会自动更新。如就拿检查点来说，如果采用的新的控制文件，没有记录最新的检查点信息，也没有关系。只要在下次检查点时间发生之前不要采用恢复作业即可。也就是说其影响是暂时的。等到新的检查点时间发生时，其就会将最新的信息更新到控制文件中。具体的来说，当发生以下事件对数据库的控制文件产生更新时，最好及时对控制文件进行备份。
　　一是表空间发生的更改。如管理员新增了一个表空间，或者删除了表空间，此时都会对控制文件产生很的影响。要进行及时的备份。另外需要注意的一点就是如果更改了表空间的状态，如将表空间设置为只读时，此时虽然没有对数据库的物理结构产生很大的影响，但是其可能影响数据的一致性问题。为此若更改了数据库表空间读写状态时，也最好对控制文件进行必要的备份。
　　二是数据文件发生物理性变化时，即新增了数据文件或者删除了某个数据文件，此时就需要对控制文件进行备份。因为如果此时不备份的话，若因为故障采用了旧的控制文件，数据库就不会读取新家的数据文件中的内容，从而导致数据丢失。所以，当数据文件发生物理变化时，对控制文件进行备份是必要的。
　　三是重做日志组或则重做日志文件发生物理性变化，如添加或者删除时，跟上面的道理相同，也最好手工立即进行控制文件的备份。
　　除了以上三个事件，一般情况下不需要对控制文件进行备份。当然，在条件可行的情况下，数据库管理员也可以将以上的备份语句写入到一个脚本程序中。然后利用系统的任务计划实现控制文件的自动备份。这也是可行的。不过即使如此，也很难实现控制文件一有变化就马上进行备份。笔者以前在Linux系统上进行过类似的测试，可以根据备份文件的更新时间来进行备份。不过笔者觉得没有这么做的必要，这只是出于技术上好奇才去研究的。各位读者若对此感兴趣的话，下次笔者可以将这个方案拿出来供家讨论。
　　总之笔者认为当数据库的物理结构发生变化时对控制文件进行备份即可。而不需要控制文件一有变化就对其进行备份。这有点劳命伤财的迹象。