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 supportare il database operativo, il data warehouse e il database di controllo ACS. I database operativi e del data warehouse sono necessari e creati quando si distribuisce il primo server di gestione nel gruppo di gestione, mentre il database ACS viene creato quando si distribuisce un agente di raccolta dati ACS nel gruppo di gestione.

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

In una distribuzione distribuita su scala media e aziendale, l'istanza di SQL Server deve trovarsi in un server autonomo dedicato o in una configurazione a disponibilità elevata di SQL Server. In entrambi i casi, SQL Server deve esistere già ed è accessibile prima di avviare l'installazione del primo server di gestione o dell'agente di 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 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 l'istanza gestita di SQL di Azure e non è riconfigurabile.

requisiti di SQL Server

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

• SQL Server 2022

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

  Nota

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

• SQL Server 2017 e aggiornamenti cumulativi come descritto qui

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

Nota

• Ogni componente di SQL Server seguente che supporta un'infrastruttura SCOM deve essere nella stessa versione principale di SQL Server:
  • Istanze del motore di database di SQL Server 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 di SQL Server deve essere uno dei tipi supportati, come descritto nella sezione impostazioni delle regole di confronto di SQL Server riportata di seguito.
• La ricerca full-text di SQL Server è necessaria per tutte le istanze del motore di database di SQL Server che ospitano uno qualsiasi dei database SCOM.
• Le opzioni di installazione di Windows Server 2016 (Server Core, Server with Desktop Experience 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

System Center Operations Manager Reporting non può essere installato 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).

Considerazioni aggiuntive sull'hardware e sul software si applicano alla pianificazione della progettazione:

• È consigliabile eseguire SQL Server nei computer con il formato di file NTFS.
• Devono essere presenti almeno 1024 MB di spazio libero su disco per il database operativo e del data warehouse. Viene applicato al momento della creazione del database e probabilmente crescerà significativamente 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 ad alcun account locale dopo l'installazione.

Impostazione delle regole di confronto di SQL Server

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

Nota

Per evitare problemi di compatibilità durante il confronto o la copia delle operazioni, è 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. Tuttavia, un aggiornamento sul posto verrà completato correttamente.

Configurazione firewall

Operations Manager dipende da SQL Server per ospitare i relativi database e una piattaforma di report per analizzare e presentare dati operativi cronologici. 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 sta progettando una distribuzione distribuita che richiederà ai gruppi di disponibilità AlwaysOn di SQL di fornire funzionalità di failover per i database di Operations Manager, sono necessarie 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 che dovranno essere consentite almeno affinché i ruoli del server nel gruppo di gestione di Operations Manager comunichino correttamente.

Scenario	Porta	Direzione	Ruolo di Operations Manager
SQL Server che ospita i database di Operations Manager	TCP 1433 *	In entrata	server di gestione e console Web (per Application Advisor e Application Diagnostics)
Servizio SQL Server Browser	UDP 1434	In entrata	server di gestione
Connessione amministrativa dedicata di SQL Server	TCP 1434	In entrata	server di gestione
Porte aggiuntive usate da SQL Server - Chiamate di procedura remota Microsoft (MS RPC) - Strumentazione gestione Windows (WMI) - Microsoft Distributed Transaction Coordinator (MS DTC)	TCP 135	In entrata	server di gestione
Listener del gruppo di disponibilità AlwaysOn di SQL Server	Porta configurata dall'amministratore	In entrata	server di gestione
SQL Server Reporting Services che ospita Operations Manager Reporting Server	TCP 80 (impostazione predefinita)/443 (SSL)	In entrata	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'istanza autonoma di SQL Server o si è distribuito un gruppo di disponibilità SQL AlwaysOn, 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 dei requisiti del firewall per SQL Server, vedere Configurare Windows Firewall per consentire l'accesso a SQL Server.

Considerazioni sulla capacità e sull'archiviazione

Database di Operations Manager

