Condividi tramite

Procedure consigliate per SQL Server in una server farm di SharePoint

  • Articolo

SI APPLICA A:yes-img-132013 yes-img-162016 yes-img-192019 yes-img-seSubscription Edition no-img-sopSharePoint in Microsoft 365

Quando si configurano e gestiscono database relazionali di SharePoint Server 2016 e 2019 in SQL Server 2014 con Service Pack 1 (SP1), SQL Server 2016 o SQL Server 2017 RTM, è necessario scegliere opzioni che promuovono 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

[!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 SharePoint Server 2016 di server multiplo, scaricare Distribuzione di SQL Server 2016 PowerPivot e Power View in una farm di SharePoint 2016 multilivello.

Nota

[!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 è la distribuzione di SharePoint Server 2016 o 2019 in un ruolo farm Single-Server o SharePoint 2013 in un server autonomo, destinato allo sviluppo o al test, e non è consigliabile per l'uso in produzione. Per altre informazioni, vedere Descrizione di MinRole e dei servizi associati in SharePoint Server 2016 e 2019 e Installare SharePoint Server 2016 o 2019 in un 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.

  • A causa di potenziali problemi di prestazioni relativi alla gestione di più istanze DI SQL, è consigliabile usare una singola istanza di SQL Server per ogni server di database distribuito.

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

  • Per SharePoint Server 2013, i piani di manutenzione sono gestiti da SharePoint:

    • Le statistiche SQL vengono gestite dalla regola di integrità "I database usati da SharePoint hanno statistiche sugli indici obsolete" che chiama proc_updatestatics
    • Per i database del contenuto la proprietà Auto Update Statistics è impostata su False

  • Per SharePoint Server 2016 e 2019, l'amministratore SQL deve creare piani di manutenzione per i database del contenuto di SharePoint:

    • Le statistiche SQL non vengono gestite dalla regola di integrità "I database usati da SharePoint hanno statistiche sugli indici obsolete"
    • Per i database del contenuto la proprietà Auto Update Statistics è impostata su True `

  • 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 Impostare le opzioni di SQL Server.

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à

Come nel caso dei server front-end e dei server applicazioni, la configurazione per i server di database influisce sulle prestazioni di SharePoint Server. Alcuni database devono trovarsi nello stesso server di altri database. Al contrario, alcuni database non possono trovarsi nello stesso server di altri database. Per altre informazioni, vedere Descrizione di MinRole e dei servizi associati in SharePoint Server 2016 e 2019 e Pianificazione e configurazione della capacità di Archiviazione e SQL Server (SharePoint Server).For more information, see Description of MinRole and associated services in SharePoint Servers 2016 and 2019 and Storage and SQL Server capacity planning and configuration (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à Always On. 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à Always On supportano ora fino a nove repliche di disponibilità.

Nota

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

I gruppi di disponibilità AlwaysOn richiedono un cluster WSFC (Windows Server Failover Clustering). Per ogni gruppo di disponibilità creato, infatti, viene messo a punto un gruppo di risorse WSFC. Per ulteriori informazioni, vedere le seguenti risorse:

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 Configurare i database.

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

    Rango Elemento
    1 File di dati tempdb e log delle transazioni
    2 File di log delle transazioni del database del contenuto
    3 Database di ricerca, tranne il database di amministrazione della ricerca
    4 File di dati del 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.

    Rango Elemento
    1 File di dati tempdb e log delle transazioni
    2 File di dati del database del contenuto
    3 Database di ricerca, tranne il database di amministrazione della ricerca
    4 File di log delle transazioni del 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.

Consiglio

[!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 in considerazione gli aspetti seguenti:

    Importante

    [!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.

    • Le impostazioni predefinite per un nuovo database devono aumentare di 1 MB. Poiché questa impostazione predefinita per l'aumento automatico comporta un aumento delle dimensioni del database, non basarsi sull'impostazione predefinita. Usare invece le indicazioni fornite in Impostare le opzioni di SQL Server.

    • 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 attenzione quando si imposta la funzionalità di aumento automatico per i database di SharePoint. Se si imposta un database su aumento automatico come percentuale, ad esempio a una percentuale di crescita del 10% (%) , un database di 5 GB aumenta di 500 MB ogni volta che un file di dati deve essere espanso. In questo scenario, lo spazio su disco potrebbe esaurirsi.

      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.

    • Per un sistema di produzione gestito, considerare la crescita automatica come una semplice emergenza per una crescita imprevista. Non usare l'opzione di aumento automatico dei dati per gestire la crescita dei dati e dei log giorno per giorno. Impostare invece l'aumento automatico per consentire una dimensione approssimativa in un anno e quindi aggiungere un margine del 20% per l'errore. Impostare anche un avviso per notificare quando lo spazio del database è insufficiente o si avvicina a una 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.

Esaminare in modo completo il monitoraggio delle risorse. Non limitare il monitoraggio alle risorse specifiche di SQL Server. È altrettanto importante tenere traccia delle risorse seguenti nei computer che eseguono SQL Server: CPU, memoria, rapporto cache/riscontri 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

Vedere anche

Concetti

Panoramica di SQL Server in un ambiente SharePoint Server 2016 e 2019

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

Ulteriori risorse

Protezione di SharePoint: proteggere SQL Server negli ambienti di SharePoint