Condividi tramite

Procedure consigliate per SQL Server in una server farm di SharePoint

  • Articolo

 

**Si applica a:**SharePoint Foundation 2013, SharePoint Server 2013, SharePoint Server 2016

**Ultima modifica dell'argomento:**2018-03-09

**Riepilogo:**informazioni su come implementare best practice per SQL Server in una farm di SharePoint Server 2016 e SharePoint Server 2013.

Quando si configurano e gestiscono database relazionali di SharePoint Server 2016 su SQL Server 2014 con Service Pack 1 (SP1) o SQL Server 2016, è necessario scegliere le opzioni appropriate per favorire le prestazioni e la sicurezza. Analogamente, è necessario scegliere le opzioni appropriate per favorire le prestazioni e la sicurezza quando si configurano e gestiscono database relazionali di SharePoint Server 2013 su SQL Server 2008 R2 con Service Pack 1 (SP1), SQL Server 2012 e SQL Server 2014.

In questo articolo sono illustrate alcune procedure consigliate, ordinate in base alla sequenza di applicazione: dall'installazione e configurazione di SQL Server alla distribuzione di SharePoint Server, fino alla gestione della farm. La maggior parte delle procedure è valida per tutte le versioni di SQL Server. Le procedure che invece si applicano alle sole versioni di SQL Server sono illustrate in sezioni separate.

Nota

Se si prevede di usare i componenti Business Intelligence di SQL Server in una farm di SharePoint Server 2016 è necessario utilizzare SQL Server 2016 CTP 3.1 o versione successiva. È ora possibile scaricare SQL Server 2016 CTP 3.1 o versioni successive per utilizzare il componente aggiuntivo SQL Server PowerPivot per SharePoint. È anche possibile utilizzare PowerView installando SQL Server Reporting Services (SSRS) nella modalità integrata di SharePoint e il componente aggiuntivo SSRS front-end dal supporto di installazione di SQL Server.
Per ulteriori informazioni, scaricare il nuovo white paper Distribuzione di PowerPivot e PowerView di SQL Server 2016 in SharePoint 2016. Per informazioni dettagliate sulla configurazione e distribuzione di funzionalità di business intelligence in una farm di server multiplo SharePoint Server 2016, scaricare Distribuzione di PowerPivot e PowerView di SQL Server 2016 in una farm di SharePoint 2016 multilivello.

Nota

Se si prevede di usare componenti di Business Intelligence di SQL Server in una farm di SharePoint Server 2013 è necessario utilizzare SQL Server 2012 con Service Pack 1 (SP1) o SQL Server 2014. Per informazioni su BI di SQL Server 2012 con SP1 e SharePoint Server 2013, vedere Installare le funzionalità di Business Intelligence di SQL Server con SharePoint 2013 (SQL Server 2012 SP1). Per ulteriori informazioni su SQL Server 2014 e SharePoint Server 2013, vedere Installare le funzionalità di Business Intelligence di SQL Server 2014.

Importante

Le best practice descritte in questo articolo si applicano al sistema di gestione di database relazionali di SQL Server con SharePoint Server.

Utilizzare un server dedicato per SQL Server

Per garantire prestazioni ottimali per le operazioni della farm, si consiglia di installare SQL Server in un server dedicato in cui non siano in esecuzione altri ruoli di farm o non siano ospitati database di altre applicazioni. L'unica eccezione è costituita dalla distribuzione di SharePoint Server 2016 in un ruolo della farm di tipo server singolo o di SharePoint 2013 in un server autonomo, che tuttavia non è una soluzione consigliata per ambienti di produzione su larga scala. Per ulteriori informazioni, vedere Descrizione di MinRole e dei servizi associati in SharePoint Server 2016 e Installare SharePoint Server 2016 in un server singolo con SQL Server.

Nota

L'indicazione di utilizzare un server dedicato per database relazionali è valida anche per la distribuzione di SQL Server in ambienti virtuali.