Il database di Operations Manager è un database di SQL Server che contiene tutti i dati necessari per Operations Manager per il monitoraggio giornaliero. Il ridimensionamento e la configurazione del server di database sono fondamentali per le prestazioni complessive del gruppo di gestione. La risorsa più critica usata dal database di Operations Manager è il sottosistema di archiviazione, ma anche la CPU e la RAM sono significative.

I fattori che influenzano il carico nel database di Operations Manager includono:

• Frequenza di raccolta dati operativi. I dati operativi sono costituiti da tutti gli eventi, gli avvisi, le modifiche di stato e i dati sulle prestazioni raccolti dagli agenti. La maggior parte delle risorse usate dal database di Operations Manager viene usata per scrivere questi dati su disco durante l'ingresso nel sistema. La frequenza dei dati operativi raccolti tende ad aumentare man mano che vengono importati altri Management Pack e vengono aggiunti altri agenti. Il tipo di computer monitorato da un agente è anche un fattore importante usato per determinare la frequenza complessiva di raccolta dati operativi. Ad esempio, un agente che monitora un computer desktop critico per l'azienda può raccogliere meno dati rispetto a un agente che monitora un server che esegue un'istanza di SQL Server con un numero elevato di database.
• Frequenza delle modifiche dello spazio dell'istanza. L'aggiornamento di questi dati nel database di Operations Manager è costoso rispetto alla scrittura di nuovi dati operativi. Inoltre, quando cambiano i dati dello spazio dell'istanza, i server di gestione eseguono query aggiuntive al database di Operations Manager per calcolare le modifiche di configurazione e gruppo. La frequenza di modifica dello spazio dell'istanza aumenta man mano che si importano Management Pack aggiuntivi in un gruppo di gestione. L'aggiunta di nuovi agenti a un gruppo di gestione aumenta temporaneamente anche la frequenza di modifiche dello spazio dell'istanza.
• Numero di console operatore e altre connessioni SDK in esecuzione contemporaneamente. Ogni Console operatore legge i dati dal database di Operations Manager. L'esecuzione di query su questi dati utilizza potenzialmente grandi quantità di risorse di I/O di archiviazione, tempo CPU e RAM. Le console operatore che visualizzano grandi quantità di dati operativi nella visualizzazione eventi, visualizzazione stato, visualizzazione avvisi e dati sulle prestazioni tendono a causare il carico più elevato nel database.

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

È possibile configurare e aggiornare i database di Operations Manager con un'installazione SQL Always-On esistente senza dover apportare modifiche dopo la configurazione.

Abilitare SQL Broker nel database di Operations Manager

System Center Operations Manager dipende da SQL Server Service Broker per implementare tutte le operazioni di attività. Se SQL Server Service Broker è disabilitato, tutte le operazioni di attività saranno 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 quasi in tempo reale, è importante avere una 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 nel data warehouse di reporting è il sottosistema di I/O di archiviazione. Nella maggior parte dei sistemi, i carichi nel data warehouse di reporting sono simili al database di Operations Manager, ma possono variare. Inoltre, il carico di lavoro inserito nel data warehouse per reporting è diverso dal carico inserito nel database di Operations Manager dall'utilizzo della Console operatore.

I fattori che influenzano il carico nel data warehouse di report includono:

• Frequenza di raccolta dati operativi. Per consentire la creazione di report più efficienti, il data warehouse di report calcola e archivia i dati aggregati oltre a una quantità limitata di dati non elaborati. L'esecuzione di questo lavoro aggiuntivo significa che la raccolta dei dati operativi nel data warehouse di report può essere leggermente più costosa rispetto al database di Operations Manager. Questo costo aggiuntivo è in genere bilanciato dal costo ridotto dei dati di individuazione dell'elaborazione da parte del data warehouse di reporting rispetto al database di Operations Manager.
• Numero di utenti di report simultanei o generazione di report pianificati. Poiché i report riepilogano spesso grandi volumi di dati, ogni utente che segnala può aggiungere un carico significativo nel sistema. Il numero di report eseguiti simultaneamente e il tipo di report in esecuzione influiscono entrambe sulle esigenze complessive di capacità. In genere, i report che eseguono query su intervalli di date di grandi dimensioni o un numero elevato di oggetti richiedono risorse di sistema aggiuntive.

In base a questi fattori, esistono diverse procedure consigliate da considerare per il dimensionamento del data warehouse di report:

• Scegliere un sottosistema di archiviazione appropriato. Poiché il data warehouse di report è parte integrante del flusso di dati complessivo attraverso il gruppo di gestione, la scelta di un sottosistema di archiviazione appropriato per il data warehouse di report è importante. Come per il database di Operations Manager, RAID 0 + 1 è spesso la scelta migliore. In generale, il sottosistema di archiviazione per il data warehouse di reporting deve essere simile al sottosistema di archiviazione per il database di Operations Manager e le linee guida applicabili al database di Operations Manager si applicano anche al data warehouse di reporting.
• Prendere in considerazione il posizionamento appropriato dei log dei dati e dei log delle transazioni. Per quanto riguarda 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 sia il database di Operations Manager che il data warehouse di reporting si trovano nello stesso server e si desidera separare i dati e i log delle transazioni, è necessario inserire i log delle transazioni per il database di Operations Manager in un volume fisico separato e spindle di disco dal data warehouse di reporting per ricevere qualsiasi vantaggio. 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 una capacità adeguata e le prestazioni di I/O del disco non influiscano negativamente sulla funzionalità di monitoraggio e creazione di report.
• Prendere in considerazione l'inserimento del data warehouse di report in un server separato dal database di Operations Manager. Anche se le distribuzioni su scala ridotta possono spesso consolidare il database di Operations Manager e il data warehouse di reporting nello stesso server, è vantaggioso separarli man mano che 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 in un server separato dal database di Operations Manager, si riscontrano prestazioni di report migliori.

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

SQL Server AlwaysOn

I gruppi di disponibilità AlwaysOn di SQL Server supportano gli 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 e versioni successive - Operations Manager, SQL Always On è preferibile rispetto al clustering di failover per offrire disponibilità elevata per i database. Tutti i database ad eccezione dell'installazione nativa di Reporting Services, che usa due database per separare l'archiviazione dati persistente dai requisiti di archiviazione temporanea, possono essere ospitati in un gruppo di disponibilità AlwaysOn.

Con Operations Manager 2022 è possibile configurare e aggiornare i database di Operations Manager con un'installazione SQL Always-On esistente senza dover apportare modifiche dopo la 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 di SQL Server di Operations Manager come database di disponibilità.

• Altre informazioni sui prerequisiti di Always On.
• Altre informazioni sulla configurazione di un cluster WSFC per i gruppi di disponibilità AlwaysOn.
• 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 sicurezza rigorosa di CLR, eseguire lo script SQL in ogni database di Operations Manager.

Stringa multisubnet

Operations Manager non supporta le parole chiave stringa di connessione (MultiSubnetFailover=True). Poiché un gruppo di disponibilità ha un nome di listener (noto come nome di rete o punto di accesso client in Gestione cluster WSFC) a seconda di più indirizzi IP di subnet diverse, ad esempio quando si esegue la distribuzione in una configurazione di failover tra siti, le richieste di connessione client dai server di gestione al listener del gruppo di disponibilità raggiungeranno un timeout di 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 l'uso di un valore TTL basso per il record DNS registrato.

Queste impostazioni consentono, quando si esegue il failover in un nodo in una subnet diversa, per un ripristino e una risoluzione più rapidi del nome del cluster con il nuovo indirizzo IP.

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 AlwaysOn

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 per la disponibilità elevata viene usata un'istanza SQL in cluster o AlwaysOn, è necessario abilitare la funzionalità di ripristino automatico nei 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 operazione, vedere l'articolo della Knowledge Base seguente Il servizio di gestione di System Center smette di rispondere dopo che un'istanza di SQL Server viene offline.

Ottimizzazione di SQL Server

