在我们的实时服务器上发生了一些死锁，我知道，这很糟糕。
无论如何，我试图弄清楚如何查看导致锁定（或持有时间过长）的 SQL 代码。
我已经添加了所有的Locks事件（获得、死锁、升级、释放、超时等），但我所看到的只是对获得/释放事件的轰炸，没有太多附加信息。
我很确定我知道导致死锁的“场景”，因为我们在插入/更新/删除后在表上有一个触发器，这做了很多额外的工作，有时高达 8 秒。
但是，在大部分额外工作中，数据从 TableA 中提取并插入到表变量中，大量工作在该表变量的内存中进行（大约 6 秒过去），然后最终插入到 TableB 中。
问题： 即使我只是将某些行选择到表变量中，这实际上会导致整个表的表锁定吗？
我已经添加了“触发跟踪”（插入表 x 值（'嗨，我在这里'）等），我基本上知道这个过程花费的时间最长（因此必须可能导致锁定？）
但我仍然不确定为什么会发生僵局。
问题： 我可以看到发生了 2 个锁升级，这是否意味着行锁已升级为表锁？
问题： 有人能给我一些关于如何进一步追踪这个僵局的提示吗？
编辑：
这是死锁图
编辑2：
这是 [UpdatePostsCleanedUriUniqueUri] 的代码，这可能会导致表锁定？
ALTER PROC [dbo].[UpdatePostsCleanedUriUniqueUri]
(
@PostIds IdentityType READONLY
)
AS
SET NOCOUNT ON
-- *************************************************************************
-- ******************* Create the Cleaned Uri's, first ********************
-- *************************************************************************
---- "Remove" any existing cleaned uri's, per location
UPDATE a
SET …有没有一种方法可以通过单击列（类似于 Excel）来获取查询结果集中列的总和，这样我就不必将该列复制并粘贴到 Excel 中以查看总数列中所有值的总和？
我正在运行 SQL Server 2008。
我有一个大型（数千万条记录）数据库，我将在其上执行完整的数据库备份。
但是，数据库足够大，事务可以在备份发生之前和期间启动，也可以在备份发生期间和之后提交。
例如：
T0 = Transaction A start
T1 = Full database backup start
T2 = Transaction B start (will not deadlock with A)
T3 = Transaction A commit/rollback (does not matter, does it?)
T4 = Full database backup end
T5 = Transaction B commit/rollback (again, does not matter, does it?)
T0 T1 T2 T3 T4 T6
||----------||----------||----------||----------||----------||---------->
我的理解是在备份期间不使用锁（尽管由于高 I/O 可能会出现其他性能问题），但我不确定我能保证什么会被提交。
此外，我担心的不是数据库将处于不一致状态，而是该状态将是什么（即使它不是确定性的，如果有一组可以一致应用的规则）以及它是如何到达那里的（例如，有多少数据文件与事务日志一起用于创建备份文件）？
在阅读这篇关于 SQL Server 中的计划缓存的文章时，我发现了一个我不知道的花絮：
...为了重用，批处理引用的对象不需要名称解析。例如，Sales.SalesOrderDetail 不需要名称解析，而 SalesOrderDetail 则需要，因为在多个架构中可能存在名为 SalesOrderDetail 的表。通常，由两部分组成的对象名称（即 schema.object）为计划重用提供了更多机会。
我正在寻找关于使用两部分对象名称的重要性的一些说明，因为“通常，两部分对象名称为计划重用提供了更多机会。”，但它首先说这是必要的。
更具体地说，我处理的大多数存储过程都在 dbo 模式中，并且只引用 dbo 对象，而没有指定 dbo 前缀。即使所有内容都使用默认模式，这些是否无法重用缓存的查询计划？
我有一个视图，它可以快速运行（几秒钟）最多 41 条记录（例如TOP 41），但需要几分钟才能运行 44 条或更多条记录，如果使用TOP 42或运行会产生中间结果TOP 43。具体来说，它将在几秒钟内返回前 39 条记录，然后在返回剩余记录之前暂停近三分钟。这个模式在查询TOP 44or时是一样的TOP 100。
这个视图最初是从一个基本视图派生出来的，在基本视图中只添加了一个过滤器，下面代码中的最后一个。如果我从基础链接子视图，或者如果我使用内联基础中的代码编写子视图，似乎没有区别。基本视图在几秒钟内返回 100 条记录。我想我可以让子视图以与基础一样快的速度运行，而不是慢 50 倍。有没有人见过这种行为？关于原因或解决方案的任何猜测？
这种行为在过去几个小时内一直是一致的，因为我已经测试了所涉及的查询，尽管在事情开始变慢之前返回的行数略有上升和下降。这并不新鲜；我现在正在查看它，因为总运行时间是可以接受的（<2 分钟），但我已经在相关的日志文件中看到这种暂停至少几个月了。
我从未见过查询被阻止，即使数据库上没有其他活动（由 sp_WhoIsActive 验证），问题仍然存在。基本视图包括NOLOCK整个内容，这是值得的。
这是子视图的简化版本，为简单起见，基本视图内联。它仍然表现出运行时间的跳跃，大约有 40 条记录。
SELECT TOP 100 PERCENT
Map.SalesforceAccountID AS Id,
CAST(C.CustomerID AS NVARCHAR(255)) AS Name,
CASE WHEN C.StreetAddress = 'Unknown' THEN '' ELSE C.StreetAddress END AS BillingStreet,
CASE WHEN C.City = 'Unknown' THEN '' ELSE SUBSTRING(C.City, 1, 40) END AS BillingCity,
SUBSTRING(C.Region, 1, 20) …我想为我的数据库中的每个表创建最好的索引。SQL Server 中是否有查询或工具可以帮助完成此过程？
index sql-server-2008 database-design sql-server sql-server-2008-r2
我们正在构建一个最初为 1 TB 的数据仓库，并将每月增长约 20gigs。
对于某些表，我们每天都在执行 ETL 过程，而对于其他表，我们每周/每月执行一次。
当有数据导入到表中时，是否需要删除并重新创建索引？
是否有必要删除和重新创建索引，或者它们是否会自动更新？
统计信息设置为自动更新。
非常感谢您的帮助和指导。
我得到了这个天才脚本：
SELECT 'ALTER INDEX [' + ix.name + '] ON [' + s.name + '].[' + t.name + '] ' +
CASE WHEN ps.avg_fragmentation_in_percent > 40 THEN 'REBUILD' ELSE 'REORGANIZE' END +
CASE WHEN pc.partition_count > 1 THEN ' PARTITION = ' + cast(ps.partition_number as nvarchar(max)) ELSE '' END
FROM sys.indexes AS ix INNER JOIN sys.tables t
ON t.object_id = ix.object_id
INNER JOIN sys.schemas s
ON t.schema_id = …今天早上我注意到我的 SQL 日志充满了以下消息：
在队列 'msdb.dbo.syspolicy_event_queue' 上运行的激活过程 '[dbo].[sp_syspolicy_events_reader]' 输出以下内容：
'无法作为数据库主体执行，因为主体“##MS_PolicyEventProcessingLogin##”不存在，这种类型的主体不能被冒充，或者您没有权限。
运行以下EXEC sp_change_users_login 'report'显示登录实际上已被孤立。
我能够按照此 MSDN 帖子中的建议运行以下命令来修复它。
EXEC sp_change_users_login
'Auto_Fix', '##MS_PolicyEventProcessingLogin##',
NULL, 'fakepassword'
但问题仍然存在：究竟是什么原因导致这位校长成为孤儿？谷歌搜索和研究表明其他人也有这个问题，但我还没有找到原因的描述。在错误开始出现的那一刻，我没有注意到任何值得注意的事情。
去年夏天，我们将整个服务器迁移到 SAN 存储模型，在迁移期间我们恢复了所有内容（包括 msdb），但那是几个月前的事情。只是最近的事情才使症状明显，因为它没有出现在几周前的日志中。
如果目标数据库中存在表，我正在尝试签入存储过程。如果没有，我将使用源数据库中的 information_schema 表创建表。但是，当我使用 sp_execute 尝试恢复表是否存在时，我收到错误过程需要“int”类型的参数“@handle”。
我没有使用@handle 参数。有人能告诉我这个错误是什么意思以及为什么我会收到它吗？我的代码的相关部分如下。
DECLARE @SQL NVARCHAR(MAX),
@Parameters NVARCHAR(4000),
@TableNotExists INT,
@SourceTable NVARCHAR(200),
@DestDB NVARCHAR(200)
BEGIN
SET @SourceTable = 'table'
SET @DestDB = 'database'
SET @Parameters = N'@SourceTableIN NVARCHAR(200), @TableNotExistsOut INT OUTPUT'
SET @SQL = N'USE [' + @DestDB + '] IF NOT EXISTS (SELECT 1 FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = ''BASE TABLE'' AND TABLE_NAME = @SourceTableIN)
BEGIN SET @TableNotExistOUT = 1 END'
EXEC sp_Execute @SQL, @Parameters, @SourceTableIN = @SourceTable, @TableNotExistsOUt = @TableNotExists OUTPUT
END
我觉得这是一个愚蠢的问题，但对于我的生活，我无法追踪发生了什么。我刚刚接管了几台服务器的管理工作，并且在所有这些服务器上，工作历史记录仅保留了 5 天。有一个清理维护计划，但它设置为保留 5 周。
EXEC msdb.dbo.sp_syspolicy_purge_history 每天都在运行，但是，历史保留天数设置为 0，所以我的理解是它无论如何都没有做任何事情。
必须有一些非常简单的东西我在这里遗漏了。任何人都可以指出我正确的方向吗？