sys.dm_db_xtp_checkpoint_files （Transact-SQL）
適用於：
SQL Server Azure SQL 資料庫 Azure SQL 受控執行個體
顯示記憶體內部 OLTP 檢查點檔案的相關信息，包括檔案大小、實體位置和交易標識碼。
注意
對於尚未關閉的目前檢查點，新檔案的狀態數據行 sys.dm_db_xtp_checkpoint_files 將會是 [建構中]。 檢查點會在自上次檢查點之後有足夠的事務歷史記錄成長，或發出 CHECKPOINT 命令時自動關閉。 如需詳細資訊，請參閱 CHECKPOINT (Transact-SQL)。
記憶體優化檔案群組會在內部使用僅限附加的檔案來儲存記憶體內部數據表的插入和刪除數據列。 檔案有兩種類型。 數據檔包含插入的數據列，而差異檔案包含已刪除數據列的參考。
SQL Server 2014 （12.x） 與較新版本大不相同，而且會在 SQL Server 2014 中討論。
如需詳細資訊，請參閱 建立和管理記憶體優化物件的記憶體。
SQL Server 2016 (13.x) 和更新版本
下表描述 的數據行sys.dm_db_xtp_checkpoint_files，從 SQL Server 2016 （13.x） 開始。
| 資料行名稱 | 類型 | 描述 |
|---|---|---|
| container_id | int | 數據或差異檔案所屬之容器的標識碼（以 FILESTREAM 類型 sys.database_files為 的檔案表示）。 在 sys.database_files 中聯file_id結 sys.database_files （Transact-SQL） 。 |
| container_guid | uniqueidentifier | 容器的 GUID，根目錄、數據或差異檔案是其中的一部分。 與數據表中的聯 file_guid 結 sys.database_files 。 |
| checkpoint_file_id | uniqueidentifier | 檢查點檔案的 GUID。 |
| relative_file_path | nvarchar(256) | 相對於所對應容器的檔案路徑。 |
| file_type | smallint | -1 免費 0 用於 DATA 檔案。 1 用於 DELTA 檔案。 根檔案 2 3 適用於大型數據檔 |
| file_type_desc | nvarchar(60) | FREE- 所有維護為 FREE 的檔案都可供配置。 免費檔案會根據系統的預期需求而有所不同。 大小上限為 1 GB。 DATA - 資料檔包含已插入記憶體優化數據表的數據列。 DELTA - 差異檔案包含已刪除之數據檔中數據列的參考。 ROOT - 根檔案包含記憶體優化和原生編譯對象的系統元數據。 LARGE DATA - 大型數據檔包含插入 （n）varchar（max） 和 varbinary（max） 數據行中的值，以及記憶體優化數據表上數據行存放區索引一部分的數據行區段。 |
| internal_storage_slot | int | 內部儲存陣列中檔案的索引。 NULL 針對 ROOT 或以外的 1狀態。 |
| checkpoint_pair_file_id | uniqueidentifier | 對應的 DATA 或 DELTA 檔案。 NULL 針對 ROOT。 |
| file_size_in_bytes | bigint | 磁碟上的檔案大小。 |
| file_size_used_in_bytes | bigint | 對於仍在填入的檢查點檔案配對，下一個檢查點之後，將會更新此數據行。 |
| logical_row_count | bigint | 針對 [數據]，插入的數據列數。 針對 Delta，在考慮卸除數據表之後刪除的數據列數目。 若為 Root，則為 NULL。 |
| state | smallint | 0 - 預先建立 1 - 正在建設中 2 - 使用中 3 - 合併目標 8 - 等候記錄截斷 |
| state_desc | nvarchar(60) | PRECREATED - 已預先配置一些檢查點檔案，以將任何等候配置新的檔案減到最少，或排除在執行交易時配置新檔案的任何等候。 這些檔案的大小可能會有所不同，而且會根據工作負載的估計需求來建立。 它們不包含任何數據。 這是資料庫中具有MEMORY_OPTIMIZED_DATA檔案群組的記憶體額外負荷。 在建構下 - 這些檢查點檔案正在建構中，這表示它們會根據資料庫所產生的記錄檔記錄填入，而且尚未屬於檢查點的一部分。 ACTIVE - 這些包含先前關閉檢查點的插入/刪除數據列。 它們包含區域讀取到記憶體的數據表內容，再於資料庫重新啟動時套用事務歷史記錄的作用中部分。 我們預期這些檢查點檔案的大小大約是記憶體優化數據表記憶體內部大小的 2 倍，假設合併作業會跟上交易式工作負載。 MERGE TARGET - 合併作業的目標 - 這些檢查點檔案會儲存合併原則所識別來源檔案的合併數據列。 安裝合併之後，MERGE TARGET 就會轉換成 ACTIVE 狀態。 等候記錄截斷 - 一旦安裝合併，且 MERGE TARGET CFP 是長期檢查點的一部分，合併來源檢查點檔案就會轉換成此狀態。 需要處於此狀態的檔案，才能讓資料庫具有記憶體優化數據表的作業正確性。 例如，若要從長期檢查點復原，以及時返回。 |
| lower_bound_tsn | bigint | 檔案中交易的下限; NULL 如果狀態不在 （1， 3） 中則為 。 |
| upper_bound_tsn | bigint | 檔案中交易的上限; NULL 如果狀態不在 （1， 3） 中則為 。 |
| begin_checkpoint_id | bigint | 開始檢查點的標識碼。 |
| end_checkpoint_id | bigint | 結束檢查點的標識碼。 |
| last_updated_checkpoint_id | bigint | 更新此檔案的最後一個檢查點標識符。 |
| encryption_status | smallint | 0, 1, 2 |
| encryption_status_desc | nvarchar(60) | 0 => UNENCRYPTED 1 => 使用金鑰 1 加密 2 => 使用金鑰 2 加密。 僅適用於使用中檔案。 |
SQL Server 2014 (12.x)
下表描述 SQL Server 2014 （12.x） 的資料sys.dm_db_xtp_checkpoint_files行。
| 資料行名稱 | 類型 | 描述 |
|---|---|---|
| container_id | int | 數據或差異檔案所屬之容器的標識碼（以 FILESTREAM 類型 sys.database_files為 的檔案表示）。 在 sys.database_files 中聯file_id結 sys.database_files （Transact-SQL） 。 |
| container_guid | uniqueidentifier | 數據或差異檔案所屬容器的 GUID。 |
| checkpoint_file_id | GUID | 數據或差異檔案的標識碼。 |
| relative_file_path | nvarchar(256) | 相對於容器位置的數據或差異檔案路徑。 |
| file_type | tinyint | 0 用於數據檔。 1 用於差異檔案。 NULL 如果狀態資料列設定為 7，則為 。 |
| file_type_desc | nvarchar(60) | 檔類型：DATA_FILE、DELTA_FILE，或 NULL 狀態數據行設定為 7。 |
| internal_storage_slot | int | 內部儲存陣列中檔案的索引。 NULL 如果狀態資料列不是 2 或 3， 則為 。 |
| checkpoint_pair_file_id | uniqueidentifier | 對應的數據或差異檔案。 |
| file_size_in_bytes | bigint | 所使用的檔案大小。 NULL 如果狀態資料列設定為 5、6 或 7，則為 。 |
| file_size_used_in_bytes | bigint | 使用的檔案大小。 NULL 如果狀態資料列設定為 5、6 或 7，則為 。對於仍在填入的檢查點檔案配對，下一個檢查點之後，將會更新此數據行。 |
| inserted_row_count | bigint | 數據文件中的數據列數目。 |
| deleted_row_count | bigint | 差異檔案中已刪除的數據列數目。 |
| drop_table_deleted_row_count | bigint | 受卸除數據表影響之數據檔中的數據列數目。 當狀態數據行等於 1 時，適用於資料檔。 顯示已卸除數據表中已刪除的數據列計數。 drop_table_deleted_row_count統計數據會在卸除數據表中數據列的記憶體垃圾收集完成並取得檢查點之後進行編譯。 如果您在卸除數據表統計數據反映在此數據行之前重新啟動SQL Server，統計數據將會在復原時更新。 復原程式不會從卸除的數據表載入數據列。 卸除數據表的統計數據會在載入階段進行編譯，並在復原完成時在此數據行中報告。 |
| state | int | 0 - 預先建立 1 - 正在建設中 2 - 使用中 3 - 合併目標 4 - 合併來源 5 - 備份/HA 的必要專案 6 - 轉換至墓碑 7 - TOMBSTONE |
| state_desc | nvarchar(60) | PRECREATED - 一小組數據和差異檔案組，也稱為檢查點檔案組 （CFP） 會保留預先配置，以最小化或消除任何等候，以在執行交易時配置新檔案。 它們會以 128 MB 的數據檔大小和 8 MB 的差異檔案大小建立，但不包含任何數據。 CFP 數目會計算為邏輯處理器或排程器的數目（每個核心一個，沒有最大值），最少 8 個。 這是具有記憶體優化數據表之資料庫中的固定記憶體額外負荷。 在 [建構] 底下 - 一組 CFP，可儲存自最後一個檢查點之後新插入且可能刪除的數據列。 ACTIVE - 這些包含先前關閉檢查點的插入和刪除資料列。 這些 CFP 包含所有必要的插入和刪除資料列，才能在資料庫重新啟動時套用事務歷史記錄的作用中部分。 假設合併作業是交易式工作負載的目前狀態，這些 CFP 的大小大約是記憶體優化數據表記憶體內部大小的兩倍。 MERGE TARGET - CFP 會儲存合併原則所識別之 CFP 的合併數據列。 安裝合併之後，MERGE TARGET 就會轉換成 ACTIVE 狀態。 MERGED SOURCE - 安裝合併作業之後，來源 CFP 會標示為 MERGED SOURCE。 請注意，合併原則評估工具可能會識別多個合併，但 CFP 只能參與一個合併作業。 BACKUP/HA 必要 - 一旦安裝合併，且 MERGE TARGET CFP 是長期檢查點的一部分，合併來源 CFP 就會轉換成此狀態。 需要處於此狀態的 CFP，才能使用記憶體優化數據表來操作資料庫的正確性。 例如，若要從長期檢查點復原，以及時返回。 一旦記錄截斷點超出其交易範圍，CFP 就可以標示為垃圾收集。 在轉換至 TOMBSTONE - 記憶體內部 OLTP 引擎不需要這些 CFP，而且可以進行垃圾收集。 此狀態表示這些 CFP 正在等候背景線程將其轉換為下一個狀態，也就是 TOMBSTONE。 TOMBSTONE - 這些 CFP 正在等候檔案數據流垃圾收集行程收集垃圾。 （sp_filestream_force_garbage_collection（Transact-SQL）） |
| lower_bound_tsn | bigint | 檔案中包含的交易下限。 NULL 如果狀態資料行不是 2、3 或 4，則為 。 |
| upper_bound_tsn | bigint | 檔案中包含的交易上限。 NULL 如果狀態資料行不是 2、3 或 4，則為 。 |
| last_backup_page_count | int | 在上次備份時決定的邏輯頁面計數。 當狀態數據行設定為 2、3、4 或 5 時適用。 NULL 如果未知頁面計數，則為 。 |
| delta_watermark_tsn | int | 寫入這個差異檔案之最後一個檢查點的交易。 這是差異檔案的浮水印。 |
| last_checkpoint_recovery_lsn | nvarchar（23） | 仍然需要檔案的最後一個檢查點復原記錄序號。 |
| tombstone_operation_lsn | nvarchar（23） | 一旦tombstone_operation_lsn落後於記錄截斷記錄序號之後，就會刪除檔案。 |
| logical_deletion_log_block_id | bigint | 僅適用於狀態 5。 |
權限
需要資料庫的 VIEW DATABASE STATE 權限。
SQL Server 2022 和更新版本的權限
需要資料庫上的 VIEW DATABASE PERFORMANCE STATE 權限。
使用案例
您可以估計記憶體內部 OLTP 所使用的總記憶體，如下所示：
-- total storage used by In-Memory OLTP
SELECT SUM (file_size_in_bytes)/(1024*1024) as file_size_in_MB
FROM sys.dm_db_xtp_checkpoint_files;
若要查看依狀態和檔案類型的記憶體使用率明細，請執行下列查詢：
SELECT state_desc
, file_type_desc
, COUNT(*) AS [count]
, SUM(file_size_in_bytes) / 1024 / 1024 AS [on-disk size MB]
FROM sys.dm_db_xtp_checkpoint_files
GROUP BY state, state_desc, file_type, file_type_desc
ORDER BY state, file_type;