Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Si applica a:
SQL Server
Viene descritto il funzionamento delle tabelle FileTable con altre caratteristiche di SQL Server.
Gruppi di disponibilità Always On e FileTables
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 non nelle repliche secondarie leggibili.
Nota
Dopo un failover, tutte le funzionalità FILESTREAM sono supportate. I dati FILESTREAM sono accessibili sia nelle repliche secondarie leggibili sia nella nuova 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 ai dati FILESTREAM o FileTable tramite le API del file system deve avvenire utilizzando i VNN anziché i nomi di computer. Per altre informazioni, vedere Usare FILESTREAM e FileTable con i gruppi di disponibilità AlwaysOn.
Partizionamento e tabelle FileTable
Il partizionamento non è supportato nelle tabelle FileTable. Con il supporto per più filegroup FILESTREAM, è possibile gestire i problemi di scalabilità verticale puri senza dovere ricorrere al partizionamento nella maggior parte degli scenari (a differenza di FILESTREAM SQL 2008).
Replicazione e FileTable
La replica e le funzionalità correlate, quali replica transazionale, replica di tipo merge, Change Data Capture e rilevamento delle modifiche, non sono supportate con le tabelle FileTable.
Semantica delle transazioni e tabelle FileTable
applicazioni Windows
Poiché le applicazioni di Windows non riconoscono le transazioni di database, le operazioni di scrittura di Windows non forniscono le proprietà ACID di una transazione di database. Pertanto, i rollback delle transazioni e il ripristino non sono possibili nelle operazioni di aggiornamento di Windows.
Applicazioni Transact-SQL
Per le applicazioni Transact-SQL eseguite nella colonna FILESTREAM (file_stream) in una tabella FileTable, la semantica dell'isolamento è la stessa utilizzata con il tipo di dati FILESTREAM in una normale tabella utente.
Notifiche di query e FileTable
La query non può contenere un riferimento alla colonna FILESTREAM nella tabella FileTable, nella clausola WHERE o in qualunque altra parte della query.
SELECT INTO e FileTables
le istruzioni SELECT INTO da una tabella FileTable non propagano la semantica della tabella FileTable nella tabella di destinazione creata (come le colonne FILESTREAM in una normale tabella). Tutte le colonne della tabella di destinazione si comportano proprio come normali colonne. A tali colonne non è associata alcuna semantica della tabella FileTable.
Trigger e FileTables
Trigger DDL (Data Definition Language)
Non vi sono considerazioni speciali relative ai trigger DDL con tabelle FileTable. I trigger DDL normali vengono 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 evento effettivi, che includono il testo del comando DDL e altre informazioni, chiamando la funzione EVENTDATA(). Non vi sono nuovi eventi o modifiche per lo schema Eventdata esistente.
Trigger DML (Data Manipulation Language)
Queste restrizioni vengono applicate durante l'operazione DDL per creare trigger.
Le FileTable non supportano 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 supportano i trigger AFTER per le operazioni DML.
I trigger definiti in una tabella FileTable non sono in grado di aggiornare alcuna tabella FileTable (inclusa la tabella FileTable padre). Questa restrizione ha come principale obiettivo di impedire che un trigger crei un conflitto di blocco con i blocchi controllati dall'accesso al file system nella stessa transazione.
Accesso non transazionale e relativi effetti sui trigger
Quando in un database è consentito l'accesso non transazionale per l'aggiornamento, è possibile eseguire un aggiornamento sul posto dei dati FILESTREAM in qualsiasi tabella, inclusa la tabella FileTable del database. Grazie a questa possibilità, l'immagine precedente del contenuto di FILESTREAM potrebbe non essere disponibile per l'utilizzo da parte del trigger.
Per operazioni di aggiornamento non transazionali tramite file system, in SQL Server viene creata una transazione interna per acquisire l'operazione CloseHandle ed possibile attivare qualsiasi trigger DML definito come parte di tale transazione. Benché non impedito, un rollback, ad esempio una transazione all'interno del corpo del trigger, non consente di eseguire il rollback delle modifiche apportate a FILESTREAM. Tale operazione di rollback può inoltre impedire l'attivazione dei trigger UPDATE, anche qualora il contenuto di FILESTREAM sia stato modificato.
Oltre a questi effetti, per i trigger nelle tabelle FileTable è necessario gestire altri due comportamenti:
In caso di operazioni di aggiornamento non transazionali nella tabella FileTable tramite il file system, è possibile che il contenuto di FILESTREAM venga bloccato in modo esclusivo da altre operazioni Win32 e non sia accessibile per operazioni di lettura/scrittura tramite il corpo del trigger. In tali casi, qualsiasi tentativo di accedere al contenuto di FILESTREAM all'interno del corpo del trigger può generare un errore di violazione della condivisione. È opportuno progettare i trigger in modo che siano in grado di gestire tali errori in modo appropriato.
L'immagine AFTER di FILESTREAM può non essere stabile, perché in alcuni casi può essere contemporaneamente soggetta a scrittura da parte di altri aggiornamenti non transazionali, 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 parte di un amministratore oppure un arresto anomalo del database, non comporta l'esecuzione dei trigger utente durante le operazioni di recupero, anche se il contenuto di FILESTREAM potrebbe essere stato modificato dall'applicazione Win32 terminata in modo anomalo.
Viste e FileTables
Visualizzazioni
È possibile creare una vista in una tabella FileTable come in qualsiasi altra tabella. A una vista creata in una tabella FileTable, tuttavia, si applicano le considerazioni seguenti:
Le viste non possono avere alcuna semantica FileTable. ad esempio il comportamento delle colonne nella vista, incluse le colonne degli attributi dei file, sarà quello di normali colonne della vista senza alcuna semantica speciale. Lo stesso vale per le righe che rappresentano file/directory.
Le viste possono essere aggiornabili in base alla semantica della "vista aggiornabile", ma i vincoli della tabella sottostante possono rifiutare gli aggiornamenti proprio come nella tabella.
È possibile visualizzare il percorso per un file nella vista aggiungendolo come colonna esplicita nella vista. Ad 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/calcolate persistenti che dipendono dalle colonne FILESTREAM. Questo comportamento è lo stesso anche per le viste definite nella tabella FileTable.
Isolamento dello snapshot e tabelle FileTable
Read Committed Snapshot Isolation (RCSI) e Snapshot Isolation (SI) si basano sulla possibilità di avere disponibile un'istantanea dei dati per le operazioni di lettura, anche quando sui dati sono in corso operazioni di aggiornamento. Le tabelle FileTable, tuttavia, consentono l'accesso in scrittura non transazionale ai dati FILESTREAM. Di conseguenza, sussistono le restrizioni seguenti per queste funzionalità in database che contengono tabelle FileTable:
Un database che contiene FileTable può essere modificato per attivare RCSI/SI.
Quando non_transactional è impostato su FULL per il database, una transazione in esecuzione con RCSI o SI presenta il comportamento seguente:
Non viene completata alcuna lettura Transact-SQL della colonna file_stream della tabella FileTable. Le operazioni INSERT e UPDATE sulla colonna continuano ad avere esito positivo, purché non leggano dalla colonna file_stream.
Se l'istruzione Transact-SQL specifica gli hint di tabella READCOMMITTEDLOCK, le operazioni di lettura riescono e acquisiscono blocchi sulle righe, anziché utilizzare il controllo delle versioni delle righe.
Anche le richieste transazionali di apertura di FileStream Win32 non riescono.
L'accesso Win32 non transazionale a FileTable riesce. Tutte le query interne eseguite da FileTable non sono influenzate.
L'indicizzazione full-text riesce sempre, indipendentemente dalle opzioni del database (READ_COMMITTED_SNAPSHOT o ALLOW_SNAPSHOT_ISOLATION).
Database secondari leggibili
Ai database secondari leggibili si applicano le stesse considerazioni degli snapshot, come descritto nella sezione precedente, Isolamento dello snapshot e tabelle FileTable.
Database indipendenti e tabelle FileTable
La funzionalità FILESTREAM da cui dipende la funzionalità FileTable richiede alcuni interventi di configurazione all'esterno del database. Pertanto, un database che usa FILESTREAM o FileTable non è completamente contenuto.
È possibile impostare il contenimento del database su PARTIAL se si desidera utilizzare alcune funzionalità dei database contenuti, ad esempio gli utenti contenuti. In tal caso, tuttavia, alcune impostazioni del database non sono contenute nel database e non vengono spostate automaticamente quando viene spostato il database.