Condividi tramite

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

  • Articolo

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

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.

Informazioni su Gestione dei limiti di archiviazione del sito di SharePoint in Microsoft 365.

Anche se i test non sono stati eseguiti in SQL Server 2014 (SP1), SQL Server 2016, SQL Server 2017 RTM o SQL Server 2019, è possibile usare questi risultati dei test come guida per pianificare e configurare il livello di archiviazione e di database DI SQL Server negli ambienti SharePoint Server Subscription Edition, 2019 o 2016. Per un'esercitazione sulla configurazione e sull'ottimizzazione di SQL Server 2012, vedere SQL Server 2012 per SharePoint Server 2013. I risultati del test sono gli stessi di SharePoint 2013.

Questo documento è destinato all'uso congiunto da parte degli implementatori della farm di SharePoint Server e degli amministratori di database di SQL Server, in quanto SharePoint Server viene spesso eseguito in ambienti in cui i database sono gestiti da amministratori di database di SQL Server separati. 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 archiviazione e database per SharePoint Server 2016 e versioni successive

È 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:

  1. Ottenere informazioni sui requisiti di archiviazione e di spazio e I/O di SQL Server

  2. Scegliere la versione e l'edizione di SQL Server

  3. Progettare l'architettura di archiviazione in base ai requisiti di capacità e di I/O

  4. Valutare i requisiti di memoria

  5. Informazioni sui requisiti della topologia di rete

  6. Configurare SQL Server

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

I database installati con SharePoint Server (Subscription Edition, 2019 o 2016) dipendono dalle applicazioni di servizio usate nell'ambiente. Tutti gli ambienti di SharePoint Server si basano sui database di sistema di SQL Server. In questa sezione viene fornito un riepilogo dei database installati con SharePoint Server. Per informazioni dettagliate sui database, vedere Tipi di database e relative descrizioni in SharePoint Server.

