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

 

Si applica a: SharePoint Foundation 2010, SharePoint Server 2010

Ultima modifica dell'argomento: 2016-11-30

In questo articolo viene descritto come pianificare e configurare l'archiviazione e il livello di database di Microsoft SQL Server in un ambiente Microsoft SharePoint Server 2010.

Le informazioni sulla pianificazione della capacità contenute in questo documento possono essere utilizzate come linee guida per la pianificazione. Si basano su test eseguiti presso Microsoft su proprietà attive. I risultati ottenuti tuttavia possono variare a seconda delle attrezzature utilizzate e dalle caratteristiche e funzionalità implementate per i propri siti.

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 utilizzato in collaborazione 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 che sia stata acquisita familiarità con i concetti illustrati in Capacity management and sizing for SharePoint Server 2010.

Processo di progettazione e configurazione dell'archiviazione e del livello di database dei prodotti SharePoint 2010

È consigliabile suddividere il processo di progettazione dell'archiviazione e del livello di database nei passaggi riportati di seguito. In ogni sezione 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 2010. Alcuni fattori chiave sono costituiti dalla quantità di contenuto, dalle caratteristiche e dalle applicazioni di servizio utilizzate, dal numero di farm e dai requisiti di disponibilità.

Prima di iniziare a pianificare l'archiviazione, è consigliabile ottenere acquisire familiarità con i database che possono essere utilizzati da SharePoint Server 2010.

Contenuto della sezione:

  • Database utilizzati dai prodotti SharePoint 2010

  • 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

  • Determinare i requisiti di archiviazione e operazioni di I/O al secondo delle applicazioni di servizio

  • Determinare i requisiti di disponibilità

Database utilizzati dai prodotti SharePoint 2010

I database installati con SharePoint Server 2010 dipendono dalle caratteristiche usate nell'ambiente. Tutti gli ambienti Prodotti SharePoint 2010 si basano sui database di sistema di SQL Server. Questa sezione fornisce un riepilogo dei database installati con SharePoint Server 2010. Per informazioni dettagliate, vedere Tipi di database e descrizioni (SharePoint Server 2010) e il diagramma sui database che supportano SharePoint 2013 (https://go.microsoft.com/fwlink/p/?LinkId=187968).

Versione ed edizione del prodotto Database

SharePoint Foundation 2010

Configurazione

Contenuto di Amministrazione centrale

Contenuto (uno o più database)

Raccolta dati di utilizzo e integrità

Servizio di integrazione applicativa dei dati

Servizio Registro applicazioni (in caso di aggiornamento dal Catalogo dati business di Microsoft Office SharePoint Server 2007)

Servizio impostazioni di sottoscrizione (se abilitato tramite Windows PowerShell)

Ulteriori database per SharePoint Server 2010 Standard Edition

Applicazione servizio di ricerca:

  • Amministrazione ricerca

  • Ricerca per indicizzazione (uno o più database)

  • Proprietà (uno o più database)

Applicazione servizio profili utente:

  • Profili

  • Sincronizzazione

  • Social tagging

Applicazione di servizio Web Analytics:

  • Area di gestione temporanea

  • Report

Archiviazione sicura

Stato

Metadati gestiti

Word Automation Services

Ulteriore database per SharePoint Server 2010 Enterprise Edition

PerformancePoint

Ulteriori database per Project Server 2010

Draft

Published

Archive

Relazioni

Ulteriore database per FAST Search Server

Amministrazione ricerca

