转载

sql server dba大牛的秘籍

维护SQL Server环境可能是一个很复杂的工作（如果准备黑SQLServer的请自行路过，我虽然不认为SQLServer是一个好的产品，但是我希望通过它去带我进入数据库领域，我更希望通过一个产品理解数据库理论，而不是深入研究一个产品。），下面列出10个可能帮你最小化运维复杂度和降低压力的方法。

在过去的几年里面，很多公司都在削减IT部门。很多DBA不得不负责越来越多的SQLServer数据库。更糟糕的是，他们之中很多并不是纯DBA，有些实际上是非自愿成为DBA而不是专业人员，有时候他们仅仅充当消防员的角色进行一个又一个的危机处理。这种情况是非常危险、困难并且难以持续的。因为没有人喜欢无休止的压力和干扰。

应对这种情况的其中一个方法是把SQLServer环境流程化，使其更容易理解和管理。基于我的（指作者）的顾问经历，总结出10条关于SQL Server DBA用于控制环境及降低整体危机发生的可能性的方法。这个列表按重要性排序。

10．制作清单（Take Inventory）：

你有多少次被要求还原那些你可能在此之前完全不知道它们存在的数据库的数据？由于现今企业中数据库的扩展非常常见，所以DBA团队可能会忽略了对数据库实例的跟踪归档。这就导致了很多数据库没有备份、没有打补丁、没有合适的安全措施和错过了一些在重要机器上实施过的管理任务。

所以，建立一个与时俱进的关于企业内部及你所管控的实例和数据库清单非常重要。因为这是你能合理管理它们的唯一方法。这个清单也可用于帮助你建立工作职责。对已知的实例定义支持策略（support policies），并在新实例部署及交付DBA管理之前建立一个配置标准。

关于这个工作，业界有很多工具可以支持，比如简单的工具有SQLPing3、SQLRecon，Quest Discovery Wizard的Planning Toolkit等。

译者注：个人认为，无管理、不运营，无清单，不管理。你连自己管理的内容、管理的对象、管理的数量等等都不知道，你说你能管理、能管好？我该不相信呢？还是不相信呢？有一个up-to-date的清单你可以轻易回答管理层提出的很多问题，诸如：现在有多少个服务器？有多少个数据库？用的是什么版本？数据库大小是多少？有多少个表？最大的表有多少行（其实大表不能仅看行，还要看列及数据类型）等等。并且可以通过这些清单去做资源规划、架构管控等任务。

9．标准化配置（Standardize Configurations）：

如果负责的数据库数量不断地增长，你会发现不同的配置也会随之不断地增长。这种情况下，在实例之间的工作切换会变得非常困难及低效。因为可能对于不同的系统要使用不同的配置，即使一个完整的应用系统，可能也涉及好几个服务器，每个服务器又承担不同的任务，导致配置的不同，管理起来的难度相当“感人啊！”

针对这个问题，需要标准化你的环境，包括盘符、服务器配置项、数据库配置、数据库维护、安全设置等等。SQL Server 2008 引入了基于策略的管理（Policy-Based Management，PBM ）功能用于协助策略的定义和实施。微软SQL Server专家制作了一个名为企业策略管理框架（Enterprise Policy Management Framework , EPM）可以用于在SQL2005和SQL 2000上实现PBM。（SQL 2008 EPMhttps://msdn.microsoft.com/en-us/library/dd542632.aspx）。这个工具的大概截图如下：

sql server dba大牛的秘籍

在过去，本人通常想到什么就做什么，很少静下心来回顾哪些可以合并，哪些是不足或者多余的，但是在最近，随着系统/数据库的增加，这种凭经验做事的方法确实带来很多隐患和加大工作成本，所以本人建议如果想少点麻烦，还是要根据规章制度来比较靠谱。

8．理解I/O子系统（Understand the I/O Subsystem）：

有几个关于I/O子系统的因素会影响SQLServer实例的正常、高效运行。你需要知道它们及其潜在影响：注：I/O子系统不仅仅指磁盘，还包括内存、网络甚至CPU的部分功能。

