关于跟踪标记
DBCC TRACEON ( trace# [ ,...n ][ , -1 ] ) [ WITH NO_INFOMSGS ]
（2）禁用指定的跟踪标记。
DBCC TRACEOFF ( trace# [ ,...n ] [ , -1 ] ) [ WITH NO_INFOMSGS ]
（3）显示跟踪标志的状态。
DBCC TRACESTATUS ( [ [ trace# [ ,...n ] ] [ , ] [ -1 ] ] ) [ WITH NO_INFOMSGS ]
实例：dbcc tracestatus(3205,-1)
| SQL Server 的未来版本可能不支持跟踪标志行为。 |
| 跟踪标志 |
说明 |
||
|---|---|---|---|
| 260 |
打印有关扩展存储过程动态链接库 (DLL) 的版本控制信息。 有关 __GetXpVersion() 的详细信息，请参阅创建扩展存储过程。 作用域：全局或会话 |
||
| 1204 |
返回参与死锁的锁的资源和类型，以及受影响的当前命令。 作用域：仅全局 |
||
| 1211 |
基于内存不足或基于锁数禁用锁升级。 SQL Server 数据库引擎不会将行锁或页锁升级到表锁。 使用此跟踪标志可生成过多的锁数目。 这样会降低数据库引擎的性能，或因为内存不足而导致 1204 错误（无法分配锁资源）。 如果同时设置了跟踪标志 1211 和 1224，则 1211 优先于 1224。 但是，由于在所有情况下（甚至在内存紧张的情况下）跟踪标志 1211 都禁止升级，因此建议使用 1224。 这有助于在使用多个锁时避免“锁不足”错误。 作用域：全局或会话 |
||
| 1222 |
以不符合任何 XSD 架构的 XML 格式，返回参与死锁的锁的资源和类型，以及受影响的当前命令。 作用域：仅全局 |
||
| 1224 |
基于锁数禁用锁升级。 但是，内存不足仍可激活锁升级。 如果锁对象使用的内存量超出下列条件之一，数据库引擎会将行锁或页锁升级为表（或分区）锁：
如果同时设置了跟踪标志 1211 和 1224，则 1211 优先于 1224。 但是，由于在所有情况下（甚至在内存紧张的情况下）跟踪标志 1211 都禁止升级，因此建议使用 1224。 这有助于在使用多个锁时避免“锁不足”错误。
作用域：全局或会话 |
||
| 1448 |
甚至在异步辅助数据库不确认接受更改的情况下，也使复制日志读取器前移。 甚至在此跟踪标志启用的情况下，日志读取器也始终等待同步辅助数据库。 日志读取器将不会超过同步辅助数据库的最小确认。 此跟踪标志应用于 SQL Server 的实例，而不仅是可用性组、可用性数据库或日志读取器实例。 应用会立即生效，无需重新启动。 此跟踪标志可提前激活或在同步辅助数据库失败时激活。 |
||
| 2528 |
禁用 DBCC CHECKDB、DBCC CHECKFILEGROUP 和 DBCC CHECKTABLE 执行的对象并行检查。 默认情况下，并行度由查询处理器自动确定。 最大并行度的配置就像并行查询的最大并行度一样。 有关详细信息，请参阅配置 max degree of parallelism 服务器配置选项。 通常应使并行 DBCC 保持启用状态。 对于 DBCC CHECKDB，查询处理器重新求值，并对检查的每个表或每批表自动调整并行度。 有时，检查可能在服务器几乎处于空闲状态时启动。 如果管理员知道在检查完成前负载将增加，则可能需要手动减小并行度或禁用并行度。 禁用对 DBCC 的并行检查可能导致 DBCC 的完成时间变长，如果运行 DBCC 时启用了 TABLOCK 功能并关闭了并行度，则表可能被锁定更长时间。 作用域：全局或会话 |
||
| 3042 |
绕过默认的备份压缩预先分配算法，以便允许备份文件仅根据需要增长以达到其最终大小。 如果您需要仅分配压缩的备份所需的实际大小以便节约空间，则此跟踪标志将很有用。 使用此跟踪标志可能会导致轻微的性能损失（在备份操作期间损失可能会增加）。 有关预先分配算法的详细信息，请参阅备份压缩 (SQL Server)。 |
||
| 3205 |
默认情况下，如果磁带机支持硬件压缩，则 DUMP 或 BACKUP 语句会使用该功能。 利用此跟踪标志，可以禁用磁带机的硬件压缩。 此选项在您需要与不支持压缩的其他站点或磁带机交换磁带时很有用。 作用域：全局或会话 |
||
| 3226 |
默认情况下，每个成功的备份操作都会在 SQL Server 错误日志和系统事件日志中添加一个条目。 如果非常频繁地创建日志备份，这些成功消息会迅速累积，从而产生一个巨大的错误日志，使查找其他消息变得非常困难。 使用这一跟踪标志，可以取消这些日志条目。 如果您频繁地运行日志备份，并且没有任何脚本依赖于这些条目，则这种做法非常有用。 |
||
| 3608 |
禁止 SQL Server 自动启动和恢复除 master 数据库之外的任何数据库。在访问数据库时将启动并恢复该数据库。 可能无法运行某些功能，如快照隔离和读提交快照。 用于移动系统数据库和移动用户数据库。 请不要在正常操作中使用。 |
||
| 3625 |
通过使用“******”屏蔽某些错误消息的参数，限制返回给不是 sysadmin 固定服务器角色成员的用户的信息量。 这可以帮助阻止披露敏感信息。 作用域：仅全局 |
||
| 4199 |
控制是否以前根据多个跟踪标志进行了多个查询优化器更改。 有关详细信息，请参阅此 Microsoft 支持文章。 作用域：全局或会话 |
||
| 4616 |
使应用程序角色可以看到服务器级元数据。 在 SQL Server 中，应用程序角色无法访问自身数据库以外的元数据，因为应用程序角色与服务器级别主体不相关联。 这是对早期版本的 SQL Server 的行为的更改。 设置此全局标志将禁用新的限制，并允许应用程序角色访问服务器级元数据。 作用域：仅全局 |
||
| 6527 |
禁止在 CLR 集成中第一次发生内存不足异常时生成内存转储。 默认情况下，SQL Server 在 CLR 中第一次发生内存不足异常时会生成小内存转储。 该跟踪标志的行为如下所示：
作用域：仅全局 |
||
| 7806 |
在 SQL Server Express 上启用专用管理员连接 (DAC)。 默认情况下，在 SQL Server Express 上不保留 DAC 资源。 有关详细信息，请参阅用于数据库管理员的诊断连接。 作用域：仅全局 |
||
| 8032 |
将缓存限制参数还原为 SQL Server 2005RTM 设置，此设置通常允许更大的缓存。 当频繁重复使用的缓存条目不适合缓存时，以及当使用“针对即席工作负荷进行优化”服务器配置选项未能解决与计划缓存相关的问题时，请使用此设置。
|
||
| 8207 |
允许事务复制的单独更新。 对订阅服务器的更新可以作为 DELETE 和 INSERT 对复制。 这可能不满足业务规则的要求，如激发 UPDATE 触发器。 使用跟踪标志 8207 时，对只影响一行的唯一列的更新（单独更新）将作为 UPDATE 而非作为 DELETE 或 INSERT 对复制。 如果该更新影响具有唯一约束的列或影响多个行，则仍将该更新作为 DELETE 或 INSERT 对复制。 |
||
| 9485 |
对 DBCC SHOW_STATISTICS 禁用 SELECT 权限。 |
如何跟踪死锁
2010-12-23 13:15:53| 分类： 数据库 | 标签：死锁 traceid 跟踪 sql server |字号 订阅
经带在论坛上看到有人在问怎么捕获和记录死锁信息，在这里，我将自己的一些心得贡献出来，与大家分享，也请各位指正。
我们知道，可以使用SQL Server自带的Profiler工具来跟踪死锁信息。但这种方式有一个很大的敝端，就是消耗很大。据国外某大神测试，profiler甚至可以占到服务器总带宽的35%，所以，在一个繁忙的系统中，使用profiler显然不是一个好主意，下面我介绍两种消耗比较少的方法。其中第二种的消耗最小，在最繁忙的系统中也可使用。第一种最为灵活，可满足多种应用。
方法一：利用SQL Server代理(Alert+Job)
具体步骤如下：
1.首先使用下面的命令，将有关的跟踪标志启用。
SQL code
DBCC TRACEON (3605,1204,1222,-1)
说明：
3605 将DBCC的结果输出到错误日志。
1204 返回参与死锁的锁的资源和类型，以及受影响的当前命令。
1222 返回参与死锁的锁的资源和类型，以及使用了不符合任何 XSD 架构的 XML 格式的受影响的当前命令(比1204更进一步,SQL 2005及以上可用)。
-1 以全局方式打开指定的跟踪标记。
以上跟踪标志作用域都是全局，即在SQL Server运行过程中，会一直发挥作用，直到SQL Server重启。
如果要确保SQL Server在重启后自动开启这些标志，可以在SQL Server服务启动选项中，使用 /T 启动选项指定跟踪标志在启动期间设置为开。(位于SQL Server配置管理器->SQL Server服务->SQL Server->属性->高级->启动参数)
在运行上面的语句后，当SQL Server中发生死锁时，已经可以在错误日志中看到了，但还不够直观(和其它信息混在一起)。（SSMS -> SQL Server实例 -> 管理 -> SQL Server日志）
2.建表，存放死锁记录
SQL code
USE [Cole] --Cole是我的示例数据库，你可以根据实际情况修改。
GO
CREATE TABLE DeadLockLog (
id int IDENTITY (1, 1) NOT NULL,
LogDate DATETIME,
ProcessInfo VARCHAR(10),
ErrorText VARCHAR(MAX)
)
GO
3.建立JOB
新建一个JOB（假设名称为DeadLockJob）,在"步骤"中新建一步骤，随便写一个步骤名称，数据库为"Cole"（见2.建表）,在"命令"栏中输入以下语句：
SQL code
--新建临时表
IF OBJECT_ID('tempdb.dbo.#ErrorLog') IS Not Null
DROP TABLE #ErrorLog
CREATE TABLE #ErrorLog (Id int IDENTITY (1, 1) NOT NULL, a DATETIME, b VARCHAR(10), c VARCHAR(MAX))
--将当前日志记录插入临时表
INSERT INTO #ErrorLog EXEC master.dbo.sp_readerrorlog
--将死锁信息插入用户表
insert DeadLockLog
select a, b, c
from #ErrorLog
where id >= (select MAX(id) from #ErrorLog WHERE c Like '%Deadlock encountered%')
DROP TABLE #ErrorLog
4.新建警报
在"新建警报"窗体的"常规"选项卡中,进行以下设置：
名称：可根据实际自行命名，这里我用DeadLockAlert
类型：选择"SQL Server性能条件警报"
对象：SQLServer:Locks
计数器：Number of Deadlocks/sec
实例：_Total
计数器满足以下条件时触发警报：高于
值：0
设置完成后，应该如下图所示：
在"响应"选项卡中，选中"执行作业"，并选择步骤3中我们新建的作业(即DeadlockJob)
到这里为止，我们已经完成了全部步骤，以后，你就可以随时查询DeadLockLog表，来显示死锁信息了。
方法二：利用服务器端跟踪。
具体实现步骤如下：
1.编写如下脚本，并执行
SQL code
-- 定义参数
declare @rc int
declare @TraceID int
declare @maxfilesize bigint
set @maxfilesize = 5
-- 初始化跟踪
exec @rc = sp_trace_create @TraceID output, 0, N'e:\DbLog\deadlockdetect', @maxfilesize, NULL
--此处的e:\dblog\deadlockdetect是文件名（可自行修改），SQL会自动在后面加上.trc的扩展名
if (@rc != 0) goto error
-- 设置跟踪事件
declare @on bit
set @on = 1
--下述语句中的148指的是locks:deadlock graph事件(参见sys.trace_events),12指的是spid列(参见sys.trace_columns)
exec sp_trace_setevent @TraceID, 148, 12, @on
exec sp_trace_setevent @TraceID, 148, 11, @on
exec sp_trace_setevent @TraceID, 148, 4, @on
exec sp_trace_setevent @TraceID, 148, 14, @on
exec sp_trace_setevent @TraceID, 148, 26, @on
exec sp_trace_setevent @TraceID, 148, 64, @on
exec sp_trace_setevent @TraceID, 148, 1, @on
-- 启动跟踪
exec sp_trace_setstatus @TraceID, 1
-- 记录下跟踪ID，以备后面使用
select TraceID = @TraceID
goto finish
error:
select ErrorCode=@rc
finish:
go
运行上述语句后，每当SQL Server中发生死锁事件，都会自动往文件e:\DbLog\deadlockdetect.trc中插入一条记录。
2.暂停和停止服务器端跟踪
如果要暂停上面的服务器端跟踪，可运行下面的语句：
SQL code
exec sp_trace_setstatus 1, 0 --第一个参数表示TraceID,即步骤1中的输出参数。第二个参数表示将状态改为0，即暂停
如果要停止上面的服务器端跟踪，可运行下面的语句：
SQL code
exec sp_trace_setstatus 1, 2 --第一个参数表示TraceID,即步骤1中的输出参数。第二个参数表示将状态改为2，即停止
3.查看跟踪文件内容
对于上面生成的跟踪文件(e:\DbLog\deadlockdetect.trc),可通过两种方法查看：
1).执行t-sql命令
SQL code
select * from fn_trace_gettable('e:\DbLog\deadlockdetect.trc',1)
结果中的TextData列即以XML的形式返回死锁的详细信息。
2).在SQL Server Profiler中打开。
依次 进入Profiler -> 打开跟踪文件 ->选择e:\DbLog\deadlockdetect.trc，就可以看到以图形形式展现的死锁信息了。