SQL Server 2016 Enterprise prestazioni scadenti

Mi dispiace essere lungo, ma voglio darti quante più informazioni possibili in modo che possano essere utili all'analisi.

So che ci sono molti post con problemi simili, tuttavia ho già seguito questi vari post e altre informazioni disponibili sul web, ma il problema rimane.

Ho un grave problema di prestazioni in SQL Server che sta facendo impazzire gli utenti. Questo problema si protrae per diversi anni e fino alla fine del 2016 è stato gestito da un'altra entità e dal 2017 è stato gestito da me.

A metà del 2017, sono stato in grado di risolvere il problema seguendo i suggerimenti di indicizzazione indicati dai report Dashboard delle prestazioni di Microsoft SQL Server 2012. L'effetto fu immediato, sembrava magico. Il processore che era negli ultimi giorni quasi sempre al 100%, è diventato super sereno e il feedback degli utenti è stato clamoroso. Anche il nostro tecnico ERP è stato contento, in quanto di solito ci sono voluti 20 minuti per ottenere determinati elenchi e alla fine ha potuto farlo in pochi secondi.

Nel tempo, tuttavia, ha iniziato lentamente a peggiorare. Ho evitato di creare più indici, temendo che troppi indici avrebbero peggiorato le prestazioni. Ma a un certo punto ho dovuto cancellare quelli che non servivano e creare quelli nuovi che Performance Dashboard mi suggerisce. Ma nessun impatto.

La lentezza avvertita è essenzialmente durante il salvataggio e la consulenza, nell'ERP.

Ho un Windows Server 2012 R2 dedicato a SQL Server 2016 Enterprise (64 bit) con la seguente configurazione:

• CPU: CPU Intel Xeon E5-2650 v3 a 2,30 GHz
• Memoria: 84 GB
• In termini di archiviazione, il server ha un volume dedicato al sistema operativo, un altro dedicato ai dati e un altro dedicato ai registri.
• 17 database
• utenti:
  • Nel DB più grande sono connessi più o meno 113 utenti contemporaneamente
  • In un altro ci sono circa 9 utenti
  • In due di essi sono 3 + 3
  • Il resto ha solo 1 utente ciascuno
  • Abbiamo un Web che scrive anche per il database più grande, ma dove l'uso è molto meno regolare e dovrebbe avere circa 20 utenti.
• Dimensione dei DB:
  • Il più grande dei database ha 290 GB
  • Il secondo più grande ha 100 GB
  • Il terzo più grande ha 20 GB
  • Il quarto 14 GB
  • Il resto è poco più di 3 GB ciascuno

Questa è l'istanza di produzione, ma abbiamo anche un'istanza di sviluppo che credo possa essere ignorata per questo scopo, perché il più delle volte sono l'unico che si collega lì, ma questo problema si verifica costantemente, anche quando non sono connesso .

Il processore è quasi sempre così:

Abbiamo routine che funzionano di notte (non problematiche) e alcune che funzionano di giorno.

Gli utenti si connettono tramite Desktop remoto ad altri computer configurati da ODBC 32 per accedere a SQL Server.

Il Datacenter in cui si trovano i server ha 100/100 Mbps, così come lo sono io. La maggior parte dei siti sono collegati da MPLS e altri da IPSec (da FO a 4G). Il provider ha fatto molte analisi e il circuito è ok.

La percentuale di hit della cache è del 99% (sia richieste utente che sessioni utente)

Le attese sono così:

Ho già raccolto dati con Perfmon e ho i risultati se mi aiutano con la tua analisi - personalmente, non ho ottenuto alcuna conclusione dall'analisi.

Conto sul vostro supporto nella risoluzione di questo problema, essendo disponibile a fornire le informazioni che ritenete necessarie per la risoluzione.

Grazie mille.

Ecco il markdown sp_blitz (ho sostituito i nomi delle aziende con pseudonimi):

Priorità 1: affidabilità :

• Ultimo buono DBCC CHECKDB oltre 2 settimane

  • maestro

  • modello - Ultimo successo CHECKDB: 2018-02-07 15: 04: 26.560

  • msdb - Ultimo controllo CHECKDB: 2018-02-07 15: 04: 27.740

