Compatibilità fileTable con altre funzionalità di SQL Server

Descrive il funzionamento delle tabelle FileTable con altre funzionalità di SQL Server.

Gruppi di disponibilità AlwaysOn e tabelle FileTable

Quando il database che contiene dati FILESTREAM o FileTable appartiene a un gruppo di disponibilità AlwaysOn:

• La funzionalità FileTable è parzialmente supportata dai gruppi di disponibilità AlwaysOn. Dopo un failover, i dati fileTable sono accessibili nella replica primaria, ma i dati di FileTable non sono accessibili nelle repliche secondarie leggibili.

  Annotazioni

  Si noti che, dopo un failover, tutte le funzionalità FILESTREAM sono supportate. I dati FILESTREAM sono accessibili sia nelle repliche secondarie leggibili che nella nuova replica primaria.

• Le funzioni FILESTREAM e FileTable accettano o restituiscono nomi di rete virtuale anziché nomi computer. Per altre informazioni su queste funzioni, vedere Funzioni FileStream e FileTable (Transact-SQL).

• Ogni accesso a dati FILESTREAM o FileTable tramite le API del file system deve utilizzare i VNN anziché nomi dei computer. Per altre informazioni, vedere FILESTREAM e FileTable con gruppi di disponibilità AlwaysOn (SQL Server).

Partizionamento e tabelle FileTable

Il partizionamento non è supportato nelle tabelle FileTable. Con il supporto di più gruppi di fileSTREAM, i problemi di scalabilità orizzontale puri possono essere gestiti senza dover ricorrere al partizionamento nella maggior parte degli scenari (a differenza di SQL 2008 FILESTREAMs).

Replicazione e FileTable

La replica e le funzionalità correlate (tra cui la replica transazionale, la replica di tipo merge, change data capture e il rilevamento delle modifiche) non sono supportate con le tabelle FileTable.

Semantica delle transazioni e FileTables

Applicazioni Windows
Le applicazioni Windows non comprendono le transazioni di database, pertanto le operazioni di scrittura di Windows non forniscono le proprietà ACID di una transazione di database. Pertanto, i rollback transazionali e il ripristino non sono possibili con le operazioni di aggiornamento di Windows.

applicazioniTransact-SQL
Per le applicazioni TSQL che riguardano la colonna FILESTREAM (file_stream) in una tabella FileTable, la semantica di isolamento è identica a quella del tipo di dati FILESTREAM in una normale tabella utente.

Notifiche di query e FileTables

La query non può contenere riferimenti alla colonna FILESTREAM nella tabella FileTable, nella clausola WHERE o in qualsiasi altra parte della query.

SELECT INTO e FileTables

Le istruzioni SELECT INTO da una FileTable non propagano la semantica di FileTable nella tabella di destinazione creata (esattamente come le colonne FILESTREAM in una tabella regolare). Tutte le colonne della tabella di destinazione si comportano esattamente come le colonne normali. Non ci sarà alcuna semantica di FileTable associata a loro.

Trigger e FileTable

Trigger di DDL (Data Definition Language)
Non esistono considerazioni speciali per i trigger DDL con tabelle FileTable. I trigger DDL normali verranno attivati per le operazioni di creazione/modifica del database, nonché per le operazioni CREATE/ALTER TABLE per le tabelle FileTable. I trigger possono recuperare i dati effettivi dell'evento che includono il testo del comando DDL e altre informazioni chiamando la funzione EVENTDATA(). Non sono presenti nuovi eventi o modifiche allo schema Eventdata esistente.

Trigger di DML (Data Manipulation Language)
Queste restrizioni verranno applicate durante l'operazione DDL per creare trigger.

• Le tabelle FileTable non supporteranno i trigger INSTEAD OF per le operazioni DML. Si tratta di una restrizione esistente per tutte le tabelle che contengono colonne FILESTREAM.

• Le tabelle FileTable supporteranno i trigger AFTER per le operazioni DML.

• I trigger definiti in una tabella FileTable non possono aggiornare alcuna tabella FileTable (inclusa la tabella FileTable padre). Questa restrizione esiste principalmente per impedire a un trigger di entrare in conflitti di blocco con i blocchi mantenuti dall'accesso al file system nella stessa transazione.

Accesso non transazionale e i relativi effetti sui trigger

• Quando l'accesso agli aggiornamenti non transazionali è consentito in un database, è possibile eseguire l'aggiornamento sul posto dei dati FILESTREAM in qualsiasi tabella, inclusa la tabella FileTable in tale database. A causa di questa possibilità, l'immagine precedente del contenuto FILESTREAM potrebbe non essere disponibile per l'uso da parte del trigger.

• Per le operazioni di aggiornamento non transazionali tramite file system, SQL Server creerà una transazione interna per acquisire l'operazione CloseHandle e gli eventuali trigger DML definiti possono essere attivati come parte di tale transazione. Un rollback di una transazione di questo tipo all'interno del corpo del trigger, pur non essendo impedito, non annulla le modifiche apportate al FILESTREAM. Tale rollback può anche impedire l'attivazione dei trigger di aggiornamento, anche se il contenuto DI FILESTREAM potrebbe essere stato modificato.

