DBCC命令5：跟踪标记

可以参考这个链接：

http://www.cnblogs.com/Amaranthus/archive/2012/08/01/2619045.html

http://www.cnblogs.com/lyhabc/articles/4092507.html?ADUIN=5146923&ADSESSION=1416359834&ADTAG=CLIENT.QQ.5329_.0&ADPUBNO=26349

跟踪标记的主要用途是：

1、获取比较深入的SQL Server信息，如Lock Manager的各种锁定操作。

2、改变某些SQL Server预设定的行为，如停止查询优化器寻找最佳执行计划的超时时间。

3、改变某些命令当前的行为，如终止使用查询提示。

  

 

--启用标志的范围是session
DBCC TRACEON(3604,1)

--启用标志的范围是global
DBCC TRACEOFF(3604,-1)


--显示已经开启的跟踪标记
DBCC TRACESTATUS


DBCC TRACEOFF(3604,1)

DBCC TRACEOFF(3604,-1)

 

 

Trace Flag 2371
默认情况下，当修改了20%的数据后，才会更新统计信息，开启标识后，
当数据行数超过25000行，那么随着数据条数的增加，这个百分比会减少。

Trace Flag 610
减少日志产生量。
 

Trace Flag  834
使用 Microsoft Windows 大页面缓冲池分配。如果服务器是SQL Server专用服务器的话，值得开启该跟踪标记。 
 

Trace Flag  835
允许SQL Server 2005和2008标准版使用＂锁定内存页＂，和在组策略中设置的结果大同小异，但是允许在标准版中使用． 
 

Trace Flag  1118
tempdb分配整个区，而不是混合区，减少SGAM页争抢。
当apply tempdb的best practice之后，还遇到争抢问题，考虑使用该跟踪标记。


Trace Flag  1204和1222
这两个跟踪标记都是将死锁写到错误日志中，不过1204是以文本格式进行，而1222是以XML格式保存。
可以通过sp_readerrorlog查看日志。

Trace Flag  1211和1224
两种方式都是禁用锁升级。但行为有所差别1211是无论何时都不会锁升级，而1224在内存压力大的时候会启用锁升级，从而避免了out-of-locks错误。当两个跟踪标记都启用是，1211的优先级更高。 
 
Trace Flag  2528
禁用并行执行DBCC CHECKDB, DBCC CHECKFILEGROUP,DBCC CHECKTABLE。这意味着这几个命令只能单线程执行，这可能会需要更多的时间，但是在某些特定情况下还是有些用处。 
 
Trace Flag  3226   
防止日志记录成功的备份。如果日志备份过于频繁的话，会产生大量错误日志，启用该跟踪标记可以使得日志备份不再被记录到错误日志。 
 
Trace Flag  4199
所有ＫＢ补丁对于查询分析器行为的修改都生效，这个命令比较危险，可能导致性能下降.


 /*
Trace Flag  806 
 
在读取过程中对页检查逻辑一致性，在错误日志中就可以看到类似下面的信息：
2004-06-25 11:29:04.11 spid51 错误： 823，严重性： 24 日状态： 2
2004-06-25 11:29:04.11 spid51 I/O 错误 （审核失败） 在读取过程中检测到的偏移量主题 SQL Server\MSSQL\data\pubs.mdf e:\Program 文件中的 0x000000000b0000.
 


Trace Flag 818  
检查写一致性
踪标志 818 启用了一个内存中的环形缓冲区，
用于跟踪由运行 SQL Server 的计算机执行的最后 2,048 个成功写操作（不包括排序和工作文件 I/O）。
发生 605、823 或 3448 之类的错误时，将传入缓冲区的日志序列号 (LSN) 值与最新写入列表进行比较。
如果在读操作期间检索到的 LSN 比在写操作期间指定的更旧，就会在 SQL Server 错误日志中记录一条新的错误信息。
大部分 SQL Server 写操作以检查点或惰性写入形式出现。惰性写入是一项使用异步 I/O 操作的后台任务。
环形缓冲区的实现是轻量的，因此对系统性能的影响可以忽略。



Trace Flag 1200 
返回加锁信息的整个过程，是学习加锁过程很牛逼的标志，示例代码如下：
 


Trace Flag 1806
 
禁用即时文件初始化，所有的磁盘空间请求全部使用填０初始化，可能造成在空间增长时产生阻塞。
 

Trace Flag 3502
在日志中显示有关checkpoint的相关信息。


Trace Flag 3505
不允许自动进行checkpoint,checkpoint只能手动进行，是非常危险的一个命令。
*/

 

 