I/O子系统的能力：读写能力及其吞吐量和磁盘空间。它们必须能够应对负载峰值的要求和在不得不购买/添加更多资源之前能应对空间增长压力。通过标识I/O瓶颈和移动数据/日志文件到其他I/O子系统从而实现一定程度的负载均衡。负载均衡被说了很多年，已经逐渐被误导成仅仅指通过横向扩展分摊负载，虽然并没有严重错误，但是我们应该更多地把注意力集中在对“负载”的均衡而不是着眼于仅仅想办法把用户请求分摊到多个服务器上这种做法上。难道磁盘读写负载的分摊就不能称为负载均衡了吗？
I/O子系统的容灾能力：通常指RAID级别和是否能实现镜像写入备份或是其他形式的镜像/复制（指I/O子系统层面而不是SQL Server层面）。保护磁盘上的数据文件和日志文件避免出现故障是DBA的首要任务。（译者注：在过去，很多人对稳定性、安全性、扩展性、高效性等系统特性排序时，都选择了安全性或者高效性，但是个人认为，一个不稳定的系统，给你账号密码有什么用？一登陆就崩溃，你能等到什么？所以我认为稳定性才是一切的前提）。但是这种选择又必须权衡，RAID 10能提供比RAID 5更好的容错能力，但是成本更高。关于这部分可以看一下白皮书：PhysicalDatabase Storage Design
I/O子系统的合理配置：RAID条带大小（RAID stripe size），NTFS分配单元/集群大小和分区对齐，这部分可以看：http://www.sqlskills.com/BLOGS/PAUL/post/Are-your-disk-partition-offsets-RAID-stripe-sizes-and-NTFS-allocation-units-set-correctly.aspx

7．创建自定义的维护计划（Create a Customized Maintenance Plan）：

你不能仅仅把数据库放到生产环境然后不管。（Youcan’t just put a database into production and walk away.）索引碎片会随着时间越来越多，从而导致性能下降。统计信息可能变得过时而导致次优/不合理的执行计划产生从而影响性能。I/O子系统可能会崩溃，这导致备份必须无处不在。

对于这些问题，可以建立针对你数据库自身的完整的维护计划。一个定制的计划远好于一个没有满足你需求的通用计划。这部分可以阅读：Top Tips for Effective SQL Server Database Maintenance http://technet.microsoft.com/magazine/2008.08.database.aspx ，文章告诉你如何构建一个优秀的维护计划。另外https://ola.hallengren.com/中的脚本可以作为构建自定义维护计划的切入点。

注：永远不要盲目相信产品提供的功能，凡是能给你选择用还是不用，开还是关的功能，都有其适用场景。SQL Server的维护计划有不少的问题，Oracle的RAC也不能完全解决负载均衡的问题，不加思考地使用别人有意无意推荐的功能，并不见得安全有效。不过你应该感谢那些热心帮助你的人。没有谁天生就有义务帮你解决问题。

6．确保系统的安全（Ensure the Security of Your System）：

花时间主动发现安全问题是极其重要的，这可以保证你不需要在发生之后才处理它们。在文章Common SQL Server Security Issues and Solutions 中列出了10个最常见的安全问题及其应对方案。同时，别忘了了解你系统的补丁情况以便你发现系统漏洞。

关于安全方面，建议看一下这两本书《SyngressSecuring SQL.Server》、《Microsoft SQL Server 2012 SecurityCookbook》，虽然它是说SQL Server的，但是不管你用什么RDBMS（关系数据库管理系统，比如oracle、MySQL、DB2等等），学一下别人的思路总可以吧。关于第二本书，鄙人简单翻译了几篇：http://blog.csdn.net/dba_huangzj/article/details/37906349

5．处理好与开发团队的关系（Get on Good Terms with Your Developers）：

在IT部门中的其中一个主要的鄙视链 是DBA团队和开发团队的关系。两个团队通常不能很好地理解对方的优先事项及其关注点——内容包括从开发进度到SQL Server设计的任何一部分。关于特性、性能问题、责任等的不同观点成为了最常见的争论所在。

