MS SQL 临时表更新失败

Question

我找不到任何东西来解释为什么当调用一个SP时，它根据记录是否已经存在于我得到的时态表上来执行插入或更新

系统版本表“MYDB.dbo”上的数据修改失败。“TemporalExample”，因为受影响记录的事务时间早于时段开始时间。

那是什么意思？这似乎只是偶尔发生，我不知道是不是因为我在运行多线程代码，而azure sql只是不喜欢当它是一个时态表时相互连接到同一个表？我正在浏览实体框架(最新版本),但我怀疑这是问题所在

我的sp就是这个

create PROCEDURE mysp 
    @ID bigint,
    @a FLOAT,
    @b NVARCHAR(10),
    @c  DECIMAL(19, 4)
AS
    SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED    

    SET NOCOUNT ON    

    BEGIN TRY

        IF EXISTS ( SELECT TOP 1 
                        Id 
                    FROM 
                        my_Temporal_Table WITH (NOLOCK) 
                    WHERE 
                        id = @ID 
                        AND a = @a
                        AND b = @b)
            BEGIN

                UPDATE 
                    my_Temporal_Table
                SET
                    Id = @ID,
                    a = @a,
                    b = @b
                    c = @c
                    DateModified =  GETUTCDATE()
                WHERE 
                    Id = @Id

            END
        ELSE    
            BEGIN

                INSERT INTO 
                    my_Temporal_Table
                        (Id, a, b, c, DateModified)
                VALUES 
                        (@ID, @a, @b, @c , GETUTCDATE())        
            END

    END TRY
    BEGIN CATCH
        DECLARE @ErrorMessage   NVARCHAR(4000),
                @ErrorSeverity  INT,
                @ErrorState     INT

        SELECT 
                @ErrorMessage = ERROR_MESSAGE(),        
                @ErrorSeverity = ERROR_SEVERITY(),
                @ErrorState = ERROR_STATE()

        -- Use RAISERROR inside the CATCH block to return error
        -- information about the original error that caused
        -- execution to jump to the CATCH block.
        RAISERROR (@ErrorMessage, -- Message text.
                   @ErrorSeverity, -- Severity.
                   @ErrorState -- State.
                   )

    END CATCH

更新我的时态表创建脚本:

    CREATE TABLE [Temporal](
    [TemporalId] [bigint] IDENTITY(1,1) NOT NULL,
    [Payment] [decimal](19, 4) NOT NULL,
    [DateModified] [datetime2](7) NOT NULL,
    [SysStartTime] [datetime2](7) GENERATED ALWAYS AS ROW START NOT NULL,
    [SysEndTime] [datetime2](7) GENERATED ALWAYS AS ROW END NOT NULL,
    CONSTRAINT [TemporalId] PRIMARY KEY CLUSTERED ([TemporalId] ASC)
        WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON),
    PERIOD FOR SYSTEM_TIME ([SysStartTime], [SysEndTime])
    )WITH(
    SYSTEM_VERSIONING = ON ( HISTORY_TABLE = [Car2].[TemporalHistory] )
    )

有人能解释为什么我可能会看到这个问题，它意味着什么，更重要的是，我如何才能修复它？

谢谢

Answer 1

这是一种黑客式的解决方法，在大多数情况下并不理想，但是，如果要在处理sql server时序列化对关键部分的访问权限，则可以使用内置的锁定机制通过SP_GETAPPLOCK授予对该关键部分的访问权限，但是，根据情况，您可能只是将瓶颈移动到另一个位置。

CREATE PROC MyCriticalWork(@MyParam INT)      
AS
    DECLARE @LockRequestResult INT=0    
    DECLARE @MyTimeoutMiliseconds INT=5000--Wait only five seconds max then timeouit

    BEGIN TRAN

    EXEC @LockRequestResult=SP_GETAPPLOCK 'MyCriticalWork','Exclusive','Transaction',@MyTimeoutMiliseconds
    IF(@LockRequestResult>=0)BEGIN

            /*
            DO YOUR CRITICAL READS AND WRITES HERE
            */

        COMMIT TRAN--Releases the lock
    END ELSE
        ROLLBACK TRAN--Releases the lock  

Answer 2

所以我解决了这个问题…似乎时态表不能很好地处理线程逻辑。我怀疑这是因为我并行地对表进行多个并发更新；链接的历史记录表的更新滞后到时间链接导致故障的程度。使我的代码成为单线程解决了这个问题。似乎很奇怪，时态表会受到几乎是一种竞争条件的约束？我知道这不是我的代码，因为相同的代码适用于其他表。因此，我想我将不得不坚持单线程逻辑，直到MS修复它