Nel caso di un'integrazione ancora più completa con SQL Server, è possibile che nell'ambiente siano inclusi ulteriori database, come illustrato negli scenari seguenti:

  • È possibile usare Microsoft SQL Server 2008 R2 PowerPivot per Microsoft SharePoint 2010 in un ambiente SharePoint Server 2010 che include SQL Server 2008 R2 Enterprise Edition e SQL Server Analysis 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 (https://go.microsoft.com/fwlink/p/?LinkID=186698).

  • È possibile utilizzare il plug-in Microsoft SQL Server 2008 Reporting Services (SSRS) con qualsiasi ambiente di prodotti SharePoint 2010. Se si utilizza il plug-in, pianificare il supporto per i due database di SQL Server 2008 Reporting Services e il carico aggiuntivo necessario per SQL Server 2008 Reporting Services.

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

In un server che ospita 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 lo strumento di benchmark SQLIO dei sottosistemi di dischi. Per informazioni dettagliate, vedere la pagina di download dello strumento di benchmark SQLIO dei sottosistemi di dischi (https://go.microsoft.com/fwlink/p/?LinkID=105586).

Per informazioni dettagliate su come analizzare i requisiti di operazioni di I/O al secondo dal punto di vista di SQL Server mediante l'analisi delle caratteristiche di I/O e il dimensionamento dei sistemi di archiviazione per le applicazioni di database di SQL Server, vedere Analyzing I/O Characteristics and Sizing Storage Systems for SQL Server Database Applications (https://sqlcat.com/whitepapers/archive/2010/05/10/analyzing-i-o-characteristics-and-sizing-storage-systems-for-sql-server-database-applications.aspx).

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 rappresentano il livello di base da pianificare in ogni distribuzione di SharePoint Server 2010.

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, ma l'aumento delle dimensioni non avviene rapidamente. Il database aumenta di circa 40 MB per ogni 50.000 raccolte siti.

Poiché i registri delle transazioni del database di configurazione possono essere estesi, è 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 desidera utilizzare il mirroring del database di SQL Server per garantire la disponibilità per il database di configurazione, sarà necessario utilizzare 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 desidera facilitare il calcolo delle stime da utilizzare 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 ulteriori informazioni sulla metodologia di pianificazione della capacità globale, vedere Capacity management and sizing for SharePoint Server 2010.

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

  1. 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 personali o di collaborazione, è 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'utilizzo 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.

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

  3. 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'utilizzo previsto per i siti.

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

  5. Utilizzare la formula seguente per calcolare la dimensione dei database del contenuto:

    Dimensione database = ((D × V) × G) + (10 KB × (E + (V × D)))

    Il valore di 10 KB nella formula è una costante che indica approssimativamente la quantità di metadati richiesti da SharePoint Server 2010. Se nel sistema è richiesto un utilizzo significativo di metadati, è possibile aumentare questa costante.

Se ad esempio si dovesse utilizzare la formula per calcolare la quantità di spazio di archiviazione necessaria per i file di dati di un database del contenuto in un ambiente di collaborazione con le caratteristiche seguenti, 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

Caratteristiche che influiscono sulle dimensioni dei database del contenuto

L'utilizzo delle caratteristiche di SharePoint Server 2010 seguenti può 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. Per ulteriori informazioni, vedere Configurare le impostazioni del Cestino (SharePoint Server 2010).

  • Controllo I dati di controllo possono formarsi rapidamente e utilizzare 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. Utilizzare 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.

  • Office Web Apps. In caso di utilizzo di Office Web Apps, la cache di Office Web Apps può influire in modo significativo sulle dimensioni di un database del contenuto. Per impostazione predefinita, la cache di Office Web Apps è impostata su 100 GB. Per ulteriori informazioni sulle dimensioni della cache di Office Web Apps, vedere Gestire la cache di Office Web Apps.

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, alla quantità di spazio su disco e al numero di server di cui si dispone. È consigliabile in genere confrontare il carico di lavoro previsto nell'ambiente con una delle soluzioni testate. Per ulteriori informazioni, vedere Risultati dei test delle prestazioni e della capacità e suggerimenti (SharePoint Server 2010).

Importante

Il test del contenuto di questa sezione non è stato ancora completato. Accedere successivamente per ulteriori informazioni.

Determinare 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 utilizzate nel proprio ambiente.

Requisiti di archiviazione e operazioni di I/O al secondo delle applicazioni di servizio di SharePoint Server 2010

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 utilizzate. Nella tabella riportata di seguito sono elencate le applicazioni di servizio disponibili in SharePoint Server 2010 che dispongono di database.

Applicazione di servizio Consigli per il calcolo delle dimensioni

Ricerca

Per il servizio di ricerca sono necessari tre database. Nell'ambiente possono essere inclusi più database delle proprietà e di ricerca per indicizzazione.

Poiché il database di amministrazione della ricerca in genere è di dimensioni ridotte, allocare 10 GB.

Per calcolare i requisiti di archiviazione per i database delle proprietà e di ricerca per indicizzazione, utilizzare i moltiplicatori seguenti:

  • Ricerca per indicizzazione: 0,046 × (somma dei database del contenuto)

  • Proprietà: 0,015 × (somma dei database del contenuto)

I requisiti di operazioni di I/O al secondo per il servizio di ricerca sono significativi.

  • Per il database di ricerca per indicizzazione, sono richiesti da 3.500 a 7.000 operazioni di I/O al secondo.

  • Per il database delle proprietà, sono richieste 2.000 operazioni di I/O al secondo.

Per informazioni dettagliate su come calcolare la capacità richiesta per il servizio di ricerca, vedere Risultati dei test delle prestazioni e della capacità e suggerimenti (SharePoint Server 2010).

FAST Search Server 2010 for SharePoint ha un'architettura diversa. Il database di ricerca per indicizzazione ha gli stessi requisiti IOPS, ma il database delle proprietà viene usato soltanto per la ricerca di persone ed è disponibile un database di amministrazione della ricerca aggiuntivo. Per informazioni dettagliate su FAST Search Server 2010 per SharePoint, vedere Plan search topology (FAST Search Server 2010 for SharePoint) e Performance and capacity management (FAST Search Server 2010 for SharePoint).

Profili utente

L'applicazione di servizio profili utente è associata a tre database: profili, sincronizzazione e social tagging.

Per calcolare i requisiti di archiviazione per i database, utilizzare le informazioni seguenti:

  • Profili. Con le impostazioni predefinite e in un ambiente configurato per l'utilizzo di Active Directory il database profili richiede circa 1 MB per profilo utente.

  • Sincronizzazione. Con le impostazioni predefinite e in un ambiente con pochi gruppi per utente il database di sincronizzazione richiede circa 630 KB per profilo utente. Il 90% dello spazio verrà utilizzato dal file di dati.

  • Social tagging. Con le impostazioni predefinite, il database di social tagging richiede circa 0,009 MB per tag, commento o valutazione. Per calcolare il numero di tag e note che verranno creati dagli utenti, considerare le informazioni seguenti relative al sito del.icio.us:

    • Circa il 10% degli utenti è considerato attivo.

    • Gli utenti attivi creano 4,5 tag e 1,8 commenti al mese.

In un ambiente di collaborazione attiva con 160.000 profili utente, 5 gruppi, 79.000 tag, commenti e valutazioni (2.500 commenti, 76.000 tag e 800 valutazioni) e con le impostazioni predefinite sono state riscontrate le dimensioni seguenti per questi database:

 

Nome del database Dimensioni del database

Profili

155 GB

Sincronizzazione

96 GB

Social tagging

0,66 GB

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 utilizzati nel sistema. Molti ambienti includeranno più istanze dell'applicazione di servizio metadati gestiti.

Web Analytics

Web Analytics dispone di due database: Area di gestione temporanea e Report. Sono numerosi i fattori che determinano le dimensioni dei database, tra cui il periodo di conservazione, il volume giornaliero dei dati monitorati e il numero di raccolte siti, di siti e di siti secondari dell'applicazione Web analizzata. Per informazioni dettagliate su come calcolare i relativi requisiti di operazioni di I/O al secondo e di dimensioni, vedere Risultati dei test delle prestazioni e della capacità e suggerimenti (SharePoint Server 2010).

Archiviazione sicura

Le dimensioni del database dell'applicazione del servizio di 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.

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

L'applicazione di servizio PerformancePoint dispone di un database, pertanto è consigliabile allocare 1 GB. I requisiti di operazioni di I/O al secondo sono minimi.

Determinare i requisiti di disponibilità

Per disponibilità si intende il livello con cui gli utenti percepiscono come disponibile un ambiente SharePoint Server 2010. 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 Pianificare la disponibilità (SharePoint Server 2010).

Scegliere la versione e l'edizione di SQL Server

Benché sia possibile eseguire Prodotti SharePoint 2010 in Microsoft SQL Server 2008 R2, SQL Server 2008 o SQL Server 2005, è consigliabile valutare la possibilità di eseguire il proprio ambiente nell'edizione Enterprise di SQL Server 2008 o SQL Server 2008 R2 per usufruire delle funzionalità aggiuntive relative a prestazioni, disponibilità, sicurezza e gestione in essa disponibili. Per ulteriori informazioni sui vantaggi derivanti dall'utilizzo di SQL Server 2008 R2 Enterprise Edition, vedere Integrazione di SQL Server 2008 R2 e Prodotti SharePoint 2010 (white paper) (SharePoint Server 2010).

Valutare in particolare se si necessita delle caratteristiche seguenti:

  • Compressione backup   La compressione backup può velocizzare i backup di SharePoint ed è disponibile in SQL Server 2008 Enterprise Edition o SQL Server 2008 R2 Standard Edition. Impostando l'opzione di compressione nello script di backup o configurando il server che esegue SQL Server in modo da effettuare la compressione per impostazione predefinita, è possibile ridurre in modo significativo le dimensioni dei backup dei database e dei log inviati. Per altre informazioni, vedere Compressione backup (SQL Server) (https://go.microsoft.com/fwlink/p/?LinkId=129381).

    Nota

    La compressione dati di SQL Server non è supportata per Prodotti SharePoint 2010, fatta eccezione per i database dell'applicazione del servizio di ricerca.

  • Transparent Data Encryption Se i requisiti di sicurezza includono la necessità di utilizzare Transparent Data Encryption, è necessario implementare SQL Server Enterprise Edition.

  • Applicazione di servizio Web Analytics Se si intende utilizzare l'applicazione di servizio Web Analytics per attività di analisi significative, prendere in considerazione SQL Server Enterprise Edition in modo che il sistema possa usufruire del partizionamento delle tabelle.

  • Distribuzione del contenuto Se si intende utilizzare la caratteristica di distribuzione del contenuto, prendere in considerazione SQL Server Enterprise Edition in modo che il sistema possa usufruire degli snapshot di database di SQL Server.

  • 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 utilizzare SQL Server 2008 o SQL Server 2008 R2 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. È disponibile solo in SQL Server 2008 o SQL Server 2008 R2 Enterprise Edition. Per altre informazioni sull'uso di Resource Governor, vedere Gestione di carichi di lavoro di SQL Server con Resource Governor.

    È consigliabile utilizzare Resource Governor con SharePoint Server 2010 per eseguire le operazioni seguenti:

    • Limitare la quantità di risorse di SQL Server utilizzate 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 utilizzate da ogni database presente nel sistema. È ad esempio possibile utilizzare Resource Governor per determinare la posizione ottimale dei database tra i computer in cui è in esecuzione SQL Server.

  • PowerPivot per SharePoint 2010 Consente la condivisione e la collaborazione a 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 Enterprise Edition Analysis Services.

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

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) sono supportate in SharePoint Server 2010, anche se l'archiviazione NAS è supportata solo per l'utilizzo con database del contenuto configurati per utilizzare Archiviazione BLOB remoti. La scelta dipende da fattori impliciti nella soluzione aziendale e nell'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.

Vengono elencati di seguito alcuni vantaggi derivanti dall'utilizzo di un'archiviazione condivisa:

  • 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, Network-Attached Storage)

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