积极与开发团队沟通配合能使你的工作更加顺畅。与开发团队进行设计审查，在投入生产以前充分测试代码，尽量避免破坏性的错误，这些都可以进一步削弱团队内部的关系。

注：我不希望每次都是DBA给开发人员“讲课”、“培训”，这会导致开发人员的可能的心理压力，不排除他们觉得自己低人一等（希望是我多虑了），大家应该平等地沟通、交流，DBA说的往往是根据一些原理、规定、现象，但是不可能保证他们完全清楚一线人员的处境及实际项目的特点，所以我更希望大家交流一下关于项目的一切。

4．制定一个完整的灾难恢复策略（Develop a Comprehensive Disaster Recovery Strategy）：

不管你的基础架构如何强悍，你都必须有一个应对偶发性灾难的计划。你不可能总能预知磁盘损坏、断电、火灾、突发性数据丢失和其他潜在问题。你需要对这些问题进行计划性防御及恢复。

与管理部门一起确定数据库停机时间和数据丢失的SLA，制定计划用于把数据从各种故障中恢复，确定你的数据库及所有SQL 实例能符合企业的业务连续性计划。对所有数据库和实例制定故障恢复的优先级。注：这段看上去其实有点扯淡，你去问业务部门试试，他们肯定只告诉你：0丢失、0停机。但是他们不知道即使是世界上最大的IT企业甚至美国国防部都不可能做到0停机。不过有必要的时候还是告知一下，最起码你得让他们知道“成本”问题。

同时也需要使用一些技术来协助你知道问题何时发生，比如数据页校验（page checksums）、一致性检查（consistency checks）、SQL 代理警报和系统操作管理器警报。这些灾难恢复基础架构配合备份、日志传送、复制和数据库镜像及其他技术可以用于更好地保护数据。关于这方面可以月度微软白皮书：High Availability with SQL Server 2008 和 Proven SQL Server Architectures for High Availability andDisaster Recovery 。

3．定期实施和测试备份（Take and Test Regular Backups）：

不管你的高可用和灾难恢复策略如何完美，你都不要放弃对数据库的常规备份。如果你的数据库损坏或者发生严重错误，可以依赖的只有最新的数据库备份，如果没有任何备份，企业将因此蒙受致命打击。除了进行常规备份，同时也要对备份文件进行周期性还原测试以便保证备份文件可用。注：没有常规校验的备份文件应该列入不可信任的文件，如果条件允许，应该把备份文件移到一个有足够空间的服务器进行完整还原。另外在本人某家公司任职时，被要求对初级DBA进行培训，当时第一课就是讲备份，可惜他们根本不想听，认为对备份认识已经足够了，但是人家大公司的Oracle的DBA团队通常都有几个人专门做备份啊，只做备份这一件事啊亲！人家工资还比我高啊！！

关于这部分可以阅读：Understanding SQL Server Backups 和 SQL Server: Recovering From Disasters Using Backups.

2．监控和维护性能（Monitor and Maintain Performance）：

性能优化一直是DBA日常工作的重要组成部分，但是也有很多方式去流程化这部分的工作：

建立性能基线以便用于判断是否性能发生了改变。
把系统拆分成可以度量的原子部分，并且确保它们不会收到外界影响。
使用“等待和队列”快速定位性能问题。
使用系统基础信息、性能计数器、等待信息去监控性能，也可以使用SQL 2008的性能数据收集功能和2005开始的性能仪表盘功能，通过它们可以得知性能状态从何时开始下降。
建立一个维护计划。
使用如数据库引擎优化顾问（DatabaseEngine Tuning Advisor，DTA，注：本人不认为DTA是个可以常用的工具，因为本人见到太多滥用导致更多问题的例子，使用时请先了解其优缺点及限制情况）、关于索引的动态管理视图（Dynamic Management Views，DMVs）去发现和实施索引策略。