管理系統建立版本之時態表中的歷程記錄資料保留

適用於：SQL Server 2016 (13.x) 和更新版本 Azure SQL 資料庫 Azure SQL 受控執行個體

使用系統設定版本的時態表時，歷程記錄資料表增加資料庫大小的程度可能會比一般資料表大，特別是在下列情況下：

• 您的歷程記錄資料保留一段很長的時間
• 您更新或刪除大量資料修改模式

對於不斷成長的大型歷程記錄資料表來說，單是儲存成本和加諸於時態查詢之上的效能負擔就可能會造成問題。 因此，開發資料保留原則來管理歷程記錄資料表中的資料是規劃及管理每個時態表生命週期的重要環節。

歷程記錄資料表的資料保留管理

若要管理時態表的資料保留，第一步是決定每個時態表所需的保留期限。 在大部分情況下，您應將保留原則視為使用時態表之應用程式商務邏輯的一部分。 例如，資料稽核和時間移動案例中的應用程式，對於供應線上查詢之歷程記錄資料的保留期間有嚴格的規範。

決定資料保留期間之後，下一個步驟是制定管理歷程記錄資料的計劃。 您必須決定儲存歷程記錄資料的方式和位置，以及如何刪除早於保留需求的歷程記錄資料。 您可以使用下列方法來管理時態歷程記錄資料表中的歷程記錄資料：

• 資料表資料分割
• 自訂清除指令碼
• 保留原則

對於以上任一種方式，移轉或清除歷程記錄資料的邏輯乃基於與目前資料表之期間結束相對應的資料行。 每個資料列的期間結束值決定資料列版本「關閉」時間，也就是落在歷程記錄資料表的時間。 例如， ValidTo < DATEADD (DAYS, -30, SYSUTCDATETIME ()) 條件指定超過一個月的歷程記錄資料需要移除或移出歷程記錄資料表。

注意

本文中的範例會使用建立系統設定版本的時態表。

使用資料表資料分割方法

資料分割資料表和索引可讓大型資料表更容易管理及擴充。 透過資料表資料分割方法，您可以使用記錄資料表資料分割來實作以時間為基礎的自訂資料清除或離線封存。 在使用資料分割刪除查詢時態表中的資料歷程記錄子集時，資料表資料分割也能帶來效能上的效益。

資料表資料分割可讓您實作滑動視窗，將歷程記錄資料最舊的部分移出歷程記錄資料表，並依照存在時間讓保留部分的大小維持不變 - 讓歷程記錄資料表中的資料等於需要的保留期限。 當 SYSTEM_VERSIONING 為 ON 時，系統支援將資料切換移出歷程記錄資料表的作業，這表示您可以在不採用維護期間或不阻礙正常工作負載的情況下清除一部分的歷程記錄資料。

注意

若要執行分割切換，歷程記錄資料表上的叢集索引必須與分割結構描述對齊 (它必須含有 ValidTo)。 由系統建立的預設歷程記錄資料表含有叢集索引，其中包含 ValidTo 和 ValidFrom 資料行，最適合進行分割、插入新歷程記錄資料及一般時態性查詢。 如需相關資訊，請參閱時態表。

滑動視窗有兩組需要執行的工作：

• 資料分割組態工作
• 週期性資料分割維護工作

為了方便解說，假設您想要保留歷程記錄資料六個月，且您想要將每個月的資料保存在不同分割區。 此外，假設您在 2023 年 9 月啟動了系統版本設定功能。

資料分割組態工作會建立歷程記錄資料表的初始資料分割組態。 在此範例中，您可以建立與滑動視窗大小相同數目的分割區 (以月份為單位)，外加一個預先準備的額外空分割區 (如本文稍後所述)。 這個設定可確保系統能在您首次啟動週期性分割區維護工作時正確地儲存新資料，而且能確保您永遠不會分割資料區，以避免昂貴的資料移動。 您應該使用 Transact-SQL 依照本文稍後部分的範例指令碼來執行這項工作。

下圖顯示保存六個月資料的初始資料分割組態。

注意

如需在設定資料分割時使用 RANGE LEFT 與 RANGE RIGHT 的效能含意，請參閱本文稍後部分中的資料表資料分割效能考量。

