解SQL Server数据库维护计划的实施步骤

      作为网管员，无论其管理的网络的规模是大还是小，在日常的管理中除了维护网络平稳运行、及时排除网络故障、保护网络安全等工作以外，备份网络中关键数据也是其中的一个非常非常重要的工作环节。

　　网络中的各种故障无非就分两种:软件故障和硬件故障。对于“硬件故障”可以通过维修或更换硬件设备得到及时解决;对于“软件故障”则可以通过重新安装或升级软件、重做网络或应用软件系统等方法及时解决，而且用此方法来解决网络故障大多需要一些基础的、关键的数据支持才能得以恢复正常。但是，网络中诸如此类的关键数据(特别是“应用软件系统”中的关键数据)的损坏或丢失，绝大部分是无法恢复和弥补的。即使可以恢复部分数据，弥补它们所花费的代价(诸如时间、人力、财力、物力等)都可能远远超出了公司的承受能力。

　　所以说，注重数据的备份工作是网管员日常管理工作中的必须时刻关注的一项任务，也是必须周期性重复操作的一项工作。

　　目录

　　现行备份策略

　　具体实现步骤

　　结束语

　　现行备份策略

　　我公司在组建局域网时，考虑到商业企业的特点，仔细考量了购、销、存三大环节中发生的各种数据及其存储问题后，选定了以Windows 20## Server为操作系统，SQL Server 2000为数据库平台来搭建局域网的应用系统的软件平台，以网线为载体将购、销、存等核心部门的计算机通过局域网平台紧密地连接起来。这样，各个核心部门每天的任何一笔业务都及时地、动态地存储到公司局域网的核心Dell服务器上的SQL Server 2000数据库中，并以此为基础平台向各方提供所需的各种数据服务。

　　因此，自公司局域网开始正式运作之日起，作为网管员的我就非常注重对局域网中的关键数据——特别是这些业务数据的备份工作。同时，我也希望备份数据的软件能够实现以下自动功能。

　　功能1:能够在每天的某个固定的时刻(如夜晚0:00:00，当然这个时间是可以自主设定的)对包含所有业务数据库在内的所有关键数据库进行一次“完全备份”。

　　功能2:能够在每天的0:00:00至23:59:59这段时间内，每间隔1个小时对功能1中所涉及到的各个数据库的事务日志进行“差异备份”。

　　功能3:每天都能够保留功能1和功能2中所生成的数据库和事务日志的最近两天的备份(即:前一天的和前两天的)，而且能够自动地删除久于两天前的所有数据库和事务日志的备份。

　　功能4:定期(如每个星期一次)将所有关键数据库的完全备份的副本备份到磁带或其它存储介质上(这部分工作可能需要手工完成)。

　　于是，围绕这些功能的实现，在日常管理工作中，我尽可能地尝试了各种备份数据的软件和方法，如Windows 2000自带的“备份”工具、SQL Server 2000自带的“备份”功能等。这些备份软件和方法的功能各有千秋，但是都存在以下缺点:

　　一种就是需要人工干预，无法实现自动备份(如Windows 2000自带的“备份”工具)。如果采用这种方法，就必须时刻人工手动备份，万一哪天因为出差或其它原因没有进行备份，而这时又出现服务器或数据故障的话，那麻烦就大了。

　　另一种就是能够实现自动备份，但是旧的备份不能被自动地删除(如SQL Server 2000自带的“备份”功能)。如果采取这种方法，就必须及时地手工删除旧的备份，否则再大的硬盘也会迅速地被用完。

　　在相互比较后，我还是决定采用第二种——SQL Server 2000自带的“备份”功能对关键数据库进行备份，因为它能够实现“自动备份”功能，比第一种略强。所以，在一段时期内，我每天上班后的第一件事就是先检查一下备份目录下各种数据的新的备份，然后手工删除旧的备份数据。这种做法一度让我很是苦恼。

　　一天，我在利用SQL Server 2000的“帮助”查询某个Transact-SQL语句的语义解释时无意中阅读到“自动化管理任务”的内容。从头到尾地仔细阅读后，我不由得眼睛一亮，原来SQL Server 2000本身自带了一个能够实现我的备份要求的、强大的功能——“数据库维护计划”。于是我立刻按照这部分内容的提示，以一个数据库为试验样本一步一步地操作，成功地创建了一个数据库维护计划。经过一个星期的试运行，这个计划果然能够实现自动备份调度，以及自动删除旧的数据备份，完全能够满足我的备份要求。

　　从那时起，我就利用SQL Server 2000的“数据库维护计划”备份所有关键数据库，而且严格地、定期地执行功能4，每个星期五将完全备份的数据库备份到磁带和局域网中其它客户机(主要是用于网络管理的网管PC)的硬盘上。这样做的目的是，能同时异地保存三份相同的备份，减少故障带来的损失。

　　而且，通过SQL Server 2000的“数据库维护计划”，我现在能够较轻松地备份所需各种数据，方便地管理其备份，相应地减少了日常工作量，也减轻了部分工作压力。

　　具体实现步骤

　　目录

　　第一步:打开SQL Server“企业管理器”窗体

　　第二步:找到“数据库维护计划”功能

　　第三步:创建“数据库维护计划”

　　第四步:维护和管理“数据库维护计划”

　　第五步:启动SQL Server 2000代理以便执行“作业”

　　第六步:检查结果

　　“数据库维护计划”功能在SQL Server 2000的“企业管理器”中可以找到。

　　说明:

　　1.以下操作是在服务器的Windows 20## Server上进行操作的。在Window 9X系统上操作相同。

　　2.由于SQL Server 2000执行备份时将产生许多文件(特别是在进行事务日志备份时)，所以建议按数据库名称分别建立独立的备份目录进行存储。

　　3.以下所有操作过程当中一般不会对数据库的使用产生影响。

　　第一步:打开SQL Server“企业管理器”窗体

　　用鼠标单击任务栏上的“开始”按钮中的“程序(P)”菜单下的“Microsoft SQL Server”子菜单中的“企业管理器”菜单项，即可打开SQL Server 2000的“企业管理器”窗体。

　　第二步:找到“数据库维护计划”功能

　　在“企业管理器”窗体中左侧的树型选项卡中，用鼠标单击“+”图标扩展开“控制台根目录”下的“Microsoft SQL Servers”，可以看到其下有一个“SQL Server组”;接着继续扩展开“SQL Server组”，此时可以看到其下出现了服务器的名称(图1中的“JXNC-SERVER”就是我的服务器的名称);再继续扩展开此服务器，可以看到其下列出了诸如“数据库”、“数据转换服务”等项目;最后单击“管理”项目，可以看到其下存在一个“数据库维护计划”(如图1)。

　　

　　单击“数据库维护计划”项目，在“企业管理器”窗口右侧将会显示出已经存在的维护计划项目。每个维护计划均包括以下项目:

　　1.名称:就是维护计划的名称。此名称可以自定义，中英文皆可。

　　2.数据库:就是维护计划所进行维护的数据库的名称。

