SQL SERVER Temporal Table 及相關怪異的故障怎么解決

這篇文章將為大家詳細講解有關SQL SERVER  Temporal Table  及相關怪異的故障怎么解決，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

 SQL SERVER  2016 有一個新功能，Temporal table，他主要的功能是保留一份完整的數據表的變化記錄，并允許通過這個表來進行數據的變更性分析。

啟用CAMAIN 中temporal tables 會產生一個新的表在原表的名稱前，增加后綴history。

主要的功能：

審核所有數據更改，并在必要時執行數據取證
與過去任何時候一樣重建數據的狀態
計算隨時間的趨勢
為決策支持應用程序維護一個緩慢變化的維度
從意外的數據更改和應用程序錯誤中恢復

我們下面來一個例子看一下 temporal 是怎么做的，我們在一個開啟了 temporal 的表中進行 DML 操作，更改其中一行的數據。

可以看到歷史表中的數據已經開始記錄修改數據之前的所有這行的原始數據

然后我們在此更改數據

然后在查詢歷史表，這次還是一樣記錄更改前的記錄狀態

在插入數據的時候，會在原表中的字段，進行記錄，而在歷史表中并不會有任何記錄，這點是要知道的。而更新記錄，刪除記錄，都會對這些操作進行記錄。同時還有一種MERGE 的方式也是將操作拆分成 DELETE ,UPDATE, INSERT 的方式來進行對應行的記錄。

這么先進的東西，從2016開始的新功能，其實深究起來，也是有問題的。

上面的問題，在HOT table 中反應的比較多，在MICORSOFT 官方的 TECH在中，有提到，并且也有一些人提出了解決方法，當然微軟并沒有認為這一個BUG。

產生這個問題的原因是這樣的，我們現在進行一個模擬，我們有兩個SESSION  A and B ，我們都要對其中一個表 CACONTRACT ，進行操作

而不幸的是， A 中的語句是這樣寫的。

UPDATE  CACONTRACT SET NUM = 2  WHERE  ID  IN （select  NUM FROM CAMAIN where num = 3）

看似沒有問題，但我們可以將他看成一個事務，如果這樣的處理時間是需要0.2毫秒， 但B SESSION 更快，例如他處理 UPDATE CACONTRACT SET BC = 2 WHERE ID = '000003DJKHJ'

看似兩個操作其實不會影響，但B 操作由于快于 A 操作，則例如 ID 000003DJKHJ  在 表中的 SysStartTime 標記為  10點15分 .27997 微妙

而 A  SESSION 在操作完畢后， 也需要在 sysstarttime 中寫上我的處理

SysStartTime 進行一個更改的操作，將 SysStartTime 更改為 10:1527987 ，這已經明顯不符合邏輯了，一個記錄SysStartTime 再次更新要比當前的時間 要早，這在邏輯上走不通，所以，這個操作 A 就被forbidden.  尤其在特別熱的表上。

光說不練假把式，來我們來模擬一下上述的情況吧

Follow me 

1 在你的測試系統上建立一個測試表

REATE 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

2  請允許以下腳本

   BEGIN TRAN

      WAITFOR DELAY '00:00:15';

      UPDATE dbo.Orders 

      SET [OrderValue] = [OrderValue] + 1;

    COMMIT TRAN

3  請在另一個 查詢窗口執行如下語句

   INSERT dbo.Orders ([OrderId], [OrderValue])

     VALUES (1, 9.99), (2, 9.99);

     GO

     SELECT * FROM dbo.Orders;

     GO

這就是插入數據在后，但卻先插入，而要更新時在前，實際操作在后。這個時序性的系統自然就吃不消了。

解決這樣的問題：

1  讓關于報錯表的 DML 操作足夠的快，避免這樣的事情發生（不過在很復雜的系統中，這很難）

2  在某些操作中，你想使用  holdlock 操作（其實是人為降低系統的處理性能）

3  在非常熱的表中，停止使用這項微軟的新功能，并等待微軟能在新的版本中更新這個BUG。

關于SQL SERVER  Temporal Table  及相關怪異的故障怎么解決就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。