我们在服务器模式下使用devexpress网格和LinqToEF,虽然我不确定这是否重要。当我们的页面首次加载网格时,它有时会很慢,并且在查询SQL DB时需要超过60秒或超时。发生这种情况时,存在高数据库I / O和等待任务。其他时候,同一个查询过得很快,您只能看到活动监视器上的CPU利用率。
数据库非常大,但我们只返回了大约100行。表中有几个索引被拉到视图中,devexpress网格使用这些索引,所有这些表的索引都有0.01或更少的碎片。
我们将重建索引,重新组织和/或重新启动服务器,并且没有关于完成哪些操作的一致性,相同的查询将来自具有高DB I / O且速度慢,CPU利用率高峰和快速。慢速> 60秒或超时,快速<2秒。
相同的疑问。
有谁知道我可以从哪里开始寻找或帮助排除故障的一些事情?
答案 0 :(得分:0)
我首先检查是否有不同的执行计划。根据您可能会或可能不会传递的参数,糟糕的执行计划可能会产生您所看到的那种结果。使用此:
SELECT *
FROM sys.dm_exec_cached_plans a
CROSS APPLY sys.dm_exec_sql_text(plan_handle) b
CROSS APPLY sys.dm_exec_query_plan(plan_handle) c
WHERE text LIKE '%SnippetOfQueryText%'
AND b.dbid = DB_ID('DBName')
检查同一查询的多个计划。调用存储过程而不是使用任何动态sql语句是一个好主意。
您可以使用此SQL在任何时间点查找缓存中的表数据:
SELECT COUNT(*) AS cached_pages_count ,
name AS BaseTableName ,
IndexName ,
IndexTypeDesc
FROM sys.dm_os_buffer_descriptors AS bd
INNER JOIN ( SELECT s_obj.name ,
s_obj.index_id ,
s_obj.allocation_unit_id ,
s_obj.object_id ,
i.name IndexName ,
i.type_desc IndexTypeDesc
FROM ( SELECT OBJECT_NAME(object_id) AS name ,
index_id ,
allocation_unit_id ,
object_id
FROM sys.allocation_units AS au
INNER JOIN sys.partitions AS p ON au.container_id = p.hobt_id
AND ( au.type = 1
OR au.type = 3
)
UNION ALL
SELECT OBJECT_NAME(object_id) AS name ,
index_id ,
allocation_unit_id ,
object_id
FROM sys.allocation_units AS au
INNER JOIN sys.partitions AS p ON au.container_id = p.partition_id
AND au.type = 2
) AS s_obj
LEFT JOIN sys.indexes i ON i.index_id = s_obj.index_id
AND i.object_id = s_obj.object_id
) AS obj ON bd.allocation_unit_id = obj.allocation_unit_id
WHERE database_id = DB_ID()
GROUP BY name ,
index_id ,
IndexName ,
IndexTypeDesc
ORDER BY obj.name;
GO