小编Bra*_*rad的帖子

我真的很难追踪我们遇到的一些阻塞。

根阻塞的SPID的状态是“睡觉”，在CMD为“命令等待”，而sqltext为SET TRANSACTION ISOLATION LEVEL READ COMMITTED。

当我查看 Top Transactions by Blocked Transactions Count 报告时，Blocking SQL Statement 是“--”。

我已经对 SQL 进行了跟踪，当阻塞发生时跟踪根阻塞 SPID，但它并没有真正引导我到任何地方。最后一个 trace 语句与sqltext上面的相同SET TRANSACTION ISOLATION LEVEL READ COMMITTED。

我已经检查了我能找到的所有相关存储过程，以确保它们具有 TRY/CATCH BEGIN TRAN/COMMIT TRAN/ROLLBACK TRAN 语句（我们对所有内容都使用存储过程，因此没有运行独立的语句）。这个问题在过去 24 小时内才开始发生，没有人声称对系统进行了任何更改。

解决方案：我们很少使用的存储过程之一在插入时出错（列数不匹配），但我们仍然对到底发生了什么感到困惑。

查看所有跟踪信息时，有时会列出此存储过程的 EXEC 语句，但绝不会在阻塞 SPID 上发生 BLOCK 之前。似乎当它开始阻塞时，跟踪没有记录它的执行（或其中的任何语句）。然而，也有其他时候跟踪确实记录了它的执行并且没有发生阻塞。

存储过程错误报告来自一个用户，我能够在跟踪中找到多个 EXEC 语句并在 SSMS 中运行它们。当我运行它们时，我们没有发生任何阻塞或它们挂起的情况。它们按预期运行（catch 块在错误发生后触发并回滚事务）。解决修复存储过程后，我们没有再看到这个问题。

我有一个简单的 SSIS 包，它加载一个包含 100000 行的虚拟文件。每行大约 4k 长，一个 int 列和一个长文本列。将此数据加载到具有聚集索引的表中时，我正在尝试测试 TF610。

在我的 SSIS 包中，我的控制流有一个执行 SQL 任务来启用 TF610，然后成功转到我的数据流任务，它将平面文件加载到表中。执行 SQL 和 OLE DB 目标都使用相同的连接。

如果我在运行 SSIS 包时启动配置文件并观察命令，我可以看到 DBCC TRACEON(610) 执行，然后 INSERT BULK 操作开始触发。他们都使用相同的 PID，所以我假设它是同一个会话。

但是，当我检查日志记录长度时，插入的日志没有被最小化。

如果我全局启用 TF610 并运行相同的 SSIS 包，尽管交易记录最少。

在我的 SSIS 包中打开 TF610 时，我一定做错了什么，但我不知道是什么......

我在无法编辑自己的作业的 SQL 2008 服务器上有 AD ID 用户。他们可以创建它们，但是为了编辑它们，他们必须删除它们然后重新添加它们。这个问题在这里解释：http : //blogs.msdn.com/b/sqlserverfaq/archive/2009/06/08/owner-of-the-job-will-not-be-able-to-modify-edit-在-job-in-sql-server.aspx

我做了进一步的研究并发现在我的特殊情况下这是因为我使用 CREATE LOGIN [domain\user] 语法添加了 AD ID 用户。使用该方法，AD ID 的大小写就是您在括号中指定的内容。

无论如何，是否可以使用正确的 Windows AD ID 案例创建用户，以便我不必弄清楚然后修改每个 AD ID 用户的登录名？

此外，我使用此脚本为特定用户获取正确的大小写：

execute as login = 'usa\johndoe'
SELECT SUSER_SNAME()
revert;

但是当我要求用户运行 SELECT SUSER_SNAME() 并给我结果时，它为我返回所有小写字母，但所有大写字母。正确的是全部大写（好吧，为了让该用户能够编辑作业）。

我不知所措，非常沮丧。

-- 我发现获得正确大小写的最佳（唯一？）方法是使用 SQL 界面添加用户，单击搜索，输入 AD ID，然后单击检查名称。对于上面的示例，它返回所有大写字母，尽管该脚本示例返回所有小写字母。

我知道这个问题一定有一个简单的答案，但我在任何地方都找不到。我们的 SQL 2012 FCI 在其 MSSQL\LOG 文件夹中有 SQLDIAG .XEL 文件。在某些情况下，这些文件通常正好为 100MB，但在 SSMS 中打开时却显示为空（表示显示 0 个事件）。

如果可能的话，我需要知道如何管理它们的最大大小和文件保留时间。

我们有一些来自 SQL 2008 FCI（升级到 SQL 2012）的根驱动器挂载点，这些挂载点只有 1GB。您可以猜到，这些挂载点正在填满，如果可能，我需要限制这些故障转移群集诊断日志，否则我将不得不提出替代解决方案。

我们有相当多的数据加载进程整天都在运行。这些进程为它们的连接设置 610 标志，然后在完成后将其关闭。因为这些消息被放入了 ERROR LOG，所以我们的 ERROR LOG 增长了很多。我们已经尝试使用 DBCC 的 WITH NO_INFOMSGS 参数，但它仍然将条目放入错误日志中（即使它没有将其放入查询输出中）。

有任何想法吗？

消息如下所示：

日期 10/23/2014 8:32:46 AM 登录 SQL Server（当前 - 2014/10/23 8:31:00 AM）

源 spid57

消息 DBCC TRACEON 610，服务器进程 ID (SPID) 57。这只是一条信息性消息；无需用户操作。

...

日期 10/23/2014 8:32:54 AM Log SQL Server（当前 - 2014/10/23 8:31:00 AM）

源 spid57

消息 DBCC TRACEOFF 610，服务器进程 ID (SPID) 57。这只是一条信息性消息；无需用户操作。

我有一个表，其中的 NVARCHAR 列包含无法转换为 BIGINT 的数据。我很清楚这一点，并已使用 过滤掉它ISNUMERIC(BB.NVARCHARCOL) = 1。尽管如此，在尝试查询数据时我仍然收到错误，说明Error converting data type nvarchar to bigint.

以下工作正常（SQL 没有报告错误）：

SELECT *
FROM myNormalTable AA INNER JOIN myBadTable BB ON BB.NVARCHARCOL = AA.MYBIGINTCOL
WHERE ISNUMERIC(BB.NVARCHARCOL) = 1

以下抛出错误：

SELECT *
FROM (
    SELECT *
    FROM myNormalTable AA INNER JOIN myBadTable BB ON BB.NVARCHARCOL = AA.MYBIGINTCOL
    WHERE ISNUMERIC(BB.NVARCHARCOL) = 1
    ) ZZ 
WHERE ZZ.MYBIGINTCOL = 1234

这种变化也会引发错误：

SELECT *
FROM (
    SELECT *
    FROM myNormalTable AA INNER JOIN
        (SELECT CAST(NVARCHARCOL AS BIGINT) …