sys.dm_db_xtp_checkpoint_files (Transact-SQL)

  • 發行項

顯示有關檢查點檔案的資訊，包括檔案大小、實體位置及交易識別碼。

注意

若為未關閉的現行檢查點，新檔案的 sys.dm_db_xtp_checkpoint_files 狀態資料行會是「建構中」。當交易記錄自前次檢查點之後成長 512MB 時，或者如果您發出 CHECKPOINT 命令 (CHECKPOINT (Transact-SQL))，檢查點會自動關閉。

記憶體最佳化的檔案群組會在內部使用檔案資料流檔案儲存記憶體中資料表的插入和刪除資料列。 有兩種檔案類型： 資料檔案包含插入的資料列，差異檔案則包含刪除的資料列。 每個資料檔案的預先配置大小為 128 MB，如果有長時間執行的交易，或是進行手動合併迫使產生的目標檔案大於 128MB 時，則可能會變大。

如需詳細資訊，請參閱＜建立及管理記憶體最佳化物件的儲存體＞。

適用於：SQL Server (SQL Server 2014 至目前版本)。

資料行名稱

類型

描述

container_id

int

資料或差異檔案所屬之容器的識別碼 (以 sys.database_files 中的 FILESTREAM 類型檔案來表示)。 與 sys.database_files (Transact-SQL) 中的 file_id 聯結。

container_guid

uniqueidentifier

資料或差異檔案所屬之容器的 GUID。

checkpoint_file_id

GUID

資料或差異檔案的識別碼。

relative_file_path

nvarchar(256)

資料或差異檔案的路徑 (相對於容器的位置)。

file_type

tinyint

0 代表資料檔案。

1 代表差異檔案。

如果 state 資料行設定為 6 則為 NULL。

file_type_desc

nvarchar(60)

檔案類型：DATA_FILE、DELTA_FILE，如果 state 資料行設定為 6 則為 NULL。

internal_storage_slot

int

內部儲存體陣列中之檔案的索引。 如果 state 資料行設定為 2 或 3 則為 NULL。

如果檢查點檔案組的狀態為 1 (建構中)，則為 NULL。

checkpoint_pair_file_id

uniqueidentifier

對應的資料或差異檔案。

file_size_in_bytes

bigint

使用的檔案大小。 如果 state 資料行設定為 4、5 或 6 則為 NULL。

file_size_used_in_bytes

bigint

所使用之檔案的使用大小。 如果 state 資料行設定為 4、5 或 6 則為 NULL。

針對仍在擴展的檢查點檔案組，這個資料行會在下一個檢查點之後更新。

inserted_row_count

bigint

資料檔案中的資料列數。

deleted_row_count

bigint

差異檔案中已刪除的資料列數。

drop_table_deleted_row_count

bigint

資料檔案中受到卸除資料表影響的資料列數目。 當 state 資料行等於 1 時，適用於資料檔案。

顯示已卸除的資料表中刪除的資料列計數。 在完成已卸除之資料表中資料列的記憶體回收及取得檢查點之後，就會編譯 drop_table_deleted_row_count 統計資料。 如果您在卸除資料表統計資料反映於這個資料行之前重新啟動 SQL Server，統計資料將會在復原期間更新。 復原程序不會從已卸除的資料表中載入資料列。 載入階段會編譯已卸除之資料表的統計資料，並在復原完成時於這個資料行中報告。

state

int

0 – 已預先建立

1 – 建構中

2 - 使用中

3 – 合併目標

4 – 已合併來源

5 – 備份/高可用性所需

6 – 正在轉換為標記

7 – 標記

state_desc

nvarchar(60)

  • 已預先建立 – 又稱為檢查點檔案組 (CFP) 的一小組資料和差異檔案組會維持預先配置狀態，如此一來，當交易正在執行時，就可移除或減少任何等候配置新檔案的情形。 其為配置全額，即資料檔案大小為 128MB 且差異檔案大小為 8 MB 但不含資料。 CFP 數目是依邏輯處理器或排程器的數目來計算 (每個核心一個，無上限)，最少為 8 個。 這是具有記憶體最佳化資料表的資料庫固定的儲存負擔。

  • 建構中 – 上一次檢查點之後用來儲存新插入而且可能已刪除之資料列的 CFP 集合。

  • 使用中 - 包含來自先前已關閉之檢查點的已插入和刪除的資料列。 這些 CFP 包含了在資料庫重新啟動時套用交易記錄的使用中部分之前所需的所有已插入和刪除的資料列。 這些 CFP 的大小大約是記憶體最佳化資料表的記憶體中大小的兩倍，前提是合併作業透過交易式工作負載維持在最新狀態。

  • 合併目標 – CFP 會儲存 CFP 中由合併原則所識別的合併資料列。 一旦安裝合併之後，「合併目標」就會轉換為「使用中」狀態。

  • 已合併來源 – 一旦安裝合併作業之後，來源 CFP 就會標示為「已合併來源」。 請注意，合併原則評估工具可識別多個合併，但是 CFP 只能參與一個合併作業。

  • 備份/高可用性所需 – 一旦安裝了合併而且合併目標 CFP 為持久性檢查點的一部分時，合併來源 CFP 就會轉換到這個狀態。 包含記憶體最佳化資料表的資料庫需要這個狀態下的 CFP 來確定其作業的正確性。 例如，若要從持久性檢查點復原來回到過去。 CFP 要等到記錄截斷點移出其交易範圍後才可標示為記憶體回收。

  • 正在轉換為標記 – 記憶體中的 OLTP 引擎不需要這些 CFP，而且可以為其進行記憶體回收。 此狀態表示這些 CFP 正在等候背景執行緒將其轉換到下一個狀態，也就是「標記」。

  • 標記 – 這些 CFP 正在等候由 FILESTREAM 記憶體回收行程進行記憶體回收。 (sp_filestream_force_garbage_collection (Transact-SQL))