[!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. La guida di riferimento rapido: Database di SharePoint Server 2016 e 2019 è disponibile per il download come file PDF o Visio .

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

Se si esegue un'ulteriore integrazione con SQL Server, l'ambiente potrebbe includere anche più database, come 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, è anche necessario pianificare il supporto del database dell'applicazione Power Pivot e il carico aggiuntivo nel 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 dei 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, è anche necessario pianificare il supporto del database dell'applicazione Power Pivot e il carico aggiuntivo nel sistema. Per altre informazioni, vedere Pianificare una distribuzione PowerPivot in una farm di SharePoint, Power Pivot - Panoramica e Apprendimento e Power View - Panoramica e apprendimento.

  • È 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 dei due database di SQL Server 2008 R2 Reporting Services e il carico aggiuntivo necessario per SQL Server 2008 R2 Reporting Services.

Nota

L'integrazione di SQL Server Reporting Services con SharePoint Server 2019 non è più supportata. Per altre informazioni, vedere Server di report di Reporting Services (modalità SharePoint) e Combinazioni supportate del server SharePoint e Reporting Services.

Informazioni su SQL Server e sulle operazioni di I/O al secondo

In un server che ospita un'istanza di SQL Server è importante che il server ottenga 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.

Non è possibile aggiungere altri tipi di risorse, ad esempio CPU o memoria, per compensare la risposta lenta del sottosistema di I/O. Tuttavia, può influenzare e causare problemi in tutta la farm. Pianificare la latenza minima prima della distribuzione e monitorare i sistemi esistenti.

Prima di distribuire una nuova farm, è consigliabile eseguire il benchmark del sottosistema di I/O usando l'utilità Diskspd. Questo strumento funziona in tutte le versioni di Windows Server 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 di grandi dimensioni. È consigliabile allocare 2 GB per il database di configurazione e 1 GB per il database del contenuto di Amministrazione centrale. Nel corso del tempo, il database di configurazione può aumentare oltre 1 GB. Non cresce rapidamente: cresce di circa 40 MB per ogni 50.000 raccolte siti.

I log delle transazioni del database di configurazione possono essere estesi. È consigliabile eseguire il backup del log delle transazioni per il database di configurazione regolarmente per forzare il troncamento. Se si usano i gruppi di disponibilità Always On di SQL Server o il mirroring del database, è consigliabile tenere il database in esecuzione in modalità di recupero con registrazione completa. Per altre informazioni, vedere Log delle transazioni (SQL Server).

Consiglio

Se non si usa una soluzione a disponibilità elevata di SQL Server, che richiede l'uso di un modello di recupero con registrazione completa, può essere opportuno riconfigurare il database per l'uso del modello di recupero con registrazione minima.

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:

  1. Usare la formula seguente per calcolare la dimensione dei database del contenuto:

    Dimensioni del database = ((D x V) x S) + (10 KB x (L + (V x D)))

    Nota

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

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

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

  4. 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. In genere viene usata una stima tre volte il numero di documenti (D), ma la formula di stima varia in base al modo in cui si prevede di usare i siti.

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

Ad esempio, usare questa formula e le caratteristiche della tabella seguente per stimare lo spazio di archiviazione necessario per i file di dati in un database del contenuto per un ambiente di collaborazione. Il risultato è che sono 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 del database = (((200.000 x 2)) x 250) + ((10 KB x (600.000 + (200.000 x 2))) = 110.000.000 KB o 105 GB

Nota

[!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 funzionalità 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

[!NOTA] Office Online Server è la versione successiva di Office Online Server. L'uso di Office Online Server con SharePoint Server 2016, 2019, Subscription Edition non influisce sulle dimensioni del database del contenuto. Per distribuire Office Online Server nella farm di SharePoint Server 2016, vedere Deploy Office Online Server.

Valutare i requisiti di operazioni di I/O al secondo dei database del contenuto

I requisiti di I/O al secondo per i database del contenuto variano in base al modo in cui viene usato l'ambiente, allo spazio disponibile su disco e al numero di server disponibili. È consigliabile in genere confrontare il carico di lavoro previsto nell'ambiente con una delle soluzioni testate. Per altre informazioni e può essere applicato alla versione più recente di SharePoint, vedere Risultati dei test di prestazioni e capacità e raccomandazioni (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. Questa percentuale è più che necessaria e può essere molto più di quanto sarà necessario nell'ambiente. Se si usa il mirroring, questa proporzione maggiore comporta un numero di operazioni di I/O molto superiore rispetto ai database del contenuto primari. Tenere presente che i database del contenuto con mirroring non sono mai leggeri.

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 di archiviazione e operazioni di I/O al secondo per tutte le applicazioni di servizio in SharePoint Server Subscription Edition, 2019 o 2016 rimangono gli stessi di SharePoint Server 2010 e 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 un documento al secondo		 Medio/Alto Media 15 GB
Log da 2 GB		 110 GB
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 10 GB
Log da 0,1 GB		 80 GB
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,4 GB
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: i test per i requisiti di archiviazione del database del profilo utente e le raccomandazioni di I/O al secondo non sono ancora stati completati. 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 del servizio metadati gestiti ha un database. Le dimensioni del database sono influenzate dal numero di tipi di contenuto e parole chiave usate nel sistema. Molti ambienti includeranno più istanze dell'applicazione del 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. È 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 del servizio informazioni sullo stato ha un database. È consigliabile allocare 1 GB. I requisiti di operazioni di I/O al secondo sono minimi.
Word Automation Services L'applicazione del servizio Di automazione di Word dispone di un database. È consigliabile allocare 1 GB. I requisiti di operazioni di I/O al secondo sono minimi.
PerformancePoint Services L'applicazione di servizio PerformancePoint ha un database. È consigliabile allocare 1 GB. I requisiti di operazioni di I/O al secondo sono minimi.
Servizio di integrazione applicativa dei dati L'applicazione del servizio di integrazione applicativa dei dati ha un database. Questo database è piccolo e una crescita significativa è improbabile. I requisiti di operazioni di I/O al secondo sono minimi. PerformancePoint Services non è applicabile per Subscription Edition.
Gestione app L'applicazione del servizio di gestione app ha un database. Questo database è piccolo e una crescita significativa è improbabile. I requisiti di operazioni di I/O al secondo sono minimi.
PowerPivot L'applicazione del servizio Power Pivot ha un database. Questo database è di piccole dimensioni e non ha alcun impatto significativo sull'I/O. È consigliabile usare le stesse operazioni di I/O al secondo del database del contenuto di SharePoint. I database del contenuto hanno requisiti di I/O significativamente più elevati rispetto al database dell'applicazione del servizio Power Pivot.

Determinare i requisiti di disponibilità

La disponibilità è la quantità di disponibilità percepita dagli utenti in un ambiente SharePoint Server. 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 all'architettura Always On e alla creazione di soluzioni di ripristino di emergenza e ad elevata disponibilità mediante i gruppi di disponibilità Always On.

Scegliere la versione e l'edizione di SQL Server

Per SharePoint Server Subscription Edition, 2019, or 2016 è consigliabile eseguire il proprio ambiente sull'Enterprise Edition dei seguenti SQL Server per sfruttare altre prestazioni e funzionalità relative a disponibilità, sicurezza e gestione aggiuntive fornite da tale versione.

  • SQL Server 2019 (SharePoint Subscription Edition, 2019 e 2016)

  • SQL Server 2017 RTM (SharePoint Servers 2016 e 2019)

  • SQL Server 2016 (SharePoint Servers 2016 e 2019)

  • SQL Server 2014 con Service Pack 1 (SP1) (solo SharePoint Server 2016)

Per altre informazioni sui vantaggi di queste versioni, vedere Funzionalità supportate dalle edizioni di SQL Server 2014, edizioni e funzionalità supportate di SQL Server 2016, Edizioni e funzionalità supportate di SQL Server 2017 e Edizioni e funzionalità supportate di SQL Server 2019 (15.x)).

Per SharePoint Server 2013 è consigliabile eseguire l'ambiente in Enterprise Edition di SQL Server 2008 R2 con Service Pack 1 (SP1), SQL Server 2012 o SQL Server 2014 per sfruttare le altre funzionalità di prestazioni, disponibilità, sicurezza e gestione offerte da queste versioni. 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).

    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.

  • Archivio BLOB remoto Se si desidera usufruire di Archivio BLOB remoto in un database o un percorso esterno ai file associati a ogni database del contenuto, sarà necessario usare Enterprise Edition di:

    SharePoint Server Subscription Edition:

    • SQL Server 2016

    • SQL Server 2017 RTM

    • SQL Server 2019

    SharePoint Server 2019:

    • SQL Server 2016

    • SQL Server 2017 RTM

    • SQL Server 2019

    SharePoint Server 2016:

    • SQL Server 2014 (SP1)

    • SQL Server 2016

    • SQL Server 2017 RTM

    • SQL Server 2019

    SharePoint 2013:

    • SQL Server 2008 R2 con SP1

    • SQL Server 2012 Enterprise Edition

  • 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 altre informazioni su come usare Resource Governor, vedere Resource Governor.

    È 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 Power Pivot per SharePoint Consente agli utenti di condividere e collaborare ai modelli di dati generati dall'utente e all'analisi in Excel sul Web aggiornando automaticamente tali analisi. È necessario disporre di Office sul Web per usare Excel sul Web con Power Pivot 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

SharePoint Server supporta le architetture di archiviazione DAS (Direct Attached Storage), SAN (Storage Area Network) e NAS (Network Attached Storage), anche se NAS è supportato solo per l'uso con database del contenuto configurati per l'uso dell'archiviazione BLOB remota. La scelta dipende da fattori all'interno della soluzione aziendale e dell'infrastruttura esistente.

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

È consigliabile in genere 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 autonomo connesso a una rete. Il suo unico scopo è fornire servizi di archiviazione dati basati su file ad altri dispositivi in rete. Il sistema operativo e il software sull'unità NAS offrono l'archiviazione dei dati, file system, l'accesso ai file e la gestione delle funzionalità (ad esempio, l'archiviazione dei file).

Nota

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

Nota

Esiste una certa confusione riguardo all'uso di Internet Small Computer System Interface (iSCSI) e si presuppone che si tratti di un protocollo NAS. Se si accede a questa risorsa di archiviazione iSCSI tramite common internet file system (CFIS), si tratta di un protocollo NAS. Ciò significa che non è possibile usare questa risorsa di archiviazione con i database del contenuto se non sono configurati per l'uso di RBS. Se tuttavia si accede a questa risorsa di archiviazione iSCSI tramite un disco rigido collegato in locale, viene considerata un'architettura SAN. Ciò significa che è possibile usarlo 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

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 aggiuntiva superiore a 64 GB

Nota

[!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 altre 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 per SQL Server 2016 e 2017.

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.

Gli altri fattori che possono influire sulla memoria necessaria includono:

  • 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 Always On, il mirroring, il 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

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 istruzioni 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. Una maggiore larghezza di banda del bus contribuisce a migliorare l'affidabilità e le prestazioni. È necessario tenere in considerazione che la larghezza di banda non viene utilizzata solo dal disco e valutare ad esempio anche l'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 delle statistiche può modificare 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, i database di ricerca e SQL Server 2019, SQL Server 2017 RTM, SQL Server 2016, SQL Server 2014 (SP1), SQL Server 2012 e SQL Server 2008 R2 con i log delle transazioni SP1 dovrebbero essere 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.

  • I test e i dati dei clienti mostrano che le prestazioni della farm di SharePoint Server possono essere ostacolate da un I/O su disco insufficiente 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

[!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 altre informazioni sui limiti delle dimensioni del database del contenuto, vedere la sezione "Limiti del database del contenuto" in Limiti e limiti software per SharePoint Server 2016 e 2019.

È 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 la aumento automatico per motivi di sicurezza. Non fare affidamento sulle impostazioni di aumento automatico predefinite. Quando si configura l'aumento automatico, prendere in considerazione le linee guida seguenti:

    • 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. Questa impostazione riduce la frequenza con cui SQL Server aumenta 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 raggiungano le dimensioni massime consigliate di 200 GB entro l'anno successivo, impostarle sulle dimensioni massime che il database dovrebbe raggiungere in un anno, con un margine di errore aggiuntivo del 20%, usando la proprietà ALTER DATABASE MAXSIZE . 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 maggiori informazioni, consultare Monitoraggio e ottimizzazione per la performance.

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 numero non deve aumentare oltre 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 overload costante, verificare se è presente un'attività di processo anomala o se il server necessita di più 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:

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. I valori seguenti rappresentano valori misurati nel tempo, non valori che si verificano durante un picco improvviso e non valori basati su una singola misurazione.

  • Disco fisico: % tempo disco: DataDrive Questo contatore mostra la percentuale di tempo trascorso in cui l'unità disco selezionata è occupata per la manutenzione delle richieste di lettura o scrittura. Si tratta di un indicatore generale della disponibilità del disco. Se il contatore Disco fisico: % tempo disco è elevato (oltre il 90%), controllare il contatore PhysicalDisk: Current Disk Queue Length per vedere quante richieste di sistema sono in attesa dell'accesso al disco. Il numero di richieste di I/O in attesa deve essere sostenuto da non più di 1,5 a 2 volte il numero di spindle 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/lettura disco Questo contatore mostra il numero medio di byte trasferiti dal disco durante le operazioni di lettura. Questo valore può riflettere la latenza del disco. Le operazioni di lettura più grandi possono comportare un aumento della latenza.

  • Disco logico: media. Byte/scrittura del disco Questo contatore mostra il numero medio di byte trasferiti al disco durante le operazioni di scrittura. Questo valore può riflettere la latenza del disco. Le operazioni di scrittura più grandi possono comportare un 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. Pertanto, un valore massimo di 8 è accettabile per un'unità logica (LUN) costituita da quattro 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. Tuttavia, questo numero di richieste può 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 altre informazioni, vedere Diskspd: A Robust Storage Performance Tool.For more information, see Diskspd: A Robust Storage Performance Tool.

    • Disco logico: media. Disco sec/Lettura Questo contatore mostra 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 log (idealmente 1 ms in una matrice memorizzata nella cache) e da 4 a 20 ms per i dati (idealmente meno di 10 ms). Possono verificarsi latenze più elevate durante le ore di punta. Tuttavia, se i valori elevati si verificano regolarmente, è necessario analizzare la causa.

    • Disco logico: media. Disco sec/Scrittura Questo contatore mostra 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 log (idealmente 1 ms in una matrice memorizzata nella cache) e da 4 a 20 ms per i dati (idealmente meno di 10 ms). Possono verificarsi latenze più elevate durante le ore di punta. Tuttavia, se i valori elevati si verificano regolarmente, è necessario analizzare 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 x 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 x 70))/2 = 110

  • disk queue length può essere calcolato 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.

Vedere anche

Concetti

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

Ottimizzare le prestazioni per SharePoint Server 2013

Procedure consigliate per SQL Server in una server farm di SharePoint

Pianificazione delle prestazioni in SharePoint Server 2013

Informazioni sulla pianificazione di prestazioni e capacità per SharePoint Server 2013

Pianificazione della capacità per SharePoint Server 2013

Ulteriori risorse

Panoramica di SQL Server in un ambiente SharePoint Server 2013