Pianificazione e configurazione dell'archiviazione e della capacità di SQL Server (SharePoint Server)
**Si applica a:**SharePoint Server 2013, SharePoint Server 2016
**Ultima modifica dell'argomento:**2018-03-09
Sintesi: informazioni su come pianificare e configurare il livello di database e archiviazione per SQL Server in SharePoint Server 2016 e SharePoint Server 2013.
Le informazioni sulla pianificazione della capacità contenute in questo documento possono essere usate come linee guida per la pianificazione e la configurazione del livello di database e archiviazione di SQL Server in un ambiente SharePoint Server. Queste informazioni si basano su test eseguiti presso Microsoft su proprietà attive. I risultati ottenuti tuttavia possono variare a seconda delle attrezzature usate e dalle caratteristiche e funzionalità implementate per i propri siti.
Nota
I test delle capacità e delle prestazioni illustrati in questo articolo si riferiscono a Microsoft SQL Server 2014 con Service Pack 1 (SP1), Microsoft SQL Server 2016, SQL Server 2017 RTM e SharePoint Server 2016. I risultati ottenuti sono gli stessi di SharePoint Server 2013.
Anche se non sono stati eseguiti test su SQL Server 2014 (SP1), SQL Server 2016 o SQL Server 2017 RTM, è possibile usare questi risultati di test come guida per pianificare e configurare il livello del database e di archiviazione di SQL Server in un ambiente SharePoint Server 2016. Per un'esercitazione sulla configurazione e sull'ottimizzazione di SQL Server 2012, vedere SQL Server 2012 per SharePoint Server 2013.
Poiché SharePoint Server viene spesso eseguito in ambienti in cui i database sono gestiti da amministratori di database di SQL Server separati, questo documento deve essere usato congiuntamente dai responsabili dell'implementazione di farm di SharePoint Server e dagli amministratori di database di SQL Server. Si presuppone una conoscenza approfondita sia di SharePoint Server che di SQL Server.
In questo articolo si presuppone la familiarità con i concetti illustrati inInformazioni sulla pianificazione di prestazioni e capacità per SharePoint Server 2013.
Processo di progettazione e configurazione del livello di database e archiviazione di SharePoint Server 2016
È consigliabile suddividere il processo di progettazione dell'archiviazione e del livello di database nei passaggi descritti più avanti. In queste sezioni vengono fornite informazioni dettagliate su ogni passaggio di progettazione, inclusi i requisiti di archiviazione e le procedure consigliate:
Ottenere informazioni sui requisiti di archiviazione e di spazio e I/O di SQL Server
Scegliere la versione e l'edizione di SQL Server
Progettare l'architettura di archiviazione in base ai requisiti di capacità e di I/O
Valutare i requisiti di memoria
Informazioni sui requisiti della topologia di rete
Configurare SQL Server
Convalidare e monitorare l'archiviazione e le prestazioni di SQL Server
Ottenere informazioni sui requisiti di archiviazione e di spazio e I/O di SQL Server
La progettazione dell'archiviazione è determinata da diversi fattori dell'architettura di SharePoint Server. I fattori chiave sono costituiti dalla quantità di contenuto, dalle caratteristiche abilitate, dalle applicazioni di servizio distribuite, dal numero di farm e dai requisiti di disponibilità.
Prima di iniziare a pianificare l'archiviazione, è consigliabile acquisire familiarità con i database utilizzabili in SharePoint Server.
Contenuto della sezione:
Database usati da SharePoint Server
Informazioni su SQL Server e sulle operazioni di I/O al secondo
Valutare i requisiti di operazioni di I/O al secondo e archiviazione di base
Valutare i requisiti di archiviazione e operazioni di I/O al secondo delle applicazioni di servizio
Determinare i requisiti di disponibilità
Database usati da SharePoint Server
I database installati con SharePoint Server 2016 dipendono dalle applicazioni di servizio in uso nell'ambiente. Tutti gli ambienti SharePoint Server 2016 si basano sui database di sistema di SQL Server. In questa sezione viene fornito un riepilogo dei database installati con SharePoint Server 2016. Per informazioni dettagliate sui database, vedere Tipi di database e relative descrizioni in SharePoint Server.
Per una panoramica grafica dei database che supportano SharePoint Server 2016, vedere Guida di riferimento rapida: Database di SharePoint Server 2016. È anche possibile scaricare questo poster di database SharePoint Server 2016, un PDF o file Visio.
Nota
Alcuni database di SharePoint Server, del motore di database di SQL Server e di SQL Server Reporting Services (SSRS) prevedono requisiti o raccomandazioni specifiche relative al percorso. Per informazioni sui percorsi di questi database, vedere Tipi di database e relative descrizioni in SharePoint Server.
I database seguenti sono i database di sistema di SharePoint Server e vengono installati automaticamente.
Configurazione
Contenuto di Amministrazione centrale
Contenuto (uno o più database)
L'elenco seguente include le applicazioni di servizio di SharePoint Server con database:
Servizio di gestione app
App per SharePoint
Servizio di integrazione applicativa dei dati
Metadati gestiti
PerformancePoint Services
Project Server (solo SharePoint Server 2013)
Servizio di ricerca
Amministrazione ricerca
Report di analisi
Ricerca per indicizzazione
Collegamento
servizio di archiviazione sicura
Servizio di traduzione SharePoint
Servizio SQL Server Power Pivot
Servizio informazioni sullo stato
Servizio impostazioni di sottoscrizione
Raccolta dati di integrità e utilizzo
Servizio profili utente
Profilo
Social tagging
Sincronizzazione
Word Automation Services
L'elenco seguente include i database SharePoint Foundation 2013:
Configurazione
Contenuto di Amministrazione centrale
Contenuto (uno o più database)
Servizio di gestione app
Applicazione servizio di ricerca:
Amministrazione della ricerca
Report di analisi (uno o più database)
Ricerca per indicizzazione (uno o più database)
Collegamento (uno o più database)
Servizio di archiviazione sicura
Applicazione di servizio per impostazioni di sottoscrizione (se abilitata tramite Windows PowerShell)
Servizio per raccolta dati di utilizzo e integrità
Word Automation Services
Nel caso di un'ulteriore integrazione con SQL Server, è possibile che nell'ambiente siano inclusi altri database, come illustrato nello scenario seguente. È possibile utilizzare SQL Server PowerPivot per SharePoint in un ambiente SharePoint Server 2016 solo se si usa SQL Server 2016 RTM Enterprise Edition e SQL Server 2016 SQL Server Analysis Services (SSAS). Se in uso, è necessario pianificare anche il supporto del database dell'applicazione PowerPivot e il carico aggiuntivo sul sistema. Per ulteriori informazioni, scaricare il nuovo documento Distribuzione di SQL Server 2016 PowerPivot e Power View 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.
È possibile usare il componente aggiuntivo SQL Server 2016 Reporting Services (SSRS) con qualsiasi ambiente SharePoint Server 2016. Se si usa il componente aggiuntivo, pianificare il supporto per i due database di SQL Server Reporting Services e il carico aggiuntivo necessario per SQL Server Reporting Services.
È possibile usare SQL Server 2012 PowerPivot per SharePoint 2013 in un ambiente SharePoint 2013 che include SQL Server 2008 R2 Enterprise Edition e SQL ServerAnalysis Services. Se è in uso, è inoltre necessario pianificare il supporto per il database dell'applicazione PowerPivot e il carico aggiuntivo sul sistema. Per altre informazioni, vedere Pianificare una distribuzione di PowerPivot in una farm di SharePoint e l'articolo di SQL Server PRO relativo all'uso di PowerPivot e Power View in Microsoft Excel 2013.
È possibile usare il plug-in SQL Server 2008 R2 Reporting Services (SSRS) con qualsiasi ambiente SharePoint 2013. Se si usa il plug-in, pianificare il supporto per i due database di SQL Server 2008 R2 Reporting Services e il carico aggiuntivo necessario per SQL Server 2008 R2 Reporting Services.
Informazioni su SQL Server e sulle operazioni di I/O al secondo
In un server che ospita un'istanza di SQL Server è estremamente importante per il server ottenere la risposta più rapida possibile dal sottosistema di I/O.
Un numero maggiore di dischi o di array più veloci fornisce operazioni di I/O al secondo sufficienti garantendo allo stesso tempo latenza e accodamento ridotti in tutti i dischi.
Una risposta lenta dal sottosistema di I/O non può essere compensata aggiungendo altri tipi di risorse, ad esempio CPU o memoria, ma può influire sulla farm e dare origine a problemi. Pianificare una latenza minima prima della distribuzione e monitorare i sistemi esistenti.
Prima di distribuire una nuova farm, è consigliabile effettuare un benchmark del sottosistema di I/O usando l'utilità Diskspd. Questo strumento funziona con tutte le versioni di Windows Server e con tutte le versioni di SQL Server. Per altre informazioni, vedere Utilità Diskspd: uno strumento di test della risorsa di archiviazione solido.
Il test di stress fornisce inoltre informazioni utili per SQL Server. Per informazioni, vedere Benchmarking della risorsa di archiviazione con DiskSpd.
Per informazioni dettagliate su come analizzare i requisiti di input/output al secondo dal punto di vista di SQL Server, vedere l'articolo relativo all'analisi delle caratteristiche di I/O e alla definizione delle dimensioni dei sistemi di archiviazione per applicazioni di database di SQL Server.
Valutare i requisiti di operazioni di I/O al secondo e archiviazione di base
L'archiviazione della configurazione e del contenuto e le operazioni di I/O al secondo costituiscono il livello di base da pianificare in ogni distribuzione di SharePoint Server.
Archiviazione della configurazione e operazioni di I/O al secondo
I requisiti di archiviazione per il database di configurazione e il database del contenuto di Amministrazione centrale non sono elevati. È consigliabile allocare 2 GB per il database di configurazione e 1 GB per il database del contenuto di Amministrazione centrale. Con il tempo le dimensioni del database di configurazione possono superare 1 GB. L'aumento delle dimensioni non avviene rapidamente. Il database aumenta di circa 40 MB per ogni 50.000 raccolte siti.
I registri delle transazioni del database di configurazione possono essere estesi. È quindi consigliabile cambiare il modello di recupero del database da modello di recupero con registrazione completa a modello di recupero con registrazione minima.
Nota
Se si vuole usare il mirroring del database di SQL Server per garantire la disponibilità per il database di configurazione, è necessario scegliere il modello di recupero con registrazione completa.
I requisiti di operazioni di I/O al secondo per il database di configurazione e il database del contenuto di Amministrazione centrale sono minimi.
Archiviazione del contenuto e operazioni di I/O al secondo
La valutazione dei requisiti di archiviazione e di operazioni di I/O al secondo per i database del contenuto non è un'attività precisa. Nel testing e nella descrizione delle informazioni riportate di seguito si intende facilitare il calcolo delle stime da usare per determinare la dimensione iniziale della distribuzione. Nel momento in cui tuttavia l'ambiente sarà in esecuzione, sarà necessario rivedere i requisiti di capacità in base ai dati dell'ambiente attivo.
Per altre informazioni sulla metodologia di pianificazione della capacità globale, vedere Informazioni sulla pianificazione di prestazioni e capacità per SharePoint Server 2013.
Formula per valutare i requisiti di archiviazione dei database del contenuto
Nel processo seguente viene illustrato come calcolare in modo approssimativo i requisiti di archiviazione per i database del contenuto, senza considerare i file di log:
Usare la formula seguente per calcolare la dimensione dei database del contenuto:
Dimensione database = ((D × V) × G) + (10 KB × (E + (V × D)))
Nota
Il valore di 10 KB nella formula è una costante che indica approssimativamente la quantità di metadati richiesti da SharePoint Server. Se nel sistema è richiesto un uso significativo di metadati, è possibile aumentare questa costante.
Calcolare il numero previsto di documenti. Questo valore viene indicato con D nella formula.
La modalità di calcolo del numero di documenti verrà determinata dalle funzionalità in uso. Per i siti di collaborazione o Siti personali, è consigliabile ad esempio calcolare il numero previsto di documenti per utente e moltiplicarlo per il numero di utenti. Per i siti di gestione dei record o di pubblicazione del contenuto, è possibile calcolare il numero di documenti che vengono gestiti e generati da un processo.
Se si esegue la migrazione da un sistema corrente, può essere più semplice estrapolare la percentuale di aumento e l'uso correnti. Se invece si crea un nuovo sistema, esaminare le condivisioni di file esistenti o altri archivi ed effettuare una valutazione in base a tale percentuale di utilizzo.
Calcolare la grandezza media dei documenti che verranno archiviati. Questo valore viene indicato con G nella formula. Può essere utile calcolare i valori medi per tipi o gruppi diversi di siti. La grandezza media dei file per Siti personali, archivi multimediali e portali di reparti diversi può variare in modo significativo.
Calcolare il numero di elementi di elenco nell'ambiente. Questo valore viene indicato con E nella formula.
Gli elementi di elenco sono più difficili da calcolare rispetto ai documenti. Viene effettuato in genere un calcolo tre volte superiore a quello del numero di documenti (D), ma questa stima varia in base all'uso previsto per i siti.
Determinare il numero approssimativo di versioni. Calcolare il numero medio di versioni previste per i documenti di una raccolta. Il risultato sarà in genere significativamente inferiore rispetto al numero massimo di versioni consentito. Questo valore viene indicato con V nella formula.
Il valore di V deve essere maggiore di zero.
Se ad esempio si dovessero usare la formula e le caratteristiche descritte nella tabella seguente per calcolare la quantità di spazio di archiviazione necessaria per i file di dati di un database del contenuto in un ambiente di collaborazione, sarebbero necessari circa 105 GB.
| Input | Valore |
|---|---|
Numero di documenti (D) |
200,000 Valore calcolato basandosi su 10.000 utenti per 20 documenti |
Grandezza media dei documenti (G) |
250 KB |
Elementi di elenco (E) |
600,000 |
Numero di versioni non simultanee (V) |
2 Secondo il presupposto che il numero massimo di versioni consentite sia 10 |
Dimensioni database = (((200.000 x 2)) × 250) + ((10 KB × (600.000 + (200.000 x 2))) = 110.000.000 KB o 105 GB
Nota
Le operazioni di I/O ottimizzate su file in SharePoint Server sono un metodo di archiviazione in cui un file viene suddiviso in parti che vengono archiviate e aggiornate separatamente. Le varie parti vengono quindi riunite quando l'utente richiede il file. Questo metodo consente di migliorare le prestazioni di I/O senza in genere comportare un aumento delle dimensioni del file. Con i file di dimensioni ridotte è tuttavia possibile notare un piccolo incremento dello spazio di archiviazione necessario su disco.
Caratteristiche che influiscono sulle dimensioni dei database del contenuto
Le caratteristiche di SharePoint Server seguenti possono influire in modo significativo sulle dimensioni dei database del contenuto:
Cestini Un documento occupa spazio in un database del contenuto finché non viene definitivamente eliminato dal Cestino principale e dal Cestino secondario. Calcolare quanti documenti vengono eliminati ogni mese per determinare l'effetto dei Cestini sulle dimensioni dei database del contenuto.
Controllo I dati di controllo possono formarsi rapidamente e usare elevate quantità di spazio in un database del contenuto, soprattutto se è attivato il controllo della visualizzazione. Anziché consentire un aumento illimitato dei dati di controllo, è consigliabile abilitare il controllo solo per eventi importanti per soddisfare esigenze normative o controlli interni. Usare le linee guida riportate di seguito per valutare lo spazio necessario da riservare per i dati di controllo:
Calcolare il numero di nuove voci di controllo per un sito e moltiplicarlo per 2 KB (le voci generalmente hanno un limite di 4 KB, con una dimensione media di circa 1 KB).
In base allo spazio che si desidera allocare, determinare il numero di giorni corrispondenti ai registri di controllo che si desidera mantenere.
Nota
Office Online Server è la versione successiva di Office Online Server. L'utilizzo di Office Online Server con SharePoint Server 2016 non influisce sulle dimensioni del database del contenuto. Per distribuire Office Online Server nella farm di SharePoint Server 2016, vedere Distribuire Office Online Server.
Valutare i requisiti di operazioni di I/O al secondo dei database del contenuto
I requisiti di operazioni di I/O al secondo per i database del contenuto variano in modo significativo in base all'utilizzo dell'ambiente, allo spazio su disco disponibile e al numero di server presenti. È consigliabile in genere confrontare il carico di lavoro previsto nell'ambiente con una delle soluzioni testate. Per altre informazioni, vedere Risultati dei testi delle prestazioni e della capacità e suggerimenti (SharePoint Server 2013).
Nei test è stato riscontrato che il numero di operazioni di I/O al secondo per i database del contenuto è compreso tra 0,05 operazioni/GB e all'incirca 0,2 operazioni/GB. È stato inoltre notato che per risultati ottimali è possibile aumentare il limite superiore a 0,5 operazioni/GB. Si tratta di un'impostazione decisamente superiore al necessario e che può rivelarsi eccessiva rispetto alle esigenze dell'ambiente corrente. Notare inoltre che se si usa il mirroring, il numero di operazioni di I/O sarà maggiore rispetto ai database del contenuto primari. Non dimenticare che i database del contenuto con mirroring possono raggiungere dimensioni rilevanti.
Valutare i requisiti di archiviazione e operazioni di I/O al secondo delle applicazioni di servizio
Dopo aver valutato i requisiti di archiviazione e operazioni di I/O al secondo dei database del contenuto, è necessario determinare i requisiti di archiviazione e operazioni di I/O al secondo delle applicazioni di servizio che verranno usate nel proprio ambiente.
Requisiti di archiviazione e operazioni di I/O al secondo delle applicazioni di servizio di SharePoint Server
Per valutare i requisiti di archiviazione per le applicazioni di servizio del sistema, è necessario innanzitutto conoscere le applicazioni di servizio e informarsi su come verranno usate. Le applicazioni di servizio disponibili in SharePoint Server 2016 e per le quali sono disponibili database sono elencate nelle tabelle seguenti. I dati relativi alle operazioni di I/O al secondo e all'archiviazione per tutte le applicazioni di servizio in SharePoint Server 2016 sono identiche a quelle di SharePoint Server 2010 e SharePoint Server 2013.
Requisiti di archiviazione e operazioni di I/O al secondo dell'applicazione di servizio di ricerca
| Database | Scalabilità | Numero di operazioni di I/O al secondo su disco | Dimensioni disco | 10 milioni di elementi | 100 milioni di elementi |
|---|---|---|---|---|---|
Ricerca per indicizzazione |
Un solo database per 20 milioni di elementi Operazioni di I/O al secondo di SQL: 10 per 1 documento al secondo |
Medio/Alto |
Media |
15GB Log da 2 GB |
110GB Log da 50 GB |
Collegamento |
Un solo database per 60 milioni di elementi Operazioni di I/O al secondo di SQL: 10 per 1 milione di elementi |
Media |
Media |
10GB Log da 0,1 GB |
80GB Log da 5 GB |
Report di analisi |
Divisione al raggiungimento di 100-300 GB |
Media |
Media |
In base all'utilizzo |
In base all'utilizzo |
Amministrazione ricerca |
Un solo database |
Minimo |
Minimo |
0.4GB Log da 1 GB |
1 GB di dati Log da 2 GB |
Requisiti di archiviazione e numero consigliato di operazioni di I/O al secondo per applicazioni di servizio
| Applicazione di servizio | Consigli per il calcolo delle dimensioni |
|---|---|
Profili utente |
L'applicazione di servizio profili utente è associata a tre database: profili, sincronizzazione e social tagging. Nota Il test dei requisiti di archiviazione e del numero consigliato delle operazioni di I/O al secondo per il database profili utente non è ancora stato completato. Visitare di nuovo questa pagina più avanti per maggiori informazioni. Per informazioni sul database profili utente, vedere Tipi di database e relative descrizioni in SharePoint Server. |
Servizio metadati gestiti |
L'applicazione di servizio metadati gestiti dispone di un database, le cui dimensioni dipendono dal numero di tipi di contenuto e di parole chiave usati nel sistema. Molti ambienti includeranno più istanze dell'applicazione di servizio metadati gestiti. |
servizio di archiviazione sicura |
Le dimensioni del database dell'applicazione del servizio archiviazione sicura dipendono dal numero di credenziali nell'archivio e dal numero di voci nella tabella di controllo. Per questa applicazione è consigliabile allocare 5 MB per ogni 1.000 credenziali. I requisiti di operazioni di I/O al secondo sono minimi. |
Servizio informazioni sullo stato |
L'applicazione di servizio informazioni sullo stato dispone di un database, pertanto è consigliabile allocare 1 GB. I requisiti di operazioni di I/O al secondo sono minimi. |
Word Automation Services |
L'applicazione Word Automation Services dispone di un database, pertanto è consigliabile allocare 1 GB. I requisiti di operazioni di I/O al secondo sono minimi. |
PerformancePoint Services |
L'applicazione di servizio PerformancePoint Services dispone di un database, pertanto è consigliabile allocare 1 GB. I requisiti di operazioni di I/O al secondo sono minimi. |
servizio di integrazione applicativa dei dati |
L'applicazione servizio di integrazione applicativa dei dati dispone di un solo database di dimensioni ridotte e per il quale non è prevista una crescita significativa. I requisiti di operazioni di I/O al secondo sono minimi. |
Gestione app |
L'applicazione di servizio di gestione app dispone di un solo database di dimensioni ridotte e per il quale non è prevista una crescita significativa. I requisiti di operazioni di I/O al secondo sono minimi. |
Word Automation Services |
L'applicazione di servizio Word Automation Services dispone di un solo database di dimensioni ridotte e per il quale non è prevista una crescita significativa. I requisiti di operazioni di I/O al secondo sono minimi. |
PerformancePoint Services |
PerformancePoint Services dispone di un solo database di dimensioni ridotte e per il quale non è prevista una crescita significativa. I requisiti di operazioni di I/O al secondo sono minimi. |
PowerPivot |
L'applicazione di servizio PowerPivot dispone di un solo database di dimensioni ridotte e con impatto non significativo su I/O. È consigliabile usare lo stesso numero di operazioni di I/O al secondo del database del contenuto di SharePoint. Notare che i requisiti di I/O dei database del contenuto sono di gran lunga superiori rispetto al database dell'applicazione di servizio PowerPivot. |
Determinare i requisiti di disponibilità
Per disponibilità si intende il livello con cui gli utenti percepiscono come disponibile un ambiente SharePoint Server 2016. Un sistema disponibile è un sistema resiliente, ovvero si verificano raramente incidenti che colpiscono il sistema e quando tali incidenti si verificano vengono intraprese azioni tempestive ed efficaci.
I requisiti di disponibilità possono determinare un aumento significativo dei requisiti di archiviazione. Per informazioni dettagliate, vedere Creare un'architettura e una strategia a disponibilità elevata per SharePoint Server. Vedere anche il white paper SQL Server 2012 relativo alla guida per l'architettura AlwaysOn e la creazione di soluzioni di ripristino di emergenza e ad elevata disponibilità mediante i gruppi di disponibilità AlwaysOn.
Scegliere la versione e l'edizione di SQL Server
Per SharePoint Server 2016 è consigliabile eseguire il proprio ambiente sull'Enterprise Edition di SQL Server 2014 con Service Pack 1 (SP1), SQL Server 2016 o SQL Server 2017 RTM per sfruttare le prestazioni e le funzionalità relative a disponibilità, sicurezza e gestione aggiuntive fornite da tali versioni. Per ulteriori informazioni sui vantaggi offerti da tali versioni, vedere Funzionalità supportate dalle edizioni di SQL Server 2014, Edizioni e funzionalità supportate di SQL Server 2016 e Edizioni e funzionalità supportate di SQL Server 2017.
Per SharePoint Server 2013 è consigliabile eseguire il proprio ambiente sull'Enterprise Edition di SQL Server 2008 R2 con Service Pack 1 (SP1), SQL Server 2012 o SQL Server 2014 per sfruttare le prestazioni e le funzionalità relative a disponibilità, sicurezza e gestione aggiuntive fornite da tale versione. Per ulteriori informazioni sui vantaggi di SQL Server 2008 R2 con SP1, SQL Server 2012 e SQL Server 2014 Enterprise Edition, vedere Funzionalità supportate dalle edizioni di SQL Server 2014, Funzionalità supportate dalle edizioni di SQL Server 2012 e Funzionalità supportate dalle edizioni di SQL Server 2008 R2.
Valutare in particolare se si necessita delle caratteristiche seguenti:
Compressione backup La compressione backup può velocizzare il backup di SharePoint ed è disponibile in tutte le edizioni di SQL Server 2008 e versioni successive. 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 log inviati. Per ulteriori informazioni, vedere Compressione backup (SQL Server) per SQL Server 2014 e Compressione backup (SQL Server) per SQL Server 2016 e SQL Server 2017 RTM.
Nota
La compressione dati di SQL Server non è supportata per SharePoint Server, fatta eccezione per i database dell'applicazione del servizio di ricerca.
Transparent data encryption Se i requisiti di sicurezza prevedono l'uso di Transparent Data Encryption, è necessario implementare SQL Server Enterprise Edition.
Distribuzione del contenuto Se si intende usare la caratteristica di distribuzione del contenuto, prendere in considerazione SQL Server Enterprise Edition in modo che il sistema possa usufruire degli snapshot di database.
Nota
Se si usa un provider di Archiviazione BLOB remoti che non supporta gli snapshot di database, non sarà possibile usarli per la distribuzione o il backup del contenuto.
Archiviazione BLOB remoti Se si desidera usufruire di Archiviazione BLOB remoti in un database o un percorso esterno ai file associati a ogni database del contenuto, sarà necessario usare SQL Server 2014 (SP1) o SQL Server 2016 o SQL Server 2017 RTM Enterprise Edition per SharePoint Server 2016 e SQL Server 2008 R2 con SP1 o SQL Server 2012 Enterprise Edition per SharePoint Server 2013.
Resource governor Resource Governor è una tecnologia introdotta in SQL Server 2008 che consente di gestire carichi di lavoro e risorse di SQL Server specificando limiti per l'utilizzo delle risorse da parte di richieste in ingresso. Resource Governor consente di differenziare i carichi di lavoro e di allocare CPU e memoria in base alle richieste, secondo i limiti specificati. Per ulteriori informazioni sull'uso di Resource Governor, vedere Resource Governor per SQL Server 2014 e Resource Governor per SQL Server 2016.
È consigliabile usare Resource Governor con SharePoint Server per eseguire le operazioni seguenti:
Limitare la quantità di risorse di SQL Server usate dai server Web oggetto del componente di ricerca per indicizzazione. Come procedura consigliata, è opportuno impostare per il componente di ricerca per indicizzazione un limite del 10% della CPU quando il sistema è sotto carico.
Monitorare la quantità di risorse usate da ogni database presente nel sistema. È ad esempio possibile usare Resource Governor per determinare la posizione ottimale dei database tra i computer in cui è in esecuzione SQL Server.
Microsoft PowerPivot per SharePoint Consente la condivisione e la collaborazione a modelli dati e analisi generati dagli utenti in Excel Online durante l'aggiornamento automatico di tali analisi. È necessario disporre di Office Online per utilizzare Excel Online con PowerPivot per SharePoint e SharePoint Server 2016. È possibile utilizzare SQL Server 2014 (SP1) o SQL Server 2016 RTM Enterprise Edition e SQL Server Analysis Services per business intelligence con SharePoint Server 2016. Tuttavia, è possibile utilizzare PowerPivot per SharePoint solo con SQL Server 2016 RTM, non con SQL Server 2014 (SP1).
PowerPivot per SharePoint 2013 Consente la condivisione e la collaborazione su modelli dati e analisi generati dagli utenti in Excel e nel browser durante l'aggiornamento automatico di tali analisi. Questo componente fa parte di SQL Server 2008 R2 Analysis Services (SSAS) ed Enterprise Edition, SQL Server 2012 SP1 Analysis Services (SSAS) Enterprise Edition e SQL Server 2014 Analysis Services (SSAS) Enterprise e Business Intelligence Edition.
Progettare l'architettura di archiviazione in base ai requisiti di capacità e di I/O
L'architettura di archiviazione e i tipi di dischi selezionati per l'ambiente possono influire sulle prestazioni del sistema.
Contenuto della sezione:
Scegliere un'architettura di archiviazione
Scegliere i tipi di dischi
Scegliere i tipi RAID
Scegliere un'architettura di archiviazione
SharePoint Server supporta le architetture dell'archiviazione DAS (Direct-Attached Storage), della rete di archiviazione (SAN, Storage Area Network) e dell'archiviazione basata sulla rete (NAS, Network-Attached Storage), anche se l'archiviazione NAS è supportata solo per l'utilizzo con database del contenuto configurati per utilizzare Archiviazione BLOB remoti.
Tutte le architetture di archiviazione devono supportare i requisiti di disponibilità definiti e garantire prestazioni adeguate in termini di operazioni di I/O al secondo e latenza. Sono considerate supportate se il sistema restituisce il primo byte di dati entro 20 millisecondi (ms).
Archiviazione DAS (Direct-Attached Storage)
L'archiviazione DAS (Direct-Attached Storage) è un sistema di archiviazione digitale direttamente collegato a un server o una workstation, senza intermediazione di una rete di archiviazione. Tra i tipi di dischi fisici DAS sono inclusi Serial Attached SCSI (SAS) e Serial Attached ATA (SATA).
È consigliabile in genere scegliere un'architettura DAS se una piattaforma di archiviazione condivisa non può garantire un tempo di risposta di 20 ms e capacità sufficiente per operazioni di I/O al secondo medie e di picco.
Rete di archiviazione (SAN, Storage Area Network)
La rete di archiviazione (SAN, Storage Area Network) è un'architettura che consente di collegare dispositivi di archiviazione di computer remoti (ad esempio array di dischi e librerie di nastri) a server in modo che i dispositivi risultino come se fossero collegati localmente al sistema operativo (ad esempio archiviazione a blocchi).
È in genere consigliabile scegliere la rete di archiviazione se nell'organizzazione è importante usufruire dei vantaggi di un'archiviazione condivisa.
I vantaggi derivanti dall'uso di un'archiviazione condivisa includono:
Riallocazione semplificata dell'archiviazione su disco tra i server.
Possibilità di gestire più server.
Nessun limite per il numero di dischi a cui è possibile accedere.
Archiviazione basata sulla rete (NAS)
Un'unità NAS è un computer indipendente connesso a una rete il cui unico scopo è fornire servizi di archiviazione di dati basati su file ad altri dispositivi della rete. Il sistema operativo e l'altro software dell'unità NAS garantiscono funzionalità di archivio dati, file system e accesso ai file, nonché la gestione di tali funzionalità, ad esempio l'archiviazione di file.
Nota
L'archiviazione NAS è supportata solo per l'utilizzo con database del contenuto configurati per usare Archiviazione BLOB remoti. Tutte le archiviazioni basate sulla rete devono rispondere a un ping entro 1 ms e devono restituire il primo byte di dati entro 20 ms. Questa restrizione non si applica al provider FILESTREAM di SQL Server locale, poiché archivia i dati solo localmente nello stesso server.
L'uso dell'interfaccia iSCSI (Internet Small Computer System Interface) presupponendo che si tratti di un protocollo NAS genera una certa confusione. Se si accede a questo spazio di archiviazione iSCSI tramite CFIS (Common Internet File System), si tratta di un protocollo NAS. Di conseguenza non è possibile usare questo spazio di archiviazione con database del contenuto se non sono configurati per l'uso di Archiviazione BLOB remoti. Se tuttavia si accede a questo spazio di archiviazione iSCSI tramite un disco rigido collegato in locale, viene considerato come un'architettura SAN e può quindi essere usato con NAS.
Scegliere i tipi di dischi
I tipi di dischi usati nel sistema possono influire sull'affidabilità e sulle prestazioni. Pur equivalendosi quasi tutte le caratteristiche, unità più grandi comportano un aumento del tempo di posizionamento medio. SharePoint Server supporta i tipi di unità seguenti:
Small Computer System Interface (SCSI)
Serial Advanced Technology Attachment (SATA)
Serial Attached SCSI (SAS)
Fibre Channel (FC)
Integrated Device Electronics (IDE)
Solid State Drive (SSD) o disco flash
Per informazioni sull'uso delle unità SSD per l'archiviazione in SQL Server, vedere l'articolo di SQL Server PRO sull'uso di dischi SSD in soluzioni di archiviazione SQL Server.
Scegliere i tipi RAID
Il meccanismo RAID (Redundant Array of Independent Disks) viene usato spesso sia per migliorare le caratteristiche delle prestazioni di singoli dischi (mediante striping dei dati su più dischi) che per fornire protezione da errori dei singoli dischi.
In SharePoint Server sono supportati tutti i tipi di RAID. È consigliabile tuttavia utilizzare RAID 10 o una soluzione RAID specifica del fornitore con prestazioni equivalenti.
Quando si configura un array di dischi RAID, allineare il file system all'offset indicato dal fornitore.
Per altre informazioni sul provisioning di RAID per SQL Server, vedere RAID.
Valutare i requisiti di memoria
La memoria necessaria per SharePoint Server è direttamente correlata alle dimensioni dei database del contenuto ospitati in un server in cui è in esecuzione SQL Server.
Man mano che si aggiungono applicazioni di servizio e caratteristiche, è probabile che i requisiti aumentino. Nella tabella seguente sono illustrate le linee guida per la quantità di memoria consigliata.
| Dimensioni complessive dei database del contenuto | RAM consigliata per un computer che esegue SQL Server |
|---|---|
Minime per distribuzioni di produzione di piccole dimensioni |
8 GB |
Minime per distribuzioni di produzione di medie dimensioni |
16 GB |
Consigliate per dimensioni fino a 2 terabyte |
32 GB |
Consigliate per dimensioni comprese tra 2 e 5 terabyte |
64 GB |
Consigliate per dimensioni superiori a 5 terabyte |
Per migliorare la velocità di memorizzazione nella cache di SQL Server, usare RAM superiore a 64 GB |
Nota
Questi valori sono superiori a quelli consigliati come valori minimi per SQL Server a causa della distribuzione di dati necessaria per un ambiente SharePoint Server. Per ulteriori informazioni sui requisiti di sistema di SQL Server, vedere Requisiti hardware e software per l'installazione di SQL Server 2014 e Requisiti hardware e software per l'installazione di SQL Server 2016.
Per informazioni sui limiti di capacità e le specifiche di SQL Server, vedere Limiti della capacità di calcolo per edizione di SQL Server e Specifiche di capacità massima per SQL Server.
Tra gli altri fattori che possono influire sulla memoria necessaria sono inclusi:
Uso del mirroring di SQL Server.
Uso frequente di file di dimensioni superiori a 15 megabyte (MB).
Informazioni sui requisiti della topologia di rete
Pianificare le connessioni di rete nell'ambito di ogni farm e tra farm diverse. È consigliabile usare una rete con latenza bassa.
Nell'elenco seguente vengono fornite alcune indicazioni e procedure consigliate:
Tutti i server della farm devono disporre di una larghezza di banda di rete LAN e di una latenza per il server in cui è in esecuzione SQL Server. La latenza non deve superare 1 millisecondo.
Non è consigliabile usare una topologia WAN con un server che esegue SQL Server distribuito in remoto da altri componenti della farm in una rete con latenza maggiore a 1 ms in quanto questa topologia non è stata testata.
Pianificare una rete WAN adeguata se si intende usare la famiglia di prodotti per l'implementazione AlwaysOn, il mirroring, log shipping o il clustering di failover di SQL Server per mantenere aggiornato un sito remoto.
È consigliabile che i server Web e i server applicazioni dispongano di due schede di rete, una per gestire il traffico dell'utente finale e l'altra per gestire le comunicazioni con i server in cui è in esecuzione SQL Server.
Nota
Se si usa iSCSI, assicurarsi che ogni scheda di rete sia dedicata alle comunicazioni di rete o a iSCI, ma non a entrambi.
Configurare SQL Server
Nelle sezioni seguenti viene descritto come pianificare la configurazione di SQL Server per SharePoint Server.
Contenuto della sezione:
Determinare il numero di istanze o di server necessari
Configurare l'archiviazione e la memoria
Impostare le opzioni di SQL Server
Configurare i database
Determinare il numero di istanze o di server necessari
In linea generale, SharePoint Server è stato progettato per usufruire della scalabilità orizzontale di SQL Server. Le prestazioni di SharePoint Server possono ad esempio essere migliori con un numero elevato di server di medie dimensioni che eseguono SQL Server anziché con pochi server di grandi dimensioni.
Posizionare sempre SQL Server in un server dedicato che non esegue altri ruoli della farm o database di hosting per altre applicazioni. È possibile fare eccezione rispetto a questa indicazione solo nel caso in cui si distribuisce il sistema in un server autonomo per un ambiente di sviluppo o di test non orientato alle prestazioni. Anche se SQL Server può essere eseguito nello stesso server di SharePoint, è consigliabile eseguire SQL Server in un server separato per ottenere prestazioni migliori.
Fare riferimento alle indicazioni seguenti per sapere quando è necessario distribuire un server aggiuntivo in cui verrà eseguita un'istanza di SQL Server:
Aggiungere un altro server di database se si dispone di più di quattro server Web in esecuzione a piena capacità.
Aggiungere un altro server di database quando il server corrente ha raggiunto i limiti di risorse in termini di RAM, CPU, velocità effettiva di I/O del disco, capacità del disco o velocità effettiva della rete.
Per ulteriori informazioni, vedere Limiti della capacità di calcolo per edizione di SQL Server e Specifiche di capacità massima per SQL Server.
Per alzare di livello l'archiviazione sicura delle credenziali quando si esegue l'applicazione del servizio di archiviazione sicura, è consigliabile ospitare il database di archiviazione sicura in un'istanza di database separata con l'accesso limitato a un amministratore.
Configurare l'archiviazione e la memoria
Nel server in cui è in esecuzione SQL Server è consigliabile allocare per la cache L2 per CPU almeno 2 MB per migliorare la memoria.
Seguire le indicazioni del fornitore per la configurazione dell'archiviazione
Per ottenere prestazioni ottimali quando si configura un array di archiviazione fisica, applicare le indicazioni del fornitore per la configurazione hardware anziché basarsi sui valori predefiniti del sistema operativo.
In assenza di indicazioni del fornitore, è consigliabile utilizzare i cmdlet di archiviazione di PowerShell disponibili per Windows Server 2012 R2. Per altre informazioni, vedere l'articolo sui cmdlet di archiviazione in Windows PowerShell.
Fornire il maggior numero possibile di risorse
Assicurarsi che i canali di I/O SQL Server per i dischi non siano condivisi da altre applicazioni, ad esempio il file di paging e i log di Internet Information Services (IIS).
Fornire la larghezza di banda del bus più ampia possibile. Un'elevata larghezza di banda del bus consente di migliorare l'affidabilità e le prestazioni. Considerare che il disco non è l'unico elemento che usa la larghezza di banda del bus. È necessario ad esempio tenere conto anche dell'accesso alla rete.
Impostare le opzioni di SQL Server
È necessario configurare le impostazioni e le opzioni di SQL Server elencate di seguito prima di distribuire SharePoint Server.
Non abilitare la creazione automatica di statistiche in un server che ospita SQL Server e supporta SharePoint Server. In SharePoint Server le impostazioni necessarie vengono configurate in fase di provisioning e aggiornamento. La creazione automatica di statistiche può modificare in modo significativo il piano di esecuzione di una query da un'istanza di SQL Server a un'altra istanza di SQL Server. Per garantire pertanto un supporto uniforme per tutti i clienti, in SharePoint Server sono disponibili suggerimenti codificati per query in modo da ottenere prestazioni ottimali in tutti gli scenari.
Per garantire prestazioni ottimali è consigliabile impostare max degree of parallelism (MAXDOP) su 1 per le istanze di SQL Server che ospitano database di SharePoint Server. Per altre informazioni su come impostare max degree of parallelism, vedere Configurare l'opzione di configurazione del server max degree of parallelism.
Configurare i database
Nelle informazioni aggiuntive seguenti vengono illustrate le procedure consigliate da pianificare nella configurazione di ogni database nell'ambiente.
Suddividere i dati tra i dischi e classificarli in ordine di priorità
In teoria il database tempdb, i database del contenuto, il database servizio di utilizzo, i database di ricerca e i log delle transazioni di SQL Server 2014 (SP1), SQL Server 2016, SQL Server 2017 RTM e SQL Server 2008 R2 con SP1 e SQL Server 2012 dovrebbero essere posizionati in dischi fisici separati.
Nell'elenco seguente vengono fornite alcune indicazioni e procedure consigliate per classificare i dati in ordine di priorità:
Quando si classificano i dati in ordine di priorità tra i dischi più veloci, usare la classificazione seguente:
File di dati e log delle transazioni di tempdb
File di log delle transazioni dei database
Database di ricerca, tranne il database di amministrazione della ricerca
File di dati dei database
In un sito portale fortemente orientato alla lettura classificare i dati in ordine di priorità nei log.
Dai dati dei test e dei clienti risulta che le prestazioni delle farm di SharePoint Server possono essere rallentate in modo significativo da operazioni di I/O su disco insufficienti per tempdb. Per evitare questo problema, allocare dischi dedicati per tempdb. Se si prevede o si effettua il monitoraggio di un carico di lavoro elevato, ovvero operazioni di lettura o di scrittura medie che richiedono più di 20 ms, potrebbe essere necessario ovviare al collo di bottiglia suddividendo i file tra i dischi oppure sostituendo i dischi con dischi più veloci.
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. A tale scopo, calcolare i processori dual core come due CPU. Calcolare ogni processore che supporta l'hyperthreading come una singola CPU. Per altre informazioni, vedere Ottimizzazione delle prestazioni di tempdb.
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.
Informarsi presso il fornitore dell'hardware di archiviazione su come configurare tutti i registri e i database di ricerca per ottimizzare le operazioni di scrittura per la propria specifica soluzione di archiviazione.
Usare più file di dati per i database del contenuto
Per ottenere prestazioni ottimali, attenersi alle indicazioni seguenti:
Creare file solo nel filegroup primario del database.
Distribuire i file su dischi separati.
Il numero di file di dati deve essere minore o uguale al numero di CPU core. A tale scopo, calcolare i processori dual core come due CPU. Calcolare ogni processore che supporta l'hyperthreading come una singola CPU.
Creare file di dati di dimensioni uguali.
Importante
Benché sia possibile usare gli strumenti di backup e ripristino inclusi in SharePoint Server per il backup e il ripristino di più file di dati, in caso di operazioni di sovrascrittura nello stesso percorso gli strumenti non saranno in grado di ripristinare più file di dati in un percorso diverso. Quando si usano più file di dati per un database del contenuto, è consigliabile pertanto preferire gli strumenti di backup e ripristino di SQL Server. Per altre informazioni su come eseguire il backup e il ripristino di SharePoint Server, vedere Pianificazione del backup e del ripristino in SharePoint Server.
Per altre informazioni su come creare e gestire i filegroup, vedere Architettura di file e filegroup.
Limitare le dimensioni dei database del contenuto per migliorare la gestibilità
Pianificare le dimensioni dei database in modo da migliorare la gestibilità, le prestazioni e la capacità di aggiornamento dell'ambiente.
Per garantire prestazioni di sistema ottimali, è consigliabile limitare le dimensioni dei database del contenuto a 200 GB, ad eccezione dei casi in cui scenari e condizioni di utilizzo specifici supportino dimensioni maggiori. Per maggiori informazioni sui limiti delle dimensioni del database del contenuto, vedere la sezione "Limiti del database del contenuto" in Limiti software statici e configurabili per SharePoint Server 2016.
È in genere consigliabile che, a meno che non vi sia una sola raccolta siti nel database, le dimensioni di una raccolta siti non superino 100 GB in modo da consentire se necessario l'uso degli strumenti di backup granulare di SharePoint Server per spostare una raccolta siti in un altro database.
Gestire attivamente l'aumento delle dimensioni dei file di dati e di log
È consigliabile gestire attivamente l'aumento delle dimensioni dei file di dati e di registro tenendo conto delle indicazioni seguenti:
Per quanto possibile, impostare anticipatamente le dimensioni previste per tutti i file di dati e di log.
È consigliabile abilitare l'aumento automatico delle dimensioni per motivi di sicurezza. Non fare affidamento sulle impostazioni predefinite per l'aumento automatico delle dimensioni.
Quando si pianificano database del contenuto le cui dimensioni superano i valori consigliati (200 GB), impostare il valore per l'aumento automatico delle dimensioni dei database su un numero fisso di megabyte anziché su un valore percentuale. In questo modo si ridurrà la frequenza con cui SQL Server incrementa le dimensioni di un file. L'aumento delle dimensioni di un file è un'operazione di blocco che occupa nuovo spazio con pagine vuote.
Se si prevede che le dimensioni calcolate del database del contenuto non raggiungeranno la dimensione massima consigliata di 200 GB in un anno, usare la proprietà ALTER DATABASE MAXSIZE per impostare il valore massimo che si prevede verrà raggiunto dal database entro un anno, con un margine aggiuntivo di errore del 20%. Controllare periodicamente questa impostazione per accertarsi che continui a essere appropriata sulla base delle percentuali di aumento passate.
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.
Convalidare e monitorare l'archiviazione e le prestazioni di SQL Server
Verificare che le prestazioni e la soluzione di backup dell'hardware siano conformi ai propri contratti di servizio. Testare in modo particolare il sottosistema di I/O del computer in cui è in esecuzione SQL Server per verificare che le prestazioni siano soddisfacenti.
Testare la soluzione di backup in uso per verificare che consenta di eseguire il backup del sistema nell'arco di tempo disponibile per la manutenzione. Se la soluzione di backup non è in grado di soddisfare i requisiti dei contratti di servizio della propria organizzazione, valutare la possibilità di usare una soluzione di backup incrementale come Microsoft System Center Data Protection Manager.
È importante monitorare i componenti seguenti di un server in cui è in esecuzione SQL Server: CPU, memoria, rapporto riscontri cache e sottosistema di I/O. In caso di rallentamento o sovraccarico di uno o più dei componenti, analizzare la strategia appropriata in base al carico di lavoro corrente e previsto. Per altre informazioni, vedere Monitoraggio e ottimizzazione delle prestazioni per SQL Server 2014 (SP1) e Monitoraggio e ottimizzazione delle prestazioni per SQL Server 2016 e SQL Server 2017 RTM.
Nelle sezioni seguenti vengono elencati i contatori delle prestazioni che è consigliabile usare per monitorare le prestazioni dei database di SQL Server in esecuzione nell'ambiente SharePoint Server. Vengono elencati inoltre per ogni contatore i valori approssimativi che indicano un sistema integro.
Per informazioni dettagliate su come monitorare le prestazioni e utilizzare i contatori delle prestazioni, vederePerformance Monitor di Windows e l'articolo sul monitoraggio delle prestazioni.
Contatori di SQL Server da monitorare
Monitorare i contatori di SQL Server seguenti per verificare l'integrità dei server:
Statistiche generali Questo oggetto fornisce contatori per monitorare attività generali a livello del server, ad esempio il numero di connessioni correnti e il numero di utenti che si connettono e disconnettono ogni secondo dai computer in cui è in esecuzione un'istanza di SQL Server. Prendere in considerazione la possibilità di monitorare il contatore seguente:
- Connessioni utente Questo contatore indica il numero di connessioni utente nel computer in cui è in esecuzione SQL Server. Se questo valore aumenta del 500% rispetto al valore di base, è possibile che si verifichi un rallentamento delle prestazioni.
Database Questo oggetto fornisce contatori per monitorare operazioni di copia di massa, la velocità effettiva di backup e ripristino e le attività del log delle transazioni. Monitorare le transazioni e il relativo log per determinare l'entità dell'attività degli utenti nel database e la quantità di dati contenuta in tale log. L'entità dell'attività degli utenti può determinare le prestazioni del database e influire sulle dimensioni del log, il blocco e la replica. Il monitoraggio di attività del log di basso livello per misurare l'attività degli utenti e l'utilizzo delle risorse consente di individuare i colli di bottiglia delle prestazioni. Prendere in considerazione la possibilità di monitorare il contatore seguente:
- Transazioni/sec Questo contatore indica il numero di transazioni eseguite al secondo in un determinato database o nell'intero server. Questo valore viene utilizzato principalmente come valore di base e per consentire di risolvere eventuali problemi.
Blocchi Questo oggetto fornisce informazioni sui blocchi di SQL Server per singoli tipi di risorse. Prendere in considerazione la possibilità di monitorare i contatori seguenti:
Tempo medio di attesa (ms) Questo contatore indica il tempo medio di attesa per ogni richiesta di blocco che ha comportato un'attesa.
Tempo di attesa blocchi (ms) Questo contatore indica il tempo di attesa per i blocchi nell'ultimo secondo.
Attese di blocco/sec Questo contatore indica il numero di blocchi al secondo che non sono stati soddisfatti immediatamente e hanno dovuto attendere la disponibilità di risorse.
Numero di deadlock/sec Questo contatore indica il numero di deadlock al secondo nel computer in cui è in esecuzione SQL Server. Questo valore non deve essere maggiore di 0.
Latch Questo oggetto fornisce contatori per monitorare blocchi di risorse di SQL Server interni denominati latch. Il monitoraggio dei latch per determinare l'attività degli utenti e l'utilizzo delle risorse consente di identificare i colli di bottiglia delle prestazioni. Prendere in considerazione la possibilità di monitorare i contatori seguenti:
Tempo medio attesa latch (ms) Questo contatore indica il tempo medio di attesa per le richieste di latch non soddisfatte immediatamente.
Attese latch/sec Questo contatore indica il numero di richieste di latch che non sono state soddisfatte immediatamente.
Statistiche SQL Questo oggetto fornisce contatori per monitorare la compilazione e il tipo di richieste inviate a un'istanza di SQL Server. Il monitoraggio del numero di compilazioni e ricompilazioni di query e del numero di batch ricevuti da un'istanza di SQL Server consente di ottenere un'indicazione della rapidità con cui SQL Server elabora le query degli utenti e dell'efficacia con cui Query Optimizer elabora le query. Prendere in considerazione la possibilità di monitorare i contatori seguenti:
Compilazioni SQL/sec Questo contatore indica quante volte al secondo viene immesso il percorso del codice di compilazione.
Ricompilazioni SQL/sec Questo contatore indica il numero di ricompilazioni di istruzioni al secondo.
Gestione buffer Questo oggetto fornisce contatori per monitorare in che modo SQL Server usa la memoria per archiviare le pagine di dati, le strutture di dati interne e la cache delle procedure, nonché contatori per monitorare le operazioni di I/O fisiche mentre SQL Server legge e scrive page di database. Prendere in considerazione la possibilità di monitorare il contatore seguente:
Percentuale riscontri cache buffer
Questo contatore indica la percentuale di pagine trovate nella cache buffer senza dover effettuare operazioni di lettura dal disco. La percentuale indica il numero totale di riscontri cache diviso per il numero totale di ricerche nella cache nel corso delle ultime migliaia di accessi alla pagina. Poiché la lettura dalla cache è molto meno onerosa in termini di risorse rispetto alla lettura dal disco, è opportuno che questa percentuale sia elevata. È possibile in genere aumentare la percentuale di riscontri cache buffer aumentando la memoria disponibile per SQL Server.
Cache dei piani Questo oggetto fornisce contatori per monitorare in che modo SQL Server usa la memoria per archiviare oggetti quali stored procedure, trigger e istruzioni Transact-SQL preparate e non preparate. Prendere in considerazione la possibilità di monitorare il contatore seguente:
Percentuale riscontri cache
Questo contatore indica il rapporto tra i riscontri cache e le ricerche per i piani.
Contatori di server fisici da monitorare
Monitorare i contatori seguenti per verificare l'integrità dei computer in cui è in esecuzione SQL Server:
Processore: % tempo processore: _Totale Questo contatore indica la percentuale di tempo durante il quale il processore esegue processi di applicazioni o del sistema operativo rispetto al periodo di inattività. Nel computer in cui è in esecuzione SQL Server il valore di questo contatore deve essere mantenuto tra il 50% e il 75%. In caso di costante sovraccarico, controllare se è presente un'attività di elaborazione anomala o se il server necessita di ulteriori CPU.
Sistema: Lunghezza coda processore Questo contatore indica il numero di thread nella coda del processore. Monitorare questo contatore per controllare che il valore sia sempre inferiore al doppio del numero di CPU core.
Memoria: MByte disponibili Questo contatore indica la quantità di memoria fisica espressa in megabyte disponibile per i processi in esecuzione nel computer. Monitorare questo contatore per controllare che venga mantenuto un livello corrispondente almeno al 20% della RAM fisica totale disponibile.
Memoria: Pagine/sec Questo contatore indica la velocità con cui le pagine vengono lette o scritte sul disco per risolvere errori di pagine hardware. Monitorare questo contatore per controllare che il relativo valore sia sempre inferiore a 100.
Per ulteriori informazioni e metodi di risoluzione dei problemi relativi alla memoria, vedere i seguenti argomenti:
SQL Server 2014 (SP1) - Monitoraggio dell'utilizzo della memoria
SQL Server 2016 e SQL Server 2017 - Monitoraggio dell'utilizzo della memoria
Per ulteriori informazioni e per i metodi di risoluzione dei problemi di memoria, vedere Monitoraggio dell’utilizzo della memoria per SQL Server 2008 R2 con SP1, Monitoraggio dell’utilizzo della memoria per SQL Server 2012 e Monitoraggio dell’utilizzo della memoria per SQL Server 2014.
Contatori di disco da monitorare
Monitorare i contatori seguenti per verificare l'integrità dei dischi. Notare che i valori seguenti rappresentano valori misurati nel tempo e non valori registrati durante un improvviso sovraccarico o basati su una singola misurazione.
Disco fisico: % Tempo disco: UnitàDati Questo contatore indica la percentuale di tempo trascorso in cui l'unità disco selezionata è stata occupata con richieste di lettura o scrittura. Si tratta di un contatore generale che indica quanto è occupato il disco. Se il valore del contatore Disco fisico: % Tempo disco è elevato (oltre il 90%), controllare il contatore Disco fisico: Lunghezza corrente coda del disco per verificare quante richieste del sistema sono in attesa di accedere al disco. Il numero delle richieste di I/O in attesa non deve superare 1,5-2 volte il numero di assi che costituiscono il disco fisico.
Disco logico: Trasferimenti disco/sec Questo contatore indica la velocità con cui vengono eseguite operazioni di lettura e scrittura sul disco. Usare questo contatore per monitorare le tendenze esponenziali ed effettuare previsioni appropriate.
Disco logico: Byte letti da disco/sec e Disco logico: Byte scritti su disco/sec Questi contatori indicano la velocità di trasferimento dei byte dal disco durante le operazioni di lettura o scrittura.
Disco logico: Media byte letti da disco Questo contatore indica il numero medio di byte trasferiti dal disco durante le operazioni di lettura. Questo valore può riflettere la latenza del disco. A operazioni di lettura estese può corrispondere un leggero aumento della latenza.
Disco logico: Media byte scritti su disco Questo contatore indica il numero medio di byte trasferiti sul disco durante le operazioni di scrittura. Questo valore può riflettere la latenza del disco. A operazioni di scrittura estese può corrispondere un leggero aumento della latenza.
Disco logico: Lunghezza corrente coda del disco Questo contatore indica il numero di richieste in sospeso sul disco al momento della raccolta dei dati relativi alle prestazioni. Per questo contatore sono consigliati valori bassi. Valori maggiori di 2 per disco possono indicare un collo di bottiglia e devono dare origine a ulteriori analisi. Ciò significa che un valore pari a 8 può essere accettabile per un'unità logica (LUN) costituita da 4 dischi. I colli di bottiglia possono creare un backlog che può estendersi oltre il server corrente che sta accedendo al disco e comportare lunghi periodi di attesa per gli utenti. Le possibili soluzioni per un collo di bottiglia prevedono l'aggiunta di più dischi all'array RAID, la sostituzione dei dischi esistenti con dischi più veloci oppure lo spostamento di dati su altri dischi.
Disco logico: Lunghezza media coda del disco Questo contatore indica il numero medio di richieste di lettura e scrittura in coda per il disco selezionato rilevate durante l'intervallo di campionamento. La regola prevede che vi siano due o meno richieste di lettura e scrittura in sospeso per asse. Questo valore può però essere difficile da misurare a causa della virtualizzazione dell'archiviazione e delle differenze nei livelli RAID tra le configurazioni. Cercare lunghezze di coda del disco più alte della media insieme a latenze del disco più alte della media. Questa combinazione può indicare un utilizzo eccessivo della cache dell'array di archiviazione o un rallentamento delle prestazioni dovuto alla condivisione dell'asse con altre applicazioni.
Disco logico: Media letture disco/sec e Disco logico: Media scritture disco/sec Questi contatori indicano il tempo medio in secondi per un'operazione di lettura o scrittura su disco. Monitorare questi contatori per verificare che i relativi valori rimangano al di sotto dell'85% della capacità del disco. Il tempo di accesso al disco aumenta in modo esponenziale se le operazioni di lettura o scrittura superano l'85% della capacità del disco. Per determinare la capacità specifica per il proprio hardware, fare riferimento alla documentazione del fornitore oppure utilizzare l'utilità Diskspd, lo strumento di test della risorsa di archiviazione per calcolarla. Per ulteriori informazioni, vedere Utilità Diskspd: uno strumento di test della risorsa di archiviazione solido (sostituisce SQLIO).
Disco logico: Media letture disco/sec Questo contatore indica il tempo medio in secondi di un'operazione di lettura dal disco. In un sistema ottimizzato i valori ideali sono compresi tra 1 e 5 ms per i registri (in teoria 1 ms in un array memorizzato nella cache) e tra 4 e 20 ms per i dati (in teoria meno di 10 ms). Nelle ore di punta possono verificarsi latenze più elevate, ma se si registrano regolarmente valori più elevati, è consigliabile ricercarne la causa.
Disco logico: Media scritture disco/sec Questo contatore indica il tempo medio in secondi di un'operazione di scrittura sul disco. In un sistema ottimizzato i valori ideali sono compresi tra 1 e 5 ms per i registri (in teoria 1 ms in un array memorizzato nella cache) e tra 4 e 20 ms per i dati (in teoria meno di 10 ms). Nelle ore di punta possono verificarsi latenze più elevate, ma se si registrano regolarmente valori più elevati, è consigliabile ricercarne la causa.
Quando si usano configurazioni RAID con il contatore Disco logico: Media byte letti da disco o Disco logico: Media byte scritti su disco, fare riferimento alle formule elencate nella tabella seguente per determinare la frequenza di input e output sul disco.
Livello RAID Formula RAID 0
I/O per disco = (letture + scritture) / numero di dischi
RAID 1
I/O per disco = [letture + (2 × scritture)] / 2
RAID 5
I/O per disco = [letture + (4 × scritture)] / numero di dischi
RAID 10
I/O per disco = [letture + (2 × scritture)] / numero di dischi
Se ad esempio si dispone di un sistema RAID 1 con due dischi fisici e i valori dei contatori corrispondono a quelli indicati nella tabella seguente:
Contatore Valore Media letture disco/sec
80
Disco logico: Media scritture disco/sec
70
Lunghezza media coda del disco
5
Il valore di I/O per disco può essere calcolato come segue: (80 + (2 × 70))/2 = 110
La lunghezza della coda del disco può essere calcolata come segue: 5/2 = 2,5
In questa situazione esiste un collo di bottiglia di I/O limite.
Altri strumenti di monitoraggio
È inoltre possibile monitorare la latenza del disco e analizzare le tendenze usando la vista a gestione dinamica sys.dm_io_virtual_file_stats in SQL Server 2008. Per altre informazioni, vedere sys.dm_io_virtual_file_stats (Transact-SQL).
SQL Server 2012 per SharePoint Server 2013
Grazie a Bill Baer, Microsoft Senior Product Marketing Manager, e a Brian Alderman, CEO e fondatore di MicroTechPoint 2nd_ssVersion2012 per aver contribuito con una serie di moduli didattici su SQL Server 2012 online. Un ringraziamento speciale a Channel 9 Microsoft per aver scelto di ospitare questi moduli didattici. Nei moduli seguenti vengono fornite informazioni dettagliate sulle impostazioni del database di SQL Server 2012 che consentiranno di migliorare prestazioni, disponibilità e sicurezza di SharePoint Server 2016.
Ottimizzazione di SQL Server 2012 per SharePoint 2013: (03) Impostazioni del server per SQL Server
Ottimizzazione di SQL Server 2012 per SharePoint 2013: (04) Disponibilità di SQL Server e SharePoint
See also
Panoramica di SQL Server in un ambiente SharePoint Server 2016
Ottimizzare le prestazioni per SharePoint Server 2013
Procedure consigliate per SQL Server in una server farm di SharePoint
Pianificare le prestazioni di pianificazione in SharePoint Server 2013
Informazioni sulla pianificazione di prestazioni e capacità per SharePoint Server 2013
Pianificazione della capacità per SharePoint Server 2013
Panoramica di SQL Server in un ambiente SharePoint Server 2013