第八章 备份和恢复

备份是数据库系统安全、可靠的重要保证。一旦系统遭到破坏，就可以使用备份进行恢复。数据库的归档日志模式决定了用户可使用的备份和恢复方式，用户应根据自身可接受的数据库恢复手段，合理地选择数据库的日志归档模式及备份方式。

本章介绍了数据库系统可能发生的各种故障、数据库一致性的概念及保证措施，以此为基础对数据库的各种备份、恢复方式进行了讲解，说明了数据导入、导出工具和备份、恢复工具之间的区别。针对常用数据库系统的备份和恢复，本章在最后进行了讨论。

8.1 数据库系统的主要故障

在数据库系统的运行过程中，谁也无法保证系统不会出现故障。由于故障的原因、所引起的后果各不相同，不同的故障需要采用不同的解决方法。依照故障对数据库系统的破坏程度，我们可以将故障分为事务故障、系统崩溃、磁盘故障。

1. 事务故障

事务故障是指一个正在执行的事务发生中断，没能够完全执行并提交。事务故障可能由以下的原因造成：

（1）逻辑错误。事务由于某些内部条件没能满足而无法继续正常执行，这些内部条件包括：非法输入、数据溢出、超出资源限制等。

（2）系统错误。事务由于系统处于不正常状态而无法继续正常执行，系统的这种不正常状态可能由死锁、处理事务的后台进程出现异常、网络中断等原因造成。

（3）用户干预。由于操作失误、数据不正确等原因，用户提前中止了事务的执行。

事务故障不可预期。在出现事务故障后，系统回滚事务，不需要恢复数据库。用户在修改了相关错误之后，可以重新执行该事务。

2. 系统崩溃

系统崩溃是指数据库系统突然进到一种停机状态，不能从这种状态继续执行，所有的业务处理中断。系统崩溃可能由以下的原因造成：

（1）操作系统出现异常

（2）数据库系统出现异常

（3）机房断电或人为关机

系统崩溃发生时，内存中的所有数据全部丢失，而磁盘等外部存储设备仍旧完好无损。系统在重新启动时，需要执行数据库恢复。

3. 磁盘故障

磁盘故障是指存放数据库数据的磁盘设备出现故障，造成磁盘中数据全部或者部分无法读写。这种磁盘故障可能由以下的原因引起：

（1）磁盘损坏

（2）磁盘控制器损坏

（3）人为地删除或者破坏了磁盘上的数据文件或者设备

磁盘故障破坏了物理数据库，影响到正在存取数据的所有事务。这种故障发生的概率最小，但是危害最大。

8.2 数据库的一致性

为什么事务故障不需要数据库恢复，而系统崩溃和磁盘故障却需要呢？数据库恢复要如何做才算完成呢？这就涉及到数据库的一致性。

8.2.1 什么是数据库一致性

数据库的一致性，也就是数据库中数据的一致性。我们知道，关系数据库系统中的各个数据表是互相关联的，是特定企业中各种信息、业务处理和往来的二维抽象。随着企业中各种信息的变化、业务的发生，数据库中的数据需要不断地被更新，从而能够正确地反映企业中的这些变化。这就是数据库的一致性，它要求数据库中的数据在某一个时刻能够正确地反映同一时刻企业中的各种数据处理，不能有任何的缺失和不完整。

数据库的一致性非常重要。不一致的数据对企业毫无用处，甚至是有害的。在第6章中，我们讨论了事务的一致性。数据库系统是以事务为基本操作单元，来处理数据库中的数据。系统正是通过保证单个事务的数据一致性，来达到整个数据库的数据一致性。

8.2.2 数据库一致性的恢复

所谓数据库恢复，也就是数据库一致性的恢复。在数据库系统发生故障、一致性遭到破坏后，管理员使用现有的数据库备份、日志信息，将数据库恢复到故障发生那一时刻的一致性状态。

事务故障的发生，只会影响到个别用户的操作。数据库系统在发现事务故障后，在向用户返回出错信息的同时，回退事务已经执行的操作，回收事务拥有的资源。由于事务本身的一致性要求，事务故障不会影响到整个数据库的一致性，因此不需要进行数据库的恢复。

在系统崩溃、数据处理突然中止时，可能存在以下的情况：

（1）一些事务的处理还没有全部完成，而这些事务已执行操作的更新已被写入了磁盘。

（2）一些已提交事务所引起的更新仍旧保留在内存中，没有写入磁盘作永久性保存。

由于这些原因，在系统崩溃时数据库会处于不一致性状态。如果系统发生磁盘故障，就会造成数据库中部分或者全部数据的丢失，数据库一致性自然遭到破坏。