　　因为一个维护计划允许同时维护多个数据库，所以此处可以显示出多个数据库的名称(在图1中可以看到名为“系统数据库备份”的数据库维护计划中的“数据库”就包括三个数据库:master、model和msdb)。

　　3.服务器:也就是维护计划所维护的数据库所处的服务器的名称。“(local)”表示是本地服务器。

　　4.对策:是指维护计划所需要进行的具体维护工作的内容。

　　图1中有3个“数据库维护计划”均为“数据库备份，事务日志备份”，它的含义就是这些维护计划中同时对所指定的数据库进行“数据库”和“事务日志”的备份。

　　第三步:创建“数据库维护计划”

　　鼠标右击“数据库维护计划”项目，选择“新建维护计划(P)”功能，将打开“数据库维护计划向导”窗体，依照此向导能够创建一个新的“数据库维护计划”。

　　步骤1:单击 “下一步(N)”按钮，打开“选择数据库”窗体(如图2)。在此窗体中可以选定一个或多个的数据库作为操作对象。为了叙述方便，我在此只选择了一个数据库“regie”。

　　

　　步骤2:单击图2中的“下一步(N)”按钮，打开“更新数据优化信息”窗体(如图3)。

　　

　　在此窗体中可以对数据库中的数据和索引重新进行组织，以及能够设定在满足一定条件的情况下，维护计划自动删除数据库中的未使用的空间，以便提高性能。

　　但要注意的是，在此窗体中，只要选定了“重新组织数据和索引页[R]”复选框，“更新查询优化器所使用的统计。示例[D]”复选框将失效(变成灰色，不能选择)。而且“重新组织数据和索引页[R]”复选框和“从数据库文件中删除未使用的空间[M]”复选框二者只要有一个被选中，其下的“调度[S]”功能才有效。单击“更改[C]”按钮可以对“调度”进行自定义。

　　各位读者可以根据自身情况决定是否选用其中的功能。当然也可以通过单击“帮助”按钮来查看各功能的具体含义。

　　在此窗体中能够便捷地设定每项作业的持续运行时间和运行的频率。完成自己的设置后，一定要选定右上角的“启用调度[B]”复选框，这样一个作业调度才算真正完成了。

　　步骤3:单击图3中的“下一步(N)”按钮，打开“检查数据库完整性”窗体。

在此窗体中可以设定维护计划在备份数据库前自动检查数据库的完整性，以便检测由于硬件或软件错误而导致数据的不一致。在此窗体中只有先选定了“检查数据库完整性[H]”复选框，其下

Sql Server 20## 数据库维护计划

 

这个星期开始为了减轻工作压力开始使用数据库维护计划(SQL Server Maintenance Plan Wizard)维护数据库，由于以前都没用过，在个人使用的免费版(Express)里也没有这个功能，所以现在好好学习了一番，这里总结一下。

维护计划向导可以用于帮助您设置核心维护任务，从而确保数据库执行良好，做到定期备份数据库以防系统出现故障，对数据库实施不一致性检查。维护计划向导可创建一个或多个 SQL Server 代理作业，代理作业将按照计划的间隔自动执行这些维护任务。它使您可以执行各种数据库管理任务，包括备份、运行数据库完整性检查、或以指定的间隔更新数据库统计信息。创建数据库维护计划可以让SQL Server有效地自动维护数据库，保持数据库运行在最佳状态，并为管理员节省了宝贵的时间。

以下是可以安排为自动运行的一些维护任务：

用新填充因子重新生成索引来重新组织数据和索引页上的数据。这确保了数据库页中包含的数据量和可用空间的平均分布，还使得以后能够更快地增长。

通过删除空数据库页压缩数据文件。

更新索引统计信息，确保查询优化器含有关于表中数据值分布的最新信息。这使得查询优化器能够更好地确定 访问数据的最佳方法，因为可以获得数据库中存储数据的详细信息。虽然 SQL Server 会定期自动更新索引统 计信息，但是此选项可以对统计信息立即进行强制更新。

对数据库内的数据和数据页执行内部一致性检查，确保系统或软件故障没有损坏数据。

备份数据库和事务日志文件。数据库和日志备份可以保留一段指定时间。这使您可以为备份创建一份历史记录 ，以便在需要将数据库还原到早于上一次数据库备份的时间的时候使用。还可以执行差异备份。

运行 SQL Server 代理作业。这可以用来创建可执行各种操作的作业以及运行这些作业的维护计划。

维护任务生成的结果可以作为报表写入文本文件，或写入 msdb 中的 sysmaintplan_log 和 sysmaintplan_log_detail 维护计划表。若要在日志文件查看器中查看结果，请右键单击“维护计划”，再单 击“查看历史记录”。

以下是详细说明：

Check Database Integrity(检查数据库完整性)

任务检查指定数据库中所有对象 的分配和结构完整性。此任务可以检查单个数据库或多个数据库，您还可以选择是否也检查数据库索引,检查所有索引页以及表数据页的完整性。

此任务封装 DBCC CHECKDB 语句。

生成的代码：

--检查当前数据库，取消信息性消息

DBCC CHECKDB WITH NO_INFOMSGS

Shrink Database(收缩数据库任务)

收缩数据库’任务”对话框可以创建一 个任务，尝试减小所选数据库的大小。

此任务封装了 DBCC SHRINKDATABASE 命令。

选项：

Shrink database when it grows beyond

当数据库大小超过指定值时收缩数据库，指定引发此任务的数据库大小(MB)。

Amount of free space to remain after shrink

收缩后保留的 可用空间，当数据库文件中的可用空间达到此值时停止收缩。

Retain freed space in database files

选择在数据库文件中保留所释放的文件空间。如果指定 NOTRUNCATE 选项，数据文件好像没有收缩。

Return freed space to operating system

选择把数据文件中任何未使用空间被释放给操作系统。无需移动任何数据即可减小文件大小。

生成的代码：

--选择Retain freed space in database files

DBCC SHRINKDATABASE (N'AdventureWorks', 10, NOTRUNCATE)

--选择Return freed space to operating system

DBCC SHRINKDATABASE(N'AdventureWorks', 10, TRUNCATEONLY)

Reorganize Index(重新组织索引)

重新组织 SQL Server 数据库表和视图中的索引。 通过使用“重新组织索引”任务，包可以重新组织单个数据库或多个数据库中的索引。如果此任务仅重新组织单个数据库中的索引，则可以选择任务要重新组织其索引的视图或表。“重新组织索引”任务还包含压缩大型对象数据的选项。大型对象数据是具有 image 、text、ntext、varchar(max)、nvarchar(max)、varbinary(max) 或 xml 数据类型的数据。

此任务封装了 Transact-SQL ALTER INDEX 语句。

如果选择压缩大型对象数据，则该语句使用 REORGANIZE WITH(LOB_COMPACTION = ON) 子句，否则 LOB_COMPACTION 将设置为 OFF。

生成代码：(只选择了Employee表)

--选择compact large objects