Priorità 10: prestazioni :

• CPU con dispari numero di core

  • Al nodo 0 sono assegnati 5 core. Questa è una configurazione NUMA davvero pessima.

  • Al nodo 1 sono assegnati 5 core. Questa è una configurazione NUMA davvero pessima.

Priorità 20: Configurazione file :

• TempDB su unità C tempdb: il database tempdb contiene file sull'unità C. TempDB cresce spesso in modo imprevedibile, mettendo il server a rischio di rimanere senza spazio su disco C e bloccarsi in modo anomalo. Anche la C è spesso molto più lenta di altre unità, quindi le prestazioni potrebbero risentirne.

Priorità 50: Affidabilità :

• Errori registrati di recente nella traccia predefinita
  • master - 2018-03-07 08: 43: 11.72 Errore di accesso: 17892, gravità: 20, stato: 1. 2018-03-07 08: 43: 11.72 Accesso non riuscito per l'accesso "esempio_utente" a causa dell'esecuzione del trigger. [CLIENTE: IPADDR]

(nota: molti errori come questo a causa di un trigger abilitato che limita le sessioni utente - per il controllo dell'utilizzo delle licenze ERP)

• Verifica della pagina non ottimale

  • DATABASE_A - Il database [DATABASE_A] ha NONE per la verifica della pagina. SQL Server potrebbe avere difficoltà a riconoscere e ripristinare il danneggiamento dell'archiviazione. Prendi invece in considerazione l'utilizzo di CHECKSUM.

  • DATABASE_B - Il database [DATABASE_B] ha NONE per la verifica della pagina. SQL Server potrebbe avere difficoltà a riconoscere e ripristinare il danneggiamento dell'archiviazione. Prendi invece in considerazione l'utilizzo di CHECKSUM.

  • DATABASE_C - Il database [DATABASE_C] ha NONE per la verifica della pagina. SQL Server potrebbe avere difficoltà a riconoscere e ripristinare il danneggiamento dell'archiviazione. Prendi invece in considerazione l'utilizzo di CHECKSUM.

  • DATABASE_D - Il database [DATABASE_D] ha NONE per la verifica della pagina. SQL Server potrebbe avere difficoltà a riconoscere e ripristinare il danneggiamento dell'archiviazione. Prendi invece in considerazione l'utilizzo di CHECKSUM.

  • DATABASE_E - Il database [DATABASE_E] ha NONE per la verifica della pagina. SQL Server potrebbe avere difficoltà a riconoscere e ripristinare il danneggiamento dell'archiviazione. Prendi invece in considerazione l'utilizzo di CHECKSUM.

  • DATABASE_F - Il database [DATABASE_F] ha NONE per la verifica della pagina. SQL Server potrebbe avere difficoltà a riconoscere e ripristinare il danneggiamento dell'archiviazione. Prendi invece in considerazione l'utilizzo di CHECKSUM.

  • DATABASE_G - Il database [DATABASE_G] ha NONE per la verifica della pagina. SQL Server potrebbe avere difficoltà a riconoscere e ripristinare il danneggiamento dell'archiviazione. Prendi invece in considerazione l'utilizzo di CHECKSUM.

  • DATABASE_H - Il database [DATABASE_H] ha NONE per la verifica della pagina. SQL Server potrebbe avere difficoltà a riconoscere e ripristinare il danneggiamento dell'archiviazione. Prendi invece in considerazione l'utilizzo di CHECKSUM.

  • DATABASE_I - Il database [DATABASE_I] ha NONE per la verifica della pagina. SQL Server potrebbe avere difficoltà a riconoscere e ripristinare il danneggiamento dell'archiviazione. Prendi invece in considerazione l'utilizzo di CHECKSUM.

  • DATABASE_Z - Il database [DATABASE_Z] ha NONE per la verifica della pagina. SQL Server potrebbe avere difficoltà a riconoscere e ripristinare il danneggiamento dell'archiviazione. Prendi invece in considerazione l'utilizzo di CHECKSUM.

  • DATABASE_K - Il database [DATABASE_K] ha NONE per la verifica della pagina. SQL Server potrebbe avere difficoltà a riconoscere e ripristinare il danneggiamento dell'archiviazione. Prendi invece in considerazione l'utilizzo di CHECKSUM.

  • DATABASE_J - Il database [DATABASE_J] ha NONE per la verifica della pagina. SQL Server potrebbe avere difficoltà a riconoscere e ripristinare il danneggiamento dell'archiviazione. Prendi invece in considerazione l'utilizzo di CHECKSUM.

  • DATABASE_L - Il database [DATABASE_L] ha NONE per la verifica della pagina. SQL Server potrebbe avere difficoltà a riconoscere e ripristinare il danneggiamento dell'archiviazione. Prendi invece in considerazione l'utilizzo di CHECKSUM.

  • DATABASE_M - Il database [DATABASE_M] ha NONE per la verifica della pagina. SQL Server potrebbe avere difficoltà a riconoscere e ripristinare il danneggiamento dell'archiviazione. Prendi invece in considerazione l'utilizzo di CHECKSUM.

  • DATABASE_O - Il database [DATABASE_O] ha NONE per la verifica della pagina. SQL Server potrebbe avere difficoltà a riconoscere e ripristinare il danneggiamento dell'archiviazione. Prendi invece in considerazione l'utilizzo di CHECKSUM.

  • DATABASE_P - Il database [DATABASE_P] ha NONE per la verifica della pagina. SQL Server potrebbe avere difficoltà a riconoscere e ripristinare il danneggiamento dell'archiviazione. Prendi invece in considerazione l'utilizzo di CHECKSUM.

  • DATABASE_Q - Il database [DATABASE_Q] ha NONE per la verifica della pagina. SQL Server potrebbe avere difficoltà a riconoscere e ripristinare il danneggiamento dell'archiviazione. Prendi invece in considerazione l'utilizzo di CHECKSUM.

  • DATABASE_R - Il database [DATABASE_R] ha NONE per la verifica della pagina. SQL Server potrebbe avere difficoltà a riconoscere e ripristinare il danneggiamento dell'archiviazione. Prendi invece in considerazione l'utilizzo di CHECKSUM.

  • DATABASE_S - Il database [DATABASE_S] ha NONE per la verifica della pagina. SQL Server potrebbe avere difficoltà a riconoscere e ripristinare il danneggiamento dell'archiviazione. Prendi invece in considerazione l'utilizzo di CHECKSUM.

  • DATABASE_T - Il database [DATABASE_T] ha NONE per la verifica della pagina. SQL Server potrebbe avere difficoltà a riconoscere e ripristinare il danneggiamento dell'archiviazione. Prendi invece in considerazione l'utilizzo di CHECKSUM.

  • DATABASE_U - Il database [DATABASE_U] ha NONE per la verifica della pagina. SQL Server potrebbe avere difficoltà a riconoscere e ripristinare il danneggiamento dell'archiviazione. Prendi invece in considerazione l'utilizzo di CHECKSUM.

  • DATABASE_V - Il database [DATABASE_V] ha NONE per la verifica della pagina. SQL Server potrebbe avere difficoltà a riconoscere e ripristinare il danneggiamento dell'archiviazione. Prendi invece in considerazione l'utilizzo di CHECKSUM.

  • DATABASE_X - Il database [DATABASE_X] ha NONE per la verifica della pagina. SQL Server potrebbe avere difficoltà a riconoscere e ripristinare il danneggiamento dell'archiviazione. Prendi invece in considerazione l'utilizzo di CHECKSUM.

• DAC remoto disabilitato - L'accesso remoto a Dedicated Admin Connection (DAC) non è abilitato. Il DAC può semplificare molto la risoluzione dei problemi in remoto quando SQL Server non risponde.

Priorità 50: Informazioni sul server :

• Inizializzazione di file istantanea non abilitata: considerare la possibilità di abilitare IFI per ripristini più rapidi e incrementi dei file di dati.

Priorità 100: Prestazioni :

• Fattore di riempimento modificato

  • DATABASE_A - Il database [DATABASE_A] ha 417 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

  • DATABASE_B - Il database [DATABASE_B] ha 318 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

  • DATABASE_C - Il database [DATABASE_C] ha 346 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

  • DATABASE_D - Il database [DATABASE_D] ha 663 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

  • DATABASE_E - Il database [DATABASE_E] ha 335 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

  • DATABASE_F - Il database [DATABASE_F] ha 1705 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

  • DATABASE_G - Il database [DATABASE_G] ha 671 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

  • DATABASE_H - Il database [DATABASE_H] ha 2364 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

  • DATABASE_I - Il database [DATABASE_I] ha 1658 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

  • DATABASE_Z - Il database [DATABASE_Z] ha 673 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

  • DATABASE_K - Il database [DATABASE_K] ha 312 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

  • DATABASE_J - Il database [DATABASE_J] ha 864 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

  • DATABASE_L - Il database [DATABASE_L] ha 1170 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

  • DATABASE_M - Il database [DATABASE_M] ha 382 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

  • DATABASE_O - Il database [DATABASE_O] ha 356 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

  • msdb - Il database [msdb] ha ​​8 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

  • DATABASE_P - Il database [DATABASE_P] ha 291 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

  • DATABASE_Q - Il database [DATABASE_Q] ha 343 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

  • DATABASE_R - Il database [DATABASE_R] ha 2048 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

  • DATABASE_S - Il database [DATABASE_S] ha 325 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

  • DATABASE_T - Il database [DATABASE_T] ha 322 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

  • DATABASE_U - Il database [DATABASE_U] ha 351 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

  • DATABASE_V - Il database [DATABASE_V] ha 312 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

  • DATABASE_X - Il database [DATABASE_X] ha 352 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

  • tempdb - Il database [tempdb] ha ​​2 oggetti con fattore di riempimento = 70%. Ciò può causare problemi di prestazioni di memoria e archiviazione, ma può anche impedire la divisione delle pagine.

• Molti piani per una query - 20763 piani sono presenti per una singola query nella cache del piano - il che significa che probabilmente abbiamo problemi di parametrizzazione.

• Trigger del server abilitati - Il trigger del server [connection_limit_trigger] è abilitato. Assicurati di capire cosa sta facendo quel trigger: meno lavoro fa, meglio è.

• Stored procedure CON RECOMPILE

  • master - [master]. [dbo]. [sp_AllNightLog] ha WITH RECOMPILE nel codice della procedura memorizzata, che può causare un aumento dell'utilizzo della CPU a causa della costante ricompilazione del codice.

  • master - [master]. [dbo]. [sp_AllNightLog_Setup] ha WITH RECOMPILE nel codice della procedura memorizzata, che può causare un aumento dell'utilizzo della CPU a causa della costante ricompilazione del codice.

Priorità 110: Prestazioni :

• Tabelle attive senza indici cluster

  • DATABASE_A - Il database [DATABASE_A] ha un sacco - tabelle senza un indice cluster - che vengono interrogate attivamente.

  • DATABASE_B - Il database [DATABASE_B] ha un sacco - tabelle senza un indice cluster - che vengono interrogati attivamente.

  • DATABASE_C - Il database [DATABASE_C] ha un sacco - tabelle senza un indice cluster - che vengono interrogate attivamente.

  • DATABASE_E - Il database [DATABASE_E] ha un sacco - tabelle senza un indice cluster - che vengono interrogate attivamente.

  • DATABASE_F - Il database [DATABASE_F] ha un sacco - tabelle senza un indice cluster - che vengono interrogati attivamente.

  • DATABASE_H - Il database [DATABASE_H] ha un sacco - tabelle senza un indice cluster - che vengono interrogate attivamente.

  • DATABASE_I - Il database [DATABASE_I] ha un sacco - tabelle senza un indice cluster - che vengono interrogate attivamente.

  • DATABASE_K - Il database [DATABASE_K] ha un sacco - tabelle senza un indice cluster - che vengono interrogate attivamente.

  • DATABASE_O - Il database [DATABASE_O] ha un sacco - tabelle senza un indice cluster - che vengono interrogate attivamente.

  • DATABASE_Q - Il database [DATABASE_Q] ha un sacco - tabelle senza un indice cluster - che vengono interrogate attivamente.

  • DATABASE_S - Il database [DATABASE_S] ha un sacco - tabelle senza un indice cluster - che vengono interrogate attivamente.

  • DATABASE_T - Il database [DATABASE_T] ha un sacco - tabelle senza un indice cluster - che vengono interrogate attivamente.

  • DATABASE_U - Il database [DATABASE_U] ha un sacco - tabelle senza un indice cluster - che vengono interrogate attivamente.

  • DATABASE_V - Il database [DATABASE_V] ha un sacco - tabelle senza un indice cluster - che vengono interrogati attivamente.

  • DATABASE_X - Il database [DATABASE_X] ha un sacco - tabelle senza un indice cluster - che vengono interrogate attivamente.

Priorità 150: Prestazioni :

(Nota: Nany consigli qui, ma non ho potuto includerli a causa della limitazione dei personaggi. Se c'è un altro modo di condividere, si prega di indicare.)

Ci hai fatto una domanda lunga (e molto dettagliata). Ora devi occuparti di una lunga risposta. ;)

Ci sono diverse cose che suggerirei di cambiare sul tuo server. Ma cominciamo con il problema più urgente.

Misure di emergenza una tantum:

Il fatto che le prestazioni siano state soddisfacenti dopo aver distribuito gli indici sul proprio sistema e le prestazioni lentamente degradanti è un suggerimento molto forte che è necessario iniziare a mantenere le proprie statistiche e (in misura minore) occuparsi della frustrazione degli indici.

Come misura di emergenza, suggerirei un aggiornamento manuale manuale delle statistiche su tutti i database. Puoi ottenere il TSQL nessecary eseguendo questo script:

DECLARE @SQL VARCHAR(1000)  
DECLARE @DB sysname  

DECLARE curDB CURSOR FORWARD_ONLY STATIC FOR  
   SELECT [name]  
   FROM master..sysdatabases 
   WHERE [name] NOT IN ('model', 'tempdb') 
   ORDER BY [name] 

OPEN curDB  
FETCH NEXT FROM curDB INTO @DB  
WHILE @@FETCH_STATUS = 0  
   BEGIN  
       SELECT @SQL = 'USE [' + @DB +']' + CHAR(13) + 'EXEC sp_updatestats' + CHAR(13)  
       PRINT @SQL  
       FETCH NEXT FROM curDB INTO @DB  
   END  

CLOSE curDB  
DEALLOCATE curDB

È fornito da Tim Ford nel suo blog post su mssqltips.com e spiega anche perché l'aggiornamento delle statistiche è importante.

Si noti che si tratta di un'attività intensiva per CPU e I / O che non deve essere eseguita durante le ore di attività.

Se questo risolve il tuo problema, ti preghiamo di non fermarti qui!

Manutenzione regolare:

Dai un'occhiata a Ola Hallengren Maintenance Solution e quindi imposta almeno questi due lavori:

• Un lavoro di aggiornamento delle statistiche (se possibile ogni notte). È possibile utilizzare questo codice CMD nel lavoro dell'agente. Questo lavoro deve essere creato da zero.

sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d MSSYS -Q "EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = NULL, @FragmentationHigh = NULL, @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y', @MaxDOP = 0, @LogToTable = 'Y'" -b

• Un lavoro di manutenzione indice. Suggerirei di iniziare con un'esecuzione programmata una volta al mese. È possibile iniziare con le impostazioni predefinite fornite da Ola per il lavoro IndexOptimize.

Ci sono diversi motivi per cui sto suggerendo il primo lavoro per aggiornare le statistiche separatamente:

• Una ricostruzione dell'indice aggiornerà solo le statistiche delle colonne coperte da quell'indice mentre una riorganizzazione dell'indice non aggiorna affatto le statistiche. Ola separa la frammentazione in tre categorie. Per impostazione predefinita verranno ricostruiti solo gli indici alti di categoria.
• Le statistiche per le colonne non coperte da un indice verranno aggiornate solo dal processo IndexOptimize.
• Per mitigare il problema chiave crescente .

SQL Server aggiornerà automaticamente le statistiche se l'impostazione predefinita viene lasciata abilitata. Il problema sono le soglie (meno un problema con SQL Server 2016). Le statistiche vengono aggiornate quando cambia un determinato numero di righe (20% nelle versioni precedenti di SQL Server). Se hai tabelle di grandi dimensioni, ciò può comportare molte modifiche prima che le statistiche vengano aggiornate. Vedi maggiori informazioni sulle soglie qui .

Dal momento che stai facendo CHECKDB, per quanto posso dire, puoi continuare a farli come prima o utilizzare la soluzione di manutenzione anche per quello.

Per ulteriori informazioni sulla frammentazione e la manutenzione dell'indice, consultare:

Panoramica sulla frammentazione dell'indice di SQL Server

Smetti di preoccuparti della frammentazione di SQL Server

Considerando il tuo sottosistema di archiviazione, suggerirei di non fissare troppo alla "frammentazione esterna" perché i dati non sono comunque archiviati in ordine sulla tua SAN.

Ottimizza le tue impostazioni

Lo script sp_Blitz ti dà un eccellente elenco per iniziare.

Priorità 20: Configurazione file - TempDB su C Drive: parla con il tuo amministratore di archiviazione. Chiedi loro se l'unità C è il disco più veloce disponibile per il tuo SQL Server. In caso contrario, metti il ​​tuo tempdb lì ... punto. Quindi controlla quanti file temdb hai. Se la risposta è una soluzione . Se non hanno la stessa dimensione, risolvi i due.

Priorità 50: Informazioni sul server - Inizializzazione file istantanea non abilitata: seguire il collegamento fornito dallo script sp_Blitz e abilitare IFI.

Priorità 50: Affidabilità - Verifica della pagina non ottimale: è necessario ripristinare l'impostazione predefinita (CHECKSUM). Segui il link che ti dà lo script sp_Blitz e segui le istruzioni.

Priorità 100: Prestazioni - Fattore di riempimento modificato: Chiediti perché ci sono così tanti oggetti con fattore di riempimento impostato su 70. Se non hai una risposta e nessun fornitore di applicazioni lo richiede rigorosamente. Riportalo al 100%.

Ciò significa sostanzialmente che SQL Server lascerà il 30% di spazio vuoto su queste pagine. Quindi, per ottenere la stessa quantità di dati (rispetto al 100% delle pagine intere) il tuo server deve leggere il 30% in più di pagine e occuperà il 30% in più di spazio in memoria. Il motivo per cui viene spesso fatto è prevenire la frammentazione dell'indice.

Ma ancora una volta, lo spazio di archiviazione sta comunque salvando quelle pagine in diversi blocchi. Quindi lo ripristinerei al 100% e lo prenderei da lì.

Cosa fare se tutti sono felici:

• Vedi il resto dell'output di sp_Blitz e decidi se modificarli come suggerito.
• Esegui sp_BlitzIndex e dai un'occhiata agli indici che hai creato, se vengono utilizzati o dove potrebbe esserci l'opportunità di aggiungerne / modificarne uno.
• Dai un'occhiata ai dati del tuo Query Store (come suggerito da Peter). Puoi trovare un'introduzione qui .
• Goditi la rockstar dal vivo che un DBA merita. ;)

