过去数年来，许多公司纷纷精简了其 IT 部门。很多数据库管理员 (DBA) 不得不承担大量的 SQL Server 数据库管理工作。更糟糕的是，经常并没有真正意义上的 DBA，而是随便找个人来充任。而且有时候，DBA 纯粹成了救火队员，在不断涌现的危机之间疲于奔命。这样恶劣的环境是不正常的，也难以持久。没有人愿意处于这种持续压力和干扰之下。
摆脱这种境况的一个方法是花点功夫来简化您的 SQL Server 环境，使之更易于理解和管理。我根据担任 SQL Server 顾问的实际经验总结出了以下十种方式，可以帮助 SQL Server DBA 提高对环境的控制力，并减少发生危机的可能性。这些方式按大致的重要程度列出，越往后越重要。
10. 编制清单
有多少次当您被要求还原受损的数据库数据时，您甚至不知道这些数据的存在？SQL Server 数据库很容易在公司内泛滥。DBA 团队可能不知道数据库中哪些数据不在了，从而失去对 SQL Server 实例的控制。这样一来，未进行备份、修补的数据库可能无法采取恰当的保护，并错失其他很多必要的管理任务。
因此，当务之急是掌握您可控的公司实例和数据库***清单。这是有效管理它们、必要时进行合并，并正确划定范围和规划项目及升级的唯一途径。编制清单还可以帮助您在与公司内各个团队协商之后，通过公布您负责的已知实例列表来明确您的职责。您可以拟定已知实例的支持策略，并要求新实例严格遵守您的配置准则，否则将不予支持。
有许多工具可以帮助您创建 SQL Server 清单，例如，像 SQLPing3 和 SQLRecon 这样的简单工具、Microsoft 评估和计划工具包和 Quest Discovery 向导等。
9. 标准化配置
如果您负责的数据库和 SQL 实例数量在不断增长，您会发现不同配置的数量也在以类似的方式增长。如果您不得不记住不同实例的配置细节，那么很难在面对不同实例时取得高效。
解决方法是尽可能标准化配置信息，如驱动器号、服务器配置选项、数据库设置、数据库维护、安全设置等等。SQL Server 2008 中引入了基于策略的管理功能，可帮助定义和实施策略。此外，Microsoft 的 SQL Server 技术专家 Lara Rubbelke 开发出了企业策略管理 (EPM) 框架，可轻松扩展到 SQL Server 2005 和 SQL Server 2000 实例上。您可以从 CodePlex 获取该 EPM 框架。图 1 显示了一个 EPM 框架报告示例。
.jpg)
图 1 企业策略管理框架报告
8. 了解 I/O 子系统
有几个与 I/O 子系统有关的因素会对 SQL Server 实例造成影响。您需要认识到这些因素及其可能的影响：
I/O 子系统的读/写吞吐量和磁盘空间容量。必须能满足工作负荷峰值要求，并能在您不得不为增长的数据量购买更多容量之前提供足够的空间。您可以确定 I/O 瓶颈并将数据和/或日志文件移至 I/O 子系统的其他部分，从而更均匀地平衡负载。
I/O 子系统的 RAID 级别冗余能力以及能否执行诸如分割镜像备份的操作和任何形式的镜像/复制（在 I/O 子系统层面，而非 SQL Server 层面）。保护好数据和日志文件，避免因驱动器故障和其他潜在问题而遭受损失是很重要的。但这往往要进行折衷 - RAID-10 的冗余能力胜过 RAID-5，价格也更昂贵。有关详细指南，请参见白皮书“物理数据库存储设计”。
I/O 子系统的 RAID 条带大小、NTFS 分配单元/簇大小和分区对齐是否配置正确。有关详细信息，请查看我的博客帖子“Are your disk partition offsets, RAID stripe sizes, and NTFS allocation units set correctly?（您的磁盘分区偏移量、RAID 条带大小和 NTFS 分配单元设置是否正确？）”。
7. 创建自定义维护计划
我在教授数据库维护课程时，总是以“你不能只是把数据库付诸生产，然后听之任之”作为开头语。索引会随时间变得越来越零碎，从而导致性能降低。统计信息逐渐过时，从而导致不良查询和恶化的性能。I/O 子系统可能遭到破坏，对备份的需求永无止境。
您可以为数据库定制一个全面的维护计划，来解决以上所有问题。自定义的计划远比不能充分满足需求的通用计划好得多。我曾于 2008 年 8 月在《TechNet 杂志》上发表了“高效维护 SQL Server 数据库的关键技巧”一文，其中介绍了如何创建好的维护计划。建立自己的维护计划的***开始方式是使用 Ola Hallengren 编写的免费脚本。我一直推荐客户使用该脚本。
6. 确保系统安全性
花点时间主动发现安全问题是很有必要的，可以防止事件发生，而不用事后再做处理。我的另一篇《TechNet 杂志》文章，“常见的 SQL Server 安全性问题和解决方案”，列出了十个最常见的安全问题以及规避方法。此外，发现漏洞时别忘了及时修补系统。
5. 处理好与开发团队的关系
在任何 IT 部门中，DBA 团队与开发团队之间的关系往往是主要矛盾之一。这两个团队通常都不理解对方的优先事项和关注点 - 从开发期限到 SQL Server 设计决策。在行为、性能问题以及部署与支持职责等方面，两个团队常常持不同观点。
您可以通过积极而有效地参与开发团队的工作来使自己的任务进展更顺利。共同组织教育课程是一种颇为奏效的方式，尤其是当气氛很友好时。在将设计付诸生产之前，与出席的 DBA 团队成员一起进行评审并充分测试代码，这有望避免可能进一步有损团队关系的破坏性错误。
4. 制定全面的灾难恢复策略
无论您的基础结构有多牢固，当灾难降临时您必须具备应急计划。您无法预知损坏、停电、火灾、意外数据丢失或其他诸多潜在问题，因此，您需要一个计划来应对这些问题并进行恢复。
您可以和管理层一起拟定数据库的停机时间及数据丢失软件许可协议，对如何从各种数据丢失类型中恢复做出规划，并确定如何将数据库和所有 SQL 实例纳入公司的业务连续性计划。弄清楚所有数据库和实例的相对重要性，以便确定灾难恢复的优先次序。
您还需要借助其他技术来帮助了解问题发生的时间，例如，页面校验和、一致性检查、SQL 代理警报和 System Center Operations Manager 警报等。灾难恢复基础结构可通过备份、日志传送、复制和数据库镜像来帮助您保护数据，并有可能通过数据库镜像或故障转移群集将故障转移到冗余系统上。以下两个 Microsoft 白皮书可为您提供帮助：“High Availability with SQL Server 2008（SQL Server 2008 高可用性）”和“Proven SQL Server Architectures for High Availability and Disaster Recovery（具备高可用性和灾难恢复功能的经检验的 SQL Server 体系结构）”。
3. 定期备份并进行测试
无论您的高可用性和灾难恢复计划有多周详，您都必须对数据库进行定期备份。如果您的数据库遭到破坏或灭顶之灾，那么您唯一的资源或许只有***的备份，倘若您没有任何备份，可能会给公司带来极其严重的后果。您不仅需要备份，还需要定期进行恢复测试，以保证这些备份在需要时能够正常使用。
您可以从我 2009 年为《TechNet 杂志》撰写的两篇文章中找到更多信息：“Understanding SQL Server Backups（了解 SQL Server 备份）”和“SQL Server:Recovering From Disasters Using Backups（SQL Server：使用备份进行灾难恢复）”。
2. 监视和维护性能
性能调节占据了 DBA 的大部分时间，但有很多方法可以简化这个过程：
建立性能基准，以便了解性能是否真的发生了变化。
将系统分解为可在无外部因素干扰下隔离测量的基元。
使用等待-排队方法快速查明性能问题。
采用系统基元、性能计数器监视性能，并等待统计信息。这样您会知道性能何时开始下降。可使用 SQL Server 2008 中的性能数据收集器功能以及 SQL Server 2005 的性能仪表板。
制定维护计划。
借助工具认真规划和执行索引策略，如数据库引擎优化顾问、DTA、缺失索引动态管理视图 (DMV) 和索引使用 DMV。
1. 懂得从何处寻找信息
要做的事情无穷无尽，懂得何时放手并寻求帮助才是上上之策。您应当了解自己的局限性，清楚自己不可能了解有关 SQL Server 的一切。如果有人能帮助您完成任务或解决问题，那么您没有必要自己苦苦挣扎并浪费宝贵的时间。
您的首要 SQL Server 信息源是 SQL Server 联机丛书，您可以下载并安装到本地，或在 MSDN 中联机搜索。《SQL Server 联机丛书》很适合用来查询语法，但如果你有更复杂的操作问题，或正尝试解决某个问题，那么***的办法是将问题发布到联机论坛。MSDN 上有许多 SQL Server 论坛，还有一些热门的社区站点，如 SQL Server Central。
还有一种寻求帮助的快速方式是借助 Twitter 的 SQL Server 社区。发布问题时加上 #sqlhelp 哈希标签，很多 SQL 专家（包括我）便可以看到您的问题。
此外，可以参加专门讨论 SQL Server 的会议，例如，每年的 PASS 社区峰会、两年一次的 SQL Server Connections 或更频繁的 SQL 星期六主题日。可以关注社区中很多 SQL Server 专家的博客。您可以通过 MVP Thomas LaRock 维护的博客排名，了解这些博客的活跃程度及关注价值。
您可能已经因工作强度过大而不堪重负，但如果能抽出一些时间来了解这些建议，您会发现自己获益匪浅。您的系统将运行得更顺畅，您将更有条理，您将获得更多的宁静 - 您终将成为一名更为专业的 DBA。
【编辑推荐】