• Oltre a questi effetti, i trigger sulle tabelle FileTable devono gestire due comportamenti aggiuntivi

  • Nel caso di operazioni di aggiornamento non transazionali su FileTable tramite il file system, è possibile che il contenuto FILESTREAM possa essere bloccato esclusivamente da altre operazioni Win32 e potrebbe non essere accessibile per la lettura/scrittura tramite il corpo del trigger. In questi casi, qualsiasi tentativo di accesso al contenuto FILESTREAM all'interno del corpo del trigger può generare un errore di "Violazione di condivisione". I trigger devono essere progettati per gestire tali errori in modo appropriato.

  • L'immagine AFTER di FILESTREAM potrebbe non essere stabile perché in alcuni casi potrebbe essere scritta attivamente da altri aggiornamenti non transazionali contemporaneamente (a causa delle modalità di condivisione consentite nell'accesso al file system).

• La terminazione anomala degli handle Win32, ad esempio l'eliminazione esplicita degli handle Win32 da un amministratore o da un arresto anomalo del database, non eseguirà trigger utente durante le operazioni di ripristino, anche se il contenuto FILESTREAM potrebbe essere stato modificato dall'applicazione Win32 terminata in modo anomalo.

Visualizzazioni e tabelle FileTable

Visualizzazioni
È possibile creare una vista in una tabella FileTable come in qualsiasi altra tabella. Tuttavia, le considerazioni seguenti si applicano a una visualizzazione creata in una tabella FileTable:

• La vista sarà priva di qualsiasi semantica FileTable. Ad esempio, le colonne nella vista (incluse le colonne attributo file) si comportano esattamente come le colonne di visualizzazione normali senza una semantica speciale e lo stesso vale per le righe che rappresentano File/directory.

• La vista può essere aggiornabile in base alla semantica "aggiornabile", ma i vincoli di tabella sottostanti possono rifiutare gli aggiornamenti esattamente come nella tabella.

• Il percorso del file per un file può essere visualizzato nella vista aggiungendolo come colonna esplicita nella vista. Per esempio:

  CREATE VIEW MP3FILES AS SELECT column1, column2, ..., GetFileNamespacePath() AS PATH, column3,... FROM Documents

Viste indicizzate
Attualmente le viste indicizzate non possono includere colonne FILESTREAM o colonne calcolate/persistenti calcolate che dipendono dalle colonne FILESTREAM. Questo comportamento rimane invariato anche con le visualizzazioni definite nella tabella FileTable.

Isolamento dello snapshot e FileTables

Read Committed Snapshot Isolation (RCSI) e Isolamento snapshot (SI) si basano sulla possibilità di avere uno snapshot dei dati disponibili per i lettori anche quando si verificano operazioni di aggiornamento sui dati. Le tabelle FileTable consentono tuttavia l'accesso in scrittura non transazionale ai dati Filestream. Di conseguenza, le restrizioni seguenti si applicano all'uso di queste funzionalità nei database che contengono tabelle FileTable:

• È possibile modificare un database che contiene tabelle FileTable per abilitare RCSI/SI.

• Quando l'accesso non_transactional è impostato su FULL per il database, una transazione eseguita secondo RCSI o SI ha il comportamento seguente:

  • Le Transact-SQL letture della colonna FileTable file_stream hanno esito negativo. INSERT e UPDATE alla colonna hanno ancora esito positivo, purché non vengano letti dalla colonna file_stream.

  • Se l'istruzione Transact-SQL specifica gli hint di tabella READCOMMITTEDLOCK, le operazioni di lettura hanno esito positivo e prendono blocchi sulle righe anziché usare il versionamento delle righe.

  • Anche le richieste di apertura FileStream Win32 transazionate hanno esito negativo.

  • L'accesso Win32 non transazionato a FileTable ha esito positivo. Tutte le query interne eseguite da FileTable non sono influenzate.

  • L'indicizzazione full-text riesce sempre, indipendentemente dalle opzioni del database impostate (READ_COMMITTED_SNAPSHOT o ALLOW_SNAPSHOT_ISOLATION).

Database secondari leggibili

Le stesse considerazioni si applicano ai database secondari leggibili, così come agli snapshot, come descritto nella sezione precedente, Snapshot Isolation e FileTables.

Database indipendenti e tabelle FileTable

La funzionalità FILESTREAM da cui dipende la funzionalità FileTable richiede una configurazione esterna al database. Pertanto, un database che utilizza FILESTREAM o FileTable non è completamente contenuto.

È possibile impostare il contenimento del database su PARTIAL se si desidera utilizzare determinate funzionalità di database indipendenti, ad esempio utenti indipendenti. In questo caso, tuttavia, è necessario tenere presente che alcune impostazioni del database non sono contenute nel database e non vengono spostate automaticamente quando il database viene spostato.

Vedere anche

Gestire FileTables