因此在出现了系统崩溃、磁盘故障之后，不可避免要进行数据库恢复，使数据库处于一致状态。

8.2.3 数据库一致性的保证措施

数据库的一致性非常关键。通过前面章节的介绍，我们知道数据库系统采取了许多有力措施，来保证数据的一致性。主要有：事务和并发控制、数据库日志、检查点操作、备份和恢复。

1. 事务和并发控制机制

在数据库系统中，对数据的更新处理以事务为操作单元，事务的原子性要求保证了单个事务的数据一致性。对多个事务的并发处理，并发控制机制实现了事务的可串行化调度，避免了事务之间的互相影响，保证了整个数据库的一致性。有关事务和并发控制机制的进一步讨论，可以参看第6章。

2. 数据库日志

数据库系统中对数据的任何更新处理，都要记录操作日志。任何数据库系统都遵循先写日志的原则。通过数据库日志，系统在保证单个事务数据一致性的同时，又保证系统恢复时能够使整个数据库处于一致状态。有关数据库日志的详细描述，可以参看第7章。

3. 检查点操作

当系统发生故障时，原则上可以通过搜索整个日志记录，决定那些事务需要重做，那些事务需要回退，从而使数据库处于一致性状态。然而这种做法的缺陷也比较明显：

（1）搜索时间太长

（2）恢复过程中的大多数工作是不必要的

大多数需要重做的事务都已经将其更新写入磁盘，尽管重做这些操作不会造成不良后果，但会使恢复过程变得很漫长。

为避免这些缺陷，数据库系统引入了检查点操作。检查点操作定期执行，将当前内存中的日志信息、被更新的数据块写入磁盘，然后在日志文件中增加检查点标记。在系统恢复时，以日志文件中的最后一个检查点标记为分界线，决定那些事务需要重新执行，那些事务需要回退。有关检查点操作的详细描述，可参看第2.2.6、8.4.1两节。

4. 备份和恢复

数据库系统的备份和恢复机制，在系统遭到破坏后能够恢复数据库的原有数据，使数据库重新处于一致性状态。这就是我们这一章需要讨论的内容。

8.3 数据库备份

数据库备份就是将数据库中的数据以及数据库的物理和逻辑结构等相关数据字典信息，存放在另外的存储介质中进行保存。一旦数据库遭到破坏，就可以利用这些数据、数据字典信息重建数据库。

数据库的备份操作可以在脱机状态下进行，其他用户要断开和数据库的连接，不能访问数据库；也可以在联机状态下进行，允许其他用户同时操作数据库；既可以备份整个数据库，也可以只备份数据库的某些部分。对数据库备份方式的选择，与特有的应用系统、数据库的日志归档模式密切相关。

依据备份时是否允许其他用户访问数据库，可以将数据库备份分为：联机备份和脱机备份。依据备份所涵盖数据及相关信息的范围，可以将数据库备份分为：完整备份和部分备份。

8.3.1 联机备份和脱机备份

联机数据库备份，就是在正常的系统运行过程中对数据库进行备份。由于在备份进行时，允许其他用户访问数据库，进行事务处理，因此一些事务对数据的更新，可能只是部分地写入备份中，致使备份中的数据不一致。正是由于这个原因，联机数据库备份也被称为非一致性的备份。

很多情况下，用户的应用环境需要24小时不间断地运行，要求数据库的联机备份。由于备份中的数据处于不一致状态（除非备份时没有其他事务处理或者整个数据库处于只读状态，不允许用户修改其中的数据），使用该备份恢复数据库时，必须要使用日志文件，使数据库处于一致状态，因此要执行联机数据库备份，必须使数据库处于归档日志模式。

联机状态下的数据库备份具有以下的特点：

（1）数据库必须使用归档日志模式

（2）备份中的数据处于不一致状态

（3）支持不停止的业务处理

（4）维护数据库的高可用性

脱机数据库备份，就是停止数据库系统的正常运行或者使数据库处于只读、单用户模式而进行的备份。由于没有其它更新事务的处理，脱机备份中的数据是一致的，因此脱机备份也被称做一致性的数据库备份。

要保证数据的一致性，执行脱机备份要中断业务的正常处理。由于备份中的数据是一致的，使用该备份恢复数据库时，可以不需要日志文件。因此使用脱机备份的数据库，可以使用归档和非归档日志模式。

在非归档日志模式下，使用脱机数据库备份进行恢复，可能会造成数据的丢失，除非从备份操作开始到故障发生那一刻的所有日志文件都没有被覆盖。

脱机状态下的数据库备份具有以下的特点：

（1）数据库可以使用归档和非归档日志模式

（2）备份中的数据处于一致状态

（3）备份时正常的业务处理被中断

