随机插入需要 10+ 秒才能完成

Question

我有一个由 .NET Entity Framework 生成的插入语句。在大多数情况下，根据 SQL Server Profiler，此特定插入将在 0 毫秒内执行。

每 30 个左右的插入中就有一个将跳转到长达 12 秒的持续时间，导致另一端的 .NET 客户端在等待时显示为“无响应”。服务器负载应该不是问题，因为我们的服务器负载非常非常轻。

这是正在对其执行插入的表：

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

SET ANSI_PADDING ON
GO

CREATE TABLE [dbo].[ProductEvents](
[EventID] [int] IDENTITY(1,1) NOT NULL,
[KID] [int] NOT NULL,
[EventDescription] [varchar](50) NOT NULL,
[EventDate] [datetime] NOT NULL,
[UserName] [varchar](50) NOT NULL,
[Notes] [varchar](max) NOT NULL,
[Version] [timestamp] NOT NULL,
[IsSynchronized] [bit] NOT NULL,
[LastSyncDate] [datetime] NULL,
 CONSTRAINT [PK_ProductEvents] PRIMARY KEY CLUSTERED 
([EventID] ASC ) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, 
IGNORE_DUP_KEY = OFF,ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

SET ANSI_PADDING OFF
GO

ALTER TABLE [dbo].[ProductEvents] ADD  CONSTRAINT [DF_ProductEvents_IsSychronized]
DEFAULT ((0)) FOR [IsSynchronized]
GO

ALTER TABLE [dbo].[ProductEvents]  WITH CHECK ADD  CONSTRAINT
[FK_ProductEvents_Products] FOREIGN KEY([KID])
REFERENCES [dbo].[Products] ([KID])
ON DELETE CASCADE
GO

ALTER TABLE [dbo].[ProductEvents] CHECK CONSTRAINT [FK_ProductEvents_Products]
GO

SQL Server Profiler 看到的查询（实际示例）：

exec sp_executesql N'insert [dbo].[ProductEvents]([KID], [EventDescription],
[EventDate], [UserName], [Notes], [IsSynchronized], [LastSyncDate])
values (@0, @1, @2, @3, @4, @5, null)
select [EventID], [Version]
from [dbo].[ProductEvents]
where @@ROWCOUNT > 0 and [EventID] = scope_identity()',N'@0 int,@1 varchar(50),@2 
datetime2(7),@3 varchar(50),@4 varchar(max) ,@5 
bit',@0=1894,@1='Modified',@2='2013-08-12 
08:09:25.4766233',@3='KNEXTION\aellison',
@4='Description changed from Mini Awareness Ribbon Cookie Cutter - RM 1698 to Mini 
Awareness Ribbon Cookie Cutter - R&M 1698.',@5=0

以下是来自 SSMS 的执行计划截图：

关于如何开始追踪这个的任何想法？

实际和估计的计划似乎是一样的。

它是一个多用户应用程序，该表将是更活跃的表之一。

探查器或任何其他工具中是否有任何简单的方法来查看阻塞是否是问题？除了阻塞之外，我还应该寻找其他任何问题吗？

Answer 1

可能是其他会话导致阻塞。请参阅问答http://dba.stackexchange.com/questions/34313/identify-blocking-and-send-alert。

如果实际计划和估计计划相同，则提供它们是没有意义的，因为它们无法解释任何事情（除了应适用于所有执行而不仅仅是缓慢实例的一般低效率）。您可以监视sys.dm_exec_requests它何时运行缓慢，以查看它正在等待谁/什么。

您还可以监视等待统计信息（例如，它可能是严重的 I/O 瓶颈）。在 Plan Explorer 中进行复制可能会有所帮助，因为您可以自动获取会话的等待统计信息（除非您启动自己的扩展事件会话，否则您只能自己获取系统范围的等待）。

要捕获潜在阻塞期间发生的情况，您还可以使用 Service Broker 和事件通知。Tony Rogerson 早在 2007 年就发布了一个示例，报告了您可以使用的 10 秒（或更长时间）的块。

另请检查数据库和日志的自动增长事件和设置。偶尔的长时间延迟可能是由于必须等待数据或日志文件增长而导致的。