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 体系结构）”。