8.3.2 完整备份和部分备份

完整备份就是备份数据库中的所有数据，不管这些数据从上一次备份以来是否被更新。

完整备份操作简单、处理方便，是最常用的数据库备份方法，可以在数据库系统联机或者脱机情况下执行。如果数据库包含大量数据，那么完整备份就需要比较长的时间，占用比较多的存储空间。

一般来说，在数据库的备份和备份之间，被更新数据只占很少的一部分，完整备份的大部分操作是不需要的。我们完全可以通过其它的途径，来减少这部分操作对系统资源的消耗。

部分备份就是只备份数据库中的部分数据，这些数据在上一次备份之后发生了改变。

我们可以使用两种类型的部分数据库备份。第一种类型是部件备份，基于数据库的结构层次来执行，如可以备份单个表空间、数据文件等。这些表空间、数据文件中的数据在上一次备份之后发生了改变。要使用此种类型的备份，用户必须要知道：应用系统对那些表空间、数据文件中的数据做了更新。对用户来说，会有一定的难度。

另一种类型的部分备份就是增量备份，是由数据库系统决定从上一次完整备份、增量备份以来，那些数据已经被更新，从而只将这些被更新的数据进行备份。

部分备份可以在数据库系统联机或者脱机情况下执行。由于只备份被更新的数据，从而缩短了备份时间、减少了存储空间使用。另外，要保证整个数据库的一致性，执行部分备份的数据库必须使用归档日志模式。

完整备份和部分备份各有自己的优缺点。完整备份操作简单，能更快地恢复数据库，但备份时要花费更多时间和存储空间；部分备份节省备份时间和存储空间，但需要更多时间进行系统恢复。一种常用的备份策略，是将完整备份和部分备份结合起来。例如：在周末执行数据库的完整备份，而在其它时间执行部分备份，从而能充分利用两种备份的优点，避免它们的缺点。

8.3.3 备份方式的选择

数据库的日志归档模式，决定了用户可以使用的备份和恢复方式。反之，用户采用的备份和恢复方式，也决定了数据库日志归档模式的选择。

数据库在非归档日志模式下，仅仅可以执行脱机的数据库完整备份（可见图8-1）。

数据库在归档日志模式下，可以选用任意的数据库备份方式（可见图8-2）。

用户应根据自身应用系统特性、日常系统维护方式，合理地选择数据库的日志归档模式、备份和恢复方式。

8.4 数据库恢复

数据库恢复，就是在异常情况下数据库的一致性遭到破坏而无法使用，通过数据库备份、日志信息，将数据库恢复到一致性状态的过程。

在数据库系统运行过程中，会出现三种类型的故障，其中系统崩溃、磁盘故障需要进行数据库的恢复。依据这两种故障的不同恢复方式，我们可以将数据库恢复划分为崩溃恢复和介质恢复。

8.4.1 崩溃恢复

数据库系统在正常停止时，会将内存中的所有日志信息、被更新过的数据写入磁盘，然后在日志文件的最后写入检查点记录。这样，所有已提交事务的更新全部落实到磁盘中，数据库中的数据就处于一致状态。如果数据库系统异常中止，那么仍旧在内存中的日志信息、被更新的数据就全部丢失。在这种情况下，一些事务的更新处理可能只是部分落实到磁盘中，从而导致数据库处于不一致状态。重新启动时，在用户能够访问数据库中的数据之前，数据库系统要首先使用日志信息，使数据库处于一致状态。这就是崩溃恢复。

1. 崩溃恢复的处理方式

崩溃恢复就是数据库系统在异常中止后重新启动，使用数据库日志文件，恢复数据库到一致状态的过程。其关键点就是：决定那些事务需要重做，那些事务需要回滚。通过重做已提交事务，避免事务的丢失；通过回滚未完成事务，删除造成数据不一致的部分事务更新。所有这些操作，是依靠日志文件以及文件中的最后一个检查点记录来实现的。

数据库系统在执行检查点操作时，暂停所有事务的更新处理，将内存中的所有日志信息、被更新过的数据写入磁盘，作永久性的保存。基于日志文件的最后一个检查点记录，系统中的事务有以下三种状态：

（1）在此之前已经提交。这些事务的更新，肯定已经落实到磁盘，不需要考虑。

（2）在此之前已开始执行，但还没有提交。这些事务的更新，在此之前的部分已经落实到磁盘，但无从确定在此之后的部分是否落实到磁盘。

（3）在此之后开始。这些事务的更新，不能确定是否落实到磁盘。