Scegliere i tipi di dischi

I tipi di dischi utilizzati 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 2010 supporta i tipi seguenti di unità:

  • 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 utilizzato 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 2010 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. In assenza di istruzioni del fornitore, fare riferimento all'articolo relativo alle procedure consigliate per le operazioni di I/O per la predistribuzione di SQL Server (https://go.microsoft.com/fwlink/p/?LinkID=105583).

Per altre informazioni sul provisioning di RAID e il sottosistema di I/O di SQL Server, vedere l'articolo relativo alle procedure consigliate per SQL Server (https://go.microsoft.com/fwlink/p/?LinkId=168612).

Valutare i requisiti di memoria

La memoria necessaria per SharePoint Server 2010 è 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 riportata di seguito vengono fornite le linee guida per la quantità di memoria consigliata.

Nota

Per le definizioni di distribuzioni di piccole e medie dimensioni, vedere la sezione relativa alle Architetture di riferimento dell'articolo Panoramica del dimensionamento e della gestione della capacità per SharePoint Server 2010.

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 2010. Per altre informazioni sui requisiti di sistema di SQL Server, vedere Requisiti hardware e software per l'installazione di SQL Server 2008 (https://go.microsoft.com/fwlink/p/?LinkId=129377).

Tra gli altri fattori che possono influire sulla memoria necessaria sono inclusi:

  • Utilizzo del mirroring di SQL Server.

  • Utilizzo 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 utilizzare una rete con latenza bassa.

