MS SQL временной таблица неудача обновления

Question

Я не могу найти что-нибудь, чтобы объяснить, почему при вызове SP, который делает вставки или обновления в зависимости от того, если записи уже существует на временные таблицы я получаю

модификации данных не удалась на системы- versioned table «MYDB.dbo.TemporalExample», поскольку время транзакции было раньше времени начала периода для затронутых записей.

какая доза это означает? Кажется, что это случается некоторое время, я задаюсь вопросом, не связано ли это с тем, что im работает многопоточный код и azure sql, но не любит взаимные соединения с одной и той же таблицей, когда это временная? Им будет хотя рамки сущности (последняя версия), но я сомневаюсь, что это вопрос

мой зр только это

 

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 

Update мой височной скрипт создания таблицы:

 

    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

Так я работал его ... кажется, что временные таблицы не играют хорошо с заправочной логикой. Я подозреваю, что потому, что я делаю несколько параллельных обновлений для таблицы параллельно; связанная с этим таблица истории отстает в своем обновлении настолько, что временная привязка вызывает сбой. Проблема в том, что мой код в одном потоке исправил проблему. Кажется странным, что временная таблица будет подвержена тому, что кажется почти условием гонки? Я знаю, что это не мой код, поскольку тот же код отлично работает для других таблиц. Поэтому я предполагаю, что мне придется придерживаться однопоточной логики до тех пор, пока MS не исправит ее.

Answer 2

Это хакерское обходное решение и не является идеальным в большинстве случаев, однако, если вы хотите сериализовать доступ к критическому разделу при работе с SQL-сервером то вы можете использовать встроенный механизм блокировки для предоставления доступа к этому критическому разделу через , однако вы можете просто перемещать узкое место в другое место в зависимости от ситуации.

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