SQL大型事务日志备份与修复问题

核心提示： 这样一来您可能会认为“修复”是一种不可靠的方式，但是当不得不进行修复时，SQL大型事务日志备份与修复问题(5)，它可以提供一种最快捷最可靠的方法来修复损坏数据，在进行灾难恢复时，则可能不应该删除这些索引，如果某索引确实在整个业务周期内都未被使用过，速度极为重要，并且

这样一来您可能会认为“修复”是一种不可靠的方式，但是当不得不进行修复时，它可以提供一种最快捷最可靠的方法来修复损坏数据。在进行灾难恢复时，速度极为重要，并且要求绝对准确。设计出经过验证能在各种情况下迅速准确地完成修复操作的复杂修复算法几乎是不可能的。例如，在修复代码中有一些复杂算法可解决为两个索引分配同一页面或范围的问题，但通常此算法都是采用此“修复”功能再加上一些修补。

此外，还有其他一些需要了解的有关“修复”的问题：

在删除损坏的结构时，“修复”不会考虑外键约束，因此，可能会删除与其他表格有外键关系的表格中的记录。如果在运行“修复”后不运行 DBCC CHECK­CONSTRAINTS，则无法确定是否发生了这种情况。

“修复”不会(也无法)考虑在应用程序级定义的、可能会被要删除的某些数据破坏的任何内在业务逻辑或数据关系。同样，如果不运行应用程序中构建的任何一种自定义的一致性检查，则无法确定是否有关系遭到破坏。

某些修复操作无法被复制。在对等拓扑中对发布服务器或节点运行“修复”可能会在拓扑中引入不一致问题，必须手动进行纠正。

鉴于以上原因，通过采用备份而非运行“修复”来从损坏中进行恢复始终是个不错的办法。但是产品中也提供了“修复”，因为一旦出现数据库受损而又没有备份的情况，最起码要有一种方法能使数据库迅速恢复联机状态。

问：我刚以一名 DBA 的身份加入一家新公司，现在需要负责管理多种应用程序及其后端数据库。其中一种应用程序的更新性能非常差。在经过调查后，我发现该应用程序使用的每个表都包含大量索引。经过多方询问后，才知道似乎是以前的 DBA 喜欢对各个表列及某些组合添加索引。我认为并非所有索引都是必要的，但我该如何找出可以安全删除的索引呢?我们运行的是 SQL Server 2005。

答：正如您所猜测的那样，大量索引极有可能是造成性能不佳的主要因素。每次在表中插入、更新或删除行时，都需要在每个非群集索引中执行相应的操作。这将在 I/O、CPU 利用率和事务日志生成等方面增加大量的管理开销。

在 SQL Server 2000 中，判断正在使用哪些索引的唯一途径是使用配置文件和检查查询计划。在 SQL Server 2005 中，则可使用新的动态管理视图 (DMV) -sys.dm_db_index_usage_stats，它可以跟踪索引使用情况。

此 DMV 会跟踪数据库启动以来的每一次索引使用及使用方式。SQL Server 关闭后所有数据库的统计信息均会丢失，某个数据库关闭或拆分后，该数据库的统计信息会丢失。其想法是如果某个索引未出现在输出中，则它肯定在数据库启动后就未被使用过。

随着时间的推移来跟踪索引使用情况的简单方法是定期拍摄 DMV 输出的快照，然后对这些快照加以比较。许多人都忽略的一点是必须跟踪索引在整个业务周期内的使用情况。如果您只是拍摄一天的快照，则可能会发现多个未使用过的索引。但是，如果这些索引是具有其他用途，比如用于帮助月底报表更快速地运行，则可能不应该删除这些索引。如果某索引确实在整个业务周期内都未被使用过，则很可能能够将其删除并回收空间以提高性能。