Configurare specifiche impostazioni di SQL Server prima di distribuire SharePoint Server

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

  • Non abilitare la creazione automatica di statistiche nei database di contenuto di SharePoint. L'abilitazione automatica delle statistiche non è supportata per SharePoint Server. SharePoint Server configura le impostazioni necessarie durante il provisioning e l'aggiornamento. L'abilitazione manuale dell'opzione di creazione automatica di statistiche su un database SharePoint può modificare in modo significativo il piano di esecuzione di una query. Per la gestione delle statistiche, i database di SharePoint utilizzano un'apposita stored procedure (proc_UpdateStatistics) oppure fanno riferimento a SQL Server.

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

    Importante

    L'impostazione del massimo grado di parallelismo su un numero diverso può determinare l'adozione di un piano di query non ottimale e una conseguente riduzione delle prestazioni di SharePoint Server.

  • Per facilitare le operazioni di manutenzione, ad esempio lo spostamento di database in un altro server, è opportuno creare alias DNS che puntano all'indirizzo IP per tutte le istanze di SQL Server. Per altre informazioni sugli alias DNS o dei nomi host, vedere il post con le istruzioni per aggiungere un alias del nome host per un'istanza di SQL Server.

Per altre informazioni su queste impostazioni e opzioni di SQL Server, vedere Set.

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

Prima di eseguire la distribuzione di SharePoint Server è opportuno pianificare e applicare la protezione avanzata del server di database. Per altre informazioni, vedere:

Configurare i server di database per assicurare prestazioni e disponibilità

Analogamente a quanto avviene per i server front-end e i server applicazioni, la configurazione dei server di database influisce sulle prestazioni di SharePoint Server. Alcuni database, ad esempio, devono risiedere necessariamente nello stesso server, mentre altri devono trovarsi in server diversi. Per altre informazioni, vedere Descrizione di MinRole e dei servizi associati in SharePoint Server 2016 e Pianificazione e configurazione dell'archiviazione e della capacità di SQL Server (SharePoint Server).

Per informazioni sui database a disponibilità elevata che utilizzano il mirroring, vedere Mirroring di database (SQL Server).

Clustering di failover e gruppi di disponibilità AlwaysOn di SQL Server

SQL Server 2012 ha introdotto la funzionalità Gruppi di disponibilità AlwaysOn. Questa funzionalità è una soluzione a disponibilità elevata e di ripristino di emergenza che rappresenta un'alternativa al mirroring di database e alle soluzioni di log shipping. I gruppi di disponibilità AlwaysOn ora supportano fino a nove repliche di disponibilità.

Nota

Il mirroring di database verrà rimosso nelle versioni future di SQL Server. Si consiglia di utilizzare i gruppi di disponibilità Always On.

Per implementare i gruppi di disponibilità AlwaysOn è necessario un cluster WSFC (Windows Server Failover Clustering). Per ogni gruppo di disponibilità creato, infatti, viene messo a punto un gruppo di risorse WSFC. Per altre informazioni, vedere le risorse seguenti:

Progettare l'archiviazione per ottimizzare velocità e gestibilità

È consigliabile separare i dati tra i vari dischi del server di database e di classificarli in ordine di priorità. Se possibile, posizionare il database tempdb, i database del contenuto, il database del servizio di utilizzo, i database di ricerca e i log delle transazioni in dischi fisici separati. Più avanti sono riportate informazioni più dettagliate in merito. Per altre informazioni, vedere Configure databases.

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

    L'elemento classificato al livello più alto dovrebbe trovarsi nelle unità più veloci.

    1. Log delle transazioni e file di dati tempdb

    2. File di log delle transazioni dei database del contenuto

    3. Database di ricerca, tranne 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 log delle transazioni, come segue.

    L'elemento classificato al livello più alto dovrebbe trovarsi nelle unità più veloci.

    1. Log delle transazioni e file di dati tempdb

    2. File di dati dei database del contenuto

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

    4. File di log delle transazioni dei database del contenuto

  • Da test e indagini sugli utenti risulta che le prestazioni complessive delle farm possono essere rallentate in modo significativo da un'insufficiente capacità di I/O del disco per il database tempdb. Per evitare questo problema, allocare dischi dedicati per l'unità in cui sono archiviati i file di dati tempdb.

  • Per ottenere prestazioni ottimali, inserire l'unità in cui sono archiviati i file di dati tempdb in un array RAID 10. Il numero di file di dati tempdb deve essere uguale al numero di core della CPU e i file di dati tempdb devono essere tutti impostati sulla stessa dimensione.

  • Suddividere i dati dei database e i file di log delle transazioni tra più dischi. Se i dati e i file di log devono condividere gli stessi dischi per motivi di spazio, 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 i database del contenuto a utilizzo intensivo, assegnando a ognuno il proprio disco.

  • Per migliorare la gestibilità, far sì che le dimensioni dei database del contenuto non superino i 200 GB apportando modifiche mirate anziché limitando le dimensioni dei database.

    Nota

    Se si modificano manualmente le dimensioni dei database di SQL Server, possono verificarsi tempi di inattività del sistema nel momento in cui viene superata la capacità massima.