因此，在崩溃恢复时，系统只要基于日志文件中的最后一个检查点记录，找到所有无法确定其更新全部写入磁盘的事务。对这些事务，由最后一个检查点记录开始，正向扫描日志文件，重新执行有提交记录的事务，没有提交记录的事务就进行回滚，这样就可以使数据库处于一致状态。

2. 崩溃恢复的处理步骤

对崩溃恢复，数据库系统大体上采用以下步骤进行处理：

（1）从日志文件的最后一条记录开始，由后至前扫描日志记录，找到日志文件中的最后一个检查点记录。

（2）找出该检查点操作发生时，正在执行、还没有提交的事务清单。然后由该检查点记录开始，正向扫描日志文件，找到该检查点操作发生后开始的新事务和提交的事务。由此我们可以得到两个事务清单：

① 有提交标识的事务清单。这些事务需要重新执行。

② 没有提交标识的事务清单。这些事务需要回滚。

（3）对需要重新执行的事务，从最后的检查点操作记录开始，正向扫描日志文件，找出这些事务的操作记录重新执行。对需要回滚的事务，从日志文件的最后开始，由后向前扫描，找出这些事务的操作，执行反向处理。

经过以上的崩溃恢复处理，数据库恢复到一致状态，系统就正常运行，允许用户访问数据库中的数据。

3. 崩溃恢复的使用说明

崩溃恢复由数据库系统自动完成，和数据库使用的日志归档模式无关。只要系统非正常关闭，再次启动时就要执行崩溃恢复。数据库系统在异常中止后重新启动，往往需要更长的时间才能够访问，就是因为系统要执行崩溃恢复的缘故。

崩溃恢复不需要使用数据库备份。从第7章我们知道：日志文件可处于活动和不活动两种状态。崩溃恢复需要使用处于活动状态的日志文件，因而它们不能被归档、删除。一旦这些活动的日志文件不小心被删除或者遭到破坏，无法完成崩溃恢复，无法恢复数据库一致性，那么整个数据库系统就遭到破坏。如果出现这种情况，就只能使用数据库备份，进行数据库的不完整恢复，从而造成数据的丢失。

如果为了提高数据库系统的处理性能，不要求事务提交前将日志信息写入磁盘，那么系统的异常中止可能会造成已提交事务的丢失，崩溃恢复不会重新执行这些事务。在这种应用环境下，在系统异常中止、重新启动后，需要进行人工检查，发现而重新执行那些丢失的事务。

8.4.2 介质恢复

由于数据库使用的磁盘介质遭到破坏，数据库中的全部或者部分数据无法读取，就需要使用数据库的备份、日志信息，来恢复遭受破坏的数据，使数据库处于一致状态，这就是介质恢复。

相对于崩溃恢复，介质恢复由用户执行，对系统的影响更大，需要花费的时间更长，操作更复杂。这就对用户提出了很高的要求。有时候不正确的命令使用、不正确的数据库备份和恢复方式选择，都可能造成意想不到的后果。在需要介质恢复时，用户必须要慎重考虑。

数据库使用的日志归档模式、备份方式，决定了可使用的介质恢复方式。

1. 非归档日志模式下的介质恢复

在数据库的非归档日志模式下，只能执行数据库的脱机完整备份。使用脱机备份恢复数据库，只能将数据库恢复到备份操作执行的那一时刻。从备份操作到故障发生这一期间内，所有的更新处理全部丢失，用户必须手工、重新执行这些操作。数据库的这种日志使用模式，备份和恢复处理相对比较简单，适合仅用于查询、开发测试环境或者有很少更新处理的数据库系统。

2. 归档日志模式下的介质恢复

大多数生产环境都使用数据库的归档日志模式。在此模式下，可以使用多种方式备份数据库。使用数据库备份和日志文件，我们可以将数据库恢复到故障发生的那一时刻。在恢复操作执行时，整个处理过程需要经过两个阶段：

（1）使用数据库备份，重构数据库，将数据库复原到备份操作执行时刻的状态。

（2）使用日志文件，重新执行已提交事务，回滚未完成事务。

根据故障原因和用户的实际情况，可以在第二阶段使用全部或者部分日志文件。依据第二阶段对日志文件的使用，我们可以进一步将介质恢复划分为完整恢复和不完整恢复。

3. 归档日志模式下的完整恢复

归档日志模式下的完整恢复，就是在介质恢复的第二个阶段，使用所有的日志文件，使所有已提交事务重新执行，而回滚所有未完成的事务，从而将数据库恢复到故障发生的那一时刻。

数据库的完整恢复，可以基于整个数据库进行，也可以基于单个表空间、数据文件进行。如果只是数据库中的单个或者多个表空间、数据文件遭到破坏，就可以只针对被破坏表空间、数据文件进行恢复。相对于整个数据库的恢复，这种恢复所需时间少，而且在恢复时不影响用户访问数库库的其余部分。

4. 归档日志模式下的不完整恢复

归档日志模式下的不完整恢复，就是在介质恢复的第二个阶段，仅仅使用部分日志文件，将数据库恢复到备份操作之后、故障发生之前的某一个时刻。

大多数情况下，我们需要对被损坏的数据库执行完整恢复。然而在下列情况下，数据库的不完整恢复就是必要的：

（1）当前处于活动状态的日志文件丢失或者被破坏。

（2）数据库恢复需要的被归档日志文件丢失或者被破坏。

（3）用户执行了错误的操作，删除或者更改了重要表中的数据，需要将数据库恢复到该误操作执行前的状态。

在不完整恢复处理时，用户可以明确指定要使用的日志文件；也可以指定一个时间点，由系统来决定将数据库恢复到这个时间点需要使用的日志文件。另外，为保证数据库的一致性，用户只能对整个数据库进行不完整恢复。基于单个表空间、数据文件上的不完整恢复是不允许的。

8.5 数据的导入和导出工具

每一个数据库系统，都会提供一些数据的导入和导出工具，用来将数据库中的数据导出到文本或者二进制的操作系统文件中，也可以从这些文件中将数据导入到数据库。在下列情况下，这些工具特别有用：

（1）在不同种类的数据库系统之间传递数据

（2）在不同的操作系统平台之间传递数据

数据的导入和导出工具，还可以用来备份和恢复数据库。用户可以使用导出工具，将整个数据库中的数据和数据字典信息一并导出，进行保存。在数据库遭到破坏后，首先使用数据字典信息重建数据库，然后再将所有的数据导入，从而起到数据库的备份和恢复目的。

这种数据库的备份和恢复方式，存在着以下的问题，需要用户注意：

（1）操作时间长。使用导入和导出工具，在导入、导出数据时需要在数据库的数据存放格式和操作系统的文本或二进制格式之间进行转换，处理时间自然会加长。

（2）将造成数据的丢失。使用导入和导出工具恢复数据库时，只能将数据库恢复到数据导出操作执行的那一时刻。从数据导出操作到故障发生这一期间内，所有的更新处理全部丢失。

（3）对数据库的使用存在问题。在数据导出时，如果数据库处于不一致状态，那么导出的数据就不一致。将这样的数据导入数据库，就没有办法使数据库处于一致状态，对数据库的使用就会存在问题。保证数据库的一致性，是使用导入和导出工具进行数据库备份和恢复要优先考虑的问题。

数据的导入和导出工具，虽说也可以达到备份和恢复的目的，但并不是数据库的备份和恢复工具，我们一定要将它们明确地区分开来。

有一些用户的应用系统使用了这样的备份、恢复方式。在每天的业务处理完成后，使用数据的导入和导出工具，将整个数据库中的数据导出，作为数据库的备份。这些用户需要明白的是：一旦数据库遭到破坏，将前一天导出的数据导入数据库，当天的数据更新肯定会全部丢失。能否接受数据更新的丢失以及可采取的补救措施，是他们必须要考虑的问题。

8.6 常用数据库系统的备份和恢复管理

每一个数据库系统都有自己的数据库备份和恢复机制，都会提供一些数据的导入和导出工具。基于对备份和恢复相关知识的掌握，用户可根据需要选择合适的数据库备份和恢复方式。

我们将在下面对常用数据库系统的备份和恢复管理进行讲解。至于它们支持的数据导入、导出工具，这里不作介绍，有兴趣的读者可参看其它相关书籍。

8.6.1 DB2数据库系统

DB2数据库可以使用日志的非归档和归档模式。由于一个表空间只属于一个数据库，并且数据库使用几个系统文件，记录单个日志文件中更新操作所涉及到的表空间，从而使数据库系统的备份和恢复，可以基于单个的表空间进行。

1. 数据库备份

DB2系统采用单实例多数据库结构，数据库和数据库之间互相独立。备份操作基于单个数据库、在数据库管理器的运行环境中进行。

对DB2数据库进行备份，可以使用联机和脱机备份，也可以使用完整和部分备份，所有的备份操作通过命令backup database完成。数据库的日志归档模式，决定了可以采用的备份方式。

缺省情况下，数据库备份使用脱机备份，要求所有的用户断开和数据库的连接。可以使用force application all命令，强制断开所有用户和数据库的连接。要使用联机备份，需要在备份命令中指定online选项。