lower_bound_tsn

bigint

檔案中包含之交易的下限。 如果 state 資料行不是 1 則為 Null。

upper_bound_tsn

bigint

檔案中包含之交易的上限。 如果 state 資料行不是 1 則為 Null。

last_backup_page_count

int

上一次備份所決定的邏輯頁計數。 當 state 資料行設定為 0、1 或 2 時適用。 如果頁面計數未知則為 NULL。

delta_watermark_tsn

int

寫入至這個差異檔案之上一次檢查點的交易。 這是差異檔案的標準。

last_checkpoint_recovery_lsn

nvarchar(23)

仍然需要此檔案之上一次檢查點的復原記錄序號 (LSN)。

tombstone_operation_lsn

nvarchar(23)

一旦 tombstone_operation_lsn 落後記錄截斷記錄檔序號，這個檔案就會遭到刪除。

logical_deletion_log_block_id

bigint

除非 state 資料行為 6，否則為 Null。

權限

需要伺服器的 VIEW DATABASE STATE 權限。

使用案例

您可以估計記憶體中資料表使用的儲存體，如下所示：

-- total storage used by in-memory tables
select sum (file_size_in_bytes)/(1024*1024) as file_size_in_MB
   from sys.dm_db_xtp_checkpoint_files 
   where internal_storage_slot is not NULL

您可以使用下列查詢估計每個檔案中的可用空間。

請注意 percent_full 資料行。 記憶體中 OLTP 會使用啟發學習法識別資料檔案的最後一筆交易。 根據交易所變更的資料列數而定，飽和百分比會有所不同。 如果完成的檢查點造成這個檔案關閉，則資料檔案中填滿的空間也可能受到影響。 您也可能看見未包含任何資料列的資料檔案。 刪除資料列之後或加入任何資料列之前的手動檢查點可能會造成這種情況發生。

select *,
str((convert 
(float, (file_size_used_in_bytes * (1 - convert (float, deleted_rows)/inserted_rows)))/file_size_in_bytes),
25, 2) as percent_full
from
( 
  select t.internal_storage_slot, file_size_in_bytes, file_size_used_in_bytes, 
  (case when inserted_row_count= 0 then 1
         when inserted_row_count > 0 then inserted_row_count end) as inserted_rows,
(select deleted_row_count 
 from sys.dm_db_xtp_checkpoint_files 
 where internal_storage_slot = t.internal_storage_slot and file_type=1) as deleted_rows
from sys.dm_db_xtp_checkpoint_files as t
where internal_storage_slot is not NULL and file_type=0) as t_t
order by internal_storage_slot

SQL Server 最多允許 8,192 個資料檔案和差異檔案組。 若要查看作用中資料檔案和差異檔案組的數目，請使用下列查詢。

-- total number of data and delta file pairs
select count (*)
from sys.dm_db_xtp_checkpoint_files
where internal_storage_slot is not NULL and file_type = 0

若要估計所使用的總儲存空間 %：

declare @deleted_row_count int; 
declare @inserted_row_count int;
declare @effective_row_percentage float

-- get the total deleted row counts by looking at active delta files
select @deleted_row_count = SUM (deleted_row_count)
from sys.dm_db_xtp_checkpoint_files 
where state = 2 and file_type = 1

-- get total inserted row count by looking at active data files
select @inserted_row_count = SUM (inserted_row_count)
from sys.dm_db_xtp_checkpoint_files 
where state = 2 and file_type = 0

-- get the effective % of active rows after accounting for the deleted rows
-- This number represents the potential space that can be freed up if deleted are removed from storage
select @effective_row_percentage =  (1 - convert (float, @deleted_row_count)/@inserted_row_count)

-- Compute the effective usage fill factor for the storage. 
-- Effective fill factor computes the effective free space in data files
-- on average after accounting for the deleted rows 
-- This should be >= 50% otherwise it is an indication that auto-merge is not keeping up
select 
str (convert (varchar(100), ((SUM (file_size_used_in_bytes)*@effective_row_percentage)/SUM (file_size_in_bytes)) *100 ),5, 2)
as [storage usage fill factor]
from sys.dm_db_xtp_checkpoint_files
where state = 2 and file_type = 0

請參閱

概念

記憶體最佳化的資料表動態管理檢視 (Transact-SQL)