Question

我是医疗保健自动化公司的DBA。我们有1个客户端正在使用我们的应用程序，这个客户端是唯一一个受到影响的客户。在随机时间，有一个存储过程需要HOURS运行。我自己和另一位DBA在出现问题时一直在排除故障并进行诊断，但它在一夜之间再次发生，我们有点不知所措。

我相信当它进入这个“车辙”时，这是因为缓存的执行计划不好。我接下来要做的是为该存储过程运行SP_Recompile并让它每次重新编译，但是如果它不再次缓存错误的计划则会告诉谁。我已经添加了MAXDOPS，因为我们认为它可能是一个并行的问题，但那些没有帮助。

我们将其缩小到一个“Step”，我们创建了一个调试数据库来捕获数据。通常这个步骤不到5分钟即可完成。现在大约需要4-5个小时。我在代码下面包含了TSQL代码段。任何建议，批评或帮助都是非常感谢！谢谢！

insert into DBAdiag.dbo.dumbcodedebug (note, createddate)
values ('PatientAuditLog Insert Start',getdate())

 SET @StartTime = GETUTCDATE();
 SET IDENTITY_INSERT [XTArchive].dbo.PatientAuditLog ON;
 INSERT INTO [XTArchive].dbo.PatientAuditLog (a.[PatientAuditLogID],a.[PatientHistoryCrossRefID],a.[PatientFieldNameTypeID],a.[OldValue],a.[NewValue],a.[CreatedDate])
 SELECT a.[PatientAuditLogID],a.[PatientHistoryCrossRefID],a.[PatientFieldNameTypeID],a.[OldValue],a.[NewValue],a.[CreatedDate] FROM dbo.PatientAuditLog a WITH (NOLOCK)
 LEFT JOIN [XTArchive].dbo.PatientAuditLog b on b.PatientAuditLogID = a.PatientAuditLogID
 WHERE a.CreatedDate <= @ArchiveProcessStartTime AND b.PatientAuditLogID IS NULL  
 AND EXISTS(SELECT 1 FROM [XTArchive].dbo.PatientHistoryCrossRef e1 where e1.PatientHistoryCrossRefID = a.PatientHistoryCrossRefID)
 option (maxdop 6)


 SELECT @RowCount = @@ROWCOUNT;
 SET IDENTITY_INSERT [XTArchive].dbo.PatientAuditLog OFF;
 PRINT N'Insert into PatientAuditLog;' + convert(varchar(11), @StartTime, 101) + ' ' + convert(varchar(13),@StartTime,114) + ';' + convert(varchar(11), getutcdate(), 101) + ' ' + convert(varchar(13),getutcdate(),114) + ';' + CAST(@RowCount AS VARCHAR(10)) + ';' + 'PatientAuditLog' + ';' + '530'

insert into DBAdiag.dbo.dumbcodedebug (note, createddate)
values ('PatientAuditLog Insert end',getdate())

Answer 1

我遇到过运行个别查询的类似问题。在这些情况下，问题似乎总是在查询计划中效率低下，其中使用嵌套循环连接而不是其他算法。

我通过对违规查询使用查询提示来修复此问题：option (merge join, hash join)。除非有索引或其中一个表真的非常小，我发现嵌套循环连接是最差的算法。

我不确定这是不是你的问题。您可以存储查询的执行计划，并检查它们是否正在为此特定客户端进行更改。

Answer 2

这是一个难以回答的问题 - 我要撰写的内容更多的是意见而不是＆＃34;回答＆＃34;。

...然而

如果您有数百个客户端都执行相同的查询（可能是在相同的架构上，使用相同的DDL等），那么＆＃34;错误的查询计划＆＃34;假设需要进一步解释。

我说你的客户之间更有可能存在其他差异，这就解释了这一点。这个客户端有更多数据吗？它们运行此查询的频率是否存在差异（它似乎是一个归档过程;可能每天运行一次意味着每次运行需要考虑的行数较少）。

如果您可以显示查询的查询计划，我们可能会提供帮助。

最后 - 我累了，所以可能会遗漏一些明显的东西 - 我认为左连接意味着你总是插入带有NULL PatientAuditLogID的记录;那是真的吗？看起来它想成为主键。

有时长时间运行程序

2 个答案: