Considerazioni sulla progettazione di SQL Server

System Center Operations Manager richiede l'accesso a un'istanza di un server che esegue Microsoft SQL Server per il supporto del database operativo, del database del data warehouse e del database di controllo ACS. Il database operativo e quello del data warehouse sono necessari e vengono creati al momento della distribuzione del primo server di gestione nel gruppo di gestione, mentre il database ACS viene creato quando si distribuisce una raccolta dati ACS nel gruppo di gestione.

In un ambiente di laboratorio o in una distribuzione di Operations Manager su scala ridotta SQL Server può essere posizionato nel primo server di gestione del gruppo di gestione.

In una distribuzione su scala da media a grande l'istanza di SQL Server deve essere posizionata su un server autonomo dedicato o in una configurazione di SQL Server a disponibilità elevata. In entrambi i casi, SQL Server deve essere già presente e accessibile prima dell'avvio dell'installazione del primo server di gestione o della raccolta dati ACS.

Non è consigliabile usare i database di Operations Manager da un'istanza DI SQL con altri database dell'applicazione. Ciò consente di evitare potenziali problemi relativi all'I/O e ad altre restrizioni relative alle risorse hardware.

Importante

Operations Manager non supporta le istanze PaaS (Platform as a Service) di SQL, inclusi prodotti come Istanza gestita di SQL di Azure o Amazon Relational Database Service (AWS RDS). Usare un'istanza di SQL Server installata in un computer Windows. L'unica eccezione è all'interno del Istanza gestita SCOM di Monitoraggio di Azure, che usa Azure SQL MI e non è riconfigurabile.

Requisiti di SQL Server

Le versioni seguenti di SQL Server Enterprise e SQL Server Standard sono supportate per un'installazione esistente della versione di System Center Operations Manager per ospitare database di server di report, operativi, del data warehouse e ACS:

• SQL Server 2022

• SQL Server 2019 con l'aggiornamento cumulativo 8 (CU8) o versione successiva, come descritto qui

  Nota

  • Operations Manager 2022 supporta SQL 2019 con CU8 o versione successiva; tuttavia, non supporta SQL 2019 RTM.
  • Usare ODBC 17.3 o versione successiva e MSOLEDBSQL 18.2 o versione successiva.

• SQL Server 2017 e aggiornamenti cumulativi, come specificato qui

Prima di aggiornare SQL Server, vedere informazioni sull'aggiornamento per 2017 e informazioni sull'aggiornamento per SQL 2019.

Nota

• Ognuno dei componenti di SQL Server seguenti che supportano un'infrastruttura SCOM deve essere nello stesso SQL Server versione principale:
  • SQL Server istanze del motore di database che ospitano uno qualsiasi dei database SCOM, ovvero OperationManager, OperationManagerDW e database SSRS ReportServer & ReportServerTempDB.
  • Istanza di SQL Server Reporting Services (SSRS).
• L'impostazione delle regole di confronto SQL Server deve essere uno dei tipi supportati, come descritto nella sezione SQL Server impostazione delle regole di confronto riportata di seguito.
• SQL Server ricerca full-text è necessaria per tutte le istanze del motore di database SQL Server che ospitano uno qualsiasi dei database SCOM.
• Le opzioni di installazione Windows Server 2016 (Server Core, Server con Esperienza desktop e Nano Server) supportate dai componenti di database di Operations Manager sono basate sulle opzioni di installazione di Windows Server supportate da SQL Server.

Nota

Non è possibile installare System Center Operations Manager Reporting in modalità side-by-side con una versione precedente del ruolo Reporting e deve essere installato solo in modalità nativa (la modalità integrata SharePoint non è supportata).

Nella pianificazione della progettazione tenere presenti le considerazioni su hardware e software riportate di seguito:

• È consigliabile eseguire SQL Server su computer con il formato di file NTFS.
• Per il database operativo e per quello del data warehouse devono essere presenti almeno 1024 MB di spazio libero su disco. Viene applicato al momento della creazione del database e probabilmente crescerà in modo significativo dopo la configurazione.
• È richiesto .NET Framework 4.
• .NET Framework 4.8 è supportato da Operations Manager 2022.
• Reporting Server non è supportato in Windows Server Core.

Per altre informazioni, vedere Requisiti hardware e software per l'installazione di SQL Server.

Nota

Anche se Operations Manager usa solo autenticazione di Windows durante l'installazione, l'impostazione autenticazione in modalità mista SQL funzionerà comunque se nessun account locale ha il ruolo db_owner. Gli account locali con il ruolo db_owner sono noti per causare problemi con System Center Operations Manager. Rimuovere il ruolo db_owner da tutti gli account locali prima di installare il prodotto e non aggiungere il ruolo db_owner a nessuno degli account locali dopo l'installazione.