/*=============================================================
3604:直接返回信息到当前客户端,而不是打印信息到错误日志文件

9292:打印出从元数据中得到的统计信息的头信息

9204:打印出被加载的统计信息

8666:打印出被加载的统计信息,同时将Showplan的详细信息打印出来

如果执行计划已经存在于缓存中，那么这些统计信息的记录则不会被打印出来.
所以需要通过DBCC FREEPROCCACHE()先清除执行计划
==============================================================*/

--1.1打开跟踪标记
DBCC TRACEON(3604, 9292, 9204)
GO
 

--1.2运行语句,在消息中返回 
/*==================================================================================
消息选项卡中返回:

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

Stats header loaded: DbName: w, ObjName: base_org, IndexId: 2, ColumnName: EMP_ID, EmptyTable: FALSE

Stats loaded: DbName: w, ObjName: base_org, IndexId: 2, ColumnName: EMP_ID, EmptyTable: FALSE

Stats header loaded: DbName: w, ObjName: base_Employee, IndexId: 1, ColumnName: EMP_ID, EmptyTable: FALSE

Stats loaded: DbName: w, ObjName: base_Employee, IndexId: 1, ColumnName: EMP_ID, EmptyTable: FALSE

Stats header loaded: DbName: w, ObjName: base_Employee, IndexId: 8, ColumnName: EMP_NAME, EmptyTable: FALSE

Stats loaded: DbName: w, ObjName: base_Employee, IndexId: 8, ColumnName: EMP_NAME, EmptyTable: FALSE

(1 行受影响)
=====================================================================================*/

SELECT emp.emp_Name, 
       COUNT(org.org_id)
FROM base_org org
INNER JOIN base_Employee emp
      ON org.Emp_ID = emp.Emp_ID
      
WHERE emp.emp_name like '王丽%'
GROUP BY emp.emp_name


--1.3查询上面语句的执行计划是否缓存
select *
from sys.dm_exec_cached_plans c 

inner join sys.dm_exec_query_stats q
        on q.plan_handle = c.plan_handle
        
cross apply  sys.dm_exec_sql_text(q.sql_handle) t

where t.text like 'SELECT emp.emp_Name, 
       COUNT(org.org_id)
FROM base_org org
INNER JOIN base_Employee emp
      ON org.Emp_ID = emp.Emp_ID
      
WHERE emp.emp_name like ''xx%''
GROUP BY emp.emp_name'



--1.4删除计划缓存中的所有元素.
--通过指定计划句柄或 SQL 句柄从计划缓存中删除特定计划，或者删除与指定资源池相关联的所有缓存条目。
DBCC FREEPROCCACHE()
GO

--1.5关闭跟踪标记
DBCC TRACEOFF(3604, 9292, 9204)
GO


--1.6开启跟踪标记
DBCC TRACEON(3604,8666)
GO


--2.1显示xml格式执行计划
set statistics xml on


--2.2
/*==================================================================================
返回结果中有xml showplan,单击字符串,按F4
内部调试信息 -> EnvColl -> Recompile -> ModTrackingInfo 点击右边的小方块:

<ModTrackingInfo>
	<Field FieldName="wszStatName" FieldValue="_WA_Sys_0000001C_0AD2A005" />
	<Field FieldName="wszColName" FieldValue="EMP_ID" />
	<Field FieldName="m_cCols" FieldValue="1" />
	<Field FieldName="m_idIS" FieldValue="2" />
	<Field FieldName="m_ullSnapShotModCtr" FieldValue="40120" />
	<Field FieldName="m_ullRowCount" FieldValue="998" />
	<Field FieldName="ullThreshold" FieldValue="699" />
    <Field FieldName="wszReason" FieldValue="heuristic" />
</ModTrackingInfo>

=====================================================================================*/
SELECT emp.emp_Name, 
       COUNT(org.org_id)
FROM base_org org
INNER JOIN base_Employee emp
      ON org.Emp_ID = emp.Emp_ID
      
WHERE emp.emp_name like '王xx'
GROUP BY emp.emp_name


set statistics xml off

--2.3开启跟踪标记
DBCC TRACEOFF(3604,8666)
GO