sys.dm_db_xtp_checkpoint_files (Transact-SQL)

Visualizza informazioni sui file del checkpoint, incluse le dimensioni del file, la posizione fisica e l'ID transazione.

Nota

Per il checkpoint corrente che non è stato chiuso, la colonna di sys.dm_db_xtp_checkpoint_files contenente gli stati per i nuovi file sarà UNDER CONSTRUCTION.Un checkpoint viene chiuso automaticamente quando il log delle transazioni aumenta di 512 MB dall'ultimo checkpoint oppure se si esegue il comando CHECKPOINT (CHECKPOINT (Transact-SQL)).

Un filegroup con ottimizzazione per la memoria utilizza internamente i file FILESTREAM per archiviare le righe inserite ed eliminate per le tabelle in memoria. Sono disponibili due tipi di file. Un file di dati include le righe inserite mentre un file differenziale contiene le righe eliminate. Ogni file di dati ha una dimensione preassegnata di 128 MB, ma può essere ingrandita nel caso di una transazione con esecuzione prolungata o durante un'unione manuale che forza la restituzione di un file di destinazione più grande di 128 MB.

Per ulteriori informazioni, vedere Creazione e gestione dell'archiviazione per gli oggetti con ottimizzazione per la memoria.

Si applica a: SQL Server (da SQL Server 2014 alla versione corrente).

