Contese TempDB

Abbiamo un database OLTP attivo da 40 GB su SQL Server 2014 SP1. Le query risultano lente con le attese di IO_Completion, la lunghezza della coda del disco che sale a 900 e SQL Server smette di rispondere. Cosa abbiamo provato:

1. Riavvia l'istanza e con in un minuto inizia a comportarsi allo stesso modo.

2. Dopo il secondo riavvio, abbiamo modificato le dimensioni iniziali di ciascun file di dati tempdb (sono stati creati 16 file di dati) e questo inizia a funzionare correttamente.

Nota: stiamo usando variabili di tabella per set di risultati intermedi. Questi set di risultati sono molto piccoli.

È successo due volte in un mese. Ogni volta che aggiungo manualmente un po 'di spazio ai file di dati, allora inizia a funzionare normalmente. La cosa più interessante è che la stessa configurazione (stesso hardware, stessa cartella e configurazione dei file, stesso carico di lavoro) che abbiamo su SQL Server 2008 R2 e SQL Server 2012 funziona bene.

Aiutateci gentilmente a trovare una soluzione permanente.

La dimensione iniziale di tutti i file di dati è uguale a 1000 MB, la corrente è di 1500 MB ciascuno. Tutti sono identici La crescita automatica è di 100 MB per ciascuno. Prima di questo stavamo affrontando la contesa di pagine PFS e GAM e siamo aumentati a 16 e il problema è stato risolto. Entrambi i flag di traccia 1117 e 1118 sono abilitati. 24 core su 2 nodi NUMA. Tutti i file di dati si trovano sullo stesso volume. Disco semplice, nessuna SAN.

L'istanza si trova su una macchina fisica. Le query con variabili di tabella e le query con join hash generano più comunemente attese IO_Completion.

La risposta dettagliata di wBob ci ha spinto a cercare più in dettaglio. Come l'abbiamo perso prima:

La crescita automatica del file 'templog' nel database 'tempdb' è stata annullata dall'utente o scaduta dopo 7704 millisecondi. Utilizzare ALTER DATABASE per impostare un valore FILEGROWTH più piccolo per questo file o per impostare esplicitamente una nuova dimensione del file.

Questo è stato riscontrato nel registro quando si verifica questo tipo di problema. Stiamo spostando TempDB per separare l'unità veloce.

Penso che tu abbia sovrascritto il tuo tempdb e che ci sia una discrepanza tra la CPU del server e la configurazione del disco, ma raccogliamo qualche informazione in più:

Domande / Ulteriori informazioni richieste

• Conferma il nome e il tipo di processore (sostanzialmente sto provando a stabilire se è 2 x hex-core con HT). Utilizzare le informazioni di sistema (ad es. Pannello di controllo> Sistema e sicurezza> Sistema su Windows Server 2012 R2) e / o lo strumento sysinternals CoreInfo per sistemi sysinternals per confermare.
• Conferma server maxdop (ad es EXEC sp_configure 'max degree of parallelism'.). Se le CPU sono hex-core, il server maxdop dovrebbe essere al massimo 6 (come da qui ), o probabilmente inferiore su un sistema OLTP. Di solito mantengo i miei file tempdb in linea con il mio server DOP fino a un massimo di 8, ma verremo su questo.
• Conferma la memoria totale del server sulla confezione e il limite di memoria di SQL Server (ad es EXEC sp_configure 'max server memory (MB)' .).
• Conferma se sulla scatola sono in esecuzione altri servizi (ad es. SSIS, SSAS, SSRS, l'applicazione, iTunes ecc.)
• Verificare che l'inizializzazione file istantanea sia abilitata per l'account del servizio SQL Server. (Modi per testarlo qui ).
• Perché esiste una discrepanza così grande tra la CPU (configurazione NUMA a 2 nodi) e un solo disco (PC di casa)? Considera di aggiungere dischi, striping, SSD per tempdb (anche se evita di reagire in modo eccessivo .
• Aggiungi un piano di esecuzione effettivo per una delle domande del problema. Anonimizzare con SQL SentrySe lo desideri, Plan Explorer .

• L'hash si unisce alle variabili di tabella in un sistema OLTP? Ciò suggerisce una mancanza di indicizzazione sulla variabile della tabella, sulla tabella principale o su entrambi. Stai dichiarando le variabili della tua tabella in questo modo (senza indici)?

  DECLARE @t TABLE ( x INT )

• Non lesinare sulla definizione della variabile di tabella anche se contiene piccoli set di risultati. È sempre meglio fornire all'ottimizzatore quante più informazioni possibili, quindi sii esplicito con nullabilità, unicità, indipendentemente dal fatto che l'indice sia raggruppato o meno, ad es.

  DECLARE @t TABLE ( x INT PRIMARY KEY )
  DECLARE @u TABLE ( x INT PRIMARY KEY NONCLUSTERED, u INT NOT NULL UNIQUE CLUSTERED, z INT NOT NULL UNIQUE, a CHAR(1) NULL ) -- not sure why you would do this but you can
  DECLARE @v TABLE ( x INT NOT NULL, y INT NOT NULL, PRIMARY KEY ( x, y ) )   -- multi-column primary key

• La pubblicazione del piano di esecuzione ti aiuterà a diagnosticare questo.

• Verifica la presenza di codice che impedisce la memorizzazione nella cache delle variabili di tabella come qui , qui . Penso che SQL dinamico e proc eseguiti con RECOMPILE siano gli unici che influenzano le variabili di tabella.

  DECLARE @u TABLE ( x INT )
  
  INSERT @u
  EXEC('DECLARE @t TABLE ( x INT ); INSERT INTO @t VALUES ( 1 ); SELECT x FROM @t;' )
  
  SELECT *
  FROM @u

• Verificare la presenza di messaggi nel registro di SQL Server (Esplora oggetti> Gestione> Registri di SQL Server), ad esempio avvisi IO.

• Controlla il Visualizzatore eventi di Windows
• Sono stati rilasciati numerosi build dopo SP1. Rivedere le correzioni CU inserite da SP1 . È possibile che siano stati corretti dei bug in SP1 nelle CU successive, ad esempio FIX: l'operatore di ordinamento si riversa su tempdb in SQL Server 2012 o SQL Server 2014 quando il numero stimato di righe e le dimensioni delle righe sono corrette https://support.microsoft.com/en- noi / kb / 3088480
• Stabilire questa è la causa prima di applicare eventuali hotfix, sebbene sia più importante tenersi aggiornati con le CU con SQL Server 2014, a causa del numero di nuove funzionalità (OLTP in memoria, archivio colonne cluster).
• Infine, la necessità di un file tempdb per core è un mito e guardando la configurazione del tuo disco penso che tempdb sia eccessivamente frammentato. Ho la sensazione che tu abbia una testa del disco, tempdb ha un filegroup, molti file.

Tuttavia dimentica ciò che pensiamo di sapere; crea un banco di prova che riproduca il tuo problema e sperimenta la riduzione del numero di file temporanei ... inizia da 1, 2, 4, 6 ecc. raccogli le informazioni, per prendere una decisione basata sull'evidenza. Ora questo è un po 'più difficile dato che il tuo problema sembra intermittente e potresti non essere in grado di pasticciare con la tua configurazione tempdb, ma è così che mi avvicinerei a questo.

In bocca al lupo. Facci sapere come vai avanti.