第一個和最後一個分割區的上限和下限分別保持「開啟」，以確保不論分割資料行中的值為何，每個新資料列都有目的地分割區。 隨著時間流逝，歷程記錄資料表中的新資料列會位於更高的分割區。 當第六個分割區填滿時，達到預計的保留期間。 這是首次啟動週期性資料分割維護工作的時候 (您需要將它排程為定期執行，在本範例中為每月一次)。

下圖說明週期性分割區維護工作 (請參閱本文稍後部分中的詳細步驟)。

週期性資料分割維護工作的詳細步驟如下︰

1. SWITCH OUT：建立暫存資料表，然後使用 ALTER TABLE (Transact-SQL) 陳述式並搭配 SWITCH PARTITION 引數，在歷程記錄資料表和暫存資料表之間切換分割區 (請參閱「範例 C.在資料表之間切換分割區」)。

   ALTER TABLE [<history table>] SWITCH PARTITION 1 TO [<staging table>];
   

   切換分割區之後，您可以選擇性地封存暫存資料表中的資料，然後丟棄或截斷暫存資料表以做好下次執行此週期性分割區維護工作的準備。

2. MERGE RANGE：使用 ALTER PARTITION FUNCTION (Transact-SQL) 並搭配 1 來合併空分割區 2 和分割區 MERGE RANGE (請參閱範例 B)。 藉由使用此函數移除最低界限，您可以有效地合併空分割區 1 和先前的分割區 2，組成新分割區 1。 其他資料分割也可以有效地變更其序數。

3. SPLIT RANGE：使用 ALTER PARTITION FUNCTION (Transact-SQL) 並搭配 SPLIT RANGE 來建立新的空分割區 7 (請參閱範例 A)。 藉由使用這個函數加入新的上限，您可以有效地為下個月份建立個別資料分割。

使用 Transact-SQL 在歷程記錄資料表上建立資料分割

使用下列 Transact-SQL 指令碼來建立資料分割函數、資料分割結構描述，以及重新建立與資料分割結構描述和資料分割對齊的叢集索引。 在此範例中，您可利用從 2023 年 9 月開始的每月資料分割來建立為期六個月的滑動視窗。

BEGIN TRANSACTION

/*Create partition function*/
CREATE PARTITION FUNCTION [fn_Partition_DepartmentHistory_By_ValidTo] (DATETIME2(7))
AS RANGE LEFT FOR VALUES (
    N'2023-09-30T23:59:59.999',
    N'2023-10-31T23:59:59.999',
    N'2023-11-30T23:59:59.999',
    N'2023-12-31T23:59:59.999',
    N'2024-01-31T23:59:59.999',
    N'2024-02-29T23:59:59.999'
);

/*Create partition scheme*/
CREATE PARTITION SCHEME [sch_Partition_DepartmentHistory_By_ValidTo]
AS PARTITION [fn_Partition_DepartmentHistory_By_ValidTo] TO (
    [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY],
    [PRIMARY], [PRIMARY], [PRIMARY]
);

/*Re-create index to be partition-aligned with the partitioning schema*/
CREATE CLUSTERED INDEX [ix_DepartmentHistory] ON [dbo].[DepartmentHistory] (
    ValidTo ASC,
    ValidFrom ASC
)
WITH (
    PAD_INDEX = OFF,
    STATISTICS_NORECOMPUTE = OFF,
    SORT_IN_TEMPDB = OFF,
    DROP_EXISTING = ON,
    ONLINE = OFF,
    ALLOW_ROW_LOCKS = ON,
    ALLOW_PAGE_LOCKS = ON,
    DATA_COMPRESSION = PAGE
) ON [sch_Partition_DepartmentHistory_By_ValidTo](ValidTo);

COMMIT TRANSACTION;

使用 Transact-SQL 來維護滑動視窗案例中的資料分割

使用下列 Transact-SQL 指令碼來維護滑動視窗案例中的資料分割。 在此案例中，您可使用 MERGE RANGE 切換移出 2023 年 9 月的資料分割，再使用 SPLIT RANGE 加入 2024 年 3 月的新資料分割。

BEGIN TRANSACTION

