更新时态表时出错

Question

我已经在“订单”表上实现了系统版本化临时表。应用程序使用不同的访问模式来修改此表中的数据。有来自应用程序的直接语句，或者应用程序在显式事务中运行长批处理，其中对多个表进行了多次更改。“订单”表上的更新不是那些长批次中的第一条语句！因此，有时我们会面临以下错误。

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

显然，这是系统版本化临时表的标准行为。https://docs.microsoft.com/en-us/sql/relational-databases/tables/temporal-tables?view=sql-server-2017#how-does-temporal-work

这是总是需要在异常例程中处理的东西吗？还是微软正在考虑改变这种行为？

-- 模拟错误信息的脚本：

CREATE TABLE dbo.Orders 
    (    
      [OrderId] INT NOT NULL PRIMARY KEY CLUSTERED  
      , [OrderValue] DECIMAL(19,4)
      , [ValidFrom] DATETIME2 (2) GENERATED ALWAYS AS ROW START  
      , [ValidTo] DATETIME2 (2) GENERATED ALWAYS AS ROW END  
      , PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo)  
     )    
     WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.OrdersHistory)); 
     GO

     INSERT dbo.Orders ([OrderId], [OrderValue])
     VALUES (1, 9.99), (2, 9.99);
     GO

     SELECT * FROM dbo.Orders;
     GO

       --Run first query
   BEGIN TRAN
      WAITFOR DELAY '00:00:15';
      UPDATE dbo.Orders 
      SET [OrderValue] = [OrderValue] + 1;
    COMMIT TRAN


       --Run Query 2 in another session sql server
    BEGIN TRAN
       UPDATE dbo.Orders 
       SET [OrderValue] = [OrderValue] + 1;
    COMMIT TRAN

Answer 1

这是总是需要在异常例程中处理的事情吗？

系统生成的开始和结束时间与执行时服务器的系统时间有关BEGIN TRANSACTION。如果您有长时间运行的事务，您应该：

1. 内置可以重试事务的异常处理。

2. 返工有问题的代码，使其执行得更快。这听起来可能需要大量工作，但有必要进行一定程度的返工才能正确处理基于时间的异常。如果您要进行返工，您不妨确定事务为何花费如此长的时间，并减轻这种行为。

或者微软是否正在考虑改变这种行为？

除非微软发布了保密协议未涵盖的公开声明，否则无法知道微软将在其产品的未来版本中做什么。他们可能会在将来的某个时刻修改时态表功能，以便开始日期和结束日期反映插入/更新时的当前系统时间，但这不是目前的工作方式。