ALTER INDEX [PK_Employee_EmployeeID] ON [HumanResources].[Employee] REORGANIZE WITH ( LOB_COMPACTION = ON )

--不选择

ALTER INDEX [PK_Employee_EmployeeID] ON [HumanResources].[Employee] REORGANIZE WITH ( LOB_COMPACTION = OFF )

Rebuild Index(重新生成索引)

重新生成 SQL Server 数据库表和视图中的索引。包可 以重新生成单个数据库或多个数据库中的索引。如果任务仅重新生成单个数据库中的索引，则可以选择任务要 重新生成其索引的视图和表。使用默认可用空间重新组织页删除数据库中表上的索引，并使用在创建索引时指 定的填充因子重新创建索引。

此任务封装 ALTER INDEX REBUILD 语句并提供下列索引重新生成选项：

Reorganize pages with the default amount of free space

指定 FILLFACTOR 百 分比或使用原始的 FILLFACTOR 量。

Change free space per page percentage to:

填充索引使用 PAD_INDEX 选项可以在索引创建过程中设置中间级页中的可用空间百分比。将每页的可用空间百分比更改,删除数据库中表上的索引，并使用新的、自动计算的填充因子重新创建索引，从而在索引页上保留指定的可用空间。

Sort results in tempdb

使用 SORT_IN_TEMPDB 选项，该选项确定在索引创建 过程中生成的中间排序结果的临时存储位置。使用索引的IGNORE_DUP_KEY 选项，该选项指定对唯一聚集或非聚集索引上多行 INSERT 事务中的重复键值的错误响应 。

Keep index online while reindexing

使用 ONLINE 选项，用户可以在索引操作期间访问基础表或聚集索引数据以及任何关联的非聚集索引。

生成代码：(只选择了Employee表)

ALTER INDEX [PK_Employee_EmployeeID] ON [HumanResources]. [Employee] REBUILD WITH ( FILLFACTOR = 90, PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, SORT_IN_TEMPDB = OFF, ONLINE = OFF )

Updata Statics(更新统计信息)

为指定的表或索引视图中的一个或多个统计信息组（ 集合）更新键值分布信息。

此任务封装 UPDATE STATISTICS 语句。

All existing statistics

如果更新应用于所有统计信息，则暗示使用 WITH ALL 子句。

Column statistics only

如果更新仅 应用于列，则包含 WITH COLUMN 子句。

Index statistics only

如果更新仅应用于索引，则包含 WITH INDEX 子句。

Full scan

全部统计

Sample by

从每个索引所对应的表中抽样的数据，此样本的大小取决 于表中的行数和数据修改的频率。

生成代码：(只选择了Employee表)
UPDATE STATISTICS [HumanResources].[Employee]

WITH FULLSCAN

Clean Up History(清除历史记录)

使用“清除历史记录”对话框，可以放 弃 msdb 数据库表中旧的历史信息。此任务支持对备份和还原历史记录、Microsoft SQL Server 代理作业历史记录和维护计划历史记录进行删除。

此任务封装 sp_delete_backuphistory 系统存储过程并将指定日期作为参数传递给该过程。

选项：

Backup and restore history

Sql Server Agent job history

Maintenance plan history

生成代码：

Execute Sql Server Agent Job(执行 SQL Server 代理作业)

任务运行 SQL Server 代理作业。SQL Server 代理作业能够自动执行您需要重复执行的任务。

此任务封装 sp_start_job 系统 过程并把 SQL Server 代理作业的名称作为参数传递给该过程。

Back Up Database Task

备份用的，太熟悉了，不介绍了。

Maintenance Cleanup Task

此任务封装 master.dbo.xp_delete_file 系统过程，用来删除备份文件。

Execute T-SQL Statement Task

执行T-SQL 任务运行Transact-SQL 语句。这个任务用向导的时候是没有的，要到设计视图里面去拖出来。

Notify Operator Task

通知操作员任务将通知消息发送到 SQL Server 代理操作员。此任务是唯一一个不封装 Transact-SQL 语句或 DBCC 命令的数据库维护任务。

执行维护计划最好按一定的顺序，首先是执行检查数据库完整性，然后是收缩数据库，重新生成索引或者重新组织索引任务，最后是更新统计信息。

重新生成索引或者重新组织索引要根据情况选择不同的操作，两个一起选择没有什么意义。决定使用哪种碎片整理方法的第一步是分析索引以确定碎片程度。使用系统函数 sys.dm_db_index_physical_stats 可以检测特定索引、表或索引视图的所有索引、一个数据库中的所有索引或所有数据库中的所有索引中的碎片。知道碎片程度后，可以确定修复碎片的最佳方法。索引碎片不太多时，可以重新组织索引。不过，如果索引碎片非常多，重新生成索引则可以获得更好的结果。

我们公司这些任务都是一个星期运行一次，几个数据库加起来有200G，数据库也不算很大，每次运行要两个小时以上，所以都是在凌晨进行。如果进行的是重新生成索引那么在执行的时候表是无法访问的，现在也没什么更好的解决方案。这个问题还在继续学习中！

 

解SQL Server“数据库维护计划”

     因为一个维护计划允许同时维护多个数据库，所以此处可以显示出多个数据库的名称(在图1中可以看到名为“系统数据库备份”的数据库维护计划中的“数据库”就包括三个数据库：master、model和msdb)。

　　3.服务器：也就是维护计划所维护的数据库所处的服务器的名称。“(local)”表示是本地服务器。

　　4.对策：是指维护计划所需要进行的具体维护工作的内容。

　　图1中有3个“数据库维护计划”均为“数据库备份，事务日志备份”，它的含义就是这些维护计划中同时对所指定的数据库进行“数据库”和“事务日志”的备份。

　　第三步：创建“数据库维护计划”

　　鼠标右击“数据库维护计划”项目，选择“新建维护计划(P)”功能，将打开“数据库维护计划向导”窗体，依照此向导能够创建一个新的“数据库维护计划”。

　　步骤1：单击 “下一步(N)”按钮，打开“选择数据库”窗体(如图2)。在此窗体中可以选定一个或多个的数据库作为操作对象。为了叙述方便，我在此只选择了一个数据库“regie”。

　　图2

　　步骤2：单击图2中的“下一步(N)”按钮，打开“更新数据优化信息”窗体(如图3)。

　　图3

　　在此窗体中可以对数据库中的数据和索引重新进行组织，以及能够设定在满足一定条件的情况下，维护计划自动删除数据库中的未使用的空间，以便提高性能。

但要注意的是，在此窗体中，只要选定了“重新组织数据和索引页[R]”复选框，“更新查询优化器所使用的统计。示例[D]”复选框将失效(变成灰色，不能选择)。而且“重新组织数据和索引页[R]”复选框和“从数据库文件中删除未使用的空间[M]”复选框二者只要有一个被选中，其下的“调度[S]”功能才有效。单击“更改[C]”按钮可以对“调度”进行自定义。

　　各位读者可以根据自身情况决定是否选用其中的功能。当然也可以通过单击“帮助”按钮来查看各功能的具体含义。

　　在此窗体中能够便捷地设定每项作业的持续运行时间和运行的频率。完成自己的设置后，一定要选定右上角的“启用调度[B]”复选框，这样一个作业调度才算真正完成了。

　　步骤3：单击图3中的“下一步(N)”按钮，打开“检查数据库完整性”窗体。

　　在此窗体中可以设定维护计划在备份数据库前自动检查数据库的完整性，以便检测由于硬件或软件错误而导致数据的不一致。在此窗体中只有先选定了“检查数据库完整性[H]”复选框，其下的“备份之前执行这些检查[R]”和“调度[S]”功能才有效。单击“更改[C]”按钮可以对“调度”进行自定义。

　　各位读者可以自主决定，较好的一种做法就是选中“检查数据库完整性[H]”复选框(推荐，因为有可能会修正一些错误)。

　　步骤4：在“检查数据库完整性”窗体中的“下一步(N)”按钮，打开“指定数据库备份计划”窗体。

　　如需对数据库进行备份，则必须选定“作为维护计划的一部分来备份数据库[A]”复选框，而且必须指定存储备份文件的位置：磁带[P]或磁盘[K]。

如果选择“磁盘[K]”作为数据库备份的位置，设定“调度”后单击“下一步(N)”按钮则显示“指定备份磁盘目录”窗体(如图4)。

　　图4

　　在图4中，可以具体指定存储备份文件的目录(可以使用默认的目录，也可自定义)、备份文件扩展名，而且能够指示备份计划自动地删除早于某个时间(图4中设定的是“2天”，也就是说两天前的所有备份文件将被自动地删除，只留下最近两天的备份)的备份文件。而图4中的“为每个数据库创建子目录[C]”功能只是在步骤1中选择了多个数据库时才有用，对于一个数据库作用不大。设定后，单击“下一步(N)”按钮则显示“指定事务日志备份计划”窗体。

　　如果选择“磁带[P]”作为数据库备份的位置，设定“调度”后单击“下一步(N)”按钮则直接显示“指定事务日志备份计划”窗体。

　　步骤5：指定“事务日志备份计划”的过程与步骤4的过程完全相同，只是在设定“调度”上稍有差别(因为我的要求是数据库每天备份一次，事务日志每1小时备份一次)。

　　步骤6：对事务日志的备份计划全部设定后，单击“下一步(N)”按钮则显示“要生成的报表”窗体。

　　在此窗体中可以指定用于存放整个备份计划执行过程中的日志的目录。设定过程与图4的操作及其相似。

　　图5

　　步骤7：完成步骤6后，单击“下一步(N)”按钮则显示“维护计划历史纪录”窗体。

在此窗体中可以指定如何存储此维护计划的历史纪录(是存放在“本地服务器”上，还是在“远程服务器”上)，而且通过指定表中的行数可以限定历史纪录的存储大小。

　　步骤8：完成步骤7后，单击“下一步(N)”按钮则显示“正在完成数据库维护计划向导”窗体(如图5)。

　　在此窗体中可以自定义一个“计划名[P]”(推荐，这样便于管理和识别)，当然也可使用默认的“计划名[P]”。而且还可以通过对“计划名[P]”下的文本框中的内容进行确认，如有误，则可通过单击窗体中的“上一步[B]”按钮退回到相应的窗体进行修改。

　　步骤9：完成步骤8后，单击“完成”按钮，则显示“维护计划已创建成功。”的提示框，再单击 “确定”按钮即成功地设定了一个新的数据库维护计划。

　　从图6中可以看到，已经成功的创建了一个新的数据库维护计划——“regie备份”。

　　第四步：维护和管理“数据库维护计划”

　　第三步完成后，对各个“数据库维护计划”的日常维护和管理都非常方便，只需要双击“数据库维护计划”即可对第三步中所涉及的内容进行变更、修正。

　　图6

　　如图6所示，鼠标右击“regie备份”，单击“属性[R]”，或者直接双击“regie备份”，打开“数据库维护计划”窗体。在此窗体中集成了第三步中涉及到的所有功能，每项功能都能任意修改，修改过程与第三步中的相应步骤一样。

但需要说明的是，在设定图7中的“报表”选项卡下的“文本报表”中的“删除早于此时间的文本报表文件[F]”选项时，也就是第三步中的步骤6中的内容，无论您将其设定成“分钟”、“小时”、“天”，还是“月”，创建成功后都将被自动地更正为“周”，而且以后无论如何修改，保存后再去查看时它仍将显示为“周”，但不意味着其它选项无效，其它选项仍然有效。

　　图7

　　第五步：启动SQL Server 2000代理以便执行“作业”

　　完成第三步后，还需启动SQL Server 20## Agent(代理)，以便执行“数据库维护计划”作业。

　　与展开SQL Server 2000“数据库维护计划”的步骤一样，在“管理”项目中，可以发现存在一个“SQL Server 代理”(如图8)。

　　图8

　　单击“SQL Server 代理”下的“作业”子菜单，在“企业管理器”窗口右侧将会显示出已经存在的作业项目(在图8中可以看到已经存在17个作业项目)。每个作业项目均包括以下数据列：

　　1.名称：当然是指作业的名称，可以自定义，中英文皆可。为了理解方便，建议用中英文结合。

　　每当新建立一个“数据库维护计划”，将自动生成以下默认名称的作业：

　　(1)当新建的“数据库维护计划”中设定了“备份数据库”功能时，将生成默认名为“DB 维护计划‘******’的 DB 备份作业”的作业。

(2)当新建的“数据库维护计划”中设定了“备份事务日志”功能时将生成默认名为“DB 维护计划‘******’的 事务日志备份作业(多服务器)”的作业。

　　以上(1)和(2)中的“******”处将显示“数据库维护计划”中的“计划名”(也就是第三步步骤8中设定的“计划名”)。

　　2.分类：指明该作业当前所属的类别。缺省值为“[未分类(本地)]”。

　　3.启用：指明该作业是否处于“启用”状态。

　　4.可运行：指明该作业是否处于“可运行”状态。

　　5.已调度：指明该作业是否处于“已调度”状态。

　　6.状态：指明该作业当前的运行状态—不在运行、正在运行。

　　7.上次运行状态(开始日期)：显示最近一次运行该作业后的状态(“已成功”、“失败”，还是“未知”)，和运行时的日期和时间。

　　8.下次运行日期：指明下一次运行该作业的日期和时间。

　　如图8所示，鼠标右击“regie完全备份”作业，单击“属性[R]”，或者直接双击“regie完全备份”作业，打开作业的“属性”窗体。在此窗体中集成了该作业的详细的配置项。每个配置项都能任意修改。“属性”窗体中有四个选项卡：

　　◆ 常规：在此选项卡中可以重新设定作业名称(“名称[N]”文本框)、修改作业的分类(“分类[Y]”下拉框)、指定作业的所有者(“所有者[W]”下拉框)、简单地对作业进行描述(“描述[R]”文本框)，以及决定是否启用此作业(“启用[E]”复选框)。

◆ 步骤：在此选项卡中可以新建、插入新的步骤，删除、编辑已有的步骤。

　　单击“编辑[E]”按钮，在“编辑作业步骤”窗体中的“常规”选项卡中的“命令[M]”文本框中可以查阅到该作业的执行语句。

　　◆ 调度：在此选项卡中可以新建调度、新建警报，删除、编辑已有的调度。

　　◆ 通知：在此选项卡中可以设定作业完成时(即当作业成功时、作业失败时)执行的操作，即发送电子邮件、传呼操作员、发出网络警报信息、写入Windows应用程序事件日志、自动删除等操作。

　　第六步：检查结果

　　经过上述五个步骤后，一个完整的备份数据库的计划就建立起来了。可以通过“资源管理器”来检查备份目录下是否存在相应地备份文件。

　　经过长时间的使用，如果以“保留2天的数据库完全备份和2天的每个一小时的事务日志备份”的备份策略来正确地建立了一个完整的数据库维护计划的话，无论何时查看相应备份目录下的文件，都应该存在102个文件：

　　◆2个数据库的完整备份，即2个以“数据库名_db_yyyy mmddhhss.bak”格式为文件名的文件；

　　◆ 3个与数据库完整备份相对应的操作过程的记录报告文件，即以“数据库名”+“备份4_yyyymmddhhss.txt” 格式为文件名的文件；

　　◆ 48个事务日志的差异备份，即2天各24个以“数据库名_tlog_yyyymmddhhss.trn”格式为文件名的文件；

　　◆ 49个与事务日志的差异备份对应的操作过程的记录报告文件，即以“数据库名”+“备份6_yyyymmddhhss.txt” 格式为文件名的文件。

　　以上文件名中，“数据库名”为第三步的步骤一中选定的数据库的名称；“yyyymmddhhss”是时间戳，其格式为：“yyyy”指“年”(4位数值)，“mm”指“月”(2位数值，不足2位的补“0”)，“dd”指“日”(2位数值，不足2位的补“0”),“hh”指“时”(2位数值，不足2位的补“0”)，“ss”指“分”(2位数值，不足2位的补“0”)。

结束语

　　对于一个企业而言，日常运作中发生的各种业务所产生的所有数据，经过计算机不断地日积月累，逐渐成为公司的一种财富和资本。利用计算机，可以便捷地统计分析部分或全部的数据，通过各种形式的反馈(如图表、表格等)，给公司的决策层用于参考，便于为公司的今后决策提供指导和帮助。正基于此，这些数据的价值随着时间的延续正呈现出几何速度的增长。因此我认为，对于数据的备份工作是网管员日常工作中最重要的工作之一。

　　通过这次“数据库维护计划”的创建，我略有感受：

　　1.经过这么长时间的运用，我认为“数据库维护计划”仍然存在不足之处，虽说“数据库维护计划”功能很强大，但是它最终的结果是生成一项作业，由“SQL Server 20## Agent”服务定期执行它来完成对数据库的备份工作。这就要求“SQL Server 20## Agent”服务能够正常地“运行”。从多次安装来看，在Windows 2000系统中“SQL Server 20## Agent”服务能够正常运行，而且能随Windows 2000的启动自动运行。但是在Window 98系统(包括第二版)中，却不能正常运行。所以说，在Windows 98系统中即使依照上述步骤成功地创建了“数据库维护计划”，也会因为“SQL Server 20## Agent”服务无法启动而变得没有任何作用。

　　2.之所以选择“完全备份”，主要在于，在进行完全备份时，SQL Server将.mdf与其对应的.ldf文件进行对比，删除一些旧的、不必要的日志，然后将.mdf和.ldf文件进行合并、压缩后一起存储。

　　◆ 优点是：能最大可能地、完整地保存数据库。

　　◆ 缺点是：存储量随着数据库的增大而增大，存储时间也将随着数据库的增大而延长。

　　3.在建立“数据库维护计划”过程，各位读者应该尽可能地去使用各种选项、功能，以便加深对“数据库维护计划”的理解和掌握。

　　4.虽然Internet上有许多第三方备份软件和工具，但是大多数是共享版。由于担心知识产权问题、病毒问题和其它问题，所以我没有试用这些第三方软件。这样的话，它们的性能我就不清楚了。也许这些软件的功能非常强大，能够满足更多的、更高的要求。在这里我只是就Windows 2000和SQL Server 2000自带的“备份”工具和软件进行一个比较。

高效维护数据库的关键技巧

Paul S. Randal

概览：

§  管理数据和事务日志文件

§  清除索引碎片

§  确保统计数据准确、最新

§  检测遭到破坏的数据库页

§  建立有效的备份策略

 目录

数据和日志文件管理
索引碎片
统计数据
损坏检测
备份
总结

在一周之内多次有人向我征求高效维护生产数据库的建议。有时问题来自 DBA，他们正在实施新的解决方案，希望得到帮助

对维护进行精细调整适合其新数据库的特点。但更为常见的情况是：提问的人不是专业 DBA，而是由于某种原因拥有数据库并承担相关责任的人员。我喜欢将这种角色称为“非自愿 DBA”。本文重点是为所有非自愿 DBA 提供数据库维护最佳实践的入门知识。

在 IT 世界里，大多数任务和程序都没有一个简单、通用的解决方案可以高效维护数据库，但却有一些必须受到重视的关键领域。我所关心的五大重要领域是（没有任何特殊的重要性顺序）：

       数据和日志文件管理

       索引碎片

       统计数据

       损坏检测

       备份

一个未经维护（或维护不良）的数据库可能会在其中的一个或多个领域内引发问题，最终可能导致应用程序性能欠佳，甚至是停机以及丢失数据。

在本文中，我将说明这些问题很重要的原因并向您展示一些缓解这些问题的简单方法。我将以 SQL Server^® 20## 为基础进行说明，但我还会着重指出您将会在 SQL Server 20## 和即将发布的 SQL Server 20## 中发现的主要差别。

数据和日志文件管理

我始终建议在接管数据库时检查的第一个领域涉及到与数据和（事务）日志文件管理相关的设置。具体地说，您应确保：

       数据和日志文件彼此分开，而且还与其他所有内容相互隔离

       自动增长已正确配置

       即时文件初始化已配置

       自动缩减未启用而且缩减不是任何维护计划的内容

当数据和日志文件（理想情况下应分别位于不同的卷中）与其他任何创建或扩展文件的应用程序共享一个卷时，可能存在文件碎片。在数据文件中，过多的文件碎片可能是导致查询（特别是扫描非常多数据的查询）效果不佳的一个因素。在日志文件中，它可能会对性能产生相当大的影响，尤其是在自动增长设置为需要增加每个文件的大小时，增量很小的情形。