Impostazione delle regole di confronto SQL Server

Le regole di confronto di SQL Server e Windows riportate di seguito sono supportate da System Center Operations Manager.

Nota

Per evitare problemi di compatibilità nelle operazioni di copia o confronto, è consigliabile usare le stesse regole di confronto per il database SQL e Operations Manager.

Regole di confronto di SQL Server

• SQL_Latin1_General_CP1_CI_AS

Regole di confronto di Windows

• Latin1_General_100_CI_AS
• French_CI_AS
• French_100_CI_AS
• Cyrillic_General_CI_AS
• Chinese_PRC_CI_AS
• Chinese_Simplified_Pinyin_100_CI_AS
• Chinese_Traditional_Stroke_Count_100_CI_AS
• Japanese_CI_AS
• Japanese_XJIS_100_CI_AS
• Traditional_Spanish_CI_AS
• Modern_Spanish_100_CI_AS
• Latin1_General_CI_AS
• Cyrillic_General_100_CI_AS
• Korean_100_CI_AS
• Czech_100_CI_AS
• Hungarian_100_CI_AS
• Polish_100_CI_AS
• Finnish_Swedish_100_CI_AS

Se l'istanza di SQL Server non è configurata con una delle regole di confronto supportate elencate in precedenza, l'esecuzione di una nuova installazione di Operations Manager avrà esito negativo. Sarà tuttavia possibile completare un aggiornamento sul posto.

Configurazione del firewall

Operations Manager dipende da SQL Server per ospitare i database e da una piattaforma per la creazione di report per analizzare e presentare i dati operativi storici. I ruoli del server di gestione, delle operazioni e della console Web devono essere in grado di comunicare correttamente con SQL Server ed è importante comprendere il percorso di comunicazione e le porte per configurare correttamente l'ambiente.

Se si progetta una distribuzione distribuita che richiederà a SQL Always On gruppi di disponibilità di fornire funzionalità di failover per i database di Operations Manager, sono disponibili impostazioni di configurazione del firewall aggiuntive che devono essere incluse nella strategia di sicurezza del firewall.

La tabella seguente consente di identificare le porte del firewall richieste da SQL Server (configurazione minima) per permettere ai ruoli server del gruppo di gestione Operations Manager di comunicare correttamente.

Scenario	Porta	Direzione	Ruolo di Operations Manager
SQL Server che ospita i database di Operations Manager	TCP 1433 *	In ingresso	server di gestione e console Web (per Application Advisor e Diagnostica applicazioni)
Servizio SQL Server Browser	UDP 1434	In ingresso	server di gestione
Connessione amministrativa dedicata SQL Server	TCP 1434	In ingresso	server di gestione
Altre porte usate da SQL Server - Chiamate di procedure remote Microsoft (MS RPC) - Strumentazione gestione Windows (WMI) - Servizio Microsoft Distributed Transaction Coordinator (MS DTC)	TCP 135	In ingresso	server di gestione
Listener del gruppo di disponibilità Always On di SQL Server	Porta configurata dall'amministratore	In ingresso	server di gestione
SQL Server Reporting Services che ospita Operations Manager Reporting Server	TCP 80 (impostazione predefinita)/443 (SSL)	In ingresso	server di gestione e Console operatore

* Mentre TCP 1433 è la porta standard per l'istanza predefinita del motore di database, quando si crea un'istanza denominata in un SQL Server autonomo o si è distribuito un gruppo di disponibilità SQL Always On, verrà definita una porta personalizzata e deve essere documentata per riferimento in modo da configurare correttamente i firewall e immettere queste informazioni durante l'installazione.

Per una panoramica più dettagliata sui requisiti dei firewall per SQL Server, vedere Configurare Windows Firewall per consentire l'accesso a SQL Server.

Considerazioni sulla capacità e l'archiviazione

Database di Operations Manager

Il database di Operations Manager è un database SQL Server contenente tutti i dati richiesti da Operations Manager per il monitoraggio quotidiano. Le dimensioni e la configurazione del server di database sono fattori di importanza critica per le prestazioni complessive del gruppo di gestione. La risorsa più critica usata dal database di Operations Manager è il sottosistema di archiviazione, ma sono elementi significativi anche la CPU e la RAM.

I fattori che influenzano il carico di lavoro nel database di Operations Manager sono i seguenti:

• Frequenza di raccolta dei dati operativi. Il termine "dati operativi" indica tutti gli eventi, gli avvisi, i cambiamenti di stato e i dati sulle prestazioni raccolti dagli agenti. La maggior parte delle risorse usate dal database di Operations Manager vengono usate per scrivere questi dati sul disco non appena arrivano al sistema. La frequenza di raccolta dei dati operativi tende ad aumentare quando si importano Management Pack aggiuntivi e si aggiungono ulteriori agenti. Anche il tipo di computer monitorato da un agente è un fattore importante per determinare la frequenza complessiva di raccolta dei dati operativi. Ad esempio, è possibile che un agente che esegue il monitoraggio di un computer desktop di importanza critica per l'azienda raccolga una quantità di dati minore rispetto a un agente che esegue il monitoraggio di un server che esegue un'istanza di SQL Server con un elevato numero di database.
• Frequenza delle modifiche di spazio dell'istanza. L'aggiornamento di questi dati nel database di Operations Manager è relativamente più costoso rispetto alla scrittura di nuovi dati operativi. Inoltre, quando i dati relativi allo spazio dell'istanza vengono modificati, i server di gestione inviano altre query al database di Operations Manager per calcolare le modifiche della configurazione e del gruppo. La frequenza delle modifiche allo spazio dell'istanza aumenta quando si importano Management Pack aggiuntivi in un gruppo di gestione. Anche l'aggiunta di nuovi agenti a un gruppo di gestione aumenta temporaneamente la frequenza delle modifiche allo spazio dell'istanza.
• Numero di Console operatore e altre connessioni SDK in esecuzione contemporaneamente. Ciascuna Console operatore legge i dati dal database di Operations Manager. L'esecuzione di query su questi dati determina potenzialmente il consumo di grandi quantità di risorse in termini di I/O dell'archiviazione, tempo di CPU e RAM. Le Console operatore che visualizzano grandi quantità di dati operativi nelle visualizzazioni Eventi, Stato, Avvisi e Dati prestazioni tendono a determinare il carico di lavoro massimo sul database.

Il database di Operations Manager è un'unica origine di errore per il gruppo di gestione e può essere reso a disponibilità elevata mediante configurazioni di failover supportate, ad esempio gruppi di disponibilità SQL Server Always On o istanze del cluster di failover.

È possibile configurare e aggiornare i database di Operations Manager con una configurazione SQL Always-On esistente senza alcuna necessità di apportare modifiche alla configurazione.

Abilitare SQL Broker nel database di Operations Manager

System Center Operations Manager dipende da SQL Server Service Broker per implementare tutte le operazioni attività. Se SQL Server Service Broker è disabilitato, tutte le operazioni di attività verranno interessate. Il comportamento risultante può variare in base all'attività avviata. È quindi importante controllare lo stato di SQL Server Service Broker ogni volta che si osserva un comportamento imprevisto intorno a un'attività in System Center Operations Manager.

Per abilitare SQL Server Service Broker, seguire questa procedura:

1. Eseguire la query SQL seguente:

   SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'
   

2. Ignorare questo passaggio se il valore visualizzato nel is_broker_enabled campo è 1 (uno). In caso contrario, eseguire le query SQL seguenti:

   ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE
   ALTER DATABASE OperationsManager SET ENABLE_BROKER
   ALTER DATABASE OperationsManager SET MULTI_USER
   

Database del data warehouse di Operations Manager

System Center : Operations Manager inserisce i dati nel data warehouse di reporting in tempo quasi in tempo reale, è importante avere capacità sufficiente in questo server che supporta la scrittura di tutti i dati raccolti nel data warehouse di reporting. Come per il database di Operations Manager, la risorsa più critica sul data warehouse di report è il sottosistema I/O dell'archiviazione. Nella maggior parte dei sistemi i carichi di lavoro del data warehouse di report sono simili a quelli del database di Operations Manager, ma possono variare. Inoltre, il carico di lavoro assegnato al data warehouse dalle funzionalità di report è diverso da quello assegnato al database di Operations Manager dall'utilizzo della Console operatore.

I fattori che influenzano il carico di lavoro sul data warehouse di report sono i seguenti:

• Frequenza di raccolta dei dati operativi. Per assicurare maggiore efficienza alle funzionalità di report, il data warehouse di report calcola e archivia dati aggregati nonché una quantità limitata di dati non elaborati. A causa di questo lavoro aggiuntivo, la raccolta di dati operativi da parte del data warehouse di report può risultare leggermente più costosa di quella del database di Operations Manager. Questo costo aggiuntivo è generalmente bilanciato dal ridotto costo di elaborazione dei dati di individuazione da parte del data warehouse di report rispetto al database di Operations Manager.
• Numero di utenti simultanei che usano le funzionalità di report o generazione pianificata di report. Poiché i report riepilogano spesso ingenti volumi di dati, ogni utente che usa le funzionalità di report può aggiungere un carico di lavoro significativo al sistema. Il numero di report eseguiti simultaneamente e il tipo di report in esecuzione influiscono entrambi sulla necessità di capacità complessiva. In genere i report che eseguono query relative a grandi intervalli di date o elevati numeri di oggetti richiedono risorse di sistema aggiuntive.

Sulla base di questi fattori, quando si determinano le dimensioni del data warehouse di report è opportuno seguire le procedure consigliate seguenti:

• Scegliere un sottosistema di archiviazione appropriato. Poiché il data warehouse di report è una parte integrante del flusso complessivo di dati attraverso il gruppo di gestione, è importante scegliere un sottosistema di archiviazione appropriato. Come per il database di Operations Manager, RAID 0 + 1 è spesso la scelta migliore. In generale, il sottosistema di archiviazione del data warehouse di report deve essere simile a quello del database di Operations Manager. Le linee guida valide per il database di Operations Manager si applicano anche al data warehouse di report.
• Determinare la posizione appropriata dei registri dati e dei log delle transazioni. Come per il database di Operations Manager, la separazione dei dati SQL e dei log delle transazioni è spesso una scelta appropriata quando si aumenta il numero di agenti. Se il database di Operations Manager e il data warehouse di report si trovano entrambi nello stesso server e si vogliono separare i registri dati e i log delle transazioni, per ottenere qualche vantaggio è necessario posizionare i log delle transazioni del database di Operations Manager in un volume fisico e in assi del disco separati da quelli del data warehouse di report. I file di dati per il database di Operations Manager e il data warehouse di Reporting possono condividere lo stesso volume fisico purché il volume fornisca capacità e prestazioni di I/O su disco adeguate non influisce negativamente sulla funzionalità di monitoraggio e creazione di report.
• È consigliabile posizionare il data warehouse di report in un server separato da quello del database di Operations Manager. Anche se le distribuzioni con scalabilità ridotta possono spesso consolidare il database di Operations Manager e il data warehouse di reporting nello stesso server, è vantaggioso separarli mentre si aumenta il numero di agenti e il volume di dati operativi in ingresso. Quando il data warehouse di report e il server di report si trovano su un server separato da quello del database di Operations Manager, offrono prestazioni migliori.

Il database del data warehouse di Operations Manager è un'unica origine di errore per il gruppo di gestione e può essere reso a disponibilità elevata mediante configurazioni di failover supportate, ad esempio gruppi di disponibilità SQL Server Always On o istanze del cluster di failover.

SQL Server Always On

I gruppi di disponibilità Always On di SQL Server supportano ambienti di failover per un set discreto di database utente (database di disponibilità). Ogni set di database di disponibilità è ospitato da una replica di disponibilità.

Con System Center 2016 - Operations Manager e versioni successive, SQL Always On è preferibile ai cluster di failover per garantire la disponibilità elevata dei database. È possibile ospitare in un gruppo di disponibilità Always On tutti i database, ad eccezione dell'installazione di Reporting Services in modalità nativa, che usa due database per separare i requisiti di archiviazione persistente dei dati dai requisiti di archiviazione temporanea.

Con Operations Manager 2022 è possibile configurare e aggiornare i database di Operations Manager con un'installazione di SQL Always-On esistente senza alcuna necessità di modifiche successive alla configurazione.

Per configurare un gruppo di disponibilità, è necessario distribuire un cluster WSFC (Windows Server Failover Clustering) per ospitare la replica di disponibilità e abilitare Always On nei nodi del cluster. È quindi possibile aggiungere il database SQL Server di Operations Manager come un database di disponibilità.

• Altre informazioni sui prerequisiti di Always On.
• Altre informazioni sulla configurazione di un cluster WSFC per Always On gruppi di disponibilità.
• Altre informazioni sulla configurazione di un gruppo di disponibilità.

Nota

Dopo aver distribuito Operations Manager nei nodi di SQL Server che partecipano a SQL Always On, per abilitare la modalità CLR Strict Security eseguire lo script SQL in ogni database di Operations Manager.

Stringa relativa a più subnet

Operations Manager non supporta le parole chiave stringa di connessione (MultiSubnetFailover=True). Poiché i gruppi di disponibilità hanno un nome di listener, noto come nome rete o punto di accesso client in Gestione Cluster WSFC, dipendente da diversi indirizzi IP di più subnet, come quando si distribuisce in una configurazione di failover tra siti, le richieste di connessione client dei server di gestione al listener del gruppo di disponibilità riscontreranno un timeout connessione.

L'approccio consigliato per ovviare a questa limitazione quando sono stati distribuiti nodi del server nel gruppo di disponibilità in un ambiente con più subnet consiste nell'eseguire le operazioni seguenti:

1. Impostare il nome di rete del listener del gruppo di disponibilità per registrare solo un singolo indirizzo IP attivo in DNS.
2. Configurare il cluster per usare un valore TTL basso per il record DNS registrato.

Tali impostazioni consentono, quando si esegue il failover in un nodo in una subnet diversa, il ripristino e la risoluzione del nome del cluster con il nuovo indirizzo IP in tempi più brevi.

Eseguire i comandi di PowerShell seguenti in uno dei nodi SQL per modificarne le impostazioni:

Import-Module FailoverClusters
Get-ClusterResource "Cluster Name"|Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource "Cluster Name"|Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource "Cluster Name"
Start-ClusterResource "Cluster Name"
Start-ClusterGroup "Cluster Name"

Se si usa Always On con un nome del listener, è necessario apportare anche queste modifiche di configurazione nel listener. Per altre informazioni sulla configurazione di un listener del gruppo di disponibilità, vedere la documentazione qui: Configurare il listener del gruppo di disponibilità - SQL Server Always On

Eseguire i comandi di PowerShell seguenti nel nodo SQL che ospita attualmente il listener per modificarne le impostazioni:

Import-Module FailoverClusters
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource <Listener Cluster Resource name>
Start-ClusterResource <Listener Cluster Resource name>
Start-ClusterGroup <Listener Cluster Group name>

Quando si usa un cluster o un'istanza SQL Always On per la disponibilità elevata, è consigliabile abilitare la funzionalità di ripristino automatico sui server di gestione per evitare il riavvio del servizio di accesso ai dati di Operations Manager ogni volta che si verifica un failover tra i nodi. Per informazioni su come configurare questa impostazione, vedere l'articolo della Knowledge Base Il servizio di gestione di System Center smette di rispondere dopo che un'istanza di SQL Server passa alla modalità offline.

Ottimizzazione di SQL Server

In generale, l'esperienza di distribuzione precedente con i clienti mostra che i problemi di prestazioni in genere non sono causati da un utilizzo elevato delle risorse (ovvero processore o memoria) con SQL Server stessa, ma direttamente correlato alla configurazione del sottosistema di archiviazione. I colli di bottiglia delle prestazioni sono in genere attribuiti al mancato rispetto delle linee guida relative alla configurazione dell'archiviazione di cui è stato eseguito il provisioning per l'istanza di database SQL Server. Di seguito sono riportati alcuni esempi:

• Allocazione di assi per i LUN non sufficiente per supportare i requisiti I/O di Operations Manager.
• Hosting dei log delle transazioni e dei file di database nello stesso volume. Questi due carichi di lavoro presentano caratteristiche di I/O e latenza diverse.
• La configurazione di TempDB non è corretta in relazione al posizionamento, al dimensionamento e così via.
• Disallineamento della partizione del disco dei volumi che ospitano i log delle transazioni del database, i file di database e TempDB.
• Ignorando la configurazione SQL Server di base, ad esempio l'uso di AUTOGROW per i file di database e di log delle transazioni, l'impostazione MAXDOP per il parallelismo delle query, la creazione di più file di dati TempDB per core CPU e così via.

La configurazione dell'archiviazione è uno dei componenti critici di una distribuzione di SQL Server per Operations Manager. I server di database tendono a essere pesantemente I/O bound a causa della rigorosa attività di lettura e scrittura del database e dell'elaborazione dei log delle transazioni. Il modello di comportamento I/O di Operations Manager è in genere il seguente: 80% scrittura e 20% lettura. Di conseguenza, una configurazione non corretta dei sottosistemi I/O può determinare un peggioramento delle prestazioni e delle operazioni dei sistemi SQL Server, problema che diventa evidente in Operations Manager.

È importante testare la progettazione SQL Server eseguendo test della velocità effettiva del sottosistema I/O prima di distribuire SQL Server. Assicurarsi che questi test siano in grado di soddisfare i requisiti di I/O con una latenza accettabile. Usare l'utilità Diskspd per valutare la capacità I/O del sottosistema di archiviazione che supporta SQL Server. L'articolo di blog seguente, creato da un membro del team di File Server nel gruppo di prodotti, fornisce indicazioni dettagliate e consigli su come eseguire test di stress usando questo strumento con codice di PowerShell e acquisire i risultati usando PerfMon. È anche possibile fare riferimento all'helper di ridimensionamento di Operations Manager per indicazioni iniziali.

