6.DBA五大浪费时间的工作
DBA以常规方式执行的一些任务，不仅对SQL Server数据库几乎没有益处，而且实际上可能对他们的生产环境造成不利影响。在本文中，我会阐述几类这样的工作。如果你正在执行其中的一些工作，我希望你能尽快停下来。
(1)收缩数据库
每天执行收缩(Shrink)数据库是一种不好的做法，有如下几个原因。从技术角度考虑，你看到的最大影响会是，每次数据库收缩之后会产生大量的索引碎片。另外，收缩数据库文件既增加了磁盘子系统的物理文件碎片，也增加了服务器的I/O负载，在运行收缩操作期间，会降低其他功能的性能。
现在，收缩数据库并不是一定会引起碎片。但是，因为文件本身是持续增长的，而你又一直在对它进行收缩，那么随着数据库自身的增长，数据库碎片将会变得越来越多。
如果你收缩日志文件，也有必然会再增长的坏影响，所有数据库操作在事务日志增长时都会处于暂停状态。在非常繁忙的系统中，这会花上一两秒的时间，会引起所有类型的锁定和阻塞，因为进程在等待事务日志增长。
另一个缺点是当数据库维护开始再次运行时，文件需要增长，这会占用CPU和磁盘资源才能完成。那么，这就会使得数据库维护时间花的更长，在SQL Server 2000和更早的版本中，或者在没有启用即时文件初始化设置的SQL Server 2005系统中尤其如此。
从管理的角度来看，这可能会给你造成一种安全错觉，因为你不知道你的数据库实际上需要多少占用空间。换句话说，如果每次你运行数据库维护进程时，你的数据库从一百GB增长到了一百三十GB，然后你把它再收缩到一百GB，你就不知道数据库实际上需要多少空间了。它需要一百GB还是一百三十GB?答案是它需要一百三十GB空间，以便它可以执行需要的数据库维护。如果你做了收缩，然后在磁盘上放了其他数据，你不可能有足够的空间执行你的数据库维护，这项任务就会失败的。
(2)碎片整理，然后重建索引
正如你所知道的(希望如此)，有两种方式清理你的数据库索引。你可以使用“REORG” 对索引进行碎片整理，或者你可以完全重建索引。实际上，在SQL Server 2005有新的数据库维护计划，做这两种工作都变的很容易了。
虽然这么做不会对数据库造成特别损坏，但主要是浪费时间(不是数据库维护，而是对相同的索引执行这两种操作)。这是因为两种操作执行的最终结果都是相同的，都会得到一个没有碎片的，对所有数据库页都有合适的填充因子的索引。
如果你频繁地在索引重建以后执行索引重组，那么你为了重组花费的CPU处理能力和磁盘I/O就浪费了，因为在执行完索引重建命令以后索引会被完全重建。你应该做其中一项操作，或者另一项，但是不能都做。如果你不确定该选择哪一种，有大量可以自动处理这些工作的产品可以供你购买(例如：Quest的容量管理器，或者Idera的SQL碎片整理管理器)，或者你可以在网上找到一些免费脚本。
(3)恢复完整备份到日志传送目标
这件事希望你不是每天都在做。日志传送被某个没有完全理解事务日志怎样工作的人设置的第一征兆就是，日志传送配置被设置为每日或者每周恢复完整备份到日志传送目标服务器。
当你备份事务日志时，自上次日志备份以来的所有数据库操作都包括在内了。这包括了新增字段和表，索引重建等待。通过恢复完整备份来更新在此期间缺少的操作，相当于你只是简单地把目标数据库删掉，然后把它恢复到相同的状态，然后向前应用在全备份恢复时备份的所有日志。所做的这些都增加了日志备份遗失的概率。
(4)删减事务日志
我在联机环境中见过的最普遍的设置之一就是下面的数据库维护计划表：
·日志备份
·索引重建
·全备份
·删减日志
每三十分钟做日志备份
在这里实际完成的是索引重建，而且执行了全备份。到目前为止，一切还算正常，不是吗?实际上，日志被删减会打断日志链，这会使所有日志备份变得无用，直到下次执行全备份。这是因为日志序列号(Log sequence Number，简称LSN)链被删减日志操作中断了。
无论什么时候事务出现时，事务日志中就会写进去一个日志序列号。在执行备份时，第一个日志序列号和最后一个日志序列号都包含在备份中，被写到了日志备份的头位置。
在日志被恢复时，日志备份中的日志序列号必须是连续的。如果他们不连续，那么SQL Server就认为日志记录丢失了，日志备份不能恢复了。
在这种情况下，全备份可以恢复到数据库。不幸的是，所做的日志备份没用了。这是因为包括在事务日志备份中的最后一个日志序列号与在日志删减后的第一份事务日志备份中的日志序列号不相同，因为删减日志命令改变了日志的序列号。
我所见到的另一种十分常见的场景是删减日志，然后执行全备份。这中做法会好一点，但是也强不到哪里去。如果全备份被破坏的话，任何在删减(truncate)语句和下一次全备份之间的事务都不能被恢复。这是为什么呢?因为既然删减日志步骤会重置日志序列号，你就不能从两天前恢复全备份，然后向前滚动所有事务日志。是的，把日志转换为简单恢复模式做的实际也是一样的事。
如果你打算删减你的事务日志，以便你可以进行收缩，那么请将屏幕向上滚动，把上面的内容再读一遍。
现在，如果你不需要完整的事务日志记录，而是让数据库完全恢复，那么你应该把数据库改为简单恢复模式。这种方式的事务日志不会增长，因为日志条目将被覆盖，而不是保存到下一次日志备份。
(5)人工通读错误日志
在一些小企业的许多DBA们会每天花时间通读错误日志来寻找问题。如果你只有一台或者两台服务器要管理的话，这中做法不会花太多时间。然而，如果你添加了越来越多的SQL Server服务器，人工浏览这些日志文件可能会花上非常长的时间。
你最好想办法以自动的方式来阅读这些日志文件并寻找错误日志。这会节约你大量时间，尤其是在日志文件增长的情况下，这样可以令你腾出时间来为能增加更多公司基线的项目工作。
如果你已经有监控解决方案了，它可能有一种读应用程序日志的方式。任何错误日志文件中的关键错误都会写到Windows应用日志中。如果你没有任何类型的监控程序，或者如果它不支持读错误日志，你可以加载错误日志文件和(或者)应用程序日志到一个表中，然后来查找错误。
要记住，有大量日常工作可以提升你所在组织的价值，也有另外一些工作不仅不给企业和(或者)SQL Server增加价值，相反实际上还可能破坏基线。好的做法是，常回头看看，看看所有这些任务，每一个任务实际上都在做什么，也要看看这些任务是确实提供了成本效益(例如，备份)，还是没有(人工通读日志)。
