Considerazioni e limitazioni delle tabelle temporali

  • Articolo

Si applica a: SQL Server 2016 (13.x) e versioni successive Database SQL diIstanza gestita di SQL di Azure

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 e 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 di cronologia è *PAGE compresso.

  • 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 usare FileTable o FILESTREAM, poiché FileTable e FILESTREAM consentono la manipolazione dei dati all'esterno di SQL Server e pertanto il controllo delle versioni del sistema non può essere garantito.

  • Non è possibile creare una tabella nodi o archi come tabella temporale o modificarla in 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'operazione online (WITH (ONLINE = ON) non influisce su ALTER TABLE ALTER COLUMN in caso di 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 a colonne 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.

  • ON DELETE CASCADE e ON UPDATE CASCADE non sono consentiti nella tabella corrente. In altre parole, quando la tabella temporale fa riferimento alla tabella nella relazione di chiave esterna (corrispondente a parent_object_id in sys.foreign_key) non sono consentite le opzioni CASCADE. Per risolvere questa limitazione, usare la logica dell'applicazione oppure i trigger AFTER per mantenere la coerenza su eliminazione nella tabella di chiave primaria (corrispondente a referenced_object_id in sys.foreign_key). Se la tabella di chiave primaria è temporale e la tabella di riferimento non lo è, questa limitazione non si applica.

  • 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 per la tabella corrente. 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

    • Change data capture e rilevamento modifiche: supportati 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 poiché potrebbe comportare dati temporali incoerenti a causa della dipendenza dall'orologio di sistema locale. 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. Può 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 Esecuzione di query sui dati in una tabella temporale con controllo delle versioni di sistema.

  • Una strategia di indicizzazione ottimale include un indice columnstore cluster e/o un indice rowstore con albero B nella tabella corrente, oltre a un indice columnstore cluster nella tabella di cronologia per dimensioni di archiviazione e prestazioni ottimali. 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 allo scopo di velocizzare non solo l'esecuzione di query temporali, ma anche le query incluse nella verifica di coerenza dei dati. La tabella di cronologia predefinita presenta un indice rowstore cluster creato in base alle colonne periodo (inizio, fine). Come minimo, è consigliabile un indice rowstore non cluster.

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

    • Definizione di periodo
    • Definizione di identità
    • Indici
    • Statistiche
    • Controlla vincoli
    • Trigger
    • Configurazione del partizionamento
    • Autorizzazioni
    • 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.

Nota

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

Passaggi successivi