DBA

觉得挺不错的一篇文章，就顺手翻译了下，如果英文凑合的话，还是看原版吧。 ：） 原文地址：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.“ 上找到更多的内容。 2，性能监控和维护 Monitor and Maintain Performance 性能调优占据了一个DBA的大部分时间，但有很多方法可以简化这个过程： ~建立性能基线，以便可以看到性能是否真的变了； ~将系统进行分解，可以没有外部因素干扰的隔离下进行测试； ~使用等待-排队的理论，快速查明性能问题 ~监控系统性能基元，性能计数器和等待统计，这样你将会知道性能在什么时候开始下降。使用2008的Data Collector 和 SQL Server 2005的 Performance Dashboard . ~建立维护计划 ~借助工具进行仔细的规划和执行索引策略，这样的工具有Database Engine Tuning Advisor（DTA）, 与索引相关的一些 Dynamic Management Views (DMVs) 1，懂得寻找所要的信息 Know Where to Find Information 知道什么时候需求帮助是非常关键的。你要知道你的限制，你是无法了解有关SQL Server的所有一切。因此没必要浪费宝贵的时间，总会有人可以帮助你的任务和问题。 你的第一信息资源是SQL Server的联机丛书，你可以下载安装在本地或者到MSDN在线搜索。SQL Server联机丛书很适合用来查询语法，但如果你有更复杂的问题，或试图解决一个问题时，最好的办法是发布到网上论坛。在MSDN上有很很多的SQL Server论坛，也有一些热门的社区，如SQL Server Central 另外一种寻找帮助的快速方法是参与Twitter的SQL Server社区，在你发布的问题时，加如#sqlhelp 标签，便能够得到很多SQL Server专家的帮助，包括我。 接着是参加SQL Server会议，如 PASS ，SQL Server connection，SQL Saturdays。Thomas LaRock维护了一份SQL Server专家 的博客活跃程度及价值排名。 你可能会因为工作强度过大而觉得不堪重负，但如果你把一些额外的工作，通过努力，并参考这些建议，你应该可以发现你会得到很大的好处。你的系统会运行的更加顺畅，你会有更好的组织，并会成为一名更加熟练的DBA. Paul S. Randal is the managing director of SQLskills.com, a Microsoft regional director and a SQL Server MVP. He worked on the SQL Server Storage Engine team at Microsoft from 1999 to 2007. He wrote DBCC CHECKDB/repair for SQL Server 2005 and was responsible for the Core Storage Engine during SQL Server 2008 development. Randal is an expert on disaster recovery, high availability and database maintenance, and is a regular presenter at conferences worldwide. He blogs at SQLskills.com/blogs/paul, and you can find him on Twitter at Twitter.com/PaulRandal.