Nell'elenco riportato di seguito 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 ms.

  • Non è consigliabile utilizzare una topologia WAN con un server che esegue SQL Server distribuito in remoto da altri componenti della farm su una rete con latenza maggiore i 1 ms. Questa topologia non è stata testata.

  • Pianificare una rete WAN adeguata se si intende utilizzare il log shipping o il mirroring 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.

Configurare SQL Server

Nelle sezioni riportate di seguito viene descritto come pianificare la configurazione di SQL Server per SharePoint Server 2010.

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

SharePoint Server 2010 in generale è stato progettato per usufruire della scalabilità orizzontale di SQL Server. È possibile pertanto ottenere prestazioni di SharePoint Server 2010 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 di farm né ospita database di altre applicazioni, a meno che non si distribuisca il sistema in un server autonomo.

Viene indicato di seguito quando è necessario distribuire un server aggiuntivo in cui verrà eseguito SQL Server:

  • Aggiungere un ulteriore server di database se si dispone di più di quattro server Web eseguiti 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.

Nota

Microsoft supporta configurazioni di server che non si basano su queste informazioni aggiuntive.

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

Se non si dispone di informazioni aggiuntive del fornitore, è consigliabile usare l'utilità di configurazione dei dischi DiskPart.exe per configurare l'archiviazione per SQL Server 2008. Per altre informazioni, vedere l'articolo sulle procedure consigliate per le operazioni di I/O per la predistribuzione (https://go.microsoft.com/fwlink/p/?LinkID=105583).

