觉得挺不错的一篇文章，就顺手翻译了下，如果英文凑合的话，还是看原版吧。 ：）
原文地址：http://technet.microsoft.com/en-us/magazine/gg299551.aspx
维护一个SQL Server环境可能会是一项非常复杂的任务。本文将列出10条可以让您降低复杂性和减少压力的SQL Server维护方法。
Paul S. Randal
在过去的几年里，越来越多的公司开始削减他们的IT部门。很多DBA不得不面对越来越多的数据库管理，更糟糕的是，有时候他们还不是真正意义上的DBA。而且在很多情况下，DBA不幸充当了消防员的角色，持续处理不断出现的危机。没有一个人愿意在这样的糟糕的工作环境下工作，因为这往往需要承担更多的压力和打击。
摆脱这种工作情形的一种方式就是多花一点时间简化自己的SQL Server工作环境，使之更容易理解和管理。根据我的SQL Server咨询经验，下面是10种方法可以提高DBA对SQL Server环境的控制能力和减少整体问题发生。这份清单里的内容按照重要程度来排序，越往下越重要。
10，编制清单 Take Inventory
有多少次在你被要求还原损坏的数据库时，你甚至不知道有这样的数据库存在？这种情况在企业的扩张过程中，随着数据库的增加是很容易发生的。如果没有有效跟踪，将会导致未管理的SQL Server实例存在。从而会使这些实例上的数据库未能有效备份，未能应用补丁，未能应用有效的安全管理或者未能应用其他必须执行的管理任务。
维护一份企业环境里最新和可控的实例和数据库清单是非常有必要的。这是有效管理它们的唯一途径，并可以确定在必要的时候、合适的范围内进行项目计划和升级。这样清单还能帮助你明确你需要负责任的数据库，并与企业内的其他团队达成一致，防止出现权责纠纷。您还可以定义已知实例的支持策略，并要求新的实例必须满足您的策略前，才去维护和支持。
有许多的工具可以帮助您创建一份SQL Server清单，如SQLPing3 、 SQLRecon 、Microsoft Assessment and Planning Toolkit、Quest Discovery Wizard
9，标准化配置 Standardize Configurations
如果你负责的数据库和SQL 实例数不断的在增长，你会发现不同配置的数目也会以类似的方式进行增长。在你需要不断记住不同实例的配置细节情况下，将会很难有高效的工作效率。
该解决方案是尽可能的标准化你的配置信息，如磁盘驱动符、服务器配置选项、数据库设置、数据库维护、安全设置等等。在SQL Server 2008里，引入了基于策略的管理(Policy-Based Management ),帮助指定和执行策略。Lara Rubbelke，一个在微软的SQL Server技术专家，开发了Enterprise Policy Management (EPM) 框架，在这个框架下，可以扩展策略管理到SQL Server 2000/2005的实例上。可以在codeplex找到EPM 框架，下图是一个简单的EPM框架报表。
8，了解IO子系统 Understand the I/O Subsystem
有几个与IO子系统相关的因素会影响到SQL Server实例，你需要对这些有一定认识并明白它们的潜在影响。
~表示IO子系统的能力可以使用读/写吞吐量和磁盘空间来衡量。它必须满足高峰期是的工作负载并有足够的空间容纳数据的增长。通过确认IO瓶颈和移动数据文件或日志文件，你可以更均匀的平衡负载。
~表示IO子系统冗余能力可以使用RAID级别和是否可以做些如镜像备份和任何形式的镜像/复制(在IO子系统级别，而非SQL Server级别)。保护数据和日志文件，避免因磁盘故障和其他潜在问题而造成损失是非常重要的。但这需要进行权衡，RAID10提供了比RAID5更好的冗余，但其价格也更昂贵。请参阅白皮书“Physical Database Storage Design”了解更多细节。
~确保IO子系统配置了正确的RAID条带大小，NTFS分配单位，簇大小和分区。可以参看“Are your disk partition offsets, RAID stripe sizes, and NTFS allocation units set correctly?” 这个博客了解更多的细节。
7，创建自定义的维护计划 Create a Customized Maintenance Plan
在我的数据库维护的教学课堂上，经常讲到“你不能只是简单的将一个数据库设置为生产库，然后走开”。如果这样的话，索引的碎片会越来越严重，从而导致性能下降；统计信息将会过期，导致不良的查询语句和糟糕的性能；IO子系统可能会遭到破坏；还有必要对备份设置永久保存。
如果为数据库定制一个全面的维护计划，将会很好的解决这些问题。一个自定义的维护计划远比不能满足需要的普通计划来得好，在我八月份的 TechNet 杂志上也提到了这个话题“Top Tips for Effective SQL Server Database Maintenance”http://technet.microsoft.com/magazine/2008.08.database.aspx，并告诉你如何建立一个好的维护计划。建立自己的维护计划的最好开始方式便是使用 Ola Hallengren 的维护脚本http://ola.hallengren.com/。这也是我一直推荐我的客户在使用的。
6，确保系统安全 Ensure the Security of Your System
花点时间主动去发现安全问题是至关重要的，也是阻止事故和不需要处理它们的基本手段。在我另外一篇TechNet 杂志上的另外一篇文章“Common SQL Server Security Issues and Solutions ”，列出了10种最常见的安全问题以及如何去避免他们。另外，不要忘记时刻应用最新的补丁来修补漏洞。
5，和你的开发团队处理好关系 Get on Good Terms with Your Developers
在任何一个IT部门里，DBA团队和开发团队往往处于紧张的关系。这两个群体通常不理解彼此的优先事项和关注点--开发的期限和SQL Server设计决策。在性能问题和围绕开发、支持的责任上也常常会有不同的观点。
你可以通过积极主动的参与开发团队活动来使工作更顺畅。组织交互式的教育课程是种很有效果的方式，特别是在一种非互相指责的氛围下。现有DBA团队需要对设计进行审查并充分的测试代码，然后再部署到生产系统上，这将会有望避免破坏性的错误和进一步破坏团队间的关系。
4，制定全面的灾难恢复策略 Develop a Comprehensive Disaster Recovery Strategy
不管你的基础架构有多好的“防弹”性能，你还是必须有一个灾难的应急计划。你无法预知损坏，停电，火灾，意外的数据丢失或其他潜在的问题，因此，你需要一个计划来应对和处理这些问题。
首先需要和管理层确定所允许停机的时间和数据丢失，并对怎样从各种数据丢失中恢复进行计划，确定如何使你的数据库和实例能够满足企业业务的持续性。弄清楚所有数据库和实例的相关重要性，以便能优先进行灾难恢复。
你还需要借助其他技术来帮助你了解问题何时发生，例如页校验，一致性检查，SQL Agent 警报 和 System Operations Manager 警报。微软还提供了多种灾难恢复基础架构来保护您的数据，如日志传送，复制，数据库镜像，故障转移集群。有两个白皮书，可以帮助到你：High Availability with SQL Server 2008 ” 和 “ Proven SQL Server Architectures for High Availability and Disaster Recovery .”
3，采用定期备份和测试 Take and Test Regular Backups
即使有再好的高可用和灾难恢复计划，你都必须要有定期的数据库备份。如果你的数据库被破坏或遭受致命的损坏，你唯一的可用资源也许只有你的最后一组备份。所以，如果你没有任何的备份，你的公司将会遭受重大的灾难。你不仅需要备份，你还需要定期的进行恢复测试，保证这些备份在需要的时候能够正常使用。
你可以在我的另外两篇为TechNet杂志写的文章---”Understanding SQL Server Backups ” and “SQL Server: Recovering From Disasters Using Backups.“ 上找到更多的内容。