日志文件在内部被划分为多个称为“虚拟日志文件”(VLF) 的片段，而且日志文件（我在这里使用单数是因为拥有多个日志文件并没有任何好处，每个数据库只应有一个日志文件）内的碎片越多，VLF 就越多。一个日志文件具有多个（比方说，200 个）VLF 后，与日志有关的操作（如为事务性复制/回滚而读取日志）、日志备份乃至 SQL Server 20## 中的触发器（触发器的实现已在 SQL Server 20## 中更改为行版本框架，而不是事务日志）可能会对性能产生负面影响。

调整数据和日志文件大小的最佳做法是创建它们时使用适当的初始大小。对于数据文件，初始大小应考虑短期内向数据库中添加其他数据的可能性。例如，如果数据的初始大小为 50GB，但您知道在接下来的六个月内将再添加 50GB 的数据，那么应创建 100GB 的数据文件，而不是多次将其增大以达到该大小。

对于日志文件而言要更复杂一些，您需要多考虑一些因素，例如事务大小（长时间运行事务在完成之前无法从日志中清除）以及日志备份频率（因为这将删除日志的非活动部分）。有关详细信息，请参阅我的妻子 Kimberly Tripp 编写的一篇很受欢迎的博客文章提高事务日志吞吐量的 8 个步骤，它发表在 SQLskills.com 上。

设置一旦完成，应不时监视文件大小，并在每一天的适当时间先行手动增加其大小。为以防万一，应保留自动增长，这样文件即使在发生一些异常事件的情况下仍可以完成所需的增长。反对将文件管理完全保留为自动增长的逻辑是步长极小的自动增长会导致文件碎片，而且自动增长会是一个耗时的过程，它可能会多次突然停止应用程序的工作。

应将自动增长大小设置为一个具体值，而不是一个百分比，以约束执行自动增长（如果发生）所需的时间和空间。例如，您可能希望将一个 100GB 的数据文件的自动增长大小设置为固定值 5GB，而不是（比方说）10%。这意味着无论文件每次变得多大，它均将按 5GB 进行增长，而不是一个持续增长的数量（10GB、11GB、12GB 等）。

当事务日志增长时（手动或自动增长），它将始终被初始化为零。数据文件在 SQL Server 20## 中具有同一默认行为，但从 SQL Server 20## 开始，您可以启用即时文件初始化，它会跳过零初始化文件，因此增长和自动增长会保持同步。所有版本的 SQL Server 中都提供了这一功能，这一点与正常的观点恰恰相佐。如欲了解详细信息，请在 SQL Server 20## 或 SQL Server 20## 的联机丛书索引中输入“即时文件初始化”。

最后，应注意不要以任何方式启用缩减。缩减可用于减小数据或日志文件的大小，但它是一个干扰很大、极耗资源的过程，会导致数据文件中产生大量的逻辑扫描碎片（详细信息请参见下文），并导致性能欠佳。我更改了 SQL Server 20## 联机丛书中的缩减条目，加入了一个警告，提醒注意此影响。但在特殊情况下，允许手动缩减单个数据和日志文件。

视频

观看 Paul Randal 演示缩减和自动缩减如何导致数据库发生严重的碎片问题。

自动缩减的后果极为严重，因为它每 30 分钟就会在背景中启动一次，并会尝试缩减自动缩减数据库选项被设置为 true 的数据库。从某种程度讲，它是一个无法预见的过程，因为它仅缩减拥有 25% 以上可用空间的数据库。自动缩减占用大量资源，会产生碎片并导致性能下降，因此在任何情况下都不是一个好计划。您应始终通过以下方式关闭自动缩减：

复制代码

ALTER DATABASE MyDatabase SET AUTO_SHRINK OFF;

包含手动数据库缩减命令的定期维护计划几乎会产生同样糟糕的结果。如果您发现您的数据库在维护计划将其缩减后持续增长，原因在于数据库运行需要该空间。

最好的做法是允许数据库增长到稳定的大小，尽量避免运行缩减。您可以在我原来的 MSDN^® 博客（位于 blogs.msdn.com/sqlserverstorageengine/archive/tags/Shrink/default.aspx）中找到有关使用缩减的缺点的详细信息，其中还有对 SQL Server 20## 中新算法的一些评论。

索引碎片

除了文件系统级和日志文件内的碎片以外，数据文件内存储表格和索引数据的结构中也可能存在碎片。数据文件内可能出现两种基本类型的碎片：

       单个数据和索引页内的碎片（有时称为内部碎片）

       由页面组成的索引或表格结构内的碎片（称为逻辑扫描碎片和扩展盘区扫描碎片）

内部碎片是页面中存在大量空白区域的位置。如图 1 所示，数据库中的每个页面大小为 8KB，页眉为 96 字节；因此，一个页面可以存储大约 8096 字节的表格或索引数据（我的博客 sqlskills.com/blogs/paul 有“深入了解存储引擎”一节，其中介绍了数据和行结构的特定表格和索引内部机制）。如果每个表格或索引记录超过页面大小的一半，可能会出现空白空间，因为每个页面只能存储一个记录。这可能很难或无法更正，因为它要求更改表格或索引架构，例如，将索引键更改为像 GUID 一样不会引发随机插入点。

图 1 数据库页的结构（单击图像可查看大图）

更常见的是，内部碎片源于数据修改（如插入、更新和删除），这可能会在页面中留下空白空间。管理不善的填充因子也可能会产生碎片；有关详细信息，请参阅“联机丛书”。根据表格/索引架构和应用程序的特征，此空白空间在其创建后可能就不再使用，导致数据库中的不可用空间量持续增长。

例如，我们来看一下一个 1 亿行表格，其中平均记录大小为 400 字节。后来，应用程序的数据修改模式为每个页面留下了平均 2800 字节的空白空间。该表格所需的总空间为 59GB，计算方法为 8096-2800 / 400 = 13 个记录/8KB 页面，然后将 1 亿除以 13 便可获得页面数。如果没有空间浪费，那么每个页面刚好容纳 20 条记录，所需的总空间下降至 38GB。这是多么大的节省！

如数据/索引页中出现空间浪费，可能导致存储同样数量的数据需要更多的页面。这不仅会占用更多的磁盘空间，还意味着查询需要执行更多的 I/O 才能读取同样数量的数据。所有这些多出的页面在数据缓存中占用了更多空间，因而占用了更多的服务器内存。

逻辑扫描碎片是由称为页面分隔的操作而引发的。当必须在特定索引页（根据索引键定义）中插入记录但页面中并没有足够的空间来容纳所插入的数据时，便会发生这种情况。该页面会被分割一半，大约 50% 的记录被移到新分配的页面。通常，这一新页面实际上并不与旧页面相邻，因此，被称为零碎的页面。扩展盘区扫描碎片在概念上与此类似。表格/索引结构内的碎片会影响 SQL Server 执行有效扫描的能力，无论是对整个表格/索引进行扫描还是按查询 WHERE 子句（例如，SELECT * FROM MyTable WHERE Column1 > 100 AND Column1 < 4000）进行扫描都会受到影响。

图 2 显示的新建索引页填充率是 100%，没有碎片，这些页面完全被充满，而且页面的物理顺序与逻辑顺序相符。图 3 显示了在随机插入/更新/删除之后出现的碎片。