In generale, l'esperienza di distribuzione precedente con i clienti mostra che i problemi di prestazioni non sono in genere causati da un utilizzo elevato delle risorse (ovvero processore o memoria) con SQL Server stesso; piuttosto è direttamente correlato alla configurazione del sottosistema di archiviazione. I colli di bottiglia delle prestazioni sono comunemente attribuiti a non seguire le indicazioni di configurazione consigliate con l'archiviazione di cui è stato effettuato il provisioning per l'istanza del database di SQL Server. Di seguito sono riportati alcuni esempi:

• Allocazione insufficiente di spindle per i LUN per supportare i requisiti di I/O di Operations Manager.
• Hosting dei log delle transazioni e dei file di database nello stesso volume. Questi due carichi di lavoro hanno caratteristiche di I/O e latenza diverse.
• La configurazione di TempDB non è corretta in relazione al posizionamento, al ridimensionamento e così via.
• Errore di allineamento della partizione del disco dei volumi che ospitano i log delle transazioni del database, i file di database e TempDB.
• Ignorare la configurazione di base di SQL Server, 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 fortemente associati a operazioni di I/O dovute a un'attività rigorosa di lettura e scrittura del database e all'elaborazione del log delle transazioni. Il modello di comportamento di I/O di Operations Manager è in genere l'80% di scritture e il 20% di letture. Di conseguenza, una configurazione non corretta dei sottosistemi di I/O può portare a prestazioni e funzionamento non ottimali dei sistemi SQL Server e diventa evidente in Operations Manager.

È importante testare la progettazione di SQL Server eseguendo test della velocità effettiva del sottosistema I/O prima della distribuzione di 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à di 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 un codice di PowerShell e acquisire i risultati usando PerfMon. È anche possibile fare riferimento all'helper di ridimensionamento di Operations Manager per indicazioni iniziali.

Dimensioni unità di allocazione NTFS

L'allineamento del volume, comunemente definito allineamento del settore, deve essere eseguito nel file system (NTFS) ogni volta che un volume viene creato in un dispositivo RAID. L'errore può causare una riduzione significativa delle prestazioni ed è in genere il risultato di un errore di allineamento della partizione con limiti di unità di striping. Può anche causare un errore di allineamento della cache hardware, con conseguente utilizzo inefficiente della cache di matrici. Quando si formatta la partizione che verrà usata per i file di dati di SQL Server, è 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 di 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.

Riserva memoria

Nota

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

Non è sempre facile identificare la quantità corretta di memoria fisica e processori da allocare per SQL Server a supporto di System Center Operations Manager (o per altri carichi di lavoro al di fuori di questo prodotto). Il calcolatore di ridimensionamento fornito dal gruppo di prodotti fornisce indicazioni basate sulla scalabilità del carico di lavoro, ma le raccomandazioni sono basate sui test eseguiti in un ambiente lab che potrebbe o meno allinearsi 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 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 influenzano la 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 non è impostata memoria sufficiente, 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 increspamento 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 per 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 è 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 SQL Server sia in grado di usare tutta la memoria disponibile, a meno che non vengano modificati in modo da tenere conto di altre applicazioni. Prendere in considerazione i requisiti di memoria specifici per il sistema operativo, altre applicazioni, lo stack di thread di 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 thread nella colonna max_worker_count di sys.dm_os_sys_info.

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

Per configurare la memoria di SQL Server in un ambiente di cui è stato eseguito il provisioning eccessivo, 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 pagina/sec e i valori lettura 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 della pagina di Gestione buffer di SQL Server sarà ridotto dopo l'aumento delle dimensioni 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 di scaricamento iniziale della cache). Se le metriche rimangono accettabili, ridurre di altri 1 GB, quindi eseguire di nuovo il monitoraggio, ripetendo come desiderato fino a quando non si determina una configurazione ideale.

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

Ottimizzare TempDB

Le dimensioni e il posizionamento fisico del database tempdb possono influire sulle prestazioni di Operations Manager. Ad esempio, se le dimensioni definite per tempdb sono troppo piccole, la parte del carico di elaborazione del sistema può essere caricata con tempdb di ridimensionamento automatico alle dimensioni necessarie per supportare il carico di lavoro ogni volta che si riavvia l'istanza di SQL Server. Per ottenere prestazioni ottimali di tempdb, è consigliabile usare la configurazione seguente per tempdb in un ambiente di produzione:

• Impostare il modello di recupero di tempdb su SIMPLE. Questo modello recupera automaticamente lo spazio di log per mantenere i requisiti di spazio ridotti.
• Preallocare lo spazio per tutti i file di tempdb impostando le relative dimensioni su un valore adeguato per il carico di lavoro tipico nell'ambiente. Impedisce l'espansione troppo frequente di tempdb, che può influire sulle prestazioni. Il database tempdb può essere impostato su aumento automatico, ma deve essere usato per aumentare lo spazio su disco per le eccezioni non pianificate.
• Creare tutti i file necessari per ottimizzare la larghezza di banda del disco. L'uso di più file riduce la contesa di archiviazione tempdb e garantisce una maggiore scalabilità. Tuttavia, non creare troppi file perché può ridurre le prestazioni e aumentare il sovraccarico di gestione. Come linea guida generale, creare un file di dati per ogni processore logico nel server (tenendo conto di eventuali impostazioni di affinity mask) e quindi regolare il numero di file verso l'alto o verso il basso in base alle esigenze. In generale, se il numero di processori logici è minore o uguale a 8, usare un numero di file di dati pari al numero dei processori logici. Se il numero di processori logici è maggiore di 8, usare otto file di dati e quindi, se la contesa continua, aumentare il numero di file di dati di più di 4 (fino al numero di processori logici) fino a quando la contesa non viene ridotta a livelli accettabili o apportare modifiche al carico di lavoro/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. Il dimensionamento uguale dei file di dati è fondamentale perché l'algoritmo di riempimento proporzionale è basato sulle dimensioni dei file. Se i file di dati vengono creati con dimensioni diverse, l'algoritmo di riempimento proporzionale tenta di usare il file più grande per le allocazioni GAM invece di distribuire le allocazioni tra tutti i file, sconfiggendo così lo scopo di creare più file di dati.
• Inserire il database tempdb in un sottosistema di I/O veloce usando unità ssd per ottenere prestazioni ottimali. In presenza di molti dischi collegati direttamente, utilizzare lo striping del disco.
• Posizionare il database tempdb in dischi diversi da quelli utilizzati 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 di allocazione delle pagine per il database tempdb. Nell'output della tabella di sistema la risorsa di attesa può essere visualizzata come "2:1:1" (pagina PFS) o "2:1:3" (pagina Mappa allocazione globale condivisa). A seconda del grado di contesa, questo può comportare anche la mancata risposta di SQL Server per brevi periodi. Un altro approccio consiste nell'esaminare le viste 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 di 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 attivo anche dopo il riciclo di SQL Server. In questo flag di traccia, SQL Server alloca extent completi a ogni oggetto di database, eliminando così la contesa nelle pagine SGAM.

Nota

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

Grado massimo di parallelismo

La configurazione predefinita di SQL Server per distribuzioni di piccole e medie dimensioni di Operations Manager è 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.

L'opzione di configurazione max degree of parallelism (MAXDOP) 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 calcolo e thread usate per gli operatori del piano di query che eseguono il lavoro in parallelo. A seconda che SQL Server sia configurato in un computer SMP (Symmetric MultiProcessing), in un computer NUMA (Non Uniform Memory Access) o in processori abilitati per l'hyperthreading, è necessario configurare l'opzione max degree of parallelism in modo appropriato.

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

Le stored procedure e le query predefinite in Operations Manager in relazione al database operativo, al data warehouse e anche al database di controllo non includono l'opzione MAXDOP, perché non esiste alcun modo durante l'installazione di eseguire query in modo dinamico sul numero di processori presentati al sistema operativo, né tenta di impostare come hardcoded il valore per questa impostazione, che potrebbe avere conseguenze negative quando viene eseguita la query.

Nota

L'opzione di configurazione max degree of parallelism non limita il numero di processori usati da SQL Server. Per configurare il numero di processori usati da SQL Server, usare l'opzione di configurazione affinity mask.

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