Non trascurando tutte le risposte che sono state molto utili e che ho applicato o che applicherò, il problema più grande non è stato facile da trovare.

Il problema è peggiorato nei giorni successivi ai nostri ultimi messaggi.

Poiché siamo basati sul cloud, né io né la società che gestisce l'infrastruttura e ci fornisce supporto ha accesso agli host fisici.

Qualcosa mi ha fatto meravigliare quando ho notato che alcuni giorni il processore era in media al 20% e altri giorni era molto più alto, oltre il 60%, quando il carico di lavoro, sebbene mai esattamente lo stesso, è simile. Esiste lo stesso numero di persone che svolgono più o meno lo stesso tipo di operazioni.

All'inizio di questa settimana, gli utenti hanno iniziato a rimanere bloccati per diversi minuti e solo il processore è stato strangolato. Ho chiesto a diversi utenti di disconnettersi (quelli che stavano spendendo più risorse ma ancora niente di straordinario), ho disattivato vari servizi collegati al database e alla fine non è cambiato nulla. Ho chiesto al amministratore di sistema che ci supporta e che può comunicare con i ragazzi del nostro cloud per accedere in remoto alla mia macchina per vedere cosa stavo vedendo e per aiutarmi a trovare qualcosa, perché non potevo fare di meglio per trovare il problema.

