Suggerimenti per l'archiviazione fisica (Office SharePoint Server)

La scelta dei dischi e delle matrici scelti, nonché le modalità con cui i dati vi vengono inseriti possono influire in modo significativo sulle prestazioni del sistema. Se non si ha sufficiente familiarità con i sistemi RAID (Redundant Array of Independent Disks), vedere le risorse seguenti:

• Per un'introduzione ai tipi di sistemi RAID utilizzati con Microsoft SQL Server 2008, vedere Livelli RAID e SQL Server (https://go.microsoft.com/fwlink/?linkid=105581&clcid=0x410).

• Per un confronto dei livelli RAID utilizzati con SQL Server 2008, vedere Confronto di implementazioni diverse di livelli RAID (https://go.microsoft.com/fwlink/?linkid=105582&clcid=0x410)

Questo argomento è dedicato principalmente a SQL Server 2008, sebbene siano supportati anche Microsoft SQL Server 2005 e Microsoft SQL Server 2000.

Utilizzare dischi e matrici RAID appropriati

Nell'elenco seguente vengono descritte alcune procedure consigliate e vengono indicati alcuni suggerimenti per la scelta del livello RAID e dei dischi rigidi ottimali:

• Le prestazioni del sistema migliorano man mano che aumentano il numero e la velocità dei dischi e delle matrici. È fondamentale mantenere bassi i valori di latenza e di accodamento per tutti i dischi.

• Per ottenere disponibilità e prestazioni elevate (lettura/scrittura casuali), configurare la matrice per RAID 10.

• Prima di configurare le matrici RAID, consultare il fornitore dell'hardware per l'archiviazione. È importante valutare se un database potrebbe beneficiare di un tempo di risposta per lettura casuale più veloce, ad esempio per contenuto Web statico per cui i sistemi RAID 5 e RAID 10 offrono prestazioni analoghe. D'altra parte, un tempo di risposta per scrittura casuale più veloce potrebbe essere più importante, ad esempio in un sito di collaborazione con operazioni di lettura e scrittura, in cui il sistema RAID 10 è più vantaggioso.

• Quando si configura una matrice RAID, è estremamente importante allineare il file system allo scostamento indicato dal fornitore. Se non si dispone di informazioni aggiuntive del fornitore, vedere Procedure consigliate per la predistribuzione del sottosistema di I/O in SQL Server(informazioni in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=105583&clcid=0x410).

Per ulteriori informazioni sul provisioning del RAID e sul sottosistema di I/O in SQL Server, vedere Procedure consigliate per la predistribuzione del sottosistema di I/O in SQL Server(informazioni in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=168612&clcid=0x410).

Prima di distribuire una nuova farm, è consigliabile effettuare il benchmark del sottosistema di I/O utilizzando lo strumento di benchmark SQLIO dei sottosistemi di dischi. Per i dettagli, vedere Strumento di benchmark SQLIO per sottosistemi di dischi(informazioni in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=105586&clcid=0x410).

Gestire l'aumento dei dati e delle dimensioni del file di registro in modo efficiente

• Valutare preventivamente le dimensioni dei dati e dei file di registro.

• È consigliabile non basarsi esclusivamente sulla funzionalità di aumento automatico delle dimensioni, bensì gestire in modo manuale l'aumento delle dimensioni dei dati e dei file di registro. È possibile abilitare l'aumento automatico per motivi di sicurezza, ma è necessario gestire attivamente l'aumento delle dimensioni dei dati e dei file di registro.

• Configurare le impostazioni relative all'aumento automatico delle dimensioni in base alle esigenze specifiche della distribuzione.

  • Quando si pianificano database del contenuto che superano le dimensioni consigliate (100 GB), impostare il valore dell'aumento automatico delle dimensioni del database specificando un numero di megabyte fisso anziché una percentuale. In questo modo è possibile ridurre la frequenza con cui SQL Server aumenta le dimensioni di un file. L'aumento delle dimensioni dei file è un'operazione di blocco, che comporta l'occupazione del nuovo spazio tramite l'aggiunta di pagine vuote.

    Nota

    SQL Server 2008 in esecuzione su Windows Server 2003 supporta l'inizializzazione immediata dei file, che può ridurre notevolmente l'impatto sulle prestazioni determinato da un'operazione di aumento delle dimensioni dei file. Per ulteriori informazioni, vedere Inizializzazione di file di database (https://technet.microsoft.com/it-it/library/ms179316.aspx).

  • Quando si pianificano database del contenuto con dimensioni inferiori a quelle consigliate (100 GB), impostare le dimensioni dei database creati su 100 GB utilizzando la proprietà ALTER DATABASE MAXSIZE.

  • Se lo spazio su disco è limitato o non è possibile modificare le dimensioni dei database, è consigliabile impostare il valore dell'aumento automatico delle dimensioni specificando una percentuale fissa. È ad esempio possibile configurare un aumento automatico del 10% per i database con dimensioni inferiori a 500 GB e un numero fisso di megabyte per i database con dimensioni superiori a 500 GB.

• Mantenere un livello di spazio disponibile almeno del 25% nei dischi per consentire l'aumento delle dimensioni e modelli di utilizzo massimo. Se si gestisce la crescita aggiungendo dischi a una matrice RAID o allocando maggiore capacità di archiviazione, monitorare attentamente le dimensioni dei dischi per evitare che lo spazio si esaurisca.

Limitare le dimensioni del database del contenuto per migliorare la gestibilità

Pianificare dimensioni dei database che migliorino la gestibilità e le prestazioni dell'ambiente.

• Nella maggior parte dei casi, per ottimizzare le prestazioni di Microsoft Office SharePoint Server 2007 si sconsiglia l'utilizzo di database del contenuto con dimensioni maggiori di 100 GB. Se il progetto richiede un database più grande di 100 GB, tenere conto delle indicazioni seguenti:

  • Non utilizzare un database più grande di 100 GB per più di una raccolta siti.

  • Utilizzare una soluzione di backup differenziale, ad esempio SQL Server 2008 o Microsoft System Center Data Protection Manager 2007, anziché gli strumenti incorporati di backup e ripristino.

  • Testare il server che esegue SQL Server 2008 e il sottosistema di I/O prima di spostare una soluzione che dipende da un database del contenuto da 100 GB.

• Limitare le dimensioni dei database del contenuto che contengono più raccolte siti a circa 100 GB.

Separare e definire le priorità dei dati tra i dischi

È consigliabile posizionare i database tempdb e del contenuto e i registri delle transazioni di SQL Server 2008 in dischi rigidi fisici distinti.

Nell'elenco seguente vengono descritte alcune procedure consigliate e vengono indicati alcuni suggerimenti per definire le priorità dei dati:

• Quando si definisce la priorità dei dati tra i dischi più veloci, rispettare la classificazione seguente:

  1. File di dati e registri delle transazioni del database tempdb

  2. File di registro delle transazioni del database

  3. Database di ricerca

  4. File di dati del database

  In un sito portale orientato particolarmente alla lettura, definire la priorità dei dati tramite i registri.

• Esaminando i dati di testing e ottenuti dai clienti, è stato rilevato che le prestazioni di una farm di Microsoft Office SharePoint Server 2007 possono essere ridotte in modo significativo da un sistema di I/O su disco per il database tempdb. Per evitare questo problema, è necessario allocare dischi dedicati per tale database. Se si prevede o si rileva un carico di lavoro elevato, ovvero se per il numero medio di operazioni di lettura o di scrittura sono necessari più di 20 millisecondi (ms), per eliminare il collo di bottiglia potrebbe essere necessario distribuire i file tra i dischi o sostituire i dischi esistenti con altri più veloci.

• Per ottenere prestazioni migliori, posizionare il database tempdb in una matrice RAID 10. Il numero di file di dati di tempdb deve corrispondere a quello delle CPU core e le dimensioni dei file di dati di tempdb devono essere impostate sullo stesso valore. A questo scopo, considerare i processori dual core come due CPU e ogni processore che supporti la tecnologia hyperthreading come una CPU singola. Per ulteriori informazioni, vedere Ottimizzazione delle prestazioni di tempdb (https://go.microsoft.com/fwlink/?linkid=148537&clcid=0x410).

• Separare i file di registro delle transazioni e i dati del database in dischi diversi. Se è necessario che i file condividano i dischi a causa delle dimensioni troppo ridotte per giustificare l'utilizzo di un intero disco o di un'intera stripe, o se non si dispone di spazio su disco sufficiente, posizionare i file con motivi di utilizzo diversi sullo stesso disco per minimizzare le richieste di accesso simultanee.

• Per informazioni sulla configurazione di tutti i registri e dei database di ricerca per l'ottimizzazione delle operazioni di scrittura per la soluzione di archiviazione specifica, consultare il fornitore dell'hardware di archiviazione.

• Allocare assi dedicati per ogni database di ricerca.

Utilizzare più file di dati per i database del contenuto con dimensioni elevate e il database di ricerca del provider di servizi condivisi

Per migliorare le prestazioni dei database del contenuto con dimensioni elevate e del database di ricerca del provider di servizi condivisi, è consigliabile utilizzare più file di dati.

Utilizzare più file di dati per i database del contenuto

Per ottimizzare le prestazioni, tenere conto dei suggerimenti seguenti:

• Creare file solo nel filegroup principale del database.

• Distribuire i file in dischi distinti.

• Il numero di file di dati deve essere minore o uguale al numero di CPU core. A questo scopo, considerare i processori dual core come due CPU e ogni processore che supporti la tecnologia hyperthreading come una CPU singola.

• Creare file di dati con dimensioni uguali.

Per ulteriori informazioni sulla creazione e la gestione dei filegroup, vedere File e filegroup fisici del database (https://go.microsoft.com/fwlink/?linkid=117909&clcid=0x410).

Utilizzare più file di dati per il database di ricerca del provider di servizi condivisi

Per i database di ricerca è consigliabile utilizzare i filegroup per separare le tabelle utilizzate principalmente per la ricerca per indicizzazione e l'elaborazione delle query. Il filegroup che ospita le tabelle maggiormente interessate dalla ricerca per indicizzazione dovrebbe essere spostato su un set di dischi diverso da quello del filegroup primario, per limitare il più possibile l'impatto sul sottosistema di I/O.

La ricerca per indicizzazione interessa principalmente le tabelle di database elencate nella tabella seguente:

Per ottimizzare le prestazioni per i database di ricerca, applicare i suggerimenti seguenti:

• Spostare le tabelle fuori dal filegroup primario per il database.

• Distribuire i file su dischi distinti.

Problemi noti

Nelle sezioni seguenti sono illustrati i problemi noti relativi all'utilizzo di filegroup per il database di ricerca.

Backup e ripristino

Le funzioni di backup e ripristino di Prodotti e tecnologie SharePoint non consentono la gestione dei filegroup. Non è in alcun modo possibile indicare dove ripristinare un nuovo filegroup. Il processo di ripristino tenta di collocare il filegroup interessato dalla ricerca per indicizzazione nella stessa unità in cui si trovava al momento del backup. Per eseguire il ripristino, è necessario che le lettere di unità utilizzate per il filegroup primario e quello di ricerca per indicizzazione siano uguali a quelle utilizzate al momento del backup iniziale.

Aggiornamenti, Service Pack e hotfix futuri

Tutti gli aggiornamenti, i Service Pack e gli hotfix applicati al server potrebbero modificare l'indice spostato nel filegroup interessato dalla ricerca per indicizzazione o aggiungere un nuovo indice a una delle tabelle spostate in tale filegroup. In questi casi, l'indice verrà nuovamente spostato o ricostruito nel filegroup primario. 

A causa del rischio di modifica degli indici, dopo l'applicazione di qualsiasi aggiornamento è consigliabile ripetere il processo di spostamento delle tabelle nel filegroup eseguendo gli script disponibili nel blog dedicato alla ricerca di contenuti nell'organizzazione.

Richiede almeno SQL Server 2005, consigliato SQL Server 2008

Lo script del team di prodotto utilizzato per spostare gli indici utilizza caratteristiche rilasciate in SQL Server 2005 e mantenute in SQL Server 2008. Questa ottimizzazione può pertanto essere eseguita solo se si utilizza SQL Server 2005

Rispettare i requisiti di configurazione indicati dal fornitore

Per ottenere prestazioni ottimali quando si configura una matrice di archiviazione fisica, rispettare i requisiti di configurazione hardware indicati dal fornitore dell'hardware di archiviazione anziché basarsi sui valori predefiniti del sistema operativo.

Se non si ottengono informazioni aggiuntive dal fornitore, è consigliabile utilizzare l'utilità di configurazione dischi DiskPart.exe disk per configurare l'archiviazione per SQL Server 2008. Per ulteriori informazioni, vedere Procedure consigliate per la predistribuzione del sottosistema di I/O(informazioni in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=105583&clcid=0x410).

Scaricare il manuale

Questo argomento è incluso nel manuale seguente, che può essere scaricato per una lettura e una stampa più agevoli:

• Pianificazione e architettura per Office SharePoint Server 2007, parte 2 (https://go.microsoft.com/fwlink/?linkid=85548&clcid=0x410)

Vedere l'elenco completo dei manuali disponibili visitando la pagina Web Contenuto scaricabile per Office SharePoint Server 2007 (https://go.microsoft.com/fwlink/?linkid=89172&clcid=0x410).