(5.1.7)引擎管理——dbcc下的的跟踪标记

 

【1】常规dbcc命令

  

dbcc help('?')  --查看dbcc 所有命令,常规下只有32个常用的
dbcc TRACEON(2588) --指定了2588标记的话,你就可以看到未公开的dbcc命令了,同时你也可以看到各种命令参数的提示了。很多dbcc命令需要开启它才能使用,比如ind,page等
dbcc help('checkdb') --帮助命令,使用其来查看命令用法,开启了上面的2588就可以用ind(查看堆表/索引组织表的数据也信息)了
dbcc TRACEON(3604) -- 指定标记,使得dbcc page的结果可以在客户端上显示出来

3064 将DBCC的结果可以在客户端上显示出来
3605 将DBCC的结果输出到错误日志。
1204 返回参与死锁的锁的资源和类型,以及受影响的当前命令。
1222 返回参与死锁的锁的资源和类型,以及使用了不符合任何 XSD 架构的 XML 格式的受影响的当前命令(比1204更进一步,SQL 2005及以上可用)。


--实例:查看表的数据页分布和数据页具体内容:DBCC的概念与用法(DBCC TRACEON、DBCC IND、DBCC PAGE)

 

 

【2】常用优化跟踪标识

【2.1】如何控制、启用、查看跟踪标识?


--(1)使用dbcc 启用跟踪标识,注意,所有跟踪在重启引擎服务后会失效,需要重新开启

DBCC TRACEON(2203,-1) --启用,-1表示全局global scope DBCC TRACEOFF(2203,1) --禁用,1表示会话session scope,默认为1,即会话范围生效 DBCC TRACESTATUS --查看当前会话开启跟踪的信息及状态

--解决重启会失效问题,即使用实例启动存储过程,把相关标识在过程中写好即可
EXEC sp_procoption @ProcName = '<procedure name>' 
    , @OptionName = ] 'startup' 
    , @OptionValue = 'on'; 

--(2)通过在SQL Server配置管理器中指定
  这种方式是通过在数据库引擎启动项里加启动参数设置,只有Global Scope。格式为-T#跟踪标记1;T跟踪标记2;T跟踪标记3。
--(3)通过注册表启动
  与(1)(2)大同小异
--~~注意,某些跟踪不能使用dbcc ,只能使用-T加在sql server配置管理器中指定

--(4)建议使用的跟踪

Trace Flag 610 --
减少日志产生量。如果你对于日志用了很多基础的best practice,比如说只有一个日志文件、VLF数量适当、单独存储,如果还是不能缓解日志过大的话,考虑使用该跟踪标记。
Trace Flag  834 --使用 Microsoft Windows 大页面缓冲池分配。如果服务器是SQL Server专用服务器的话,值得开启该跟踪标记。
Trace Flag  835 --允许SQL Server 2005和2008标准版使用"锁定内存页",和在组策略中设置的结果大同小异,但是允许在标准版中使用.
Trace Flag  1118 --tempdb分配整个区,而不是混合区,减少SGAM页争抢。
Trace Flag  1204和1222 --这两个跟踪标记都是将死锁写到错误日志中,不过1204是以文本格式进行,而1222是以XML格式保存。可以通过 sp_readerrorlog来查看错误日志 最佳实践:dbcc traceon (1204,1222,3605,-1)
Trace Flag  1211和1224 --两种方式都是禁用锁升级。但行为有所差别1211是无论何时都不会锁升级,而1224在内存压力大的时候会启用锁升级,从而避免了out-of-locks错误。当两个跟踪标记都启用是,1211的优先级更高。
Trace Flag  2528 --不建议开启,禁用并行执行DBCC CHECKDB, DBCC CHECKFILEGROUP,DBCC CHECKTABLE。这意味着这几个命令只能单线程执行,这可能会需要更多的时间,但是在某些特定情况下还是有些用处。
Trace Flag  3226 --防止日志记录成功的备份。如果日志备份过于频繁的话,会产生大量错误日志,启用该跟踪标记可以使得日志备份不再被记录到错误日志。
Trace Flag  2371 --允许增加数据库内统计信息的更新频率(统计信息参考:https://www.cnblogs.com/gered/p/9087055.html


--(5)不建议使用的跟踪
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 --返回加锁信息的整个过程,是学习加锁过程很牛逼的标志。 最佳实践:DBCC TRACEON(1200,3604,-1) ;dbcc tracestatus;
Trace Flag 1806 --禁用即时文件初始化,所有的磁盘空间请求全部使用填0初始化,可能造成在空间增长时产生阻塞。
Trace Flag 3502 --在日志中显示有关checkpoint的相关信息。
Trace Flag 3505 --不允许自动进行checkpoint,checkpoint只能手动进行,是非常危险的一个命令。

--(6)其他跟踪标记

--8602 停止索引提示功能
--8755 停止锁提示功能
--8780 停止最优化超时配置,强制做完整的最优化动作
--3004:数据库还原详细信息记录在errorlog里面
--1117:同一个文件组内的多个文件插入数据的时候会同时增长,而不是只增长第一个数据文件

      

 

【3】参考文献:

桦仔:sql server跟踪标志合集

宋大神:DBA应该知道的一些SQL Server跟踪标记

 

上一篇:无法于 SQL Database 利用 DBCC CHECKIDENT 重新设定识别值时的替代作法


下一篇:CSS基础之选择器