日期:2014-05-16  浏览次数:20502 次

深入SQL Server数据库速度提升问题

  SQL服务器的性能管理通常是反应式的,它侧重的是服务器的运行状态。数据库管理员会对问题作出响应而不是将避免问题的产生摆在首位。可视性也很大程度上仅限于观测数据库服务器而不是了解SQL服务器怎样直接对程序用户的产生影响。

  等待时间分析是对SQL服务器数据库性能的一种改进方法,它不再只是监测系统的运行状况而已,等待时间分析侧重于应用程序响应询问所需的时间。其结果是一种能够迅速回答关键问题的分析技巧,如为什么数据库要让用户进行等待,我们又可以为此做些什么呢?

  由于轻量级监测技术和无代理架构的发展,等待时间分析现在已经可以应用与实际操作了。它利用了SQL服务器中新设备来暴露等待类型,这些步骤在SQL服务器处理询问时积累延时。

  事半功倍

  对于IT机构来说,使用等待时间分析的结果可以减少数据库操作的成本并改进IT服务。数据库管理员可以用更少的服务器完成更多的工作。从SQL Server 2000到2005再到2008,开发周期缩短了。对于那些要用更少的资源提供更优质服务的IT公司来说,等待时间分析是实现成本效益的答案。

  数据库管理员通常位于两难的境地。对于响应程序用户的数据库来说,他们的数量是有限的,但是他们却不能看到数据库减缓的原因。通常这样的事情根本不是发生在其数据库中,但是却源于应用程序代码,网络或者系统架构。为了获取改变的应用程序代码,数据管理器必须为程序员提供证据,与此同时,程序员会感到十分疑惑因为他们并不了解数据库。这些问题是典型的依赖于旧式服务器状态监测技术的表现。

  等待时间分析

  有效的等待时间分析不仅仅是截取等待类型的数据。为了能有效地在模糊数据点中生成有用信息,它必须利用商业智能情境中验证过的技术。其中关键的概念包括:

  • 测量时间,不要考虑操作 对于应用程序用户,I/O操作或逻辑读取的数量已经没有什么意义。重要的是应用程序响应所需的时间。从这一角度来实现优化要侧重于数据库所需的时间。等待类所做的就是这一操作。
  • 注意查询 问题的关键是SQL查询级别的测量和单独对话。测量通过实体或数据库的等待而不会减缓其速度的工具不会给出有价值的信息。
  • 持续捕获 整个过程中要时刻保持监视。通过观测所有的对话,数据库管理员可以发现任何问题。当用户因为程序速度减慢而寻求帮助的时候,数据肯定已经准备好了。依赖于间歇性追踪的系统将错过可能发生的错误。
  • 历史地观测 要明白需要修复什么,数据库管理员应该研究数据库的趋势和变化,而不只是看到即时结果。有效的等待时间分析用历史的眼光来比较当前等待类的统计数据和以前的统计以便发现其中的不同之处,这有助于解决潜在的新问题。

  SQL Server等待类

  意识到SQL 服务器等待类是了解该方法的第一步。任何有悖于SQL服务器运行的语句都将面对等待,因为SQL服务器会为要完成的命令按照顺序访问资源。请求会等待要检索的,要写入磁盘或是要写入SQL服务器日志的数据。当等待变成一个长期过程或超量时,就会出现性能问题了。

  普通等待类

  SQL服务器会记录类的信息以及等待进程的持续时间。虽然在SQL服务器中有100多种类,但是其中可能只有少数会出现问题。任何等待类都以LCK_开始,这意味着该任务在等待获得一个锁定。例如,一个LCK_M_IX的等待类意味着等待获取Intent Exclusive锁定。20多种等待类是锁定等待,这些等待之所以恰当是因为SQL服务器中大多数执行的任务要求某种锁定。下一个最普遍的锁定种类是ASYNC_IO_COMPLETION和ASYNC_NETWORK_IO。前一个是等待I/O操作完成的等待,后一个是等待I/O在网络上完成的等待。最后,留意一下CXPACKET等待状态。当某一进程试图使查询处理器交换迭代同步时会出现这一等待。这说明了服务器并行设置问题。花时间弄清楚怎样的潜在等待状态是耗时的。平均来说,大约20种潜在等待状态表现了80%的问题。在完成等待时间分析之后,你就习惯某些等待类了。


相关阅读:
  • SQL Server的MDF文件恢复/修复方法 (iSQlServer, 2009-5-19)
  • SQL Server如何对日志进行压缩 (iSQlServer, 2009-5-19)
  • 计算SQL Server备份一次所花的时间 (iSQlServer, 2009-5-19)

?