检查索引碎片的结果:
处理过后的索引碎片:
--SQL2005以后有一个动态管理视图sys.dm_exec_query_stats,返回缓存查询计划的性能统计信息
--SQL会统计从上次SQL启动以来,一共做了多少次logical读写,多少次physical读,还记录执行所用的 CPU时间总量
--按照物理读的页面数排序 前50名
--找出使用内存比较多的语句,简化他们,调整应用程序行为,减少工作负荷
--检查动态管理视图,了解每个查询资源信号量的状态信息。(SQL里默认有两个查询资源信号量,分别处理复杂度不一样
--的查询,这样的设计有助于防止几个超大的查询把整个SQL资源用尽,连一些很简单的查询都不能响应的现象发生)
--resource_semaphore_id:资源信号量的非唯一ID,0表示常规资源信号量,1表示小型查询资源信号量
--target_memory_kb:该资源信号量能够授予使用的内存目标,也就是当前的使用上限
--total_memory_kb:资源信号量现在所持有的总内存,是可用内存和被授予内存的和。如果系统内存不足或频繁强制缩小内存,该值可以
--大于target_memory_kb值,但意味着这个资源信号量有内存压力
--available_memory_kb:可用于新授予的内存
--granted_memory_kb:授予的总内存
--used_memory_kb:授予内存中实际使用的部分
--grantee_count:内存授予得到满足的活动查询数
--waiter_count:等待内存授予得到满足的查询数,如果不为0,意味着内存压力存在
--timeout_error_count:自服务器启动以来的超时错误总数,对于小型查询资源信号量,该值为null
--检查sys.dm_exec_query_memory_grants,返回已经获得内存授予的查询的有关信息,或依然在等待内存授予的查询的
--有关信息。无须等待就获得内存授予的查询将不会出现在此视图中。所以对一个没有内存压力的SQL,这个视图应该是空的
--返回控制
--session_id:正在运行查询的会话ID(spid)
--scheduler_id:正在计划查询的SQL Processor调度的ID
--dop:查询的并行度
--request_time:查询请求内存授予的日期和时间
--grant_time:向查询授予内存的日期和时间。如果尚未授予内存,则此值为null
--requested_memory_kb:请求的内存总量
--granted_memory_kb:实际授予的内存总量。如果尚未授予内存,该值为null。在典型情况下,该值应该与requested_memory_kb相同
--创建索引时,除了初始授予的内存外,服务器还允许增加按需分配的内存
--used_memory_kb:此刻使用的物理内存
--query_cost:估计查询开销
--timeout_sec:查询放弃内存授予请求前的超时时间
--resource_semaphore_id:查询正在等待的资源信号量的非唯一ID
--wait_order:等待查询在指定的queue_id中的顺序,如果其他查询获得内存授予或超时,则给定查询的该值可以更改。如果已授予内存,则为null
--is_next_candidate:下一个内存授予的候选对象:1:是 0:否 null:已授予内存
--wait_time_ms:等待时间。如果已经授予内存,则为null
--plan_handle:查询计划的标志符。使用sys.dm_exec_query_plan可提取实际的xml计划
--sql_handle:查询的TSQL文本标志符。查询中使用他链接sys.dm_exec_sql_text获取实际的TSQL文本
--SQL2005 DMV SQL启动以来累计使用CPU资源最多的语句 前50名
--找到最经常做重编译的存储过程
--返回经常执行的100条语句