图 2 不带碎片的新建索引页；页面被完全填充（单击图像可查看大图）

图 3 随机插入、更新和删除之后出现内部和逻辑扫描碎片的索引页（单击图像可查看大图）

有时可以通过更改表格/索引架构来防止碎片，但正如我前面所提到的，这可能很难或根本无法实现。如果预防并不是办法，可以想办法在碎片产生后将其删除，具体来讲，是重新生成或重新组织索引。

重新生成索引涉及创建索引的新副本（有效压缩且尽可能连续），然后丢弃旧的零碎副本。在 SQL Server 删除旧的索引副本之前创建新副本时，在数据文件内所需的可用空间大致相当于此索引的大小。在 SQL Server 20## 中重新生成索引始终都是脱机进行的。在 SQL Server 20## Enterprise Edition 中，索引重新生成可以联机进行，但有几个限制。而重新组织使用原位算法对索引进行压缩并整理碎片；它运行只需要 8KB 的额外空间，而且始终是联机运行的。实际上，在 SQL Server 20## 中，我专门编写了索引重新组织代码，用于替代重新生成索引，它的优点是联机且节省空间。

在 SQL Server 20## 中，用于调查的命令为 ALTER INDEX …… REBUILD 用于重新生成索引，ALTER INDEX … REORGANIZE 用于重新组织索引。此语法分别取代了 SQL Server 20## 中的命令 DBCC DBREINDEX 和 DBCC INDEXDEFRAG。

这些方法之间有许多种权衡选择，例如，所生成的事务记录量、所需的数据库可用空间量以及中断进程是否不会丢失数据等。您可以在 microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx 上找到一份白皮书，其中介绍了这些权衡选择以及更多信息。虽然白皮书内容是根据 SQL Server 20## 编写的，但其中的概念向后续版本的过渡性很好。

一些人只是选择每晚或每周重新生成或重新组织所有索引（例如，使用维护计划选项），而不是找出哪些索引被分割为碎片以及删除碎片是否会带来任何好处。对于那些只是希望不费多少气力就可适当放置内容的非自愿 DBA 来说，这是一个不错的解决方案，但请注意：对于一些资源非常珍贵的大型数据库或系统来说，它可是一个非常糟糕的选择。

更好的方法包括使用 DMV sys.dm_db_index_physical_stats（或 SQL Server 20## 中的 DBCC SHOWCONTIG）来定期确定哪些索引被分割为碎片，然后选择是否以及如何对其进行操作。本白皮书还介绍了对这些更有针对性的选项的使用。此外，您还可以看到一些进行这种筛选的示例代码，即 SQL Server 20## 联机丛书 DMV sys.dm_db_index_physical_stats 条目的示例 D (msdn.microsoft.com/­library/ms188917) 或 SQL Server 20## 以及更新版本联机丛书 DBCC SHOWCONTIG 条目的示例 E (msdn.microsoft.com/library/aa258803)。

无论您使用哪种方法，定期调查并修复碎片都是非常明智的做法。

查询处理器是 SQL Server 的一个部件，用于决定应如何执行查询，具体来说，是使用哪些表格和索引以及对其执行哪些操作才能获得所需的结果；它称为查询计划。此决策制定过程所需的一些最重要的信息就是统计数据，它们说明表格或索引内各个列的数据值分步情况。很明显，统计数据必须要准确而且保持最新，才能为查询处理器提供帮助，否则可能会导致查询计划性能不佳。

统计数据是通过读取表格/索引数据并确定相关列的数据分布而生成的。可以通过扫描特定列的所有数据值（全面扫描）构建统计数据，也可以根据用户指定的数据百分比（采样扫描）建立统计数据。如果列中各值的分布非常均匀，那么采样扫描就应该足以能满足要求，与全面扫描相比，这种方式会使统计数据的创建和更新更快。

请注意，可通过打开 AUTO_CREATE_STATISTICS 和 AUTO_UPDATE_STATISTICS 数据库选项自动创建和维护统计数据，如图 4 所示。这些选项默认情况下是打开的，但如果您只是继承了数据库，请进行检查加以确认。有时统计数据可能已过时，在这种情况下可以通过对特定的统计数据集使用 UPDATE STATISTICS 操作手动更新它们。或者，可以使用 sp_updatestats 存储过程，该过程会更新所有过时的统计数据（在 SQL Server 20## 中，sp_updatestats 更新所有统计数据，无论期限为何）。

图 4 通过 SQL Server Management Studio 更改数据库设置（单击图像可查看大图）

如果您想要在定期维护计划中更新统计数据，有一个问题您应当注意。UPDATE STATISTICS 和 sp_updatestats 均默认使用先前指定的采样级（如果有），这可能达不到全面扫描的效果。索引重新生成会自动使用全面扫描更新统计数据。 如果您在重新生成索引之后手动更新统计数据，最后得到的统计数据可能不太准确！如果来自手动更新的采样扫描覆盖通过索引重新生成而产生的全面扫描，可能会发生这种情况。而另一方面，重新组织索引根本不更新统计数据。

同样，许多人的维护计划是在重新生成所有索引之前或之后的某个时刻更新所有统计数据，因此可能不知道得到的是不太准确的统计数据。如果您经常做出的选择只是重新生成所有索引，这也会处理统计数据。如果您选择了更为复杂的方式，其中涉及删除碎片，您也应该执行此操作以维护统计数据。以下是我的一些建议：

       分析索引并确定要对哪些索引进行操作以及如何删除碎片。

       对于尚未重新生成的所有索引，更新统计数据。

       更新所有非索引列的统计数据。

有关统计数据的详细信息，请参阅白皮书“^® SQL Server 20## 中的查询优化器所使用的统计信息”(microsoft.com/technet/prodtechnol/sql/2005/qrystats.mspx)。

损坏检测

我已经介绍了与性能相关的维护。现在我想换一项内容，介绍一下损坏检测与缓解。

您所管理的数据库一定会包含有用的信息，那么您如何确保数据在出现灾难时没有损坏或可以恢复呢？详细论述完整的灾难恢复和高可用性策略超出了本文的范围，但可以介绍一些简单的操作。

绝大多数的损坏是由“硬件”引起的。为什么我用引号将其引起来呢？因为此处的硬件实际上是指“SQL Server 下属 I/O 子系统中的某些内容”。I/O 子系统由操作系统、文件系统驱动程序、设备驱动程序、RAID 控制器、电缆、网络以及物理磁盘驱动器等组成。有许多地方确实会发生问题。

一个最常见的问题是当发生电源故障时磁盘驱动器正在写出数据库页。如果驱动器无法在电源耗尽之前完成写操作（或者写操作已缓存，但没有足够的备用电池来刷新驱动器的缓存），就可能在磁盘上产生不完整的页面映像。因为 8KB 数据库页实际上由 16 个连续的 512 字节扇区组成，所以这种情况可能会发生。不完整的写操作可能写出新页面中的一些扇区，但也会留下上一页面映像中的一些扇区。这种情况称为破损页。如果发生了这一情况，应如何检测呢？

