我有一个具有两个事务的存储过程。第一种是基于对控制表的内部联接从表中删除行。第二种是使用同一控制表上的另一个内部联接将行插入回到同一表中。
此存储过程的性能是可变的。有时我可以执行它以在几秒钟内插入几千行(<15,000)。我下次尝试执行该命令时,它立即变为可运行状态,最后等待的时间是SOS_Scheduler_Yield。我一直在寻找这种等待,并有所了解。
我已经检查过类似的东西:
服务器上的电源设置(CPU上的最大频率)。在尝试执行之前,CPU并不忙-它通常少于1%,在执行“挂起”时会跳到13%。
将需要处理的结果数量减少到几百个,有时效果很快-但有时会以相同的方式挂起
我尝试重新编译查询计划,但没有任何改善
在2个涉及的表上重建索引而没有任何改善(聚集索引)
检查了查询计划。最昂贵的操作是聚簇索引插入。我不认为这是问题所在,因为有时它可以很好地执行。
我在VM中使用SQL Server 2012。
有什么可以尝试的吗?
表创建:
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [A].[SummLoads](
[shiftID_L] [int] NULL,
[Excav] [nvarchar](20) NULL,
--50 more columns here
[ExcelDate] [int] NULL,
[ID] [bigint] IDENTITY(1,1) NOT NULL,
CONSTRAINT [PK_SummLoads] PRIMARY KEY NONCLUSTERED
(
[ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 80) ON [PRIMARY]
) ON [PRIMARY]
GO
存储过程:
ALTER PROCEDURE [B].[sp_SSISsumLoads]
AS
BEGIN
--EXEC sp_recompile 'MDM.[B].[sp_SSISsumLoads]' Force Recompile
--BEGIN TRAN
--Delete shifts to be replaced
DELETE sl
FROM mdm.a.summLoads sl
INNER JOIN mdm.tmp.ALD_Control AC
ON sl.shiftID_L = MDM.A.fn_SI_to_ShiftID(l_shiftindex)
--Re-insert removed data
INSERT INTO MDM.A.SummLoads
SELECT
[shiftID_L]
,[Excav]
,[OperEx]
--some columns omitted
,sum([GrOx]*ALD.TonnesLoaded) AS 'GrOx'
,datediff(d,'1899-12-30',MDM.A.fn_shiftID_to_date([shiftID_l]))
FROM [MDM].[A].[ALDsun] ALD
INNER JOIN MDM.B.Materials GM
ON ALD.MatCode# = GM.MatCode#
INNER JOIN mdm.tmp.ALD_Control AC
ON ShiftID_L = MDM.A.fn_SI_to_ShiftID(AC.l_shiftindex)
LEFT OUTER JOIN mdm.b.eGOH_Factors AS EF
ON EF.eqmtModel# = ALD.EqmtModelTk#
GROUP BY
[shiftID_L]
,[Excav]
,[OperEx]
,EqmtModelEx
,EqmtModelEx#
,EqmtModelTk
,[EqmtModelTk#]
,[Mine]
,[Mine#]
,contractor
,contractor#
,GM.MatCode
,GM.MatCode#
,GM.MatType
,GM.MatDPR
,GM.Prod
,GM.Prod#
,[GradeID]
,[LocDig]
,[LocDump]
,[DumpArea];
注意:sp中的联接表是带有聚集索引的小型助手(<50行)。
编辑2:我检查了VM资源分配。 CPU不会承受持续的压力,并且永远不会超过25%。内存只有65Gb,只有62Gb,但是VM内的性能监视器基本上所有这些都由SQL Server服务保留。