如果没有在备份命令中明确指定，备份操作就基于整个数据库进行。要执行部分备份，必须在备份命令中指定相关选项。DB2系统支持两种类型的部分备份。增量备份有两种处理方式：incremental和delta。在incremental方式下，将对上一次完整备份之后发生改变的所有数据进行备份。而使用delta方式，是备份上一次备份（可以是完整备份，也可以是增量备份）之后的所有数据改变。DB2系统的部件备份，只能够在表空间的级别上实现，可以在命令中指定要备份的一个或者多个表空间。

2. 数据库恢复

用户要访问DB2数据库，首先要启动数据库管理器。然而在数据库管理器启动之后，所有数据库并不会被打开。数据库可以由管理员使用命令手工激活，也可以在收到用户数据访问请求后被自动激活。数据库在被激活时，系统会检查它的状态。如果数据库处于不一致状态，就自动执行崩溃恢复。

DB2系统有三种类型的恢复方式：崩溃恢复（crash recovery）、版本恢复（version recovery）、前滚恢复（rollforward recovery）。版本恢复和前滚恢复属于介质恢复，分别对应介质恢复的两个阶段。版本恢复使用数据库备份，通过命令restore database将数据库恢复到备份操作执行的那一时刻；前滚恢复使用日志信息，通过命令rollforward database将数据库恢复到故障发生的那一刻或者之前的任一时刻。

DB2数据库的介质恢复，要求在实例的运行环境中进行。数据库的日志归档模式，决定了恢复操作的处理步骤。

在日志的非归档模式下，只能使用数据库的一致性备份进行版本恢复。在恢复完成后就可以打开数据库。

而在日志的归档模式下，在版本恢复完成后，还需要使用日志文件进行前滚恢复，在此之后才可以打开数据库。在前滚恢复时，可以根据需要，指定使用全部还是部分日志文件，从而决定执行完整恢复还是不完整恢复。

此外，在数据库的日志归档模式下，还可以基于表空间进行数据库的部分恢复。这种部分恢复，可以在系统联机状态下进行，从而不会中断用户对其它数据的访问。

8.6.2 ORACLE数据库系统

ORACLE数据库系统可以使用日志的非归档和归档模式。由于系统在执行检查点操作时，除了日志文件，还需要在每一个控制文件、数据文件的头部，写入相应的时间戳信息，因而系统可以对单个的表空间、数据文件进行备份和恢复，操作比较方便和灵活。但因此对数据库系统性能的不利影响，就不可避免。

1. 数据库备份

ORACLE系统采用多实例单数据库结构。可以使用以下两种方式备份数据库：

（1）使用rman工具。在rman运行环境中，可以手工使用命令备份数据库，也可以设定备份操作的执行脚本、执行时间，由系统自动完成数据库的备份。

（2）使用操作系统命令。数据库管理员执行操作系统命令，拷贝组成数据库的数据文件到另外的存储位置上，从而达到备份的作用，这种备份被称为用户管理备份。

在ORACLE系统中，把rman工具备份和用户管理备份统称为物理备份。因为这两种备份方式，是直接对组成数据库的物理文件进行备份。把使用数据导入和导出工具执行的备份称为逻辑备份，因为这种备份不仅要导出数据库中的数据，而且会把各种对象的创建语句放置到二进制文件中。

对ORACLE数据库的物理备份，可以使用联机和脱机备份，也可以使用完整和部分备份。数据库的日志归档模式，决定了可以采用的备份方式。

使用rman工具备份，必须要保证实例被启动。要执行脱机备份，数据库需要处于mount状态；可以在数据库被打开、mount状态下，执行联机备份。

ORACLE系统支持两种类型的数据库部分备份。部件备份能够在表空间、数据文件的级别上实现，rman工具和用户管理备份均支持部件备份；增量备份只能在rman工具中实现，不能在用户管理备份中使用。部分备份在rman工具和用户管理备份中的具体实现和要求，与使用脱机备份还是联机备份有关。

使用用户管理备份，可以在实例没有启动，或者实例启动、数据库处于mount或只读状态下，进行脱机备份。在执行联机备份时，首先要使用alter tablespace命令，使要备份的表空间、数据文件处于备份状态，然后才能使用操作系统命令进行拷贝。在拷贝完成后，再次使用alter tablespace命令结束表空间、数据文件的备份状态。

2. 数据库恢复

用户要访问ORACLE数据库，首先要启动实例。数据库在被打开时，系统会检查它的状态。如果数据库处于不一致状态，系统就自动执行崩溃恢复。

ORACLE系统的介质恢复，使用命令restore database、recover database来完成，这两个命令分别对应介质恢复的两个阶段。命令restore database使用数据库备份，将数据库恢复到备份操作执行的那一时刻；而命令recover database使用日志信息，将数据库恢复到故障发生的那一刻或者之前的任一时刻。

