数据库介质失败后的数据库恢复

[摘 要] 文章根据具体的数据库管理系统（SYBASE ASE 12.5）分析介质失败后如何恢复数据库，包括数据库介质失败后的各种情况、数据全部可恢复情况的灾难恢复步骤、部分恢复数据库数据的灾难恢复步骤等内容。

[关键词] 数据库；介质；备份；恢复

[作者简介] 谢声时，中国人民银行海口中心支行，研究方向：信息安全，海南 海口，570105

[中图分类号] TP311 [文献标识码] A [文章编号] 1007-7723（2012）10-0034-0002

为了数据库的安全，我们对应用系统数据制定了可行的备份策略。数据库介质失败后，数据库的恢复程度因数据库的存放方法及备份策略的不同而不同。系统管理员制定每天进行数据库备份、每小时进行事务日志备份的备份方案。早上8时，系统进行了数据库的备份。早上9时，系统进行了数据库事务日志的该天第一次备份，早上10时，系统进行了数据库事务日志的该天第二次备份。早上10时后，数据库介质失败造成数据库失败。很显然，由于没有备份，10时后到介质失败前的数据修改很可能没法恢复。我们能否恢复最后一次执行数据库事务日志备份和介质失败点之间的数据库数据修改呢？针对数据库介质的失败，在最后一次数据库事务日志备份和介质失败点之间的数据修改可能全部不能恢复，也可能全部可以恢复。本文将根据具体的数据库管理系统（SYBASE ASE 12.5）分析介质失败后如何恢复数据库。

一、数据库介质失败后的情况

数据库介质失败后可分为在最后一次数据库事务日志备份后的数据全部不能恢复、全部能恢复和需要部分恢复的情况。

（一）最后一次事务日志备份后的数据全部不可恢复

该情况下数据库设备没有镜像且存放数据库日志的设备也失败。早上8时，系统进行了数据库的备份。早上9时，系统进行了数据库事务日志的该天第一次备份，早上10时，系统进行了数据库事务日志的该天第二次备份。10时后，数据库介质失败造成数据库失败。由于没有备份，10时后到介质失败前的数据修改全部没法恢复，数据库的灾难恢复最多能恢复到最后一次事务日志备份前的数据。

（二）最后一次事务日志备份后的数据全部可恢复

该情况下数据库设备有镜像或者存放数据库日志的设备没失败。早上8时，系统进行了数据库的备份。早上9时，系统进行了数据库事务日志的该天第一次备份，早上10时，系统进行了数据库事务日志的该天第二次备份。10时后，数据库介质失败造成数据库失败。如果数据库设备有镜像，则10时后到介质失败前的数据修改没受介质失败的影响，镜像设备仍能继续工作。如果存放事务日志的设备没失败，则10时后到介质失败前的关于数据修改的事务日志没受介质失败的影响，仍可进行事务日志的备份。数据库的灾难恢复能恢复到介质失败前的所有数据。

（三）最后一次事务日志备份的数据仅需要部分恢复

该情况下用户操作失误破坏数据库数据。早上8时，系统进行了数据库的备份。早上9时，系统进行了数据库事务日志的该天第一次备份，早上10时，系统进行了数据库事务日志的该天第二次备份。10时30分一个用户由于操作失误删除了一个重要的数据表中的数据。事后，我们发现重要的数据被删除了。这时，我们考虑的是部分的数据恢复，仅将数据库数据恢复到早上10时30分。

二、数据全部可恢复情况的灾难恢复步骤

数据全部可恢复情况的灾难恢复步骤为：

1. 执行dump transaction with no_truncate命令备份数据库的事务日志。其中，执行dump transaction with no_truncate命令的语法格式为dump transaction database_name to device_name with no_truncate。如dump transaction safesdb to dump_salesdb_log with no_truncate。

2. 删除坏的数据库。

3. 重新创建新的数据库。

4. 用load database 命令恢复最新的数据库备份。按备份时间顺序执行事务日志的恢复，其中最后一个恢复的事务日志是由带with no_truncate参数的备份生成的。

三、部分恢复数据库数据的灾难恢复步骤

部分恢复数据库数据的数据操作即按时间点恢复数据库数据。按时间点恢复数据库的操作主要是一个load transation命令执行过程，它可以通过事务日志中的特别的时间点依据事务日志恢复数据库数据。使用load transaction命令恢复分数据库数据命令的语法格式为load transaction database_name from device_name with until_time="date-time"其中，date-time的格式为“month，day，year hh：mm：ss：ms [AM|PM]”。当需要按时间点恢复数据库数据时，可按以下步骤进行：

1. 使用sp_who命令列出正在使用数据库的用户，并通知在线用户退出系统。

2. 设置数据库操作，将数据库的模式设置为单用户模式。

sp_dboption salesdb， "single user"， true

use salesdb

checkpoint

3. 使用dump transaction命令备份数据库的事务日志。

dump transaction salesdb to dump_salesdb_log。

4. 使用load database命令恢复数据库的最新数据库备份。

load database salesdb from dump_salesdb_db。

5. 使用load transaction命令按顺序恢复最后一次备份数据库之后的事务日志备份。

6. 使用带参数"until_time"的load transaction命令恢复带有失误操作记录的事务日志，使数据库事务日志恢复到失误操作前的时间点。

load transactionsalesdb from dump_salesdb_log

with until_time="Dec 31，2006 11：59：59：650PM"。

7. 使用checkstorage检查和纠正恢复后的数据库的一致性。

dbcc checkstorage （salesdb）。其中，checkstorage是检查数据库一致性的命令。该命令的执行需要一些准备工作，包括规划用于checkstorage操作的"dbccdb"的资源、配置"number of worker processes"和"memory per worker process"服务器配置、安装"dbccdb"数据库、增加工作空间片段、创建数据库"dbccdb"的工作空间、指定目标数据库特征、估计配置等工作。

8. 备份恢复后的数据库。

dump database salesdb to dump_salesdb_dev。

9. 将数据库的单用户模式更改为非单用户模式。

sp_dboption salesdb， "single user"， false。

[参考文献]

[1]Performance and Tuning：Configuring Adaptive Server Enterprise Volume 2.