Dimensioni dell'unità di allocazione NTFS

L'allineamento dei volumi, noto anche come allineamento dei settori, deve essere seguito nel file system (NTFS) ogni volta che viene creato un volume su un dispositivo RAID. In caso contrario, può causare una riduzione significativa delle prestazioni ed è in genere il risultato di un disallineamento della partizione con limiti di unità di striping. Questo può causare anche problemi di allineamento della cache hardware e di conseguenza un utilizzo inefficiente della cache degli array. Quando si formatta la partizione che verrà usata per SQL Server file di dati, è consigliabile usare una dimensione di unità di allocazione di 64 KB (ovvero 65.536 byte) per dati, log e tempdb. Tenere presente, tuttavia, che l'uso di dimensioni delle unità di allocazione superiori a 4 KB comporta l'impossibilità di usare la compressione NTFS nel volume. Anche se SQL Server supporta i dati di sola lettura nei volumi compressi, non è consigliabile.

Riservare la memoria

Nota

Gran parte delle informazioni contenute in questa sezione proviene da Jonathan Kehayias nel suo post di blog Quanto memoria ha effettivamente bisogno del mio SQL Server? (sqlskills.com).

Non è sempre facile identificare la quantità corretta di memoria fisica e processori da allocare per SQL Server in supporto di System Center Operations Manager (o per altri carichi di lavoro al di fuori di questo prodotto). Il calcolatore di dimensionamento fornito dal gruppo di prodotti fornisce indicazioni in base alla scalabilità del carico di lavoro, ma le raccomandazioni sono basate sui test eseguiti in un ambiente lab che può o non essere allineato al carico di lavoro e alla configurazione effettivi.

SQL Server consente di configurare la quantità minima e massima di memoria che verrà riservata e usata dal processo. Per impostazione predefinita, SQL Server può modificare i propri requisiti di memoria in modo dinamico in base alle risorse di sistema disponibili. L'impostazione predefinita per min server memory è 0 e l'impostazione predefinita per max server memory è 2.147.483.647 MB.

I problemi relativi alle prestazioni e alla memoria possono verificarsi se non si imposta un valore appropriato per la memoria massima del server. Molti fattori influiscono sulla quantità di memoria da allocare a SQL Server per garantire che il sistema operativo possa supportare altri processi in esecuzione su tale sistema, ad esempio la scheda HBA, gli agenti di gestione e l'analisi in tempo reale antivirus. Se la memoria sufficiente non è impostata, il sistema operativo e SQL eseguiranno la pagina su disco. Ciò può causare l'aumento dell'I/O del disco, riducendo ulteriormente le prestazioni e creando un effetto di increspatura in cui diventa evidente in Operations Manager.

È consigliabile specificare almeno 4 GB di RAM per la memoria minima del server. Questa operazione deve essere eseguita per ogni nodo SQL che ospita uno dei database di Operations Manager (operativo, data warehouse, ACS).

Per la memoria massima del server, è consigliabile riservare inizialmente un totale di:

• 1 GB di RAM per il sistema operativo
• 1 GB di RAM ogni 4 GB di RAM installata (fino a 16 GB di RAM)
• 1 GB di RAM ogni 8 GB di RAM installata (oltre 16 GB di RAM)

Dopo aver impostato questi valori, monitorare il contatore Memory\Available MBytes in Windows per determinare se è possibile aumentare la memoria disponibile per SQL Server. Windows segnala che la memoria fisica disponibile è in esecuzione bassa a 96 MB, quindi idealmente il contatore non dovrebbe essere eseguito inferiore a circa 200-300 MB, per assicurarsi di avere un buffer. Per i server con 256 GB di RAM o versione successiva, è probabile che non venga eseguito più di 1 GB.

Tenere presente che questi calcoli presuppongono che si voglia SQL Server essere in grado di usare tutta la memoria disponibile, a meno che non vengano modificati per tenere conto di altre applicazioni. Prendere in considerazione i requisiti di memoria specifici per il sistema operativo, altre applicazioni, lo stack di thread SQL Server e altri allocatori a più pagine. Una formula tipica è ((total system memory) – (memory for thread stack) – (OS memory requirements) – (memory for other applications) – (memory for multipage allocators)), dove la memoria per lo stack di thread = ((max worker threads) (stack size)). Le dimensioni dello stack sono di 512 KB per sistemi x86, 2 MB per sistemi x64 e 4 MB per i sistemi IA64 ed è possibile trovare il valore per max worker threads nella colonna max_worker_count di sys.dm_os_sys_info.