SQL Server 提供了一种用于检测此情况的机制。它包括存储该页面每个扇区的几位并在其位置编写特定的模式（这恰好是在页面被写入磁盘之前发生的）。如果重新读取页面时此模式有变化，SQL Server 便会知道该页面已“破损”并引发错误。

在 SQL Server 20## 及后续版本中，提供了一种更加全面的机制，称为页面校验和，可以检查页中的任何损坏。这包括在写出页面之前编写整页校验和，然后在重新读取该页时对其进行检测，就象检测破损页一样。在启用页面校验和之后，必须将页读入缓冲池，以某种方式进行更改，然后在其受页面校验和保护之前将其重新写出到磁盘。

因此，最好的做法是为 SQL Server 20## 之后的版本启用页面校验和，为 SQL Server 20## 启用破损页检测。要启用页面校验和，请使用：

复制代码

ALTER DATABASE MyDatabase SET PAGE_VERIFY CHECKSUM;

要为 SQL Server 20## 启用破损页检测，请使用：

复制代码

ALTER DATABASE MyDatabase SET TORN_PAGE_DETECTION ON;

通过这些机制，您可以在某个页面出现损坏时进行检测，但只能在读取页面时进行。如何能够便于强制读取所有分配的页面？执行此操作（以及查找其他任何类型的损坏）的最好方法是使用 DBCC CHECKDB 命令。无论指定的选项为何，此命令始终都会读取数据库中的所有页面，从而导致验证所有页面校验和或破损页检测。您还应该设置警报，这样您就可了解用户在运行查询时何时遇到了损坏问题。您可以使用 24 个严重性错误警报得到上述所有问题的通知（图 5）。

图 5 为所有 24 个严重性错误设置警报（单击图像可查看大图）

因此，另一种最佳做法是定期对数据库运行 DBCC CHECKDB 以验证其完整性。此命令有许多形式，其运行频率也有很多说法。遗憾的是，还没有任何对此做介绍的白皮书。但是，因为 DBCC CHECKDB 是我为 SQL Server 20## 编写的主要代码段，因此我已在博客中对此做了详尽的说明。请参阅我博客中的 "CHECKDB From Every Angle" (sqlskills.com/blogs/paul)，里面有许多有关一致性检查、最佳实践以及方法建议的精深文章。对于非自愿 DBA，一条经验法则是在每次进行完整数据库备份时都运行 DBCC CHECKDB（更多相关信息请参见下文）。我建议运行以下命令：

复制代码

DBCC CHECKDB ('MyDatabase') WITH NO_INFOMSGS,

  ALL_ERRORMSGS;

如果此命令有任何输出，表明 DBCC 已在数据库中发现了一些损坏。随之而来的就是如果 DBCC CHECKDB 发现了任何损坏应如何处理。这时就轮到备份出场了。

当发生损坏或其他灾难时，最有效的恢复方法是从备份还原数据库。此方法假定您第一时间进行了备份，而且这些备份本身没有损坏。人们经常想知道在其没有做任何备份的情况下如何让严重损坏的数据库重新运行起来。如果某种形式的数据丢失对您的业务逻辑和关系数据完整性造成了严重破坏，这一点根本做不到。

因此，完全有理由主张进行定期备份。使用备份和还原的细节远远超出了本文的范围，但我可以简要介绍一些如何建立备份策略的基础知识。

首先，应定期进行完整数据库备份。这会为您提供一个之后还原可以达到的时间点。可以使用 BACKUP DATABASE 命令进行完整数据库备份。相关示例请参阅“联机丛书”。若要增加保护，可以使用 WITH CHECKSUM 选项，它会验证所读取页的页面校验和（如果有）并计算整个备份的校验和。您应选择一个频率，它会反映您的业务能容忍的数据或工作丢失量。例如，每天进行一次完整数据库备份，意味着在发生灾难的情况下您最多可能丢失一天的数据。如果您仅使用完整数据库备份，应采用 SIMPLE 恢复模型（通常称为恢复模式），以避免与事务日志增长管理相关的复杂性。

其次，始终保留几天的备份，如果发生了损坏，使用几天之前的备份也要好于根本没有备份。您还应使用 RESTORE WITH VERIFYONLY 命令验证备份的完整性（仍请参阅“联机丛书”）。如果您在创建备份时使用了 WITH CHECKSUM 选项，运行验证命令将检查备份校验和是否仍然有效，并重新检查备份内的所有页面校验和。

第三，如果每日完整数据库备份不满足业务所能承受的最大数据/工作丢失量，您可试用差异数据库备份。差异数据库备份以完整数据库备份为基础，并包含自上次完整数据库备份后所有更改的记录（一个常见误解是差异备份是增量备份，其实不然）。一个示例策略是采用每日完整数据库备份，并每四个小时进行一次差异数据库备份。差异备份额外提供了一个时间点恢复选项。如果您仅使用完整数据库备份和差异数据库备份，仍应使用 SIMPLE 恢复模型。

最后，可恢复性最终涉及的是使用日志备份。它们仅在 FULL（或 BULK_LOGGED）恢复模型中可用，提供了自上次日志备份后所生成的所有日志记录的备份。使用定期完整数据库（也可能是差异数据库）备份维护一组日志备份会提供无限数量的恢复目标时间点（包括最新的恢复）。需要权衡的是事务日志将继续增长，直到通过日志备份将其释放。此处的示例策略将每天进行完整数据库备份，每四个小时进行一次差异数据库备份并在每半小时进行一次日志备份。

决定备份策略并对其进行设置可能会相当复杂。最起码，您应定期进行完整数据库备份，以确保您至少拥有一个可从中恢复的时间点。

正如您所看到的，要确保数据库保持良好状况并可供使用，必须要完成几项任务。以下是我制订的最终检查表，适合接管数据库的非自愿 DBA：

       删除多余的事务日志文件碎片。

       正确设置自动增长。

       关闭所有计划的缩减操作。

       打开即时文件初始化。

       定期检测并删除索引碎片。

       打开 AUTO_CREATE_STATISTICS 和 AUTO_UPDATE_STATISTICS，并定期更新统计数据。

       启动页面校验和（或者至少在 SQL Server 20## 上启动破损页检测）。

       定期运行 DBCC CHECKDB。

       定期进行完整数据库备份以及用于时间点恢复的差异和日志备份。

我在本文中给出了 T-SQL 命令，但您也可以利用 Management Studio 完成诸多操作。希望我的建议能帮您提高数据库的维护效率。如果您有任何反馈或问题，请发送电子邮件至 paul@sqlskills.com。

Paul S. Randal 是 SQLskills.com 的常务董事，也是 SQL Server MVP。从 1999 年到 20## 年，他一直在 Microsoft 的 SQL Server 存储引擎团队工作。Paul 是灾难恢复、高可用性和数据库维护方面的专家。他的博客地址是 SQLskills.com/blogs/paul。