Procedure consigliate per SQL Server 2008 in una farm di SharePoint Server 2010

Si applica a: SharePoint Server 2010

Ultima modifica dell'argomento: 2016-11-30

In questo articolo vengono descritte le procedure consigliate per la configurazione e la manutenzione di Microsoft SQL Server 2008 in un ambiente Microsoft SharePoint Server 2010. L'ordine delle procedure si basa sulla sequenza di applicazione, dall'installazione e configurazione di SQL Server 2008 alla distribuzione di SharePoint Server fino alla manutenzione della farm.

Questo articolo fa parte di una serie di articoli sulle procedure consigliate per SharePoint Server. Per altri articoli della serie, vedere Procedure consigliate (SharePoint Server 2010). Per ulteriori informazioni e risorse sulle procedure consigliate per SharePoint Server 2010, vedere il Centro risorse sulle procedure consigliate (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=220280&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

1. Utilizzare un server dedicato per SQL Server 2008

Per garantire prestazioni ottimali per le operazioni della farm, è consigliabile installare SQL Server 2008 in un server dedicato che non esegue altri ruoli di farm né ospita database di altre applicazioni. La sola eccezione è rappresentata dalla distribuzione di SharePoint Server 2010 in un server autonomo, una soluzione sconsigliata per ambienti di produzione su larga scala.

2. Configurare specifiche impostazioni di SQL Server 2008 prima di distribuire SharePoint Server 2010

Per garantire uniformità di comportamento e prestazioni, configurare le opzioni e impostazioni seguenti prima di distribuire SharePoint Server 2010.

• Non abilitare la creazione automatica di statistiche in un SQL Server che supporta SharePoint Server.

• Impostare il massimo grado di parallelismo (MAXDOP) su 1 per le istanze di SQL Server che ospitano database di SharePoint Server 2010, per garantire che ogni richiesta venga gestita da un singolo processo di SQL Server.

  Importante

  In un ambiente SharePoint Server qualsiasi altra impostazione causerà la selezione di un piano di query non ottimale per l'esecuzione, con uno scadimento generale delle prestazioni.

• Per facilitare la manutenzione e l'eventuale spostamento del database in caso di necessità futura, configurare alias di connessione di SQL Server per ogni server di database della farm.

Per ulteriori informazioni, vedere Impostare le opzioni di SQL Server.

3. Applicare la protezione avanzata del server di database prima di distribuire SharePoint Server 2010

Prima di distribuire SharePoint Server 2010 è consigliabile pianificare e applicare la protezione avanzata del server di database. Ciò include la protezione del ruolo del server di database per SharePoint Server e SQL Server. Per ulteriori informazioni, vedere:

• Pianificare la protezione avanzata (SharePoint Server 2010)

• Applicare a SQL Server la protezione avanzata per gli ambienti SharePoint (SharePoint Server 2010)

4. Configurare i server di database per assicurare prestazioni e disponibilità

Analogamente a quanto avviene per i server Web e i server applicazioni, la configurazione dei server di database influisce sulle prestazioni di SharePoint Server 2010. Alcuni database necessitano di condividere la posizione con altri specifici database o di trovarsi in una posizione separata rispetto ad altri specifici database. Per ulteriori informazioni, vedere:

• Panoramica del dimensionamento e della gestione della capacità per SharePoint Server 2010

• Pianificazione e configurazione dell'archiviazione e della capacità di SQL Server (SharePoint Server 2010)

Per i database a disponibilità elevata che utilizzano il mirroring, consultare le indicazioni sulle procedure consigliate in Procedure consigliate per il mirroring del database e considerazioni sulle prestazioni (https://go.microsoft.com/fwlink/?linkid=185119&clcid=0x410).

5. Progettare l'archiviazione per ottimizzare velocità e gestibilità

È consigliabile separare i dati tra i dischi del server di database e classificarli in ordine di priorità. Se possibile, posizionare il database tempdb, i database del contenuto, il database servizio di utilizzo, i database di ricerca e i registri delle transazioni di SQL Server 2008 in dischi fisici separati. Nell'elenco riportato di seguito vengono illustrate alcune indicazioni e procedure consigliate per la gestione di dati e registri e la loro classificazione in ordine di priorità. Per ulteriori informazioni, vedere Configurare i database.

• Per i siti di collaborazione o a elevata frequenza di aggiornamento, utilizzare la classificazione seguente per la distribuzione dell'archiviazione:

  1. File di dati e registri delle transazioni di tempdb sui dischi più veloci

  2. Registri delle transazioni dei database del contenuto

  3. Database di ricerca, eccetto il database di amministrazione della ricerca

  4. File di dati dei database del contenuto

• In un sito portale fortemente orientato alla lettura assegnare una priorità superiore ai dati e alle ricerche rispetto ai registri delle transazioni, come segue:

  1. File di dati e registri delle transazioni di tempdb sui dischi più veloci

  2. File di dati dei database del contenuto

  3. Database di ricerca, eccetto il database di amministrazione della ricerca

  4. Registri delle transazioni dei database del contenuto

• Dati ottenuti da test e dagli utenti indicano che le prestazioni complessive delle farm possono essere rallentate in modo significativo da un'insufficiente capacità di I/O del disco per tempdb. Per evitare questo problema, allocare dischi dedicati per tempdb.

• Per ottenere prestazioni ottimali, posizionare il database tempdb in un array RAID 10. Il numero di file di dati di tempdb deve essere uguale al numero di CPU core e i file di dati di tempdb devono essere impostati sulla stessa dimensione.

• Suddividere i dati dei database e i registri delle transazioni tra più dischi. Se i file devono condividere i dischi perché di dimensioni troppo ridotte per giustificare un intero disco o stripe oppure se non si dispone di spazio sufficiente su disco, posizionare i file con modelli di utilizzo diversi nello stesso disco per ridurre al minimo le richieste di accesso simultaneo.

• Utilizzare più file di dati per database del contenuto a utilizzo intensivo, assegnando a ognuno il proprio disco

• Per migliorare la gestibilità, limitare le dimensioni dei database del contenuto a 50 GB

Una corretta configurazione dei sottosistemi di I/O è molto importante per assicurare prestazioni e funzionamento ottimali dei sistemi SQL Server. Per ulteriori informazioni, vedere Storage Top 10 Best Practices

6. Gestire attivamente l'aumento delle dimensioni dei file di dati e di registro

È consigliabile gestire attivamente l'aumento delle dimensioni dei file di dati e di registro tenendo conto delle indicazioni riportate di seguito:

• Ove possibile, impostare anticipatamente le dimensioni finali previste per tutti i file di dati e di registro, oppure incrementarle periodicamente a intervalli definiti, ad esempio mensili o semestrali, oppure prima dell'implementazione di un nuovo sito a elevati volumi di archiviazione, ad esempio durante la migrazione di file.

• È consigliabile abilitare l'aumento automatico delle dimensioni dei database come misura protettiva, per evitare di esaurire lo spazio nei file di dati e di registro. Tenere presente quanto segue:

  Importante

  È necessario tenere conto dei problemi operativi e di prestazioni associati all'utilizzo dell'opzione di aumento automatico delle dimensioni. Per ulteriori informazioni, vedere Considerazioni per le impostazioni "aumento automatico delle dimensioni" e "compattazione automatica" in SQL Server (https://go.microsoft.com/fwlink/?linkid=117750&clcid=0x410)

  • Non fare affidamento sulle impostazioni predefinite per l'aumento automatico delle dimensioni ma seguire le indicazioni fornite in Impostare le opzioni di SQL Server.

  • Impostare i valori di aumento automatico come percentuale invece di un numero fisso di megabyte. Più il database è grande, maggiore deve essere l'incremento.

    Si consideri ad esempio uno scenario dove il contenuto viene incrementato gradualmente, di 100 MB alla volta, con l'aumento automatico impostato su 10 MB. Sorge però all'improvviso l'esigenza di un grande spazio di archiviazione dati per un nuovo sito di gestione di documenti, si supponga con una dimensione iniziale di 50 GB. A questo punto l'aumento automatico dovrà essere di 500 MB, non di 10 MB.

  • Nel caso di un sistema di produzione gestito, l'aumento automatico delle dimensioni deve essere considerato unicamente una misura di emergenza per una crescita inattesa. Evitare di gestire la crescita quotidiana di dati e registri utilizzando l'opzione di aumento automatico.

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

7. Monitorare continuamente l'archiviazione e le prestazioni di SQL Server

È consigliabile monitorare continuamente l'archiviazione e le prestazioni di SQL Server, per assicurarsi che il server di database di produzione gestisca adeguatamente il carico cui è sottoposto. Un monitoraggio continuo consente inoltre di stabilire benchmark utilizzabili per la pianificazione delle risorse.

Considerare il monitoraggio delle risorse da un punto di vista olistico; non limitarlo alle risorse specifiche di SQL Server. È ugualmente importante monitorare i componenti seguenti di un server che esegue SQL Server: CPU, memoria, rapporto riscontri cache e sottosistema di I/O.

In caso di rallentamento o sovraccarico di uno o più componenti del server di database, analizzare la strategia appropriata in base al carico di lavoro attuale e previsto. Per ulteriori informazioni, vedere:

• Monitoraggio e ottimizzazione delle prestazioni (https://go.microsoft.com/fwlink/?linkid=131173&clcid=0x410)

• Risolvere i problemi relativi alle prestazioni in SQL Server 2008 (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=168448&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

• Performance Monitoring Getting Started Guide

8. Utilizzare la compressione dei backup per velocizzare i backup e ridurre le dimensioni dei file

La compressione dei backup può velocizzare i backup di SharePoint ed è disponibile in SQL Server 2008 Enterprise Edition o SQL Server 2008 R2 Standard Edition. Impostando l'opzione di compressione nello script di backup o configurando il server che esegue SQL Server in modo da effettuare la compressione per impostazione predefinita, è possibile ridurre in modo significativo le dimensioni dei backup dei database e dei registri inviati. Per ulteriori informazioni, vedere Compressione backup (SQL Server) (https://go.microsoft.com/fwlink/?linkid=129381&clcid=0x410) e Compressione dei dati: strategia, pianificazione della capacità e procedure consigliate (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=223674&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

Ringraziamenti

Il team addetto alla pubblicazione di contenuti per SharePoint Server 2010 ringrazia gli autori seguenti per il contributo offerto per questo articolo:

• Stephen Dillon, Senior Consultant

• Gus Apostal, Senior Program Manager, SQL Server