Configurazione di SQL Server per FILESTREAM
annuncio pubblicitario
Articolo tecnico su SQL Server Autore: Paul S. Randal (SQLskills.com) Revisori tecnici: Alexandru Chirica, Arkadi Brjazovski, Prem Mehra, Joanna Omel, Mike Ruthruff, Robin Dhamankar Data di pubblicazione: ottobre 2008 Contesto di applicazione: SQL Server 2008 Riepilogo: in questo white paper viene descritta la funzionalità FILESTREAM di SQL Server 2008, che consente di archiviare i dati BLOB e di accedervi in modo efficiente utilizzando una combinazione di SQL Server 2008 e del file system NTFS. Vengono illustrate le possibili opzioni per l'archiviazione BLOB, la configurazione di Windows e SQL Server per l'utilizzo dei dati FILESTREAM, alcune considerazioni per combinare FILESTREAM con altre funzionalità, nonché alcune informazioni dettagliate su aspetti dell'implementazione, quali il partizionamento e le prestazioni. Questo white paper è destinato ad architetti, professionisti IT e amministratori di database incaricati della valutazione o dell'implementazione di FILESTREAM. Si presuppone che i lettori abbiano familiarità con Windows e SQL Server e dispongano di una conoscenza di base dei concetti relativi ai database, ad esempio le transazioni. Introduzione La società moderna è caratterizzata da un'elevatissima velocità di generazione dei dati, con la conseguente necessità di individuare modi efficienti e controllati di archiviazione e accesso. La scelta tra le varie tecnologie disponibili per soddisfare tale necessità dipende spesso dalla natura dei dati da archiviare, che possono essere strutturati, semistrutturati o non strutturati: I dati strutturati sono dati che possono essere facilmente archiviati in uno schema relazionale, ad esempio i dati di vendita di una società. Tali dati possono essere archiviati in un database con una tabella di informazioni sui prodotti venduti dalla società, un'altra di informazioni sui clienti e un'altra con i dettagli delle vendite dei prodotti ai clienti. È possibile accedere ai dati e modificarli utilizzando un linguaggio di query avanzato quale Transact-SQL. I dati semistrutturati sono dati conformi a uno schema approssimativo ma non adatti a essere archiviati in un set di tabelle di database, ad esempio i dati in cui ogni punto dati potrebbe avere attributi radicalmente diversi. I dati semistrutturati vengono spesso archiviati utilizzando il tipo di dati xml nel software di database di Microsoft® SQL Server® e ne viene eseguito l'accesso utilizzando un linguaggio di query basato su elementi, quale XQuery. I dati non strutturati possono non adattarsi ad alcuno schema (ad esempio dati crittografati) o possono essere costituiti da grandi quantità di dati binari (di molti MB o anche GB) apparentemente privi di schema, ma in realtà con uno schema insito di tipo molto semplice, ad esempio file di immagine, video in streaming o clip audio. I dati binari sono in questo caso dati che possono avere qualsiasi valore, non solo quelli esplicitamente digitati. Questi valori di dati sono comunemente noti come oggetti binari di grandi dimensioni o, più semplicemente, BLOB. In questo white paper viene descritta la funzionalità FILESTREAM di SQL Server 2008, che consente di archiviare i dati BLOB e di accedervi in modo efficiente utilizzando una combinazione di SQL Server 2008 e del file system NTFS. Vengono illustrate la funzionalità FILESTREAM, le possibili opzioni per l'archiviazione BLOB, la configurazione del sistema operativo Windows® e di SQL Server per l'utilizzo dei dati FILESTREAM, alcune considerazioni per combinare FILESTREAM con altre funzionalità, nonché informazioni dettagliate su aspetti dell'implementazione, quali partizionamento e prestazioni. Opzioni per l'archiviazione BLOB Mentre i dati strutturati e semistrutturati possono essere facilmente archiviati in un database relazionale, la scelta della posizione di archiviazione dei dati non strutturati o BLOB è più complicata. Nel decidere dove archiviare i dati BLOB è opportuno tenere presenti le esigenze indicate di seguito. 2 Prestazioni: il modo in cui i dati verranno utilizzati è fondamentale. Se è richiesto un accesso tramite flusso, l'archiviazione dei dati in un database di SQL Server può risultare più lenta rispetto all'archiviazione in una posizione esterna come il file system NTFS. Quando si utilizza l'archiviazione nel file system, i dati vengono letti dal file e passati all'applicazione client (direttamente o tramite ulteriore buffering). Quando vengono archiviati in un database di SQL Server, i dati BLOB devono prima essere letti nella memoria di SQL Server (il pool di buffer) e quindi passati tramite una connessione client all'applicazione client. Questo significa non solo che i dati vengono sottoposti a un ulteriore passaggio di elaborazione, ma anche che la memoria di SQL Server viene inutilmente "inquinata" dai dati BLOB, con la possibilità di causare ulteriori problemi di prestazioni alle operazioni di SQL Server. Sicurezza: i dati sensibili il cui accesso deve essere strettamente controllato possono essere archiviati in un database, dove la sicurezza può essere gestita tramite i consueti controlli di accesso di SQL Server. Se gli stessi dati vengono archiviati nel file system, è necessario implementare metodi di sicurezza diversi, ad esempio gli elenchi di controllo di accesso (ACL). Dimensioni dei dati: in base alla ricerca citata più avanti in questo white paper, per i BLOB inferiori a 256 kilobyte (KB) (come le icone widget) è preferibile l'archiviazione in un database, mentre per i BLOB superiori a 1 megabyte (MB) è preferibile l'archiviazione all'esterno del database. Per i BLOB di dimensioni comprese tra 256 KB e 1 MB, la soluzione di archiviazione più efficiente dipende dal rapporto lettura/scrittura dei dati e dalla frequenza di "sovrascrittura". Se si archiviano i dati BLOB esclusivamente nel database, ad esempio utilizzando il tipo di dati varbinary (max), è necessario rispettare il limite di 2 gigabyte (GB) per BLOB. Accesso client: il protocollo utilizzato dal client per accedere ai dati di SQL Server, ad esempio ODBC, potrebbe non essere adatto ad applicazioni quali lo streaming di file video di grandi dimensioni. In questo caso potrebbe essere necessario archiviare i dati nel file system. Semantica transazionale: se ai dati BLOB sono associati dati strutturati che verranno archiviati nel database, le modifiche ai dati BLOB dovranno essere conformi alla semantica transazionale in modo che i due set di dati rimangano sincronizzati. Ad esempio, se viene eseguito il rollback di una transazione di creazione di dati BLOB e di una riga in una tabella di database, il rollback deve essere eseguito sia per la creazione dei dati BLOB che per la creazione della riga di tabella. Questo meccanismo può diventare molto complesso se i dati BLOB sono archiviati nel file system senza collegamento al database. Frammentazione dei dati: operazioni frequenti di aggiornamento e sovrascrittura provocano lo spostamento dei BLOB nell'ambito dei file di database di SQL Server o del file system, a seconda di dove siano archiviati. In questo caso, se i BLOB sono di grandi dimensioni possono diventare frammentati, ovvero non archiviati in una parte contigua del disco. Il problema della frammentazione può essere gestito più facilmente tramite il file system che tramite SQL Server. Facilità di gestione: una soluzione che include più tecnologie non integrate è più complessa e costosa di una soluzione integrata in termini di gestione. Costo: il costo della soluzione di archiviazione dipende dalla tecnologia utilizzata. Le considerazioni precedenti relative alle dimensioni e alla frammentazione sono basate sul noto articolo di Microsoft Research in cui si discute se sia meglio archiviare gli oggetti di grandi dimensioni (BLOB) in un database o in un file system (autori: Gray, Van Ingen e Sears). Il documento contiene ulteriori informazioni sui possibili compromessi e può essere scaricato al seguente indirizzo: http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2006-45 Sono disponibili diverse soluzioni per l'archiviazione BLOB, ognuna delle quali presenta vantaggi e svantaggi rispetto alle esigenze appena descritte. Nella tabella seguente vengono confrontate tre opzioni comuni per archiviare dati BLOB, inclusa la funzionalità FILESTREAM, in SQL Server 2008. Aspetto confrontato Dimensioni massime BLOB Prestazioni di flusso di BLOB di grandi dimensioni Sicurezza File server/file system Dimensioni volume NTFS Eccellenti ACL manuali Soluzione di archiviazione SQL Server (tramite FILESTREAM varbinary(max)) Da 2 GB a 1 byte Dimensioni volume NTFS Scarse Eccellenti Integrata Integrata + ACL automatici Basso Integrata Coerenza a livello di dati Più semplici Costo per GB Basso Alto Facilità di gestione Scarsa Integrata Integrazione con dati Difficile Coerenza a livello strutturati di dati Sviluppo Più complessi Più semplici e distribuzione di applicazioni Recupero dalla Eccellente Scarso Eccellente frammentazione dei dati Prestazioni di Eccellenti Moderate Scarse aggiornamenti piccoli e frequenti Tabella 1. Confronto delle tecnologie di archiviazione BLOB prima di SQL Server 2008 3 FILESTREAM è l'unica soluzione che offre coerenza transazionale per dati strutturati e non strutturati, nonché gestione integrata, sicurezza, costi contenuti e prestazioni di flusso eccellenti. L'efficacia della soluzione si basa sulla separazione dell'archiviazione, nei file di database per i dati strutturati e nel file system per i dati BLOB non strutturati, e sulla capacità di mantenere la coerenza transazionale tra i due archivi. Ulteriori informazioni sull'architettura di FILESTREAM vengono fornite nella sezione "Panoramica di FILESTREAM" seguente. Panoramica di FILESTREAM FILESTREAM è una nuova funzionalità di SQL Server 2008 che consente di archiviare i dati strutturati nel database e i dati non strutturati associati (cioè i dati BLOB) direttamente nel file system NTFS. Per accedere ai dati BLOB è quindi possibile utilizzare le API di flusso Win32® a prestazioni elevate, anziché SQL Server, molto meno adatto a questo scopo in termini di prestazioni. FILESTREAM assicura sempre la coerenza transazionale tra i dati strutturati e non strutturati, consentendo anche il recupero temporizzato di dati FILESTREAM tramite i backup dei log. La coerenza viene mantenuta automaticamente da SQL Server e non richiede alcuna logica personalizzata nell'applicazione. In FILESTREAM la coerenza viene assicurata tramite l'equivalente di un log delle transazioni del database, con pressoché gli stessi requisiti di gestione (descritti in maggior dettaglio nella sezione "Configurazione dell'operazione di Garbage Collection di FILESTREAM" più avanti in questo white paper). La combinazione del log delle transazioni del database e del log delle transazioni FILESTREAM permette il corretto recupero dei dati FILESTREAM e dei dati strutturati dal punto di vista transazionale. Piuttosto che un tipo di dati completamente nuovo, FILESTREAM è un attributo di archiviazione del tipo di dati varbinary (max) esistente, di cui mantiene la maggior parte del comportamento. La differenza consiste nella modalità di archiviazione dei dati BLOB, che avviene nel file system anziché nei file di dati di SQL Server. Poiché FILESTREAM è implementato come colonna varbinary (max) e integrato direttamente nel motore di database, la maggior parte degli strumenti e delle funzioni di gestione di SQL Server funziona senza modifiche per i dati FILESTREAM. Si noti che il comportamento del tipo di dati varbinary (max) normale rimane totalmente invariato in SQL Server 2008, incluso il limite delle dimensioni di 2 GB. Con l'aggiunta dell'attributo FILESTREAM, una colonna varbinary (max) diventa di dimensioni praticamente illimitate, anche se in realtà viene posto un limite dalle dimensioni del volume NTFS sottostante. I dati FILESTREAM vengono archiviati nel file system in un set di directory NTFS chiamate contenitori di dati, che corrispondono a filegroup speciali nel database. L'accesso transazionale ai dati FILESTREAM è controllato da SQL Server e da un driver di filtro del file system installato quando FILESTREAM viene abilitato a livello di Windows. L'utilizzo di un driver di filtro del file system consente inoltre l'accesso remoto ai dati FILESTREAM tramite un percorso UNC. In SQL Server viene gestito un collegamento tra le righe delle tabelle e i file FILESTREAM associati. Ciò significa che l'eliminazione o la ridenominazione di file FILESTREAM direttamente tramite il file system provoca il danneggiamento del database. L'utilizzo di FILESTREAM richiede alcune modifiche allo schema delle tabelle di dati (principalmente il requisito dell'univocità dell'ID di ogni riga) e prevede inoltre alcune restrizioni quando viene combinato con altre funzionalità (ad esempio l'impossibilità di crittografare i dati FILESTREAM). Ulteriori dettagli su questo aspetto vengono forniti nella sezione "Configurazione di SQL Server per FILESTREAM" più avanti in questo white paper. 4 I dati FILESTREAM sono accessibili e modificabili in due modalità: con il modello di programmazione standard Transact-SQL o tramite le API di flusso Win32. Entrambi i meccanismi assicurano il supporto completo per le transazioni e per la maggior parte delle operazioni DML, inclusi inserimento, aggiornamento, eliminazione e selezione. I dati FILESTREAM sono supportati anche nelle operazioni di manutenzione quali backup, ripristino e verifica della coerenza. L'eccezione principale consiste nel fatto che non sono supportati aggiornamenti parziali ai dati FILESTREAM. Qualsiasi aggiornamento a un valore dei dati FILESTREAM viene convertito nella creazione di una nuova copia del file di dati FILESTREAM. Il file precedente viene rimosso in modo asincrono, come descritto nella sezione "Configurazione dell'operazione di Garbage Collection di FILESTREAM" più avanti in questo white paper. Due modelli di programmazione per l'accesso ai dati BLOB È possibile accedere ai dati archiviati in una colonna FILESTREAM utilizzando le transazioni TransactSQL o le API Win32. In questa sezione vengono fornite alcune informazioni generali sui modelli di programmazione e su come utilizzarli. Accesso tramite Transact-SQL Utilizzando Transact-SQL è possibile effettuare operazioni di inserimento, aggiornamento ed eliminazione di dati FILESTREAM come indicato di seguito. I campi FILESTREAM possono essere prepopolati tramite un'operazione di inserimento (con un valore vuoto o un valore non Null di piccole dimensioni). Tuttavia, le interfacce Win32 costituiscono un modo più efficiente di trasmettere una grande quantità di dati. Quando i dati FILESTREAM vengono aggiornati, i dati BLOB sottostanti nel file system vengono modificati. Quando un campo FILESTREAM viene impostato su NULL, i dati BLOB associati al campo vengono eliminati. Non è possibile utilizzare aggiornamenti a blocchi di Transact-SQL implementati come UPDATE.Write() per eseguire aggiornamenti parziali ai dati FILESTREAM. Quando si elimina una riga che contiene dati FILESTREAM oppure si elimina o si tronca una tabella con tali dati, vengono eliminati anche i dati BLOB sottostanti nel file system. L'effettiva rimozione fisica dei file FILESTREAM avviene con un processo asincrono eseguito in background, come illustrato nella sezione "Configurazione dell'operazione di Garbage Collection di FILESTREAM" più avanti in questo white paper. Per ulteriori informazioni ed esempi sull'utilizzo di Transact-SQL per accedere ai dati FILESTREAM, vedere l'argomento "Accedere a dati FILESTREAM con Transact-SQL" nella documentazione online di SQL Server 2008 (http://msdn.microsoft.com/it-it/library/cc645962.aspx). Accesso tramite flusso Win32 Per consentire al file system transazionale di accedere ai dati FILESTREAM è disponibile la nuova funzione intrinseca GET_FILESTREAM_TRANSACTION_CONTEXT() che fornisce il token che rappresenta la transazione corrente a cui è associata la sessione. È necessario che la transazione sia stata avviata e non ne sia stato ancora eseguito il commit o il rollback. Ottenendo un token, l'applicazione associa le operazioni di flusso nel file system di FILESTREAM con una transazione avviata. La funzione restituisce NULL se non esistono transazioni esplicitamente avviate. È necessario ottenere un token prima di poter accedere ai file FILESTREAM. 5 In FILESTREAM il motore di database consente di controllare lo spazio dei nomi del file system fisico dei BLOB. Una nuova funzione intrinseca, PathName, fornisce il percorso UNC logico del BLOB che corrisponde a ogni campo FILESTREAM nella tabella. L'applicazione utilizza questo percorso logico per ottenere l'handle Win32 e operare sui dati BLOB mediante normali interfacce del file system Win32. La funzione restituisce NULL se il valore della colonna FILESTREAM è NULL. Questo meccanismo evidenzia il fatto che è necessario che un file FILESTREAM sia stato creato in precedenza perché sia possibile accedervi a livello Win32. Questa operazione viene eseguita come descritto in precedenza. Il supporto per il flusso Win32 opera nel contesto di una transazione di SQL Server. Dopo l'ottenimento di un token di transazione e un nome di percorso, è possibile utilizzare l'API OpenSqlFilestream Win32 per ottenere un handle di file Win32. In alternativa, è possibile utilizzare l'API SqlFileStream gestita. Il relativo handle può quindi essere utilizzato dalle interfacce di flusso Win32, ad esempio ReadFile() e WriteFile(), per accedere al file e aggiornarlo mediante il file system. Di nuovo, si noti che i file FILESTREAM non possono essere direttamente eliminati né rinominati tramite il file system. In caso contrario la coerenza a livello di collegamento tra il database e il file system andrà persa, cioè il database risulterà essenzialmente danneggiato. L'accesso al file system di FILESTREAM consente di modellare un'istruzione Transact-SQL utilizzando le operazioni di apertura e chiusura dei file. L'istruzione si avvia quando un handle di file viene aperto e termina quando l'handle viene chiuso. Ad esempio, se un handle di scrittura viene chiuso, qualsiasi possibile trigger AFTER registrato nella tabella si attiva come se fosse stata completata un'istruzione UPDATE. Per ulteriori informazioni ed esempi sull'utilizzo delle API Win32 per accedere ai dati FILESTREAM, vedere l'argomento "Gestione di dati FILESTREAM mediante Win32" nella documentazione online di SQL Server 2008 (http://msdn.microsoft.com/it-it/library/cc645940.aspx). Semantica transazionale Tutti gli handle di file devono essere chiusi prima del commit o del rollback della transazione. Se un handle viene lasciato aperto quando viene eseguito il commit di una transazione, il commit avrà esito negativo e ulteriori operazioni di lettura e scrittura sull'handle provocheranno prevedibilmente un errore. A quel punto dovrà essere eseguito il rollback della transazione. Allo stesso modo, se il database o l'istanza del motore di database si arresta, tutti gli handle aperti vengono invalidati. Ogni volta che un file FILESTREAM viene aperto per un'operazione di scrittura, viene creato un nuovo file di lunghezza zero e al suo interno viene scritto l'intero valore dei dati FILESTREAM aggiornato. Il file precedente viene rimosso in modo asincrono, come descritto nella sezione "Configurazione dell'operazione di Garbage Collection di FILESTREAM" più avanti in questo white paper. Con FILESTREAM, tramite il motore di database viene assicurata la durabilità della transazione al commit per i dati BLOB di FILESTREAM modificati accedendo tramite flusso al file system. Questa operazione viene eseguita utilizzando il log FILESTREAM indicato in precedenza e uno scaricamento esplicito dei contenuti dei file FILESTREAM su disco. 6 Semantica dell'isolamento La semantica dell'isolamento è gestita dai livelli di isolamento delle transazioni del motore di database. Quando si accede ai dati FILESTREAM tramite le API Win32, viene supportato solo il livello di isolamento READ-COMMITTED. L'accesso tramite Transact-SQL supporta anche i livelli di isolamento REPEATABLE-READ e SERIALIZABLE. Inoltre, utilizzando l'accesso tramite Transact-SQL è possibile effettuare letture dirty attraverso il livello di isolamento READ-UNCOMMITTED o l'hint per la query NOLOCK, ma con tale accesso non verranno visualizzati gli aggiornamenti in transito dei dati FILESTREAM. Le operazioni di apertura dell'accesso al file system non attendono alcun blocco, ma danno immediato esito negativo se non possono accedere ai dati a causa dell'isolamento della transazione. Le chiamate API di flusso hanno esito negativo con ERROR_SHARING_VIOLATION se l'operazione di apertura non può continuare a causa della violazione dell'isolamento. Aggiornamenti parziali Per consentire l'esecuzione di aggiornamenti parziali, l'applicazione può eseguire un controllo FS del dispositivo (FSCTL_SQL_FILESTREAM_FETCH_OLD_CONTENT) per recuperare il contenuto obsoleto nel file a cui fa riferimento l'handle aperto. Questa operazione può essere eseguita anche utilizzando l'API SqlFileStream gestita con il flag ReadWrite. In questo modo verrà attivata una copia del contenuto obsoleto sul lato server, come descritto in precedenza. Per ottenere prestazioni migliori dell'applicazione ed evitare timeout quando si utilizzano file molto grandi, si consiglia di utilizzare operazioni di I/O asincrone. Se viene eseguito FSCTL dopo la scrittura sull'handle, l'ultima operazione di scrittura verrà resa persistente e le scritture precedenti eseguite sull'handle andranno perdute. Per ulteriori informazioni sugli aggiornamenti parziali, vedere l'argomento "Esecuzione di aggiornamenti parziali di dati FILESTREAM" nella documentazione online di SQL Server 2008 (http://technet.microsoft.com/it-it/library/cc627407.aspx). Write-through da client remoti L'accesso remoto al file system per i dati FILESTREAM è abilitato tramite il protocollo SMB (Server Message Block). Se il client è remoto, la memorizzazione nella cache delle operazioni di scrittura dipende dalle opzioni specificate e dall'API utilizzata. Ad esempio, l'impostazione predefinita per le API in codice nativo è di eseguire il write-through, mentre l'impostazione predefinita per le API gestite prevede l'utilizzo del buffering. Questa differenza riflette i commenti e i suggerimenti dei clienti sulle varie API e le modalità di utilizzo nelle versioni CTP provvisorie di SQL Server 2008. Si consiglia il consolidamento (tramite buffering) delle piccole operazioni di scrittura delle applicazioni in esecuzione sui client remoti, in modo da effettuare un numero minore di operazioni con dati di dimensioni superiori. Inoltre, se viene utilizzato il buffering, è consigliabile eseguire uno scaricamento esplicito dal client prima del commit della transazione. La creazione di viste con mapping alla memoria (I/O con mapping alla memoria) utilizzando handle FILESTREAM non è supportata. Se per i dati FILESTREAM viene utilizzato il mapping della memoria, il motore di database non può assicurare la coerenza e la durabilità dei dati né l'integrità del database. 7 Quando utilizzare FILESTREAM Anche se presenta molte caratteristiche utili, la tecnologia FILESTREAM non costituisce necessariamente la scelta ottimale in tutte le situazioni. Come indicato in precedenza, le dimensioni dei dati BLOB e i modelli di accesso sono i fattori più significativi quando si sceglie se archiviare i dati BLOB interamente nel database o utilizzando FILESTREAM. La dimensione influisce sugli aspetti seguenti: Efficienza con cui è possibile accedere ai dati BLOB utilizzando l'uno o l'altro meccanismo di archiviazione. Come indicato in precedenza, l'accesso tramite flusso ai dati BLOB di grandi dimensioni è più efficiente con FILESTREAM, ma gli aggiornamenti parziali sono (potenzialmente molto) più lenti. Efficienza di backup della combinazione di dati strutturati e dati BLOB utilizzando l'uno o l'altro meccanismo di archiviazione. Un backup in cui vengono combinati i file di database di SQL Server e un numero elevato di file FILESTREAM risulta più lento del backup di soli file di database di SQL Server per una dimensione totale equivalente. Ciò accade a causa dell'overhead supplementare del backup di ogni file NTFS (uno per ogni valore di dati FILESTREAM). L'overhead diventa più significativo quando i file FILESTREAM sono di dimensioni inferiori, in quanto l'overhead di tempo diventa una percentuale maggiore del tempo totale di backup per MB di dati. Nel grafico di esempio seguente viene illustrata la velocità effettiva relativa delle letture locali di dati BLOB di varie dimensioni utilizzando varbinary (max), FILESTREAM tramite Transact-SQL e FILESTREAM tramite il file system NTFS. Si può osservare (sulla linea blu) che l'accesso tramite Win32 ai dati FILESTREAM diventa diverse volte più veloce dell'accesso tramite Transact-SQL ai dati varbinary (max) man mano che le dimensioni dei dati aumentano. Si noti che le misurazioni della velocità effettiva sono espresse in megabit al secondo (Mbps). Figura 1. Prestazioni di lettura di BLOB di diverse dimensioni 8 Le cifre relative a NTFS includono il tempo necessario per avviare una transazione, recuperare il nome del percorso e il contesto di transazione da SQL Server e aprire un handle Win32 per i dati FILESTREAM. Ogni test è stato eseguito utilizzando lo stesso computer con quattro core di processore e un pool di buffer a caldo di SQL Server. Come fattore ulteriore, va considerato se il client o il livello intermedio possono essere scritti (o modificati) in modo da utilizzare le API di flusso Win32 oltre al normale accesso a SQL Server. In caso contrario, FILESTREAM non è appropriato, in quanto le prestazioni migliori vengono ottenute tramite le API di flusso Win32. Configurazione di Windows per FILESTREAM Come per qualsiasi altra distribuzione, prima di distribuire un'applicazione in cui viene utilizzato FILESTREAM è importante preparare il server Windows che ospiterà il database di SQL Server e i contenitori di dati FILESTREAM associati. In questa sezione viene descritto come configurare l'hardware di archiviazione e il file system NTFS in preparazione all'utilizzo di FILESTREAM. Viene quindi illustrato come abilitare FILESTREAM a livello di Windows. Selezione e configurazione dell'hardware Una delle cause più comuni delle scarse prestazioni di un carico di lavoro è una configurazione hardware inadeguata. Talvolta la causa è la memoria insufficiente, che provoca il sovraccarico del pool di buffer di SQL Server, talvolta si tratta semplicemente della mancanza nell'hardware di archiviazione delle capacità di velocità effettiva di I/O necessarie al carico di lavoro. Per le applicazioni in cui viene utilizzato FILESTREAM per il flusso a prestazioni elevate di dati BLOB tramite le API Win32, la scelta e la configurazione dell'hardware di archiviazione sono di importanza critica. Nelle sezioni seguenti vengono descritte alcune procedure consigliate per la scelta e il layout di archiviazione. Per una discussione più approfondita su questo argomento, vedere il white paper sulla progettazione dell'archiviazione di un database fisico nella libreria TechNet (http://www.microsoft.com/technet/prodtechnol/sql/2005/physdbstor.mspx). Dopo avere progettato il layout ottimale, è consigliabile eseguire il test di carico per convalidare le capacità di prestazioni del sottosistema di I/O. Questo aspetto viene trattato in dettaglio nell'articolo sulle procedure consigliate per SQL Server in cui viene illustrata la configurazione del sottosistema di I/O prima della distribuzione (http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/pdpliobp.mspx) nella libreria TechNet. Layout dell'archiviazione fisica Quando si stabilisce l'ubicazione di un contenitore di dati FILESTREAM, è opportuno tenere in considerazione il relativo carico di lavoro previsto, nonché i carichi di lavoro nei contenitori di dati o nei file di SQL Server nella medesima ubicazione. Ogni contenitore di dati FILESTREAM potrebbe dover disporre di un proprio volume, poiché più contenitori di dati con carichi di lavoro pesanti in un singolo volume potrebbero provocare effetti di contesa di risorse. Il punto da ricordare è che la valutazione dei carichi di lavoro non va trascurata, perché la collocazione di tutte le risorse di archiviazione su un unico volume può generare problemi di prestazioni. Il livello di separazione richiesta dipende dagli specifici scenari dei clienti. È inoltre possibile creare uno schema di tabella in SQL Server che consente un bilanciamento approssimativo del carico di dati FILESTREAM tra più volumi. Questa operazione viene descritta nella sezione "Bilanciamento del carico di dati FILESTREAM". 9 Scelta del livello RAID I vantaggi offerti dalla tecnologia RAID sono noti e molto è stato scritto sulla scelta di un livello RAID adeguato ai requisiti dell'applicazione, pertanto in questo white paper non si ripeteranno queste informazioni. Nel già citato white paper sulla progettazione dell'archiviazione di un database fisico è inclusa un'eccellente sezione sui livelli RAID e sui relativi criteri di scelta. Qui di seguito viene riportata una semplice panoramica dei fattori da considerare. I livelli RAID presentano molti aspetti di differenziazione, in particolare in termini di prestazioni di lettura/scrittura, resilienza all'errore e costo. Ad esempio, il livello RAID 5 ha un costo relativamente basso, è in grado di gestire gli errori di una sola unità nella matrice RAID e può essere inadatto per i carichi di lavoro con intensa attività di scrittura. D'altra parte, il sistema RAID 10 offre eccellenti prestazioni di lettura e scrittura ed è in grado di gestire gli errori di più unità (in base al livello di mirroring utilizzato), ma è più costoso, considerando che almeno il 50% delle unità nella matrice RAID è ridondante. Questi sono i tre fattori principali da considerare nella scelta di un livello RAID. È possibile scegliere un livello RAID diverso per il volume in cui viene archiviato ciascun database utente e anche un livello RAID diverso tra il volume in cui sono archiviati i file di dati e il volume in cui sono archiviati i file di log di un singolo database. In presenza di un carico di lavoro che richiede il flusso a prestazioni elevate di dati FILESTREAM, si potrebbe istintivamente scegliere di associare il volume del contenitore di dati FILESTREAM al livello RAID che fornisce le prestazioni di lettura superiori. Tuttavia, questa scelta potrebbe non assicurare un elevato grado di resilienza agli errori. D'altra parte, la scelta potrebbe cadere sul livello RAID utilizzato per gli altri volumi in cui vengono archiviati i dati del database, ma in questo caso potrebbero mancare i requisiti di prestazioni richiesti dal carico di lavoro. Il punto che si desidera evidenziare in questo white paper è che la scelta del livello RAID per i volumi dei contenitori di dati FILESTREAM dovrebbe essere operata dopo aver attentamente valutato tutti i fattori interessati con i relativi vantaggi e svantaggi e non in base a uno solo di essi. Scelta dell'interfaccia di unità Nei database comuni che includono dati BLOB, le dimensioni totali dei dati BLOB possono essere di molto superiori alle dimensioni totali dei dati strutturati. Quando si implementa una soluzione che prevede l'archiviazione dei dati FILESTREAM in volumi distinti, è possibile valutare di utilizzare un sistema di archiviazione più economico per il volume, ad esempio IDE o SATA (da qui in avanti semplicemente "SATA"), anziché un sistema archiviazione SCSI più costoso. Prima di compiere questa scelta è importante comprendere vantaggi e svantaggi di ciascun sistema e i possibili compromessi. In questa sezione viene fornita una panoramica delle diverse caratteristiche dei sistemi SCSI da un parte e IDE/SATA dall'altra per favorire una scelta informata in base alle prestazioni e all'affidabilità offerte, nonché ai costi da sostenere. Capacità e prestazioni Le unità SATA tendono ad avere maggiore capacità rispetto alle unità SCSI, ma minore velocità di rotazione (RPM). Anche se sono disponibili unità SATA a 10.000 RPM, la maggior parte di esse offre 5.400 o 7.200 RPM. Le unità SCSI a prestazioni elevate offrono 10.000 e anche 15.000 RPM. Il valore RPM può essere un'utile metrica di confronto, ma le due cifre realmente significative per un confronto sono la latenza, cioè il tempo di attesa prima che la testina del disco si trovi nella posizione corretta sulla superficie del disco, e la velocità media di trasferimento, cioè la quantità di dati che può essere trasferita dalla/alla superficie del disco al secondo. È inoltre importante che le unità siano in grado di elaborare modelli complessi di I/O in modo efficiente. Quando si scelgono le unità, verificare che le unità SATA includano il supporto NCQ (Native Command Queue) e le unità SCSI includano il supporto CTQ (Command Tag Queue). Tale supporto consente l'elaborazione di più operazioni interleaved di I/O su disco e assicura così migliori prestazioni. 10 Per riepilogare, le unità SCSI si caratterizzano in genere per migliori valori di latenza e velocità di trasferimento e quindi offrono migliori prestazioni di flusso, ma potenzialmente hanno un costo più elevato. Affidabilità Per garantire affidabilità e funzionalità di recupero attraverso il meccanismo di log write-ahead, in SQL Server devono essere assicurati ordine di scrittura e durabilità. Per ulteriori informazioni su tali requisiti di I/O, vedere il white paper sui concetti di base relativi all'I/O in SQL Server nella libreria TechNet (http://www.microsoft.com/technet/prodtechnol/sql/2005/iobasics.mspx). Per l'affidabilità, la tecnologia SCSI è migliore della SATA perché, a differenza di quest'ultima, supporta in modo uniforme la scrittura forzata dei dati sul disco. Ciò avviene attraverso il supporto del processo writethrough, con il quale i dati da scrivere non vengono affatto memorizzati nella cache, oppure attraverso il supporto dello scaricamento forzato dei contenuti della cache sul disco. In mancanza dell'uno o dell'altro meccanismo potrebbero verificarsi difficoltà di recupero dopo un problema hardware, software o di alimentazione. Tutti i tipi di interfaccia possono supportare il collegamento a caldo per consentire le operazioni di ripristino e nel contempo mantenere la disponibilità. La funzionalità FILESTREAM si basa su due aspetti che assicurano ordine di scrittura e durabilità: durabilità dei dati in fase di commit della transazione; registrazione write-ahead per la creazione e l'eliminazione di file FILESTREAM. La durabilità dei dati viene ottenuta dal driver del file system di FILESTREAM che esegue uno scaricamento esplicito dei file che sono stati modificati prima del commit di una transazione (i dettagli del meccanismo esulano dall'ambito di questo white paper). Ciò assicura che, in caso di interruzione dell'alimentazione, i dischi senza cache alimentata a batteria non contengano dati FILESTREAM di cui è stato eseguito il commit, ma non lo scaricamento, che potrebbero andare persi. Se le unità SATA non supportano un'operazione di scaricamento forzato, la recuperabilità può essere pregiudicata e i dati possono andare persi. La registrazione write-ahead si basa sulla coerenza dei metadati NTFS, a sua volta basata sull'affidabilità delle unità sottostanti. Per le unità SCSI il problema non esiste, ma se le unità SATA non supportano lo scaricamento forzato può verificarsi la perdita di alcune delle modifiche ai metadati in caso di interruzione dell'alimentazione. Questa situazione può dare adito a una serie di scenari: 11 È impossibile recuperare il file system NTFS e il volume non può essere montato, ovvero il contenitore di dati FILESTREAM è essenzialmente offline. Il file system NTFS viene recuperato ma le modifiche ai metadati NTFS vengono perse e SQL Server non è in grado di eseguire il rollback di una transazione senza commit con cui viene eseguito un inserimento di dati FILESTREAM, ovvero si verifica una dispersione di dati FILESTREAM. Il file system NTFS viene recuperato ma le modifiche ai metadati NTFS vengono perse e SQL Server non è in grado di eseguire il rollback di una transazione senza commit con cui viene eseguita un'eliminazione di dati FILESTREAM, ovvero si verifica una perdita di dati FILESTREAM. Si noti che in tutti e tre gli scenari la situazione equivale effettivamente al caso in cui i dati BLOB vengono archiviati esternamente al database in un volume NTFS con unità SATA sottostanti che non supportano la forzatura dei dati sul disco. L'utilizzo di FILESTREAM in un volume con unità SATA sottostanti in questo caso è effettivamente preferibile all'archiviazione dei dati BLOB in file NTFS RAW sullo stesso volume, poiché la coerenza a livello di collegamenti di FILESTREAM fornisce un meccanismo per rilevare la presenza di questi problemi (tramite l'esecuzione di DBCC CHECKDB sul database). In sintesi, i dati FILESTREAM possono essere archiviati in modo affidabile in volumi con risorse di archiviazione SATA sottostanti, purché le unità SATA supportino la forzatura dei dati sul disco tramite lo scaricamento della cache. Configurazione di NTFS Anche il sottosistema di I/O più accuratamente progettato in esecuzione su hardware a prestazioni elevate potrebbe non funzionare nel modo previsto se il file system (in questo caso NTFS) non è configurato correttamente. In questa sezione vengono descritte alcune opzioni di configurazione che possono influire su un carico di lavoro che include dati FILESTREAM. Per una panoramica più completa di NTFS, vedere l'articolo di riferimento tecnico a NTFS (http://technet.microsoft.com/it-it/library/cc758691.aspx) e l'articolo sull'utilizzo dei file system (http://technet.microsoft.com/it-it/library/bb457112.aspx) nella libreria TechNet. Ottimizzazione delle prestazioni di NTFS La configurazione predefinita di NTFS non prevede la gestione di un carico di lavoro a prestazioni elevate con decine di migliaia di file in una singola directory del file system, ovvero lo scenario di FILESTREAM. È necessario configurare due opzioni NTFS per facilitare le prestazioni di FILESTREAM. È particolarmente importante impostare queste opzioni in modo corretto prima dell'organizzazione di qualsiasi attività di benchmarking di prestazioni. In caso contrario, i risultati non saranno rappresentativi delle reali prestazioni di FILESTREAM. La prima opzione di configurazione da disabilitare riguarda il processo di generazione di nomi in formato 8.3 quando vengono creati nuovi file o rinominati file esistenti. Questo processo genera un nome secondario per ogni file al solo fine della compatibilità con le precedenti applicazioni a 16 bit. L'algoritmo genera un nuovo nome in formato 8.3, ma per assicurarne l'univocità deve analizzare tutti i nomi file in formato 8.3 esistenti nella directory. Poiché il numero di file nella directory tende ad aumentare (generalmente oltre i 300.000), questo processo richiede un tempo sempre maggiore. Il tempo necessario per creare un file aumenta a sua volta, a discapito delle prestazioni, pertanto la disabilitazione di questo processo può consentire un significativo miglioramento delle prestazioni. Per disabilitare il processo, digitare il comando seguente al prompt dei comandi e quindi riavviare il computer: fsutil behavior set disable8dot3 1 Nota: con questa opzione la generazione di nomi in formato 8.3 viene disabilitata in tutti i volumi NTFS sul server. Se i volumi vengono utilizzati da applicazioni a 16 bit, possono verificarsi problemi dopo la modifica di questo comportamento. 12 La seconda opzione da disabilitare riguarda l'aggiornamento dell'ultima data/ora di accesso a un file. Se il carico di lavoro accede brevemente a più file, viene spesa una quantità di tempo sproporzionata solo per aggiornare l'ultima data/ora di accesso a ogni file. Anche la disabilitazione di questa opzione può consentire un notevole miglioramento delle prestazioni. Per disabilitare il processo, digitare il comando seguente al prompt dei comandi e quindi riavviare il computer: fsutil behavior set disablelastaccess 1 Dimensione del cluster A tutti i file system di Windows è associato il concetto di "cluster", ovvero l'unità di allocazione dello spazio su disco. Poiché un cluster è la più piccola quantità allocabile di spazio su disco, in presenza di file molto piccoli alcuni cluster potrebbero rimanere inutilizzati (essenzialmente sprecati). Pertanto la dimensione del cluster è in genere sufficientemente piccola da evitare che i file di piccole dimensioni sprechino spazio su disco. Per i file di grandi dimensioni possono essere allocati molti cluster, mentre per i file che aumentano di dimensioni nel tempo possono essere man mano assegnati più cluster. Se le dimensioni di un file aumentano notevolmente, ma in piccoli blocchi, è probabile che i cluster allocati non siano contigui sul disco, cioè siano "frammenti". Ciò significa che, più piccoli sono i cluster, più un file che aumenta di dimensioni risulterà frammentato. La dimensione del cluster deve pertanto essere un compromesso tra lo spreco di spazio e la riduzione della frammentazione. Per ulteriori informazioni sulle diverse dimensioni dei cluster nei file system di Windows, vedere l'articolo della Knowledge Base "Dimensioni di cluster predefinite per NTFS, FAT ed exFAT" (http://support.microsoft.com/kb/140365). Per utilizzare FILESTREAM, la dimensione consigliata delle singole unità di dati BLOB è di almeno 1 MB. In questo caso, è consigliabile che la dimensione del cluster NTFS per il volume del contenitore di dati FILESTREAM sia impostata su 64 KB per ridurre la frammentazione. Questa operazione deve essere eseguita manualmente poiché l'impostazione predefinita per i volumi NTFS fino a 2 terabyte (TB) è di 4 KB. A tale scopo è possibile utilizzare l'opzione /A nel comando di formattazione. Al prompt dei comandi, ad esempio, digitare: format F: /FS:NTFS /V:MyFILESTREAMContainer /A:64K Questa impostazione deve essere combinata con ampie dimensioni di buffer, come descritto nella sezione "Considerazioni sull'ottimizzazione e sul benchmarking delle prestazioni" più avanti in questo white paper. Gestione della frammentazione Come descritto in precedenza, molti file che in un volume aumentano di dimensioni diventano frammentati. Ciò significa che la raccolta dei cluster allocati a un file non è contigua. Quando il file viene letto in sequenza, le testine del disco sottostante devono leggere tutti i cluster in sequenza, pertanto è probabile che debbano leggere diverse parti del disco. Anche se i file non aumentano di dimensioni dopo essere stati creati, se vengono creati su un volume in cui lo spazio disponibile non si trova in un unico blocco contiguo, è possibile che vengano frammentati immediatamente, in assenza di un numero sufficiente di cluster contigui per ospitarli. 13 La frammentazione riduce le prestazioni di lettura sequenziale rispetto a condizioni di frammentazione assente o scarsa. Il problema è molto simile a quello della frammentazione degli indici in un database che rallenta le prestazioni di analisi dell'intervallo di query. È pertanto necessario che la frammentazione venga rimossa periodicamente tramite l'utilizzo di uno strumento di deframmentazione, in modo da mantenere un buon livello di prestazioni di lettura sequenziale. Inoltre, se il volume da utilizzare per ospitare il contenitore di dati FILESTREAM è già stato utilizzato in precedenza o contiene ancora altri dati, è opportuno controllare ed eventualmente correggere il livello di frammentazione. Compressione I dati archiviati in NTFS possono essere compressi per risparmiare spazio su disco. Ciò comporta tuttavia un maggiore utilizzo della CPU per comprimere e decomprimere i dati quando vengono rispettivamente scritti o letti. Inoltre, la compressione non è utile se i dati non sono essenzialmente comprimibili. Ad esempio, i dati casuali, i dati crittografati o i dati che sono già stati compressi non vengono compressi in modo efficiente, ma vengono comunque elaborati tramite l'algoritmo di compressione di NTFS, provocando un overhead della CPU. Per questi motivi, la scelta della compressione va fatta solo quando i dati possono essere compressi in modo significativo e l'utilizzo aggiuntivo di CPU non provoca una riduzione delle prestazioni del carico di lavoro. Si noti anche che la compressione può essere abilitata solo se la dimensione del cluster NTFS è al massimo di 4.096 byte. La compressione può essere abilitata quando il volume del contenitore di dati FILESTREAM viene formattato, utilizzando l'opzione /C del comando di formattazione. Ad esempio: format F: /FS:NTFS /V:MyFILESTREAMContainer /A:4096 /C È possibile abilitare per la compressione anche un volume esistente, utilizzando i passaggi seguenti: 1. In Risorse del computer o in Esplora risorse fare clic con il pulsante destro del mouse sul volume da comprimere o decomprimere. 2. Fare clic su Proprietà per visualizzare la finestra di dialogo Proprietà. 3. Nella scheda Generale selezionare o deselezionare la casella di controllo Comprimi unità per risparmiare spazio su disco, quindi fare clic su OK. 4. Nella finestra di dialogo Conferma cambiamenti attributi scegliere se applicare la compressione all'intero volume o solo alla cartella radice. 14 Questa procedura è illustrata nella figura seguente. Figura 2. Compressione di un volume esistente tramite Esplora risorse Gestione dello spazio Sebbene più contenitori di dati FILESTREAM possano essere collocati in un singolo volume NTFS, per vari motivi è preferibile impostare un mapping di tipo 1:1 tra contenitori di dati e volumi NTFS. Oltre al rischio di potenziali contese di risorse dipendenti dal carico di lavoro, non è possibile gestire l'utilizzo dello spazio del contenitore di dati FILESTREAM dall'interno di SQL Server, pertanto, se necessario, vanno utilizzate le quote disco NTFS. Le quote disco vengono rilevate per utente e per volume, quindi la presenza di più contenitori di dati FILESTREAM in un singolo volume rende difficile stabilire quale contenitore stia utilizzando più spazio su disco. Si noti che tutti i file FILESTREAM vengono creati con l'account del servizio SQL Server. Se questa impostazione viene modificata, si inizierà a imputare lo spazio su disco al nuovo account del servizio. È disponibile un solo driver di filtro del file system FILESTREAM per ogni volume NTFS con un contenitore di dati FILESTREAM e uno per ogni versione di SQL Server con un contenitore di dati FILESTREAM nel volume. Ogni driver di filtro è responsabile della gestione di tutti i contenitori di dati FILESTREAM per il volume specificato, per tutte le istanze in cui viene utilizzata una determinata versione di SQL Server. 15 Ad esempio, un volume che ospita tre contenitori di dati FILESTREAM, uno per ognuna delle tre istanze di SQL Server 2008, disporrà di un solo driver di filtro del file system FILESTREAM di SQL Server 2008. Sicurezza È necessario soddisfare due requisiti di sicurezza per utilizzare la funzionalità FILESTREAM. Innanzitutto, SQL Server deve essere configurato per la sicurezza integrata. In secondo luogo, se si intende utilizzare l'accesso remoto, la porta SMB (445) deve essere abilitata nei sistemi firewall, analogamente a quanto richiesto per il normale accesso condiviso remoto. Per ulteriori informazioni, vedere l'articolo della Knowledge Base relativo alla panoramica sui servizi e ai requisiti delle porte di rete per Windows Server (http://support.microsoft.com/kb/832017). Considerazioni sul software antivirus Il software antivirus è ormai presente in ogni ambiente moderno. In FILESTREAM non è prevista la possibilità di impedire al software antivirus di analizzare i file nel contenitore di dati FILESTREAM, dal momento che questo comporterebbe problemi di sicurezza. Normalmente, i criteri impostati nei programmi antivirus determinano l'azione da intraprendere sui file ritenuti certamente o probabilmente contaminati: eliminare il file o limitarne l'accesso (mettendolo nella cosiddetta "quarantena"). In entrambi i casi, l'accesso ai dati BLOB nel file interessato viene impedito e in SQL Server il file risulterà eliminato. È consigliabile che il software antivirus venga impostato in modo tale da mettere i file in quarantena e non eliminarli. In SQL Server è possibile utilizzare DBCC CHECKDB per individuare quali file risultano mancanti e l'amministratore di Windows può correlare i nomi dei file al log del software antivirus ed eseguire azioni correttive. Abilitazione di FILESTREAM in Windows FILESTREAM è una funzionalità ibrida la cui abilitazione richiede l'intervento sia dell'amministratore di Windows che dell'amministratore di SQL Server. Il duplice intervento è necessario per mantenere la separazione delle responsabilità tra i due amministratori, soprattutto se l'amministratore di SQL Server non è anche l'amministratore di Windows. L'abilitazione di FILESTREAM a livello di Windows comporta l'installazione di un driver di filtro del file system, operazione per la quale sono necessari privilegi di cui dispone solo un amministratore di Windows. A livello di Windows, la funzionalità FILESTREAM viene abilitata durante l'installazione di SQL Server 2008 o tramite l'esecuzione di Gestione configurazione SQL Server. Di seguito sono elencati i passaggi da eseguire: 1. 2. 3. 4. 5. 6. 16 Nel menu Start scegliere Tutti i programmi, Microsoft SQL Server 2008, Strumenti di configurazione, quindi fare clic su Gestione configurazione SQL Server. Nell'elenco dei servizi fare clic con il pulsante destro del mouse su Servizi di SQL Server, quindi scegliere Apri. Nello snap-in Gestione configurazione SQL Server individuare l'istanza di SQL Server in cui si desidera abilitare FILESTREAM. Fare clic con il pulsante destro del mouse sull'istanza, quindi scegliere Proprietà. Nella finestra di dialogo Proprietà di SQL Server fare clic sulla scheda FILESTREAM. Selezionare la casella di controllo Abilita FILESTREAM per l'accesso Transact-SQL. 7. 8. 9. Se si desidera leggere e scrivere dati FILESTREAM da Windows, fare clic su Abilita FILESTREAM per l'accesso tramite il flusso di I/O dei file. Nella casella Nome condivisione di Windows immettere il nome della condivisione di Windows. Se i client remoti devono accedere ai dati FILESTREAM archiviati in tale condivisione, selezionare Consenti ai client remoti l'accesso tramite flusso ai dati FILESTREAM. Fare clic su Applica. Nella figura seguente viene illustrata la scheda FILESTREAM descritta nella procedura. Figura 3. Configurazione di FILESTREAM tramite Gestione configurazione SQL Server Questa procedura deve essere eseguita per ogni istanza di SQL Server nella quale verrà utilizzata la funzionalità FILESTREAM, prima che tale funzionalità possa essere utilizzata da SQL Server. Si noti che in questa fase non è richiesta la specificazione di contenitori di dati FILESTREAM, che viene invece effettuata al momento della creazione di un filegroup FILESTREAM in un database dopo l'abilitazione di FILESTREAM in SQL Server. 17 Si noti che è possibile disabilitare l'accesso FILESTREAM a livello di Windows anche quando la funzionalità è abilitata in SQL Server. In questo caso, dopo che l'istanza di SQL Server viene riavviata, tutti i dati FILESTREAM risulteranno non disponibili. Verrà visualizzato il seguente avviso. Figura 4. Avviso visualizzato a seguito della disabilitazione di FILESTREAM tramite Gestione configurazione SQL Server Configurazione di SQL Server per FILESTREAM Ogni istanza di SQL Server in cui viene utilizzata la funzionalità FILESTREAM deve essere configurata separatamente, sia a livello di Windows che a livello di SQL Server. Dopo l'abilitazione di FILESTREAM, è necessario configurare un database per l'archiviazione dei dati FILESTREAM e solo successivamente è possibile definire tabelle che includano colonne FILESTREAM. In questa sezione viene descritto come configurare FILESTREAM a livello di SQL Server e come creare database e tabelle abilitati per FILESTREAM. Viene inoltre illustrata l'interazione di FILESTREAM con altre funzionalità di SQL Server 2008. Considerazioni sulla sicurezza FILESTREAM richiede l'utilizzo della sicurezza integrata, cioè l'autenticazione di Windows. Quando un'applicazione che utilizza Win32 tenta di accedere ai dati FILESTREAM, l'utente di Windows viene convalidato tramite SQL Server. Se l'utente dispone dell'accesso tramite Transact-SQL ai dati FILESTREAM, l'accesso verrà concesso anche a livello Win32, purché il token di transazione venga ottenuto nel contesto di sicurezza dell'utente di Windows che esegue l'apertura del file. Il requisito dell'autenticazione di Windows deriva dalla natura delle API di I/O dei file di Windows. L'unico modo per passare l'identità del client dall'applicazione client a SQL Server durante un'operazione di I/O dei file consiste nell'utilizzare il token di Windows associato al thread del client. Quando il contenitore di dati FILESTREAM viene creato, viene automaticamente protetto in modo che solo l'account del servizio SQL Server e i membri del gruppo builtin/Administrators possano accedere all'albero di directory del contenitore di dati. È necessario prestare attenzione a non modificare mai il contenuto del contenitore di dati se non tramite i metodi transazionali supportati, poiché l'utilizzo di altri metodi provocherebbe danni al contenitore. Abilitazione di FILESTREAM in SQL Server Il secondo passaggio dell'abilitazione di FILESTREAM viene eseguito nell'istanza di SQL Server 2008. Questo passaggio non deve essere eseguito fino a quando FILESTREAM non è stato abilitato a livello di Windows e il volume NTFS in cui verranno archiviati i dati FILESTREAM non è stato preparato in modo adeguato (come descritto nella sezione "Configurazione di Windows per FILESTREAM"). 18 L'accesso a FILESTREAM viene controllato in SQL Server tramite sp_configure per impostare l'opzione di configurazione filestream_access_level su uno di tre possibili valori, indicati di seguito. 0 - disabilita il supporto di FILESTREAM per l'istanza corrente 1 - abilita FILESTREAM solo per l'accesso tramite Transact-SQL 2 - abilita FILESTREAM per l'accesso tramite Transact-SQL e tramite flusso Win32 Nell'esempio seguente viene illustrata l'abilitazione di FILESTREAM per l'accesso tramite Transact-SQL e tramite flusso Win32. EXEC sp_configure filestream_access_level, 2; GO RECONFIGURE; GO L'istruzione RECONFIGURE è necessaria per rendere effettivo il valore appena configurato. Si noti che se FILESTREAM non è stato abilitato a livello di Windows, non verrà abilitato a livello di SQL Server quando il codice precedente viene eseguito. Il valore configurato corrente può essere trovato utilizzando il codice seguente: EXEC sp_configure filestream_access_level; GO Se FILESTREAM non è configurato a livello di Windows, il valore "config_value" nell'output di sp_configure sarà diverso (cioè 0) dal valore "run_value" dopo l'esecuzione dell'istruzione RECONFIGURE. Creazione di un database abilitato per FILESTREAM Una volta abilitato FILESTREAM sia a livello di Windows che a livello di SQL Server, è possibile definire un contenitore di dati FILESTREAM. A tale scopo, è necessario definire un filegroup FILESTREAM in un database. Tra i filegroup FILESTREAM e i contenitori di dati FILESTREAM esiste un mapping di tipo 1:1. È possibile definire un filegroup FILESTREAM al momento della creazione di un database oppure crearlo separatamente utilizzando un'istruzione ALTER DATABASE. Nell'esempio seguente viene creato un filegroup FILESTREAM in un database esistente. ALTER DATABASE Production ADD FILEGROUP FileStreamGroup1 CONTAINS FILESTREAM; GO 19 La clausola CONTAINS FILESTREAM è necessaria per distinguere il nuovo filegroup dai normali filegroup del database. Se la funzionalità FILESTREAM è disabilitata, l'istruzione avrà esito negativo con l'errore seguente: Messaggio 5591, livello 16, stato 3, riga 1 La funzionalità FILESTREAM è disabilitata. Se FILESTREAM è abilitato a livello di Windows e a livello di SQL Server, il filegroup verrà creato. A questo punto, il contenitore di dati FILESTREAM viene definito aggiungendo un singolo file al filegroup. Il nome del percorso specificato è quello della directory che verrà creata come radice del contenitore di dati. L'intero nome del percorso, escluso il nome della directory finale, deve essere già esistente. Nell'esempio successivo viene definito il contenitore di dati per il filegroup FileStreamGroup1 creato in precedenza. ALTER DATABASE Production ADD FILE ( NAME = FSGroup1File, FILENAME = 'F:\Production\FSDATA') TO FILEGROUP FileStreamGroup1; GO A questo punto verrà creata la directory FSDATA, che sarà vuota tranne che per due elementi: Il file filestream.hdr, che contiene i metadati FILESTREAM per il contenitore di dati. La directory $FSLOG, che è l'equivalente FILESTREAM del log delle transazioni di un database. Si noti che un database può includere più filegroup FILESTREAM. Ciò può risultare utile per separare l'archiviazione BLOB di più tabelle nel database. Creazione di una tabella per archiviare i dati FILESTREAM Quando il database dispone di un filegroup FILESTREAM, è possibile creare tabelle contenenti colonne FILESTREAM. Come indicato in precedenza, una colonna FILESTREAM è una colonna varbinary (max) che dispone dell'attributo FILESTREAM. Il codice seguente crea una tabella con una sola colonna FILESTREAM. USE Production; GO 20 CREATE TABLE DocumentStore ( DocumentID INT IDENTITY PRIMARY KEY, Document VARBINARY (MAX) FILESTREAM NULL, DocGUID UNIQUEIDENTIFIER NOT NULL ROWGUIDCOL UNIQUE DEFAULT NEWID ()) FILESTREAM_ON FileStreamGroup1; GO Una tabella può includere più colonne FILESTREAM, ma i dati di tutte le colonne FILESTREAM in una tabella devono essere archiviati nello stesso filegroup FILESTREAM. Se la clausola FILESTREAM_ON non viene specificata, verrà utilizzato il filegroup FILESTREAM impostato come predefinito. Questa potrebbe non essere la migliore configurazione e provocare problemi di prestazioni. Una volta creata la tabella, il contenitore di dati FILESTREAM conterrà un'altra directory, corrispondente alla tabella, con una sottodirectory che corrisponde alla colonna FILESTREAM nella tabella. La sottodirectory conterrà i file di dati una volta che i dati vengono immessi nella tabella. La struttura di directory dipenderà dal numero di colonne FILESTREAM nella tabella e dal fatto che la tabella sia o meno partizionata. Si noti che, per includere una o più colonne FILESTREAM, una tabella deve disporre anche di una colonna del tipo di dati uniqueidentifier con l'attributo ROWGUIDCOL. Questa colonna non deve consentire valori Null e deve avere un vincolo a colonna singola UNIQUE o PRIMARY KEY. Il valore GUID della colonna deve essere specificato tramite un'applicazione al momento dell'inserimento dei dati o tramite un vincolo DEFAULT che utilizza la funzione NEWID() (o NEWSEQUENTIALID() se è configurata la replica di tipo merge, come indicato nella sezione "Combinazioni di funzionalità e relative restrizioni" più avanti). Per ulteriori informazioni sui dettagli e sulle restrizioni relativi allo schema e alle opzioni di tabella richiesti, vedere l'argomento "CREATE TABLE (Transact-SQL)" nella documentazione online di SQL Server 2008 (http://msdn.microsoft.com/it-it/library/ms174979.aspx). Configurazione dell'operazione di Garbage Collection di FILESTREAM I file di dati FILESTREAM nel contenitore di dati FILESTREAM non possono essere aggiornati parzialmente. Ciò significa che qualsiasi modifica ai dati BLOB nella colonna FILESTREAM comporta la creazione di un intero nuovo file di dati FILESTREAM. Il file precedente deve essere mantenuto a scopo di recupero finché non è più necessario. I file che rappresentano dati FILESTREAM eliminati o gli inserimenti di dati FILESTREAM di cui è stato eseguito il rollback vengono mantenuti in modo analogo. I file non più necessari vengono rimossi tramite un processo di Garbage Collection. Questo processo è automatico, a differenza di quanto accade in Windows SharePoint® Services, dove le operazioni di Garbage Collection devono essere implementate manualmente nell'archivio BLOB esterno. 21 Per tutte le operazioni sui file FILESTREAM viene eseguito il mapping a un numero di sequenza del file di log (LSN) nel log delle transazioni del database. Se il log delle transazioni è stato troncato dopo l'LSN dell'operazione FILESTREAM, il file non è più necessario e può essere sottoposto all'operazione di Garbage Collection. Pertanto, qualsiasi circostanza che possa impedire il troncamento del log delle transazioni può impedire anche l'eliminazione fisica di un file FILESTREAM. Alcuni esempi: I backup del log non sono stati eseguiti, nel modello di recupero FULL o BULK_LOGGED. È presente una transazione attiva con esecuzione prolungata. Il processo di lettura log repliche non è stato eseguito. L'operazione di Garbage Collection di FILESTREAM è un'attività in background che viene attivata dal processo di checkpoint del database. Un checkpoint viene eseguito automaticamente quando è stato generato un log delle transazioni di lunghezza sufficiente. Per ulteriori informazioni, vedere l'argomento "Relazione tra i checkpoint e la parte attiva del log" nella documentazione online di SQL Server 2008 (http://msdn.microsoft.com/it-it/library/ms189573.aspx). Dato che le operazioni sui file FILESTREAM vengono registrate a livello minimo nel log delle transazioni del database, può trascorrere del tempo prima che il numero dei record generati nel log delle transazioni attivi un processo di checkpoint e venga eseguita l'operazione di Garbage Collection. Se questo diventa un problema, è possibile forzare l'operazione di Garbage Collection utilizzando l'istruzione CHECKPOINT. Considerazioni sul partizionamento Se la tabella contenente i dati FILESTREAM è partizionata, la clausola FILESTREAM_ON deve specificare uno schema di partizionamento che includa i filegroup FILESTREAM e si basi sulla funzione di partizionamento della tabella. Tale operazione è necessaria perché il normale schema di partizionamento include filegroup normali che non possono essere utilizzati per archiviare dati FILESTREAM. La definizione di tabella (in un'istruzione CREATE TABLE o CREATE CLUSTERED INDEX … WITH DROP_EXISTING) specifica quindi entrambi gli schemi di partizionamento. Con lo schema di partizionamento di FILESTREAM è possibile specificare che per tutte le partizioni sia eseguito il mapping a un singolo filegroup, ma questa impostazione non è consigliabile poiché può provocare problemi di prestazioni. Questa sintassi è illustrata nell'esempio seguente, appositamente formulato: CREATE PARTITION FUNCTION DocPartFunction (INT) AS RANGE RIGHT FOR VALUES (100000, 200000); GO CREATE PARTITION SCHEME DocPartScheme AS PARTITION DocPartFunction TO (Data_FG1, Data_FG2, Data_FG3); GO 22 CREATE PARTITION SCHEME DocFSPartScheme AS PARTITION DocPartFunction TO (FS_FG1, FS_FG2, FS_FG3); GO CREATE TABLE DocumentStore ( DocumentID INT IDENTITY PRIMARY KEY, Document VARBINARY (MAX) FILESTREAM NULL, DocGUID UNIQUEIDENTIFIER NOT NULL ROWGUIDCOL UNIQUE DEFAULT NEWID () ON Data_FG1) ON DocPartScheme (DocumentID) FILESTREAM_ON DocFSPartScheme; GO Si noti che per utilizzare la colonna DocumentID come colonna di partizionamento, è necessario che l'indice non cluster sottostante che applica il vincolo UNIQUE nel DocGUID sia esplicitamente posizionato su un filegroup, in modo che la colonna DocumentID possa fungere da colonna di partizionamento. Ciò significa che il cambio di partizione è possibile solo se i vincoli UNIQUE vengono disabilitati prima di eseguire tale cambio, in quanto si tratta di indici non allineati, per poi essere nuovamente abilitati in seguito. Proseguendo con l'esempio precedente, il codice seguente crea una tabella e quindi tenta un cambio di partizione. CREATE TABLE NonPartitionedDocumentStore ( DocumentID INT IDENTITY PRIMARY KEY, Document VARBINARY (MAX) FILESTREAM NULL, DocGUID UNIQUEIDENTIFIER NOT NULL ROWGUIDCOL UNIQUE DEFAULT NEWID ()); GO ALTER TABLE DocumentStore SWITCH PARTITION 2 TO NonPartitionedDocumentStore; GO 23 Il cambio di partizione non riesce con il messaggio seguente: Messaggio 7733, livello 16, stato 4, riga 1 Istruzione'ALTER TABLE SWITCH' non riuscita. L'elemento tabella 'FileStreamTestDB.dbo.DocumentStore' è partizionato mentre l'elemento 'UQ_Document_8CC1617F60ED59' non è partizionato. Se si disabilita l'indice univoco nella tabella di origine e si riprova, si ottiene il codice seguente: ALTER INDEX [UQ__Document__8CC331617F60ED59] ON DocumentStore DISABLE; GO ALTER TABLE FileStreamTest3 SWITCH PARTITION 2 TO NonPartitionedFileStreamTest3; GO Anche questa operazione non riesce, con il messaggio seguente: Messaggio 4947, livello 16, stato 1, riga 1 Istruzione ALTER TABLE SWITCH non riuscita. Nella tabella di origine 'FileStreamTestDB.dbo.DocumentStore' non esiste un indice identico all'indice 'UQ_NonParti_8CC3316103317E3D' nella tabella di destinazione 'FileStreamTestDB.dbo.NonPartitionedDocumentStore'. Gli indici univoci devono essere disabilitati sia nelle tabelle partizionate che non partizionate prima che il cambio possa continuare. ALTER INDEX [UQ__NonParti__8CC3316103317E3D] ON NonPartitionedDocumentStore DISABLE; GO ALTER TABLE DocumentStore SWITCH PARTITION 2 TO NonPartitionedDocumentStore; GO ALTER INDEX [UQ__NonParti__8CC3316103317E3D] ON NonPartitionedDocumentStore REBUILD WITH (ONLINE = ON); 24 ALTER INDEX [UQ__Document__8CC331617F60ED59] ON NonPartitionedDocumentStore REBUILD WITH (ONLINE = ON); GO Ulteriori informazioni sul partizionamento dei dati FILESTREAM verranno incluse in un imminente white paper sul partizionamento in SQL Server 2008. Bilanciamento del carico dei dati FILESTREAM Il partizionamento può essere utilizzato anche per creare uno schema di tabella che consenta un bilanciamento approssimativo del carico dei dati FILESTREAM tra più volumi. Ciò può essere consigliabile per vari motivi, ad esempio per restrizioni hardware o per consentire l'archiviazione in volumi diversi delle aree sensibili di una tabella. Il codice seguente mostra una funzione e uno schema di partizionamento basati sulla colonna uniqueidentifier che distribuisce i dati FILESTREAM in modo efficiente tra 16 volumi, effettuando nel contempo lo striping dei dati strutturati in due filegroup. USE master; GO -- Creare il database CREATE DATABASE Production ON PRIMARY (NAME = 'Production', FILENAME = 'E:\Production\Production.mdf'), FILEGROUP DataFilegroup1 (NAME = 'Data_FG1', FILENAME = 'F:\Production\Data_FG1.ndf'), FILEGROUP DataFilegroup2 (NAME = 'Data_FG2', FILENAME = 'G:\Production\Data_FG2.ndf'), FILEGROUP FSFilegroup0 CONTAINS FILESTREAM (NAME = 'FS_FG0', FILENAME = 'H:\Production\FS_FG0'), FILEGROUP FSFilegroup1 CONTAINS FILESTREAM (NAME = 'FS_FG1', FILENAME = 'I:\Production\FS_FG1'), FILEGROUP FSFilegroup2 CONTAINS FILESTREAM (NAME = 'FS_FG2', FILENAME = 'J:\Production\FS_FG2'), 25 FILEGROUP FSFilegroup3 CONTAINS FILESTREAM (NAME = 'FS_FG3', FILENAME = 'K:\Production\FS_FG3'), FILEGROUP FSFilegroup4 CONTAINS FILESTREAM (NAME = 'FS_FG4', FILENAME = 'L:\Production\FS_FG4'), FILEGROUP FSFilegroup5 CONTAINS FILESTREAM (NAME = 'FS_FG5', FILENAME = 'M:\Production\FS_FG5'), FILEGROUP FSFilegroup6 CONTAINS FILESTREAM (NAME = 'FS_FG6', FILENAME = 'N:\Production\FS_FG6'), FILEGROUP FSFilegroup7 CONTAINS FILESTREAM (NAME = 'FS_FG7', FILENAME = 'O:\Production\FS_FG7'), FILEGROUP FSFilegroup8 CONTAINS FILESTREAM (NAME = 'FS_FG8', FILENAME = 'P:\Production\FS_FG8'), FILEGROUP FSFilegroup9 CONTAINS FILESTREAM (NAME = 'FS_FG9', FILENAME = 'Q:\Production\FS_FG9'), FILEGROUP FSFilegroupA CONTAINS FILESTREAM (NAME = 'FS_FGA', FILENAME = 'R:\Production\FS_FGA'), FILEGROUP FSFilegroupB CONTAINS FILESTREAM (NAME = 'FS_FGB', FILENAME = 'S:\Production\FS_FGB'), FILEGROUP FSFilegroupC CONTAINS FILESTREAM (NAME = 'FS_FGC', FILENAME = 'T:\Production\FS_FGC'), FILEGROUP FSFilegroupD CONTAINS FILESTREAM (NAME = 'FS_FGD', FILENAME = 'U:\Production\FS_FGD'), FILEGROUP FSFilegroupE CONTAINS FILESTREAM (NAME = 'FS_FGE', FILENAME = 'V:\Production\FS_FGE'), FILEGROUP FSFilegroupF CONTAINS FILESTREAM (NAME = 'FS_FGF', FILENAME = 'W:\Production\FS_FGF'); GO 26 USE Production; GO -- Creare una funzione di partizione basata sugli ultimi 6 byte del GUID CREATE PARTITION FUNCTION LoadBalance_PF (UNIQUEIDENTIFIER) AS RANGE LEFT FOR VALUES ( CONVERT (uniqueidentifier, '00000000-0000-0000-0000-100000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-200000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-300000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-400000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-500000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-600000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-700000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-800000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-900000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-a00000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-b00000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-c00000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-d00000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-e00000000000'), CONVERT (uniqueidentifier, '00000000-0000-0000-0000-f00000000000')); GO -- Creare uno schema di partizionamento di FILESTREAM che consenta il mapping a 16 filegroup FILESTREAM CREATE PARTITION SCHEME LoadBalance_FS_PS AS PARTITION LoadBalance_PF TO ( FSFileGroup0, FSFileGroup1, FSFileGroup2, FSFileGroup3, 27 FSFileGroup4, FSFileGroup5, FSFileGroup6, FSFileGroup7, FSFileGroup8, FSFileGroup9, FSFileGroupA, FSFileGroupB, FSFileGroupC, FSFileGroupD, FSFileGroupE, FSFileGroupF); GO -- Creare uno schema di partizionamento dei dati per il round robin tra due filegroup CREATE PARTITION SCHEME LoadBalance_Data_PS AS PARTITION LoadBalance_PF TO ( DataFileGroup1, DataFileGroup2, DataFileGroup1, DataFileGroup2, DataFileGroup1, DataFileGroup2, DataFileGroup1, DataFileGroup2, DataFileGroup1, DataFileGroup2, DataFileGroup1, DataFileGroup2, DataFileGroup1, DataFileGroup2, DataFileGroup1, DataFileGroup2); GO -- Creare la tabella partizionata CREATE TABLE DocumentStore ( DocumentID INT IDENTITY, Document VARBINARY (MAX) FILESTREAM NULL, DocGUID UNIQUEIDENTIFIER NOT NULL ROWGUIDCOL DEFAULT NEWID (), CONSTRAINT DocStorePK PRIMARY KEY CLUSTERED (DocGUID), CONSTRAINT DocStoreU UNIQUE (DocGUID)) ON LoadBalance_Data_PS (DocGUID) FILESTREAM_ON LoadBalance_FS_PS; GO 28 Il bilanciamento del carico può essere facilmente testato tramite il codice seguente: SET NOCOUNT ON; GO -- Inserire 10000 righe per testare il bilanciamento del carico DECLARE @count INT = 0; WHILE (@count < 10000) BEGIN INSERT INTO DocumentStore DEFAULT VALUES; SET @count = @count + 1; END; GO -- Controllare la distribuzione SELECT COUNT ($PARTITION.LoadBalance_PF (DocGUID)) FROM DocumentStore GROUP BY $PARTITION.LoadBalance_PF (DocGUID); GO I risultati dell'esecuzione di esempio di questo test sono le righe 631, 641, 661, 640, 649, 637, 618, 618, 576, 608, 595, 645, 640, 616, 602 e 623 in ogni filegroup FILESTREAM da FS_FG0 a FS_FGF. Combinazioni di funzionalità e relative restrizioni Poiché la funzionalità FILESTREAM consente di archiviare dati nel file system, esistono alcune restrizioni e considerazioni da tenere presenti quando si combina FILESTREAM con altre funzionalità di SQL Server. In questa sezione viene fornita una panoramica delle combinazioni di funzionalità a cui prestare attenzione. Per ulteriori informazioni, vedere l'argomento "Compatibilità FILESTREAM con altre funzionalità di SQL Server" nella documentazione online di SQL Server 2008 (http://msdn.microsoft.com/it-it/library/bb895334.aspx). 29 Replica Sia la replica transazionale sia la replica di tipo merge supportano i dati FILESTREAM, ma è necessario tenere presenti molte considerazioni, come quelle indicate di seguito. Quando la topologia di replica include istanze in cui vengono utilizzate diverse versioni di SQL Server, esistono limitazioni sulle dimensioni dei dati che è possibile inviare alle istanze legacy. Le opzioni di filtro di replica determinano se l'attributo FILESTREAM viene replicato o meno mediante la replica transazionale. Le dimensioni massime del valore di dati varbinary (max) che possono essere replicate nella replica transazionale senza replicare l'attributo FILESTREAM sono pari a 2 GB. Quando si utilizza la replica di tipo merge, sia la replica sia FILESTREAM richiedono una colonna uniqueidentifier. Nell'utilizzo della replica di tipo merge, assicurarsi che i GUID nello schema della tabella siano sequenziali, ovvero utilizzare NEWSEQUENTIALID() invece di NEWID(). Mirroring del database Il mirroring del database non include il supporto per FILESTREAM. Non è possibile creare un filegroup FILESTREAM sul server principale né configurare il mirroring per un database in cui sono contenuti filegroup FILESTREAM. Crittografia I dati FILESTREAM non possono essere crittografati utilizzando i metodi di crittografia di SQL Server. Se Transparent Data Encryption è abilitato, i dati FILESTREAM non vengono crittografati. Clustering di failover FILESTREAM è completamente supportato dal clustering di failover. In tutti i nodi del cluster, FILESTREAM deve essere abilitato a livello di Windows e i contenitori di dati FILESTREAM devono essere collocati in risorse di archiviazione condivisa in modo che i dati siano disponibili in tutti i nodi. Per ulteriori informazioni, vedere l'argomento "Configurazione di FILESTREAM in un cluster di failover" nella documentazione online di SQL Server 2008 (http://msdn.microsoft.com/it-it/library/cc645886.aspx). Full-text L'indicizzazione full-text viene eseguita per una colonna FILESTREAM nello stesso modo in cui avviene per una colonna varbinary (max). La tabella deve includere una colonna aggiuntiva contenente l'estensione di file per i dati BLOB archiviati nella colonna FILESTREAM. Snapshot del database In SQL Server non è previsto il supporto di snapshot del database per i contenitori di dati FILESTREAM. Se un file di dati FILESTREAM è incluso in una clausola CREATE DATABASE ON, l'istruzione non verrà eseguita e verrà generato un errore. Se un database contiene dati FILESTREAM, sarà comunque possibile creare uno snapshot del database di filegroup normali. In questo caso, verrà restituito un messaggio di avviso e i filegroup FILESTREAM verranno contrassegnati come offline nello snapshot del database. Le query verranno eseguite come previsto sullo snapshot del database a meno che tentino di accedere ai dati FILESTREAM. In questo caso verrà generato un errore. 30 Un database non può essere ripristinato come snapshot se contiene dati FILESTREAM, in quanto non è possibile stabilire in che stato i dati FILESTREAM fossero nel momento rappresentato dallo snapshot del database. Viste, indici, statistiche, trigger e vincoli Le colonne FILESTREAM non possono far parte di una chiave di indice o essere specificate come colonna INCLUDE in un indice non cluster. È possibile definire una colonna calcolata che faccia riferimento a una colonna FILESTREAM, ma la colonna calcolata non può essere indicizzata. Non è possibile creare statistiche su colonne FILESTREAM. Non è possibile creare vincoli PRIMARY KEY, FOREIGN KEY e UNIQUE su colonne FILESTREAM. Le viste indicizzate non possono contenere colonne FILESTREAM, mentre le viste non indicizzate possono contenerle. Non è possibile definire trigger Instead-of su tabelle che contengono colonne FILESTREAM. Livelli di isolamento Quando si accede ai dati FILESTREAM tramite le API Win32, viene supportato solo il livello di isolamento READ-COMMITTED. L'accesso tramite Transact-SQL supporta anche i livelli di isolamento REPEATABLE-READ e SERIALIZABLE. Inoltre, utilizzando l'accesso tramite Transact-SQL è possibile effettuare letture dirty attraverso il livello di isolamento READ-UNCOMMITTED o l'hint per la query NOLOCK, ma con tale accesso non verranno visualizzati gli aggiornamenti in transito dei dati FILESTREAM. Backup e ripristino FILESTREAM funziona con tutti i modelli di recupero e tutti i tipi di backup e ripristino (completo, differenziale e di log). In una situazione di emergenza, se l'opzione CONTINUE_AFTER_ERROR viene specificata con un'opzione BACKUP o RESTORE, i dati FILESTREAM potrebbero non venire recuperati con perdita di dati zero (analogamente al recupero dei dati normali quando si specifica CONTINUE_AFTER_ERROR). Sicurezza L'istanza di SQL Server deve essere configurata per l'utilizzo della sicurezza integrata se è richiesto l'accesso Win32 ai dati FILESTREAM. Log shipping Il log shipping prevede il supporto di FILESTREAM. Sia sui server primari che secondari deve essere in esecuzione SQL Server 2008 o una versione successiva e FILESTREAM deve essere abilitato a livello di Windows. SQL Server Express SQL Server Express supporta FILESTREAM. Il limite delle dimensioni di 4 GB non include il contenitore di dati FILESTREAM. 31 Tuttavia, se dati FILESTREAM vengono inviati alla o dall'istanza di SQL Server Express tramite Service Broker, è necessario prestare attenzione, perché in Service Broker non è previsto il supporto dell'archiviazione di dati in formato FILESTREAM nelle code di trasmissione o destinazione. Ciò significa che se l'una o l'altra coda aumenta, potrebbe venire raggiunto il limite di 4 GB delle dimensioni del database. Un'alternativa in questo caso è l'utilizzo di uno schema in cui la conversazione di Service Broker funge da trasporto di notifiche che segnalano che è necessario inviare o ricevere dati FILESTREAM. La trasmissione effettiva dei dati FILESTREAM viene quindi eseguita tramite accesso remoto attraverso la condivisione FILESTREAM del contenitore di dati FILESTREAM dell'istanza di SQL Server Express. Considerazioni sull'ottimizzazione e sul benchmarking delle prestazioni Quando si ottimizza un carico di lavoro FILESTREAM è necessario tenere presenti alcune considerazioni importanti: Verificare che l'hardware sia configurato correttamente per FILESTREAM. Verificare che la generazione di nomi in formato 8.3 sia disabilitata in NTFS. Verificare che il rilevamento di data/ora dell'ultimo accesso sia disabilitato in NTFS. Verificare che il contenitore di dati FILESTREAM non si trovi su un volume frammentato. Verificare che la dimensione dei dati BLOB sia appropriata per l'archiviazione con FILESTREAM. Verificare che i contenitori di dati FILESTREAM dispongano di propri volumi dedicati. Un fattore importante da evidenziare riguarda le dimensioni del buffer utilizzato dal protocollo SMB, a sua volta utilizzato per il buffering delle letture dei dati FILESTREAM. Nei test effettuati con il sistema operativo Windows Server® 2003, dimensioni del buffer maggiori (multipli di circa 60 KB) tendono a migliorare la velocità effettiva. Buffer di dimensioni maggiori possono essere più efficienti su altri sistemi operativi. Vi sono poi ulteriori considerazioni per quanto riguarda il confronto di un carico di lavoro FILESTREAM con altre opzioni di archiviazione (dopo l'ottimizzazione del carico di lavoro FILESTREAM): Verificare che l'hardware di archiviazione e il livello RAID corrispondano. Verificare che l'impostazione di compressione del volume corrisponda. Tenere in considerazione se in FILESTREAM viene eseguito il write-through in base all'API utilizzata e alle opzioni specificate. Considerazioni sulla migrazione dei dati Uno scenario comune dell'utilizzo di SQL Server 2008 è la migrazione dei dati BLOB esistenti nelle risorse di archiviazione FILESTREAM. La descrizione dettagliata degli strumenti o del codice per effettuare tali migrazioni esula dall'ambito di questo white paper, tuttavia di seguito viene indicato un semplice flusso di lavoro da utilizzare: 32 Esaminare le considerazioni relative alle dimensioni dei dati per l'utilizzo di FILESTREAM per assicurarsi che le dimensioni medie dei dati interessati siano tali da rendere appropriata l'archiviazione FILESTREAM. Esaminare le informazioni disponibili sulle combinazioni di funzionalità e le relative limitazioni per assicurare che l'archiviazione FILESTREAM funzioni con tutti gli altri requisiti dell'applicazione. Seguire le indicazioni contenute nella precedente sezione "Considerazioni sull'ottimizzazione e sul benchmarking delle prestazioni". Verificare che nell'istanza di SQL Server venga utilizzata la sicurezza integrata e che FILESTREAM sia abilitato a livello di SQL Server e a livello di Windows. Verificare che la posizione del contenitore di dati FILESTREAM di destinazione disponga di spazio sufficiente per archiviare i dati BLOB di cui viene eseguita la migrazione. Creare i filegroup FILESTREAM richiesti. Duplicare gli schemi di tabella interessati, modificando in FILESTREAM le colonne BLOB necessarie. Eseguire la migrazione di tutti i dati non BLOB nel nuovo schema. Eseguire la migrazione di tutti i dati BLOB nelle nuove colonne FILESTREAM. Procedure consigliate per l'utilizzo di FILESTREAM Questa sezione contiene una raccolta di procedure consigliate emerse in seguito all'utilizzo di FILESTREAM durante le attività di test interne e pubbliche sulla versione provvisoria della funzionalità. Come tutte le procedure consigliate, si tratta di generalizzazioni che potrebbero non essere adatte a ogni situazione e scenario. Sono indicate di seguito, senza un ordine specifico: Quando possibile, è opportuno evitare più accodamenti di piccole dimensioni a un file FILESTREAM, perché ogni accodamento comporta la creazione di un intero nuovo file FILESTREAM. Ciò potrebbe risultare molto costoso per file FILESTREAM di grandi dimensioni. Se possibile, riunire più accodamenti in una colonna varbinary (max) e quindi accodarli alla colonna FILESTREAM al raggiungimento di una soglia di dimensione. Con un carico di lavoro di scrittura con numerosi thread multipli, valutare la possibilità di impostare il parametro AllocationSize per le API SqlFilestream o OpenSqlFilestream. Dimensioni iniziali più elevate di allocazione limiteranno il rischio di frammentazione a livello di file system, soprattutto se si combinano con una grande dimensione del cluster NTFS, come descritto in precedenza. Se i file FILESTREAM hanno grandi dimensioni, evitare aggiornamenti Transact-SQL che comportano accodamenti o anteposizioni di dati a un file. Queste operazioni provocano in genere lo spooling dei dati in tempdb e in un nuovo file fisico, con un conseguente impatto sulle prestazioni. Quando si legge un valore FILESTREAM, considerare gli aspetti indicati di seguito: o Se è necessario leggere solo i primi byte, valutare l'utilizzo della funzione SUBSTRING. o Se è necessario leggere l'intero file, valutare l'accesso tramite Win32. o Se è necessario leggere parti casuali del file, valutare la possibilità di aprire l'handle del file mediante SetFilePointer. o Per la lettura di un intero file, specificare il flag FILE_SEQUENTIAL_ONLY. o Utilizzare buffer con dimensioni multiple di 60 KB (come descritto in precedenza). È possibile ottenere le dimensioni di un file FILESTREAM senza dover aprire un handle del file aggiungendo una colonna calcolata persistente alla tabella in cui sono archiviate le dimensioni del file FILESTREAM. La colonna calcolata viene aggiornata mentre il file è già aperto per le operazioni di scrittura. Conclusione In questo white paper è stata descritta la funzionalità FILESTREAM di SQL Server 2008, che consente di archiviare i dati BLOB e di accedervi in modo efficiente utilizzando una combinazione di SQL Server 2008 e del file system NTFS. Per concludere, è utile ripetere i punti principali trattati nel white paper. 33 L'archiviazione FILESTREAM non è adatta in tutti i casi. In base a ricerche precedenti a al comportamento della funzionalità FILESTREAM, i dati BLOB di dimensioni di almeno 1 MB a cui non si accede tramite Transact-SQL sono i migliori candidati all'archiviazione come dati FILESTREAM. È necessario inoltre considerare anche il carico di lavoro dell'aggiornamento, poiché qualsiasi aggiornamento parziale a un file FILESTREAM comporta la creazione di una copia completa del file. Un carico di lavoro di aggiornamento particolarmente elevato potrebbe ridurre talmente le prestazioni da non giustificare l'utilizzo di FILESTREAM. Per assicurare la riuscita della distribuzione è opportuno valutare in dettaglio le combinazioni delle funzionalità. Ad esempio, in SQL Server 2008 RTM il mirroring del database non può essere utilizzato con i dati FILESTREAM e lo stesso vale per l'isolamento dello snapshot. La maggior parte delle altre combinazioni di funzionalità è supportata, ma per qualche funzionalità, come la replica, possono esistere delle restrizioni. In questo white paper non viene fornita una tassonomia completa delle funzionalità e della loro interazione. È pertanto consigliabile consultare le più recenti sezioni della documentazione online di SQL Server prima di procedere alla distribuzione, soprattutto perché alcune restrizioni potrebbero non essere più applicabili nelle versioni future. Infine, se FILESTREAM viene distribuito senza configurare correttamente Windows e SQL Server, potrebbe non essere possibile ottenere i livelli di prestazioni previsti. Per evitare problemi di prestazioni è consigliabile adottare le procedure consigliate e le indicazioni sulla configurazione descritte in precedenza. Per ulteriori informazioni http://www.microsoft.com/italy/server/sql: sito Web SQL Server http://technet.microsoft.com/it-it/sqlserver/: TechCenter di SQL Server http://msdn.microsoft.com/it-it/sqlserver/: risorse online per gli sviluppatori di SQL Server Il documento è risultato utile? Esprimere una valutazione utilizzando una scala compresa tra 1 (scarso) e 5 (eccellente), indicandone i motivi. Ad esempio: La valutazione è alta perché il documento contiene esempi validi, catture di schermate nitide, spiegazioni chiare o altri motivi? La valutazione è bassa perché il documento contiene esempi confusi, catture di schermate sfocate, spiegazioni poco chiare? I commenti aiuteranno Microsoft a migliorare la qualità dei white paper pubblicati. Commenti e suggerimenti. 34