Inoltre, il tecnico non ha trovato nulla. Alla fine ha iniziato a darmi qualche motivo per cui qualcos'altro doveva causare questo problema ed era quando ha contattato il cloud. Nel cloud, non hanno realizzato nulla, solo perché a causa del bilanciamento del carico configurato tra host fisici, la VM che supporta il nostro SQL Server è stata spostata alcune volte quel giorno tra host fisici. Fortunatamente, ho detto al nostro tecnico esattamente a che ora i problemi hanno iniziato a verificarsi quel giorno, che coincideva con il momento in cui la VM era stata spostata l'ultima volta in uno degli host fisici da cui non aveva lasciato il resto della giornata.

Se il tecnico non avesse seguito da vicino questo problema, questa sarebbe stata più una di quelle volte in cui avrebbe persino potuto parlare con i ragazzi del cloud, ma quando hanno visto i campioni delle prestazioni, non avrebbero ottenuto nulla, perché ancora una volta il cloud ha visto campioni con CPU dell'ordine del 40/50%, quando in realtà era in media superiore all'80% e spesso bloccato al 100%.

Ora la macchina si trova su un host fisico (non si sposta tra host) e sebbene non abbiamo ancora raggiunto le prestazioni perfette, tutti stanno lavorando e danno un feedback molto più positivo, perché la CPU media è di circa il 20% con tutti i nostri utenti e Servizi.