对应于数据库备份，ORACLE系统有两种类型的介质恢复方式：rman工具和用户管理恢复。不管采用那种介质恢复方式，数据库的日志归档模式，决定了恢复操作的处理步骤。

使用rman工具进行介质恢复，要求数据库处于mount状态，这样系统可以从控制文件中获取数据库的备份信息。在使用restore database、recover database命令恢复数据库之后，数据库的日志归档模式，就决定了数据库可以被打开的方式。

对用户管理恢复，如果数据库使用非归档日志模式，那么可以执行操作系统命令，用数据库备份（备份中包含日志文件）覆盖数据库现有的数据文件，在此之后，就可以启动实例、打开数据库，数据库的恢复处理完成，不会用到命令restore database、recover database。

如果数据库使用归档日志模式，在使用数据库备份（备份中不包含日志文件）覆盖现有数据文件之后，需要启动实例、使数据库处于mount状态。然后使用recover database命令，根据需要选择全部或者部分日志文件，进行完整或者不完整恢复，将数据库恢复到故障发生的那一刻或者之前的任一时刻。在此之后，才可以打开数据库，结束数据库的恢复处理。

另外，在数据库的日志归档模式下，可以基于表空间、数据文件，进行数据库的部分恢复。这种部分恢复，可以在系统联机状态下进行，从而不会中断用户对其它数据的访问。

8.6.3 INFORMIX数据库系统

INFORMIX数据库系统只能使用日志的归档模式。任何逻辑日志文件被写满后、再次被使用之前，必须被归档保存。由于一个表空间可以属于多个数据库，存放多个数据库中的数据，因此不能够基于单个的表空间、大块（chunk）进行数据库备份，但用户可以针对单个的表空间进行恢复。

1. 数据库备份

INFORMIX系统采用单实例多数据库结构，数据库和数据库之间关系紧密。数据库备份就是备份整个数据库系统（包含所有的数据库），不能够只对一个数据库单独进行备份。备份操作使用ontape命令，在系统的运行环境中完成。

对INFORMIX系统进行备份，可以使用联机和脱机备份，也可以使用完整和部分备份。缺省情况下备份在联机状态下执行。要使用脱机备份，可以使系统进入单用户模式。INFORMIX系统支持多个级别上的增量备份，但不支持部件备份，即不能仅仅对单个的表空间、大块进行备份。

另外，也可以使用onbar 命令进行数据库备份，它需要第三方的存储设备和相关软件。

2. 数据库恢复

INFORMIX系统的启动，将一并打开所有数据库。在数据库被打开时，系统会检查数据库的状态。如果数据库处于不一致状态，就自动执行崩溃恢复。有时候可能会由于中断的长事务，在回滚时没有空闲日志空间而引起崩溃恢复失败。这时就需要使用介质恢复，来恢复数据库系统。

INFORMIX系统的介质恢复，分为物理恢复和逻辑恢复，分别对应介质恢复的两个阶段。物理恢复将数据库恢复到备份操作执行的那一时刻，而逻辑恢复使用物理和逻辑日志文件，将数据库恢复到故障发生的那一刻或者之前的任一时刻。

数据库中被破坏表空间的类型决定了介质恢复可以使用的处理过程。根表空间（root tablespace）、存放物理日志或者逻辑日志的表空间，属于关键表空间。如果这些表空间遭到破坏，那么数据库系统就无法启动、运行。除此之外的表空间，都属于非关键表空间。它们被损坏后，系统仍旧可以启动、运行，只是这些表空间中的数据不能被访问。

对遭到破坏的非关键表空间，可以在系统联机状态下进行介质恢复，使用物理和逻辑日志信息，将该表空间恢复到故障发生的那一刻。在恢复操作的执行过程中，允许用户访问其它表空间中的数据。这种恢复方式被称为热恢复。

如果被损坏的是关键表空间，就只能在脱机状态下进行介质恢复，这种恢复方式被称为冷恢复。为了降低恢复处理对用户数据访问的影响，我们可以首先使用冷恢复方式恢复关键表空间，然后启动数据库系统，在此之后再使用热恢复方式恢复非关键表空间。这种恢复方式被称为混合恢复。

数据库恢复操作使用ontape命令完成，也可以使用onbar 命令。

8.6.4 SYBASE数据库系统

SYBASE数据库系统只能使用日志的归档模式。日志表中的空间再次被使用前，日志信息必须被删除。SYBASE系统不支持任何形式的部分备份（包括增量备份），也只能对整个数据库进行恢复。

1. 数据库备份

SYBAS系统采用单实例多数据库结构。系统中的多个数据库可以分为：系统数据库和用户数据库，这些数据库之间的关系比较紧密。系统的启动，将一并启动整个实例、打开所有数据库。备份操作基于单个数据库、在系统的运行环境中进行。

