【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 --禁用即时文件初始化，所有的磁盘空间请求全部使用填０初始化，可能造成在空间增长时产生阻塞。
Trace Flag 3502 --在日志中显示有关checkpoint的相关信息。
Trace Flag 3505 --不允许自动进行checkpoint,checkpoint只能手动进行，是非常危险的一个命令。
--（6）其他跟踪标记
--8602 停止索引提示功能
--8755 停止锁提示功能
--8780 停止最优化超时配置，强制做完整的最优化动作
--3004：数据库还原详细信息记录在errorlog里面
--1117：同一个文件组内的多个文件插入数据的时候会同时增长，而不是只增长第一个数据文件
【3】参考文献：