Una corretta configurazione dei sottosistemi di I/O è di fondamentale importanza per assicurare prestazioni e funzionamento ottimali dei sistemi SQL Server. Per altre informazioni, vedere Monitoraggio dell'utilizzo del disco.

Suggerimento

Tenere presente che il metodo di misurazione della velocità dei dischi non è lo stesso per i file di dati e i file di log. Non sempre le unità che risultano più veloci per i dati di database lo sono anche per i file di log. È necessario, infatti, prendere in considerazione i modelli di utilizzo, le attività di I/O e le dimensioni dei file.

Gestire attivamente l'aumento delle dimensioni dei file di dati e di log

Di seguito sono riportati alcuni consigli per gestire attivamente l'aumento delle dimensioni dei file di dati e di log.

  • Quando possibile, impostare in anticipo le dimensioni finali previste per tutti i file di dati e di log. In alternativa, 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.

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

    Importante

    È necessario tenere conto dei problemi di operatività e prestazioni associati all'utilizzo dell'opzione di aumento automatico delle dimensioni. Per altre informazioni, vedere Considerazioni per le impostazioni "aumento automatico" e "compattazione automatica" in SQL Server.

    • Per impostazione predefinita, la dimensione di un nuovo database aumenta in base a incrementi di 1 MB. Si consiglia tuttavia di non utilizzare questa impostazione poiché può comportare un aumento considerevole della dimensione del database, ma di seguire le indicazioni fornite in Set.

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

      Nota

      Prestare molta attenzione quando si imposta l'opzione di aumento automatico delle dimensioni per i database di SharePoint. Se si imposta il valore di aumento automatico come percentuale, ad esempio su 10%, la dimensione di un database di 5 GB aumenta di 500 MB ogni volta che è necessario espandere un file di dati, con il rischio di esaurire rapidamente lo spazio su disco.

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

    • Nel caso di un sistema di produzione gestito, l'aumento automatico delle dimensioni deve essere considerato unicamente come misura di emergenza per una crescita inattesa. Evitare quindi di utilizzare l'opzione di aumento automatico per gestire la crescita quotidiana di dati e log, ma impostarla in modo da raggiungere una dimensione approssimativa nell'arco di un anno, a cui aggiungere un margine di errore del 20%. Si consiglia inoltre di impostare un avviso per ricevere una notifica quando lo spazio nel database sta per essere esaurito o il database sta per raggiungere la dimensione massima.

  • 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.

Monitorare continuamente l'archiviazione e le prestazioni di SQL Server

Si consiglia di monitorare continuamente l'archiviazione e le prestazioni di SQL Server per accertarsi che il server di database di produzione gestisca in modo appropriato il carico a cui è sottoposto. Un monitoraggio continuo consente inoltre di definire benchmark utilizzabili per la pianificazione delle risorse.

Considerare il sistema di monitoraggio delle risorse in un quadro più ampio, non limitato alle risorse specifiche di SQL Server. Nei computer che eseguono SQL Server, infatti, è molto importante monitorare anche le risorse seguenti: CPU, memoria, rapporto riscontri cache e sottosistema di I/O.

In caso di rallentamento o sovraccarico di una o più risorse del server, tenere presente le indicazioni fornite negli articoli seguenti, in base al carico di lavoro attuale e previsto.

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

Compressione backup può velocizzare le operazioni di backup di SharePoint. È disponibile in SQL Server Standard ed Enterprise Edition. Se si imposta l'opzione di compressione nello script di backup o si configura SQL Server da comprimere per impostazione predefinita, è possibile ridurre notevolmente le dimensioni di backup del database e i log consegnati. Per ulteriori informazioni, vedere Compressione backup (SQL Server) e Compressione dati o Abilitare la compressione in una tabella o un indice

Riconoscimenti

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

  • Kay Unkroth, Senior Program Manager, SQL Server

  • Chuck Heinzelman, Senior Program Manager, SQL Server

See also

Panoramica di SQL Server in un ambiente SharePoint Server 2016
Pianificazione e configurazione dell'archiviazione e della capacità di SQL Server (SharePoint Server)

Protezione di SharePoint: proteggere SQL Server negli ambienti di SharePoint