对SYBASE数据库进行备份，可以使用联机和脱机备份，但不支持任何形式的部分备份。缺省情况下，数据库备份是在系统运行环境中联机进行。要执行数据库的脱机备份，可以设置数据库属性，使数据库处于单用户操作模式。数据库备份操作通过命令dump database完成。

由于SYBASE系统中日志信息以表的形式存放，因此数据库备份要包含日志信息，但数据库备份操作不会清除已经被备份的日志。一种好的做法就是首先使用命令dump transaction备份并清除不再被使用的日志，然后再执行数据库备份。

如果系统的数据字典发生了改变，就应当备份master系统数据库，以方便整个系统的恢复。

2. 数据库恢复

用户要访问SYBASE数据库，首先要启动整个系统。系统启动时将打开所有数据库，数据库按照系统数据库、用户数据库以及用户数据库在系统表sysdatabases中的顺序依次打开。数据库在被打开时，系统会检查它的状态。如果数据库处于不一致状态，就自动执行崩溃恢复。

系统中被破坏数据库的类型决定了介质恢复可以使用的处理过程。如果master系统数据库遭到破坏，那么整个系统无法启动、运行。在这种情况下，可以使用命令创建一个新的master数据库，然后启动到单用户环境，使用备份或者相关结构信息，对master数据库进行恢复。对其他的系统数据库，由于损坏不会导致系统不能运行，对它们的修复只要在系统运行环境下使用备份进行恢复即可。

如果用户数据库遭到破坏，则该数据库中的数据无法被使用，而整个系统仍旧可以运行。对它的恢复，需要在系统运行环境下进行。但必须要注意的是，在恢复之前要使用带with no_truncate选项的dump transaction命令，备份失败数据库当前的日志记录。有了这些日志信息，就可以将该用户数据库恢复到故障发生的那一刻。

对用户数据库的介质恢复，需要两个处理过程，分别对应介质恢复的两个阶段：

（1）使用命令load database，通过备份将数据库恢复到备份操作执行的那一时刻；

（2）使用命令load transaction，通过日志信息将数据库恢复到故障发生的那一刻或者之前的任一时刻。

在以上的恢复操作完成之后，使用online database命令使用户数据库处于联机状态，从而该数据库就可以被用户访问。

8.7 本章小结

数据库系统的运行会出现各种故障。依照故障的破坏程度，可以将故障分为事务故障、系统崩溃、磁盘故障。系统崩溃和磁盘故障需要进行数据库恢复。

数据库恢复就是恢复数据库的数据一致性。数据库的一致性，要求数据库中的数据在某一个时刻能够正确地反映同一时刻企业中的各种数据处理，不能有任何的缺失和不完整。为了保证一致性的实现，数据库系统采取了事务和并发控制、数据库日志、检查点操作、备份和恢复等有力措施。

数据库备份就是将数据库中的数据以及数据库的物理和逻辑结构等相关字典信息，存放在另外的存储介质中进行保存。可以划分为联机备份和脱机备份，完整备份和部分备份。

联机备份在正常的系统运行过程中进行，允许其他用户访问数据库，进行事务处理，也被称为非一致性备份。脱机备份在系统停止运行、数据库处于只读或者单用户模式下进行，系统中不存在其它更新事务，也称为一致性备份。

完整备份需要备份数据库中的所有数据。部分备份只备份上一次备份以来被更新的数据，可分为增量备份和部件备份。

数据库恢复就是在异常情况下，数据库的一致性遭到破坏而无法使用，通过数据库的备份、日志信息，将数据库恢复到一致性状态的过程。可以划分为崩溃恢复和介质恢复。

崩溃恢复在系统异常中止、重新启动时，由系统自动完成，使用处于活动状态的日志文件，将数据库恢复到一致状态。它和数据库使用的日志归档模式无关。

如果磁盘介质遭到破坏，数据库中的全部或者部分数据无法读取，就需要介质恢复。介质恢复需要使用数据库的备份、日志信息，由管理员手工执行。

在数据库的非归档日志模式下，介质恢复只能将数据库恢复到备份操作执行的那一时刻。

在数据库的归档日志模式下，如果所有的日志文件完好，使用完整的介质恢复，就可以将数据库恢复到故障发生的那一时刻。对不完整的介质恢复，可以根据需要，将数据库恢复到备份操作之后、故障发生之前的任一个时刻。

数据的导入和导出工具，并不是数据库的备份和恢复工具。使用这种方式进行数据库的备份和恢复，必须要考虑数据更新丢失以及可采取的补救措施。