Considerazioni e limitazioni delle tabelle temporali

Si applica a: SQL Server 2016 (13.x) e versioni successive database SQL di Azure AzureSQL Managed InstanceSQL database in Microsoft Fabric

Esistono alcune considerazioni e limitazioni da tenere presenti quando si lavora con le tabelle temporali, a causa della natura del controllo delle versioni di sistema:

  • Una tabella temporale deve avere una chiave primaria definita per correlare i record compresi tra la tabella corrente e la tabella di cronologia. La tabella di cronologia non può avere una chiave primaria definita.

  • Le colonne periodo SYSTEM_TIME usate per registrare i valori ValidFrom e ValidTo devono essere definite con un tipo di dati datetime2.

  • La sintassi temporale funziona su tabelle o viste archiviate localmente nel database. Se si tratta di un oggetto remoto, come delle tabelle su un server collegato o una tabella esterna, non è possibile usare direttamente la clausola FOR o i predicati di periodo nella query.

  • Se durante la creazione della tabella di cronologia viene specificato il nome di una tabella di cronologia, è necessario specificare il nome tabella e il nome schema.

  • Per impostazione predefinita, la tabella della cronologia è PAGE compressa.

  • Se la tabella corrente è partizionata, la tabella di cronologia viene creata nel gruppo di file predefinito perché la configurazione del partizionamento non viene replicata automaticamente dalla tabella corrente nella tabella di cronologia.

  • Le tabelle temporali e di cronologia non possono utilizzare FileTable o FILESTREAM. FileTable e FILESTREAM consentono la manipolazione dei dati all'esterno di SQL Server, quindi il controllo delle versioni del sistema non può essere garantito.

  • Non è possibile creare una tabella di nodi o di archi come tabella temporale né modificarla in una tabella temporale.

  • Mentre le tabelle temporali supportano i tipi di dati BLOB, ad esempio (n)varchar(max), varbinary(max), (n)text e image, a causa delle loro dimensioni non si possono evitare costi di archiviazione significativi e implicazioni sulle prestazioni. Di conseguenza, quando si progetta il sistema è importante prestare attenzione mentre si usano questi tipi di dati.

  • La tabella di cronologia deve essere creata nello stesso database della tabella corrente. L'esecuzione di query temporali su Linked Server non è supportata.

  • La tabella di cronologia non può includere vincoli (chiave primaria, chiave esterna, vincoli di colonna o tabella).

  • Le viste indicizzate non sono supportate sulle query temporali, ovvero quelle che usano la clausola FOR SYSTEM_TIME.

  • L'opzione online (WITH (ONLINE = ON) non ha alcun effetto su ALTER TABLE ALTER COLUMN in una tabella temporale con controllo delle versioni di sistema. La colonna ALTER non viene eseguita come operazione online, indipendentemente dal valore che è stato specificato per l'opzione ONLINE.

  • Le istruzioni INSERT e UPDATE non possono fare riferimento alle colonne del periodo SYSTEM_TIME. Eventuali tentativi di inserire valori direttamente in tali colonne vengono bloccati.

  • TRUNCATE TABLE non è supportato mentre SYSTEM_VERSIONING è ON.

  • La modifica diretta dei dati in una tabella di cronologia non è consentita.

  • Per non invalidare la logica DML, i trigger INSTEAD OF non sono consentiti né per la tabella corrente né per quella di cronologia. I trigger AFTER sono consentiti solo nella tabella corrente. Questi trigger sono bloccati nella tabella di cronologia per evitare di invalidare la logica DML.

  • L'utilizzo di tecnologie di replica è limitato:

    • Gruppi di disponibilità: completamente supportati

    • Acquisizione dei dati modificati e rilevamento delle modifiche: Supportato solo per la tabella corrente

    • Snapshot e replica transazionale: supportata solo per un singolo server di pubblicazione senza attivazione di tabella temporale e per un sottoscrittore con attivazione di tabella temporale. L'uso di più sottoscrittori non è supportato a causa della dipendenza dall'orologio del sistema locale, che può portare a dati temporali incoerenti. In questo caso, il server di pubblicazione viene usato per un carico di lavoro OLTP, mentre il sottoscrittore viene usato per la ripartizione di report, inclusa l'esecuzione di query AS OF. All'avvio dell'agente di distribuzione viene aperta una transazione che viene mantenuta aperta fino a quando l'agente di distribuzione non è interrotto. ValidFrom e ValidTo vengono popolati con il momento di avvio della prima transazione avviata dall'agente di distribuzione. Potrebbe essere preferibile eseguire l'agente di distribuzione in base a una pianificazione anziché usare il comportamento predefinito di esecuzione continua, se per l'applicazione o l'organizzazione è importante ValidFrom e ValidTo vengano popolati con un'ora vicina all'ora di sistema corrente. Per altre informazioni, vedere scenari di utilizzo tabelle temporali.

    • Replica di tipo merge: non supportata per le tabelle temporali

  • Le query normali influiscono solo sui dati della tabella corrente. Per eseguire query sui dati della tabella di cronologia, è necessario usare le query temporali. Per ulteriori informazioni, vedere Eseguire query sui dati in una tabella temporale con controllo delle versioni gestito dal sistema.

  • Una strategia di indicizzazione ottimale include un indice columnstore clusterizzato e/o un indice rowstore B-tree nella tabella corrente, nonché un indice columnstore clusterizzato nella tabella di cronologia, per ottimizzare lo spazio di archiviazione e le prestazioni. Se si crea o si usa una tabella di cronologia propria, è consigliabile creare questo tipo di indice costituito da colonne periodo a partire dalla fine della colonna periodo. Questo indice velocizza l'esecuzione di query temporali e le query che fanno parte della verifica della coerenza dei dati. La tabella di cronologia predefinita presenta un indice rowstore cluster creato in base alle colonne periodo (inizio, fine). Come requisito minimo, è consigliato un indice rowstore non clusterizzato.

  • Le proprietà o gli oggetti seguenti non vengono replicati dalla tabella corrente alla tabella di cronologia quando si crea quest'ultima:

    • Definizione del periodo
    • Definizione di identità
    • Indexes
    • Statistics
    • Verifica dei vincoli
    • Triggers
    • Configurazione del partizionamento
    • Permissions
    • Predicati di sicurezza a livello di riga

  • Una tabella di cronologia non può essere configurata come tabella corrente in una catena di tabelle di cronologia.

Note

Nella documentazione viene usato in modo generico il termine albero B in riferimento agli indici. Negli indici rowstore, il motore di database implementa un albero B+. Ciò non si applica a indici columnstore o a indici in tabelle ottimizzate per la memoria. Per altre informazioni, vedere Architettura e guida per la progettazione degli indici SQL Server e Azure SQL.

Contenuti correlati

  • Last updated on