Queste considerazioni si applicano anche ai requisiti di memoria per SQL Server da eseguire in una macchina virtuale. Poiché SQL Server è progettato per memorizzare nella cache i dati nel pool di buffer e in genere userà la quantità di memoria massima possibile, può essere difficile determinare la quantità ideale di RAM necessaria. Quando si riduce la memoria allocata a un'istanza di SQL Server, si raggiungerà infine un punto in cui l'allocazione di memoria inferiore viene scambiata per un accesso di I/O su disco superiore.

Per configurare SQL Server memoria in un ambiente di cui è stato eseguito il overprovisioning, iniziare monitorando l'ambiente e le metriche delle prestazioni correnti, inclusi l'aspettativa di vita della pagina di Gestione buffer di SQL Server e le letture di pagine/sec e i valori letture disco fisico/sec. Se l'ambiente ha memoria in eccesso, l'aspettativa di vita delle pagine aumenterà di un valore di uno al secondo senza ridurre il carico di lavoro, a causa della memorizzazione nella cache; il valore di lettura/sec della pagina di Gestione buffer SQL Server sarà basso dopo l'avvio della cache e le letture del disco fisico/sec rimarranno basse.

Dopo aver compreso la baseline dell'ambiente, è possibile ridurre la memoria massima del server di 1 GB, quindi vedere come influisce sui contatori delle prestazioni (dopo eventuali concessioni iniziali di scaricamento della cache). Se le metriche rimangono accettabili, ridurre di un altro 1 GB, quindi ripetere di nuovo la procedura desiderata fino a determinare una configurazione ideale.

Per altre informazioni, vedere Opzioni di configurazione della memoria del server.

Ottimizzare TempDB

La dimensione e la posizione fisica del database TempDB possono influire sulle prestazioni di Operations Manager. Ad esempio, se la dimensione definita per TempDB è troppo piccola, parte del carico di elaborazione del sistema può essere automaticamente aumentata fino a raggiungere le dimensioni necessarie per supportare il carico di lavoro ogni volta che si riavvia l'istanza di SQL Server. Per ottenere prestazioni ottimali, è consigliabile che in un ambiente di produzione TempDB sia configurato come segue:

• Impostare il modello di ripristino del database TempDB su Semplice. Questo modello recupera automaticamente spazio di log per ridurre i requisiti di spazio.
• Preallocare lo spazio per tutti i file TempDB impostando la dimensione di file su un valore sufficientemente grande per il carico di lavoro tipico dell'ambiente. Questo impedisce un aumento troppo frequente delle dimensioni di TempDB, con possibili effetti negativi sulle prestazioni. Il database TempDB può essere impostato per l'aumento automatico delle dimensioni. Questa impostazione, tuttavia, deve essere usata per aumentare lo spazio su disco in caso di eccezioni non pianificate.
• Creare tutti i file necessari per ottimizzare la larghezza di banda del disco. L'uso di più file riduce i conflitti di archiviazione in TempDB e si traduce in una maggiore scalabilità. Tuttavia, non creare troppi file perché può ridurre le prestazioni e aumentare il sovraccarico di gestione. Come regola generale, creare un file di dati per ogni processore logico presente nel server (tenendo conto di qualsiasi impostazione della maschera di affinità) e quindi aumentare o ridurre il numero di file in base alle necessità. Se il numero di processori logici è minore o uguale a 8, usare un numero di file di dati pari a quello dei processori logici. Se il numero di processori logici è maggiore di 8, usare otto file di dati e quindi, se il conflitto continua, aumentare il numero di file di dati di multipli di 4 (fino a raggiungere il numero di processori logici) finché il conflitto non viene ridotto a livelli accettabili. In alternativa, apportare modifiche al carico di lavoro o al codice. Se la contesa non viene ridotta, potrebbe essere necessario aumentare il numero di file di dati.
• Rendere ogni file di dati la stessa dimensione, consentendo prestazioni di riempimento proporzionali ottimali. L'uguale dimensione dei file è un fattore di importanza critica perché l'algoritmo di riempimento proporzionale è basato sulla dimensione dei file. Se i file di dati vengono creati con dimensioni diverse, l'algoritmo di riempimento automatico tenta di usare il file più grande per le allocazioni GAM anziché distribuire le allocazioni tra tutti i file, annullando in tal modo lo scopo della creazione di più file di dati.
• Per ottenere prestazioni ottimali, posizionare il database TempDB in un sottosistema I/O veloce usando unità SSD. Usare lo striping del disco se sono presenti diversi dischi collegati direttamente.
• Posizionare il database TempDB in dischi diversi da quelli usati dai database utente.