/*(1) Create staging table */
CREATE TABLE [dbo].[staging_DepartmentHistory_September_2023] (
    DeptID INT NOT NULL,
    DeptName VARCHAR(50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
    ManagerID INT NULL,
    ParentDeptID INT NULL,
    ValidFrom DATETIME2(7) NOT NULL,
    ValidTo DATETIME2(7) NOT NULL
) ON [PRIMARY]
WITH (DATA_COMPRESSION = PAGE);

/*(2) Create index on the same filegroups as the partition that will be switched out*/
CREATE CLUSTERED INDEX [ix_staging_DepartmentHistory_September_2023]
ON [dbo].[staging_DepartmentHistory_September_2023] (
    ValidTo ASC,
    ValidFrom ASC
)
WITH (
    PAD_INDEX = OFF,
    SORT_IN_TEMPDB = OFF,
    DROP_EXISTING = OFF,
    ONLINE = OFF,
    ALLOW_ROW_LOCKS = ON,
    ALLOW_PAGE_LOCKS = ON
) ON [PRIMARY];

/*(3) Create constraints matching the partition that will be switched out*/
ALTER TABLE [dbo].[staging_DepartmentHistory_September_2023]
    WITH CHECK ADD CONSTRAINT [chk_staging_DepartmentHistory_September_2023_partition_1]
    CHECK (ValidTo <= N'2023-09-30T23:59:59.999')

ALTER TABLE [dbo].[staging_DepartmentHistory_September_2023]
    CHECK CONSTRAINT [chk_staging_DepartmentHistory_September_2023_partition_1]

/*(4) Switch partition to staging table*/
ALTER TABLE [dbo].[DepartmentHistory] SWITCH PARTITION 1
TO [dbo].[staging_DepartmentHistory_September_2023]
    WITH (WAIT_AT_LOW_PRIORITY(MAX_DURATION = 0 MINUTES, ABORT_AFTER_WAIT = NONE))

/*(5) [Commented out] Optionally archive the data and drop staging table
      INSERT INTO [ArchiveDB].[dbo].[DepartmentHistory]
      SELECT * FROM [dbo].[staging_DepartmentHistory_September_2023];
      DROP TABLE [dbo].[staging_DepartmentHIstory_September_2023];
*/
/*(6) merge range to move lower boundary one month ahead*/
ALTER PARTITION FUNCTION [fn_Partition_DepartmentHistory_By_ValidTo]()
    MERGE RANGE(N'2023-09-30T23:59:59.999');
/*(7) Create new empty partition for "April and after" by creating new boundary point and specifying NEXT USED file group*/
ALTER PARTITION SCHEME [sch_Partition_DepartmentHistory_By_ValidTo] NEXT USED [PRIMARY]
    ALTER PARTITION FUNCTION [fn_Partition_DepartmentHistory_By_ValidTo]()
    SPLIT RANGE(N'2024-03-31T23:59:59.999');
COMMIT TRANSACTION

您可以稍微修改先前的指令碼，並運用於一般的每月維護程序中：

1. 在步驟 (1) 中，針對要移除的月份建立新的暫存表格 (此範例中的下一個月份是 10 月)。
2. 在步驟 (3) 中，建立及檢查符合要移除之資料月份的條件約束︰ValidTo <= N'2023-10-31T23:59:59.999' (適用於 10 月資料分割)。
3. 在步驟 (4) 中，SWITCH 將 1 資料分割為新建立的暫存表格。
4. 在步驟 (6) 中，藉由合併下限來改變資料分割函數：MERGE RANGE(N'2023-10-31T23:59:59.999' (在移出 10 月的資料之後)。
5. 在步驟 (7) 中，藉由建立新的上限來分割資料分割函數：SPLIT RANGE (N'2024-04-30T23:59:59.999' (在移出 10 月的資料之後)。

然而，最好的方案是定期執行不需要修改指令碼即可在每個月執行適當動作的一般性 Transact-SQL 指令碼。 您可以將先前的指令碼一般化，以根據提供的參數採取行動 (需要合併的下限和使用分割區分割建立的新界限)。 為了避免在每個月建立暫存資料表，您可以將檢查條件約束變更為比對要切換移出的資料分割，藉此預先建立暫存資料表並重複使用。請參閱下列頁面以了解如何使用 Transact-SQL 指令碼將 滑動視窗全面自動化 的概念。

資料表資料分割效能考量

執行 MERGE 和 SPLIT RANGE 操作來避免任何資料移動至關重要，因為資料移動可能會造成繁重的效能負荷。 如需詳細資訊，請參閱修改資料分割函數。 在建立資料分割函數時，可使用 RANGE LEFT 而非 RANGE RIGHT 來執行此動作。

讓我們先以視覺化方式說明 RANGE LEFT 和 RANGE RIGHT 選項的意義：

當您將資料分割函數定義為 RANGE LEFT 時，指定的值是資料分割的上限。 當您使用 RANGE RIGHT 時，指定的值是資料分割的下限。 當您使用 MERGE RANGE 操作來移除資料分割函數定義中的界限時，基礎實作也會移除包含界限的資料分割。 如果該資料分割不是空的，系統會將資料移動到 MERGE RANGE 操作所產生的資料分割。

在滑動視窗案例中，請務必移除最低的資料分割界限。

• RANGE LEFT 案例：最低分割區界限屬於分割區 1，由於該分割區是空的 (在分割區切換移出後)，所以 MERGE RANGE 不會引發任何資料移動。
• RANGE RIGHT 案例：最低分割區界限屬於分割區 2，它不為空，因為分割區 1 已透過切換移出被清空。在此情況下，MERGE RANGE 會引發資料移動 (分割區 2 的資料會移至分割區 1)。 若要避免資料移動，滑動視窗案例中的 RANGE RIGHT 需要擁有始終為空的分割區 1。 這意味著如果使用 RANGE RIGHT，與 RANGE LEFT 案例相比，應該建立和維護一個額外分割區。

結論：在滑動分割區中使用 RANGE LEFT 可讓分割區管理更加簡單，並能避免資料移動。 不過，使用 RANGE RIGHT 來定義分割區界限稍微簡單一些，因為您不需要處理日期時間的對時問題。

使用自訂清除指令碼方法

當資料表資料分割不可行時，另一個方法是使用自訂清除指令碼刪除記錄資料表中的資料。 唯有當 SYSTEM_VERSIONING = OFF 時，您才可以刪除歷程記錄資料表中的資料。 為了避免資料不一致，請在維護期間 (當修改資料的工作負載未作用時) 或交易內 (有效地封鎖其他工作負載) 執行清除作業。 這項作業需要目前和歷程記錄資料表的 CONTROL 權限。

為了盡可能避免阻礙一般應用程式和使用者查詢，於交易內執行清除指令碼時，請在設定延遲的情況下以較小的區塊刪除資料。 對於每個要刪除的資料區塊來說，雖然所有案例都沒有最合適的大小，不過在單一交易中刪除 10,000 個以上的資料列就可能會造成顯著影響。

所有時態表的清除邏輯都一樣，因此只要透過為每個要限制資料歷程記錄之時態表排程為定期執行的一般預存程序，您就可以將其自動化。

下圖說明如何安排單一資料表的清除邏輯，以減少對執行中工作負載的影響。

以下是一些實作程序的高階指導方針。 將清除邏輯排程為每天執行，並且逐一處理所有需要清除資料的時態表。 使用 SQL Server Agent 或其他工具來排程這個程序：

• 如上圖所示，以小區塊為單位，按照最舊資料列到最新資料列的順序，利用多次反覆運算的方式刪除每個時態表中的歷程記錄資料，避免在單一交易中刪除所有資料列。
• 將每個反覆運算視為叫用移除歷程記錄資料表部分資料的一般預存程序實作 (如需此程序，請參閱此程序的下列程式碼範例)。
• 在每次叫用程序時，計算需要刪除單一時態表中多少資料列。 根據前述結果和需要的反覆運算數目，判斷每次程序叫用的動態分割點。
• 在單一資料表的反覆運算之間規劃一段延遲期間，以減少對存取時態表之應用程式的影響。

對於刪除單一時態表之資料的預存程序，其內容可能與以下程式碼片段相似 (在環境中套用之前，請仔細檢閱以下程式碼並加以調整)：

DROP PROCEDURE IF EXISTS usp_CleanupHistoryData;
GO
CREATE PROCEDURE usp_CleanupHistoryData @temporalTableSchema SYSNAME,
    @temporalTableName SYSNAME,
    @cleanupOlderThanDate DATETIME2
AS
DECLARE @disableVersioningScript NVARCHAR(MAX) = '';
DECLARE @deleteHistoryDataScript NVARCHAR(MAX) = '';
DECLARE @enableVersioningScript NVARCHAR(MAX) = '';
DECLARE @historyTableName SYSNAME
DECLARE @historyTableSchema SYSNAME
DECLARE @periodColumnName SYSNAME

/*Generate script to discover history table name and end of period column for given temporal table name*/
EXECUTE sp_executesql
N'SELECT @hst_tbl_nm = t2.name,
      @hst_sch_nm = s2.name,
      @period_col_nm = c.name
  FROM sys.tables t1
  INNER JOIN sys.tables t2 ON t1.history_table_id = t2.object_id
  INNER JOIN sys.schemas s1 ON t1.schema_id = s1.schema_id
  INNER JOIN sys.schemas s2 ON t2.schema_id = s2.schema_id
  INNER JOIN sys.periods p ON p.object_id = t1.object_id
  INNER JOIN sys.columns c ON p.end_column_id = c.column_id AND c.object_id = t1.object_id
  WHERE t1.name = @tblName AND s1.name = @schName',
N'@tblName sysname,
    @schName sysname,
    @hst_tbl_nm sysname OUTPUT,
    @hst_sch_nm sysname OUTPUT,
    @period_col_nm sysname OUTPUT',
@tblName = @temporalTableName,
@schName = @temporalTableSchema,
@hst_tbl_nm = @historyTableName OUTPUT,
@hst_sch_nm = @historyTableSchema OUTPUT,
@period_col_nm = @periodColumnName OUTPUT

IF @historyTableName IS NULL OR @historyTableSchema IS NULL OR @periodColumnName IS NULL
    THROW 50010, 'History table cannot be found. Either specified table is not system-versioned temporal or you have provided incorrect argument values.', 1;

/*Generate 3 statements that run inside a transaction:
  (1) SET SYSTEM_VERSIONING = OFF,
  (2) DELETE FROM history_table,
  (3) SET SYSTEM_VERSIONING = ON
  On SQL Server 2016, it is critical that (1) and (2) run in separate EXEC statements, or SQL Server generates the following error:
  Msg 13560, Level 16, State 1, Line XXX
  Cannot delete rows from a temporal history table '<database_name>.<history_table_schema_name>.<history_table_name>'.
*/

SET @disableVersioningScript = @disableVersioningScript
    + 'ALTER TABLE [' + @temporalTableSchema + '].[' + @temporalTableName
    + '] SET (SYSTEM_VERSIONING = OFF)'
SET @deleteHistoryDataScript = @deleteHistoryDataScript + ' DELETE FROM ['
    + @historyTableSchema + '].[' + @historyTableName + '] WHERE ['
    + @periodColumnName + '] < ' + '''' + CONVERT(VARCHAR(128), @cleanupOlderThanDate, 126) + ''''
SET @enableVersioningScript = @enableVersioningScript + ' ALTER TABLE ['
    + @temporalTableSchema + '].[' + @temporalTableName
    + '] SET (SYSTEM_VERSIONING = ON (HISTORY_TABLE = [' + @historyTableSchema
    + '].[' + @historyTableName + '], DATA_CONSISTENCY_CHECK = OFF )); '

BEGIN TRANSACTION
    EXEC (@disableVersioningScript);
    EXEC (@deleteHistoryDataScript);
    EXEC (@enableVersioningScript);
COMMIT;

使用時態歷程記錄保留原則方法

適用於：SQL Server 2017 (14.x) 和更新版本，以及 Azure SQL Database。

時態歷程記錄保留可在個別的資料表層級上設定，讓使用者建立彈性的過時原則。 套用暫時保留很簡單：只需要在資料表建立或結構描述變更期間設定一個參數。

定義保留原則之後，資料庫引擎會開始定期檢查是否有可自動清除資料的合格歷程記錄資料列。 識別相符資料列及從歷程記錄資料表中移除它們的作業，會以明確的方式在系統排程和執行的背景工作中進行。 會根據代表 SYSTEM_TIME 期間結束的資料行，檢查歷程記錄資料表資料列的存留期條件。 如果保留期限 (例如，設定為六個月) 資料表資料列符合清除資格，請滿足下列條件：

ValidTo < DATEADD (MONTH, -6, SYSUTCDATETIME())

在上述範例中，ValidTo 資料列對應 SYSTEM_TIME 期間的結束。

如何設定保留原則？

設定時態資料表的保留原則之前，請先檢查是否已在資料庫層級啟用時態歷程記錄保留：

SELECT is_temporal_history_retention_enabled, name
FROM sys.databases;

資料庫旗標 is_temporal_history_retention_enabled 預設會設定為 ON，但使用者可以使用 ALTER DATABASE 陳述式進行變更。 在還原時間點 (PITR) 操作之後，此值自動設為 OFF。 若要為您的資料庫啟用時態歷程記錄保留清除功能，請執行下列陳述式：

ALTER DATABASE [<myDB>]
SET TEMPORAL_HISTORY_RETENTION ON;

藉由指定 HISTORY_RETENTION_PERIOD 參數值，在資料表建立期間設定保留原則：

CREATE TABLE dbo.WebsiteUserInfo
(
    UserID INT NOT NULL PRIMARY KEY CLUSTERED,
    UserName NVARCHAR(100) NOT NULL,
    PagesVisited int NOT NULL,
    ValidFrom DATETIME2(0) GENERATED ALWAYS AS ROW START,
    ValidTo DATETIME2(0) GENERATED ALWAYS AS ROW END,
    PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo)
 )
WITH (SYSTEM_VERSIONING = ON
    (
        HISTORY_TABLE = dbo.WebsiteUserInfoHistory,
        HISTORY_RETENTION_PERIOD = 6 MONTHS
    )
);

可以使用不同的時間單位來指定保留期間：DAYS、WEEKS、MONTHS 和 YEARS。 如果省略 HISTORY_RETENTION_PERIOD，會使用 INFINITE 保留期。 您也可以明確地使用 INFINITE 關鍵字。

在某些狀況中，您可能想要在資料表建立後設定保留，或變更先前設定的值。 在這種情況下，請使用 ALTER TABLE 陳述式：

ALTER TABLE dbo.WebsiteUserInfo
SET (SYSTEM_VERSIONING = ON (HISTORY_RETENTION_PERIOD = 9 MONTHS));

若要檢閱目前的保留原則狀態，請使用下列查詢，以聯結資料庫層級的暫時保留啟用旗標與個別資料表的保留期間：

SELECT DB.is_temporal_history_retention_enabled,
    SCHEMA_NAME(T1.schema_id) AS TemporalTableSchema,
    T1.name AS TemporalTableName,
    SCHEMA_NAME(T2.schema_id) AS HistoryTableSchema,
    T2.name AS HistoryTableName,
    T1.history_retention_period,
    T1.history_retention_period_unit_desc
FROM sys.tables T1
OUTER APPLY (
    SELECT is_temporal_history_retention_enabled
    FROM sys.databases
    WHERE name = DB_NAME()
    ) AS DB
LEFT JOIN sys.tables T2
    ON T1.history_table_id = T2.object_id
WHERE T1.temporal_type = 2;

SQL Database 如何刪除過時資料列？

清除處理序取決於歷程記錄資料表的索引配置。 只有包含叢集索引 (B+ 型樹狀目錄或資料行存放區）的歷程記錄資料表可以設定有限的保留原則。 建立的背景工作可利用有限的保留期間為所有時態表執行過時資料清除。 資料列存放區 (B+ 型樹狀目錄) 叢集索引的清除邏輯會刪除較小區塊 (最多 10K) 中的過時資料列，最大限度地減輕資料庫記錄和 I/O 子系統的壓力。 雖然清理邏輯會利用必要的 B+ 樹狀結構索引，但無法絶對保證早於保留期間之資料列的刪除順序。 因此，請勿在應用程式中對清除順序採用任何相依性。

叢集資料行存放區清理工作可一次移除整個資料列群組 (每個通常包含 1 百萬個資料列)，這是非常有效率的方法，特別是在高速產生歷程記錄資料時。

卓越的資料壓縮和有效率的保留清除，可讓叢集資料行存放區索引成為您的工作負載快速產生大量歷程記錄資料時的完美選擇。 此模式一般適用於使用時態表進行變更追蹤和稽核、趨勢分析或 IoT 資料擷取的大量交易處理工作負載。

如需詳細資訊，請參閱使用保留原則管理時態表中的歷程記錄資料。

相關內容

• 暫存資料表
• 開始使用系統建立版本的時態表
• 時態表系統一致性檢查
• 使用時態表進行資料分割
• 時態表考量與限制
• 時態表安全性
• 系統版本設定時態表與記憶體最佳化資料表
• 暫存資料表中繼資料檢視和函數