Nome colonna	Tipo	Descrizione
container_id	int	ID del contenitore (rappresentato come file con tipo FILESTREAM in sys.database_files) di cui fa parte il file di dati o il file differenziale. Join con file_id in sys.database_files (Transact-SQL).
container_guid	uniqueidentifier	GUID del contenitore di cui fa parte il file di dati o il file differenziale.
checkpoint_file_id	GUID	ID del file di dati o differenziale.
relative_file_path	nvarchar(256)	Percorso del file di dati o differenziale, relativo al percorso del contenitore.
file_type	tinyint	0 per il file di dati. 1 per il file differenziale. NULL se la colonna contenente gli stati è impostata su 6.
file_type_desc	nvarchar(60)	Tipo di file: DATA_FILE, DELTA_FILE o NULL se la colonna contenente gli stati è impostata su 6.
internal_storage_slot	int	Indice del file nella matrice di archiviazione interna. NULL se la colonna contenente gli stati è impostata su 2 o 3. NULL se lo stato di una coppia di file del checkpoint è 1 -- UNDER CONSTRUCTION.
checkpoint_pair_file_id	uniqueidentifier	File di dati o differenziale corrispondente.
file_size_in_bytes	bigint	Dimensioni del file in uso. NULL se la colonna contenente gli stati è impostata su 4, 5 o 6.
file_size_used_in_bytes	bigint	Dimensioni utilizzate del file in uso. NULL se la colonna contenente gli stati è impostata su 4, 5 o 6. Per le coppie di file del checkpoint ancora da popolare, questa colonna verrà aggiornata dopo il checkpoint successivo.
inserted_row_count	bigint	Numero di righe del file di dati.
deleted_row_count	bigint	Numero di righe eliminate del file differenziale.
drop_table_deleted_row_count	bigint	Numero di righe nei file di dati interessati dall'eliminazione di una tabella. Si applica ai file di dati quando la colonna contenente gli stati è uguale a 1. Mostra i conteggi delle righe eliminate dalle tabelle eliminate. Le statistiche drop_table_deleted_row_count vengono compilate dopo il completamento del Garbage Collection in memoria delle righe delle tabelle eliminate e l'esecuzione di un checkpoint. Se si riavvia SQL Server prima che le statistiche delle tabelle eliminate vengono riflesse nella colonna, le statistiche verranno aggiornate durante il recupero. Il processo di recupero non carica le righe delle tabelle eliminate. Le statistiche delle tabelle eliminate vengono compilate durante la fase di caricamento e riportate nella colonna al termine del recupero.
stato	int	0 – PRECREATED 1 – UNDER CONSTRUCTION 2 - ACTIVE 3 – MERGE TARGET 4 – MERGED SOURCE 5 – REQUIRED FOR BACKUP/HA 6 – IN TRANSITION TO TOMBSTONE 7 – TOMBSTONE
state_desc	nvarchar(60)	PRECREATED: un set ridotto di coppie di file di dati e file differenziali, noto anche come coppie di file di checkpoint (CFP) viene mantenuto preallocato per ridurre o eliminare le attese di allocazione di nuovi file durante l'esecuzione delle transazioni. Hanno dimensioni intere, con file di dati di 128 MB e file differenziali di 8 MB, ma non contengono dati. Il numero di coppie di file di checkpoint è calcolato in base al numero di processori logici o utilità di pianificazione (uno per core, senza limiti) con un minimo di 8. Si tratta di un overhead di archiviazione fisso nei database con tabelle con ottimizzazione per la memoria. UNDER CONSTRUCTION: set di coppie di file di checkpoint in cui vengono archiviate le righe di dati appena inserite ed eventualmente eliminate dall'ultimo checkpoint. ACTIVE: contengono le righe inserite ed eliminate dai precedenti checkpoint chiusi. Queste coppie di file di checkpoint contengono tutte le righe inserite ed eliminate richieste prima dell'applicazione della parte attiva del log delle transazioni al riavvio del database. Le dimensioni di queste coppie di file di checkpoint saranno all'incirca il doppio delle dimensioni in memoria delle tabelle con ottimizzazione per la memoria, supponendo che l'operazione di unione sia corrente con il carico di lavoro transazionale. MERGE TARGET: nella coppia di file di checkpoint vengono archiviate le righe di dati consolidate dalle coppie di file di checkpoint identificate dai criteri di unione. Una volta installata l'operazione di unione, lo stato di MERGE TARGET diventa ACTIVE. MERGED SOURCE: una volta installata l'operazione di unione, le coppie di file di checkpoint di origine vengono contrassegnate come MERGED SOURCE. Si noti che l'analizzatore dei criteri di unione può identificare più operazioni di unione ma una coppia di file di checkpoint può partecipare solo a un'operazione di unione. REQUIRED FOR BACKUP/HA: una volta installata l'operazione di unione e dopo che la coppia di file di checkpoint di MERGE TARGET è diventata parte del checkpoint durevole, le coppie di file di checkpoint di origine dell'unione passano a questo stato. Le coppie di file di checkpoint in questo stato sono necessarie per la correttezza operativa del database in cui sia inclusa una tabella con ottimizzazione per la memoria. Ad esempio, per recuperare da un checkpoint durevole tornando indietro nel tempo. Una coppia di file di checkpoint può essere contrassegnata per il processo di Garbage Collection quando il punto di troncamento del log va oltre l'intervallo di transazioni. IN TRANSITION TO TOMBSTONE: queste coppie di file di checkpoint non sono necessarie per il motore di OLTP in memoria e possono essere sottoposte al processo di Garbage Collection. Questo stato indica che le coppie di file di checkpoint sono in attesa del thread in background per passare allo stato successivo, ovvero allo stato TOMBSTONE. TOMBSTONE: queste coppie di file di checkpoint sono in attesa di essere sottoposte al processo di Garbage Collection dal Garbage Collector di FILESTREAM. (sp_filestream_force_garbage_collection (Transact-SQL))
lower_bound_tsn	bigint	Limite inferiore delle transazioni incluse nel file. Null se la colonna contenente gli stati è diversa da 1.
upper_bound_tsn	bigint	Limite superiore delle transazioni incluse nel file. Null se la colonna contenente gli stati è diversa da 1.
last_backup_page_count	int	Conteggio delle pagine logiche determinato nell'ultimo backup. Si applica quando la colonna contenente gli stati è impostata su 0, 1 o 2. NULL se il conteggio delle pagine non è noto.
delta_watermark_tsn	int	Transazione dell'ultimo checkpoint che ha scritto in questo file differenziale. Si tratta della filigrana per il file differenziale.
last_checkpoint_recovery_lsn	nvarchar(23)	Numero di sequenza del file di log (LSN) di recupero dell'ultimo checkpoint per cui è ancora richiesto il file.
tombstone_operation_lsn	nvarchar(23)	Il file verrà eliminato una volta che tombstone_operation_lsn non è più sincronizzato con l'LSN di troncamento del log.
logical_deletion_log_block_id	bigint	Null, a meno che la colonna contenente gli stati non sia 6.

Autorizzazioni

È richiesta l'autorizzazione VIEW DATABASE STATE per il server.

Modalità di utilizzo comuni

È possibile stimare lo spazio di archiviazione utilizzato dalle tabelle in memoria come indicato di seguito:

-- 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

È possibile stimare lo spazio disponibile in ogni file con la query seguente.

Si noti la colonna percent_full. OLTP in memoria utilizza un approccio euristico per individuare l'ultima transazione per il file di dati. A seconda del numero di righe modificate dalla transazione varia la percentuale di completamento. Lo spazio occupato di un file di dati può variare anche quando è stato eseguito un checkpoint che ha causato la chiusura del file. È inoltre possibile che un file di dati sia senza righe. Ciò può essere causato da un checkpoint manuale dopo l'eliminazione delle righe e prima dell'aggiunta di qualsiasi riga.

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 consente fino a 8.192 coppie di file di dati e file differenziali. Per vedere il numero delle coppie attive di file di dati e file differenziali, utilizzare la query seguente.

-- 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

Per stimare la percentuale di spazio di archiviazione totale utilizzato:

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

Vedere anche

Concetti

Viste a gestione dinamica correlate alle tabelle con ottimizzazione per la memoria (Transact-SQL)