Per configurare TempDB, è possibile eseguire la query seguente o modificarne le proprietà in Management Studio.

USE [tempdb]
GO
DBCC SHRINKFILE (N'tempdev' , 8)
GO
USE [master]
GO
ALTER DATABASE [tempdb] MODIFY FILE ( NAME = N'tempdev', NEWNAME = N'tempdb', SIZE = 2097152KB , FILEGROWTH = 512MB )
GO
ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdb2', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\tempdb2.mdf' , SIZE = 2097152KB , FILEGROWTH = 512MB )
GO

Eseguire la query SELECT * from sys.sysprocesses T-SQL per rilevare la contesa dell'allocazione della pagina per il database tempdb. Nell'output della tabella di sistema, la risorsa attesa può visualizzare fino a "2:1:1" (pagina PFS) o "2:1:3" (pagina Shared Global Allocation Map (Mappa allocazione globale condivisa)). A seconda del grado di conflitto, è possibile che SQL Server non risponda per brevi periodi. Un altro approccio consiste nell'esaminare la vista a gestione dinamica [sys.dm_exec_request o sys.dm_os_waiting_tasks]. I risultati mostreranno che queste richieste o attività sono in attesa di risorse tempdb e hanno valori simili evidenziati in precedenza quando si esegue la query sys.sysprocesses .

Se le raccomandazioni precedenti non riducono significativamente la contesa dell'allocazione e la contesa si trova nelle pagine SGAM, implementare il flag di traccia -T1118 nei parametri di avvio per SQL Server in modo che il flag di traccia rimanga effettivo anche dopo che SQL Server viene riciclato. Con questo flag di traccia SQL Server alloca extent completi a ciascun oggetto di database, eliminando il conflitto sulle pagine SGAM.

Nota

Questo flag di traccia influisce su ogni database nell'istanza di SQL Server.

Massimo grado di parallelismo

La configurazione predefinita di SQL Server per distribuzioni di Operations Manager di piccole/medie dimensioni è adeguata per la maggior parte delle esigenze. Tuttavia, quando il carico di lavoro del gruppo di gestione aumenta verso l'alto verso uno scenario di classe aziendale (in genere 2.000+ sistemi gestiti dall'agente e una configurazione di monitoraggio avanzata, che include il monitoraggio a livello di servizio con transazioni sintetiche avanzate, monitoraggio dei dispositivi di rete, multipiattaforma e così via) è necessario ottimizzare la configurazione di SQL Server descritta in questa sezione del documento. Un'opzione di configurazione che non è stata illustrata nelle linee guida precedenti è MAXDOP.

MAXDOP, l'opzione di configurazione del massimo grado di parallelismo di Microsoft SQL Server, controlla il numero di processori usati per l'esecuzione di una query in un piano parallelo. Questa opzione determina le risorse di elaborazione e thread usate per gli operatori del piano di query che lavorano in parallelo. A seconda che SQL Server sia configurato in un computer multiprocesso simmetrico (SMP), un computer NUMA (Non Uniform Memory Access) o processori abilitati per hyperthreading, è necessario configurare in modo appropriato l'opzione max degree of parallelism.

Quando SQL Server viene eseguito su un computer con più microprocessori o CPU, questa opzione rileva il miglior grado di parallelismo, ovvero il numero di processori impiegati per eseguire una singola istruzione per ciascuna esecuzione del piano parallelo. Per impostazione predefinita, il valore di questa opzione è 0, che consente a SQL Server di determinare il massimo grado di parallelismo.

Le stored procedure e le query pre-definite in Operations Manager in quanto si riferisce al database operativo, al data warehouse e anche al database di controllo non includono l'opzione MAXDOP, perché non è possibile eseguire query dinamicamente sul numero di processori presentati al sistema operativo, né tentare di eseguire il hardcode del valore per questa impostazione, che potrebbe avere conseguenze negative quando la query viene eseguita.

Nota

L'opzione di configurazione max degree of parallelism non limita il numero di processori usati dal SQL Server. Per configurare il numero di processori usati da SQL, usare l'opzione di configurazione della maschera di affinità.

• Per i server che usano più di otto processori, usare la configurazione seguente: MAXDOP=8
• Per i server che usano otto o meno processori, usare la configurazione seguente: MAXDOP=0 a N

  Nota

  In questa configurazione N rappresenta il numero di processori.