讨论四：运行的MSSQL系统突然变慢了，应该如何去排查

开着拖拉机泡妞 2013-12-17 03:38:47

加精

welcome 魔君

继续

.
.
.
.
.
.
.
.
.
.

...全文

7980 71 打赏收藏转发到动态举报

写回复

用AI写文章

71 条回复

切换为时间正序

请发表友善的回复…

发表回复

xiaoyao_98 2014-10-15

打赏
举报

具体问题具体分析，应该从硬件、软件、系统等方面分析，

还在加载中灬 2014-10-15

打赏
举报

围观神贴!!

Neo_whl 2014-09-02

打赏
举报

学习，支持

gem227 2014-08-11

打赏
举报

mssql主要是内存占用比较多，你可以做个计划任务定期释放下内存，这样就能缓解系统运行速度慢的问题！

wangnaisheng 2014-07-31

打赏
举报

mark一下，学习~

Joylwu 2014-07-25

打赏
举报

以下选自《Inside Microsoft SQL Server 2008: T-SQL Querying》使用自顶向下方法的优化论。这种方法首先分析实例级的等待时间，再通过一系列步骤将其不断细化，直到找出系统中导致大量等待的进程/组件。一旦找出这些令人讨厌的进程，就可以集中优化它们了。以下是这种方法论的主要步骤： 1. 分析实例级别的等待优化方法论的第一步是在实例级别上找出什么类型的等待占用了大部分的等待时间。这可以通过查询动态管理图（DMV, dynamic management view)来完成。该 DMV 包含了400多种等待类型，大多数类型在SQL Server联机丛书中至少有一段简单的文字说明。如果考虑一下，你会认为这个数暈还算是可以管理的等级，可以将这个DMV作为优化的起点。而其它一些性能工具则不适合在开始时使用，因为它们提供的信息量太大，让你无从入手。 2. 关联等待和队列在实例级找出重量级的等待之后，就应该把它们和队列关联起来，以找出有问题的资源。这一步主要是用性能监视器（PerformanceMonitor)的计数器来完成任务的。例如，如果在上一步找到的是与I/O相关的等待，这时就应该检査不同的I/O队列、缓存命中率、内存计数器。平均在每个（磁盘）转轴上的一个I/O队列中，正在等待的I/O命令不应该超过两个。缓存命中率应该尽可能要髙。 3. 确定方案在找出主要等待类型和这些等待所涉及的资源之后，接下来的这一步是优化过程中承上启下的 —步，根据到目前为止所掌握的信息，你将确定下一步研究的行动方案。 4. 细化到数据库/文件级优化处理的下一步是细化到数据库/文件级别。这一步要找出哪些数据库占用了大部分等待开销。在数据库内，还需要再细化到文件类型（数据/日志），因为文件的类型决定了要采取的行动方案。在数据库/文件级别分析I/O信息的一种工具是动态管理函数sys.dm_io_virtual_file_stats。这个函数接受一个数据库ID和文件ID作为输入，返回与该数据库文件相关的I/O信息。如果将这两个参数都指定为NULL，则返回关于所有数据库和所有文件的信息。 5. 细化到进程级既然己经知道了哪些数据库导致了大部分性能问题，现在就应该继续细化到进程级别，也就是说，找出要优化的进程(存储过程、査询等)。对于这个任务，使用SQL Server内建的跟踪（tracing)功能特别方便。这一步要对工作负荷（workload,代表正在关注的数据库在系统中的典型活动）进行跟踪，分析跟踪数据，并找出要优化的进程。跟踪会影响系统的性能，应该尽量减少这种影响： ->不要使用SQL Server Profiler GUI进行跟踪； ->不要把跟踪数据直接写到表，这样会严重影响性能。把跟踪数据写到磁盘文件是最快的选择； ->跟踪会产生大量的数量和额外的I/O操作。不要把目标跟踪文件放到包含数据库文件（如数据、日志和tempdb)的磁盘上。理想的情况是，为目标跟踪文件专门配置单独的磁盘驱动器； ->慎重选择事件类和数据列，只跟踪需要的佶息，移除所有默认的和不必要的对象； ->使用跟踪筛选功能，只选择相关的事件。 6. 优化索引/査询现在己经知道了哪些査询模式需要进行优化，可以着手更具体的査询优化步骤了