Fornire il maggior numero possibile di risorse

Verificare che i canali di I/O di SQL Server per i dischi non siano condivisi da altre applicazioni, ad esempio il file di paging e i registri 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 utilizza 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 riportate di seguito prima di distribuire SharePoint Server.

  • Non abilitare la creazione automatica di statistiche in un computer SQL Server che 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 2010. Per altre informazioni su come impostare max degree of parallelism, vedere Opzione max degree of parallelism (https://go.microsoft.com/fwlink/p/?LinkId=189030).

  • Per migliorare la gestibilità, configurare gli alias di connessione di SQL Server per ogni server di database della farm. Un alias di connessione è un nome alternativo che può essere usato per la connessione a un'istanza di SQL Server. Per altre informazioni, vedere Impostazione di un alias SQL Server per il servizio SQL Server Agent (SQL Server Management Studio) (https://go.microsoft.com/fwlink/p/?LinkId=132064).

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 registri delle transazioni di SQL Server 2008 dovrebbero essere posizionati in dischi fisici separati.

Nell'elenco riportato di seguito vengono illustrate alcune procedure consigliate e indicazioni per classificare i dati in ordine di priorità:

  • Quando si classificano i dati in ordine di priorità tra i dischi più veloci, utilizzare la classificazione seguente:

    1. File di dati e registri delle transazioni di tempdb

    2. Registri delle transazioni dei database

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

    4. File di dati dei database

    In un sito portale fortemente orientato alla lettura classificare i dati in ordine di priorità nei registri.

  • Dai dati dei test e dei clienti risulta che le prestazioni delle farm di SharePoint Server 2010 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 monitorizza 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 (https://go.microsoft.com/fwlink/p/?LinkID=148537).

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

Utilizzare più file di dati per i database del contenuto

Per ottenere prestazioni ottimali, seguire le indicazioni riportate di seguito:

  • 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 utilizzare gli strumenti di backup e ripristino inclusi in SharePoint Server 2010 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 utilizzano più file di dati per un database del contenuto, è consigliabile pertanto utilizzare gli strumenti di backup e ripristino di SQL Server. Per ulteriori informazioni su come eseguire il backup e il ripristino di SharePoint Server 2010, vedere Pianificare il backup e il ripristino in SharePoint Server 2010.

Per altre informazioni su come creare e gestire i filegroup, vedere Architettura di file e filegroup (https://go.microsoft.com/fwlink/p/?LinkId=117909).

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 sui Limiti relativi ai database del contenuto in Gestione della capacità di SharePoint Server 2010: Limiti software statici e configurabili.

È 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 2010 per spostare una raccolta siti in un altro database.

Per altre informazioni sugli archivi documenti di grandi dimensioni, vedere l'articolo relativo alla valutazione dei requisiti in termini di prestazioni e capacità per archivi documenti su larga scala disponibile in Risultati dei test delle prestazioni e della capacità e suggerimenti (SharePoint Server 2010).

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

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

  • Per quanto possibile, impostare anticipatamente le dimensioni previste per tutti i file di dati e di registro.

  • È consigliabile abilitare l'aumento automatico delle dimensioni per motivi di sicurezza. Non fare affidamento sulle impostazioni predefinite per l'aumento automatico delle dimensioni. Per la configurazione di questa caratteristica, 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. 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.

    • Impostare il valore di aumento automatico delle dimensioni del database delle proprietà di archiviazione delle applicazioni del servizio di ricerca sul 10%.

    • Se si prevede che le dimensioni calcolate del database del contenuto non raggiungeranno la dimensione massima consigliata di 200 GB entro l'anno successivo, utilizzare 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 utilizzare una soluzione di backup incrementale come System Center Data Protection Manager (DPM) 2010.

È importante monitorare i componenti seguenti di un server in cui è in esecuzione SQL Server: 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 l'articolo relativo alla risoluzione dei problemi di prestazioni in SQL Server 2008 (https://go.microsoft.com/fwlink/p/?LinkID=168448).

Nelle sezioni riportate di seguito vengono elencati i contatori delle prestazioni che è consigliabile utilizzare per monitorare le prestazioni dei database di SQL Server in esecuzione nell'ambiente SharePoint Server 2010. Vengono elencati inoltre per ogni contatore i valori approssimativi che indicano un sistema integro.

Per informazioni dettagliate sul monitoraggio delle prestazioni e sull'uso dei contatori delle prestazioni, vedere Guida introduttiva al monitoraggio delle prestazioni (https://go.microsoft.com/fwlink/p/?LinkId=189032).

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 la quantità 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 registro delle transazioni. Monitorare le transazioni e il registro delle transazioni per determinare l'entità delle attività degli utenti nel database e la quantità di dati contenuta nel registro delle transazioni. L'entità delle attività degli utenti può determinare le prestazioni del database e influire sulle dimensioni del registro, il blocco e la replica. Il monitoraggio di attività del registro di basso livello per misurare l'attività degli utenti e l'utilizzo delle risorse consente di individuare colli di bottiglia delle prestazioni. Prendere in considerazione la possibilità di monitorare il contatore seguente:

    • Transazioni/sec Questo contatore indica la quantità 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 le attività degli utenti e l'utilizzo delle risorse consente di identificare 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'efficienza 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 l'utilizzo della memoria da parte di SQL Server 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 durante la lettura e la scrittura di pagine di database da parte di SQL Server. 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 quantità di memoria disponibile per SQL Server.

  • Cache dei piani Questo oggetto fornisce contatori per monitorare l'utilizzo della memoria da parte di SQL Server per archiviare oggetti quali stored procedure, trigger e istruzioni Transact-SQL ad hoc e 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 nella cache 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 altre informazioni e per i metodi di risoluzione dei problemi relativi alla memoria, vedere Monitoraggio dell'utilizzo della memoria (https://go.microsoft.com/fwlink/p/?LinkID=105585).

Contatori di disco da monitorare

Monitorare i contatori seguenti per verificare l'integrità dei dischi. Si noti che i valori riportati di seguito 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. Utilizzare 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, ma questo valore 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 usare lo strumento di benchmark SQLIO per sottosistemi di dischi per calcolarla. Per altre informazioni, vedere l'articolo relativo allo strumento di benchmark SQLIO per sottosistemi di dischi (https://go.microsoft.com/fwlink/p/?LinkID=105586).

    • 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 utilizzano 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 riportata di seguito 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) (https://go.microsoft.com/fwlink/p/?LinkID=105587).

See Also

Other Resources

Centro risorse: Gestione di prestazioni e capacità (SharePoint Server 2010)
Centro risorse: Gestione dei database (SharePoint Server 2010)