Nel frattempo, abbiamo anche inserito tempdb su un altro disco (era sul disco del sistema operativo) e abbiamo aumentato i file, per essere più in accordo con il numero di core delle CPU.

Anche il numero di core è stato adeguato in base alle raccomandazioni di sp_Blitz.

C'era anche una routine automatica che era in esecuzione tutto il giorno sulla base di una vecchia data ... e poiché non è finita la mattina quando siamo arrivati, e non abbiamo modo di controllare se è in esecuzione o meno, ho ancora iniziato a eseguire manualmente. Ma probabilmente l'altro stava ancora correndo e stava correndo due volte durante quel periodo. Abbiamo modificato la data per ridurre il tempo necessario e ora è notte fonda. Ma questa non era la soluzione, poiché era stata risolta prima di molti problemi che avevamo come quello descritto qui.

Siamo anche riusciti a convincere l'assistente ERP a pianificare un incontro con il produttore, quindi mostreremo il nostro sistema e cercheremo suggerimenti, oltre a chiarire alcuni dubbi, poiché ci sono raccomandazioni nei video di formazione che sono contrarie alla maggior parte di raccomandazioni, incluso lo stesso Microsoft, come Priority Boost on e Fill Factor 70%.

Poiché l'applicazione ha anche una schermata di manutenzione, cercherò la periodicità richiesta di queste operazioni di manutenzione e ciò che resta da fare al di fuori dell'applicazione. La mia idea è quella di utilizzare i piani di Ola Hallengren.

Credo che la risposta di Thomas Kronawitter sia assolutamente corretta e la sto applicando, tuttavia, penso che questa descrizione possa essere importante per altre persone che dopo aver seguito tutte le buone pratiche non riescono ancora a risolvere il problema perché può trovarsi negli host fisici . Grazie Thomas.