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

Quando lavori con tabelle temporali, tieni presente le seguenti considerazioni e limitazioni dovute alla natura del sistema versionato:

  • Una tabella temporale deve avere una chiave primaria definita, per correlare i record tra la tabella corrente e la tabella storica. 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 della storia viene creata sul file group predefinito perché la configurazione di partizionamento non viene replicata automaticamente dalla tabella corrente alla tabella storica.

  • 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. Quando progetti il tuo sistema, fai attenzione quando usi 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 nelle query temporali, cioè quelle che utilizzano 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 evitare di invalidare la logica del linguaggio di manipolazione dei dati (DML), INSTEAD OF i trigger non sono permessi né sulla tabella corrente né sulla tabella storica. 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 e tracciamento dei dati delle modifiche: supportato solo nella 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 utilizzato per un carico di lavoro di elaborazione delle transazioni online (OLTP), mentre il sottoscrittore viene usato per demandare il carico delle attività di reporting (inclusa l'esecuzione di AS OF query). Quando l'agente di distribuzione inizia, apre una transazione che resta aperta fino a quando l'agente di distribuzione non si ferma. ValidFrom e ValidTo vengono popolati con l'ora di inizio 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.

    • Replicazione di fusione: 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 oppure un indice rowstore B-tree sulla tabella corrente e un indice columnstore clusterizzato sulla tabella di cronologia, per ottimizzare lo spazio di archiviazione e le prestazioni. Se crei o usi una tua tabella storica, crea questo tipo di indice composto da colonne di periodo che iniziano con la colonna di fine periodo. Questo indice accelera le query temporali e le query che fanno parte del controllo di coerenza dei dati. La tabella di cronologia predefinita crea un indice rowstore clusterizzato basato sulle colonne del periodo (fine, inizio). Al minimo, usa 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 di periodo
    • Definizione di identità
    • Indexes
    • Statistics
    • Verifica dei vincoli
    • Trigger
    • Configurazione del partizionamento
    • Permissions
    • Predicati di sicurezza a livello di riga

  • Non puoi configurare una tabella di cronologia come la tabella attuale in una catena di tabelle di storia.

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 ulteriori informazioni, vedi Guida sulla progettazione e sull'architettura degli indici SQL Server e Azure SQL.

Contenuti correlati

  • Last updated on