Che cos'è lo hot spotting nel contesto dell'aggiunta di file a tempdb?

Sto cercando di scoprire se è possibile aggiungere file tempdb a un SQL Server senza riavviare il servizio SQL Server. Ho visto questa risposta qui su amministratori di database:

• Tempdb Aggiungi file richiede il riavvio

E una risposta afferma:

AGGIUNGI: nessuna interruzione richiesta. Sebbene, come sottolineato da Sean di Microsoft, SQL preferirà utilizzare i file compilati in basso. Se stai passando da 1 file di dati e ne aggiungi altri, SQL utilizzerà i nuovi per un po ', ma le tue prestazioni non saranno peggiori di avere un solo file. Tuttavia, se ne hai già 2+ e ne aggiungi uno in più, allora sarà attivo su quello nuovo e diminuirà le prestazioni.

Tuttavia, un commento avverte quanto segue:

Vorrei aggiungere un addendum alla parte "Aggiungi": "Aggiungi: No, ma molto probabilmente sarai sbilanciato, così sarai avvistato a caldo che potrebbe peggiorare le cose".

Ho le seguenti domande su quel commento, ma mi è stato chiesto di porre quelle domande in una mia nuova domanda (questa) piuttosto che porre il commentatore tramite il commento nelle risposte a quella domanda.

In particolare:

1. Che cos'è l'hot spotting? (Ho ricevuto alcune informazioni tramite Google ma non in dettaglio cosa succede con l'hotspotting su tempdb dopo aver aggiunto i file)
2. Che dire di hot spotting rende le cose molto peggio in tempdb?
3. Quali cose specifiche nel DB peggiorerebbero molto?

1. Che cos'è l'hot spotting?

   "Hot spotting" in questo contesto significa che, sebbene tempdb abbia più file, tutto il lavoro di I / O viene eseguito in un singolo file. Se tempdb è abbastanza occupato da giustificare l'aggiunta di file, lo squilibrio che porta a hot-spotting (a causa del riempimento proporzionale ) avrà vita breve, quindi penso che gli avvertimenti potrebbero essere un po 'Chicken Little. Nella mia esperienza, comunque.

2. Che dire di hot spotting rende le cose molto peggio in tempdb?

   Penso che sia ritenuto peggiore in tempdb perché richiede un peso maggiore dell'attività di scrittura nella maggior parte dei carichi di lavoro. Puoi certamente riscontrare problemi simili nei database degli utenti, ma poiché stai già cercando di risolvere un problema in tempdb ...

3. Quali cose specifiche nel DB peggiorerebbero molto?

   Scrivi tempi, soprattutto. Immagina che tutti provino a utilizzare lo stesso bancomat, anche quando ci sono altri 7 bancomat nelle vicinanze. Solo così tanto può essere scritto in qualsiasi momento; tutto il resto deve aspettare. Con più file (e abbastanza core per pianificare il lavoro), l'I / O può essere distribuito in modo più uniforme.

   Solo sii sicuro:

   • hai un numero pari di file
   • tutti i file hanno le stesse dimensioni
   • tutti i file hanno le stesse impostazioni di aumento automatico
   • il numero di file è in qualche modo determinato dal numero di core
   • a seconda della versione (abilitati per impostazione predefinita nelle versioni più moderne di SQL Server ), si utilizzano i flag di traccia 1117 (ingrandisci tutti i file di dati contemporaneamente) e 1118 (non utilizzare estensioni di allocazione miste).

1. Che cos'è l'hot spotting?

Aaron ha ragione e non ripeterò ciò che ha detto sopra, tuttavia non si tratta solo di IO del disco. La parte principale con cui molte persone hanno problemi in TempDB è dovuta alla contesa su alcune strutture di tracciamento.

Poiché la presenza di più file tempdb consente agli algoritmi di riempimento proporzionale e round robin di avere effettivamente luogo in modo "equo" tra le allocazioni, l'aggiunta di un nuovo file senza allocazioni lo rende un po 'meno. Non sono d'accordo sul fatto che si tratti di un avvertimento "piccolo pollo" (vedi gli aggiornamenti del prodotto di seguito) se inizi a vedere le PAGELATCH_*attese su quel nuovo file e non molti o nessuno su altri file. Questo in genere accade su sistemi con attività TempDB elevata e che hanno già più di un singolo file.

Si noti che ci sono opzioni in SQL Server 2019 per modificare alcune delle tabelle di sistema sottostanti in tabelle in memoria che possono avere un miglioramento poiché gli oggetti in memoria sono allocati in modo diverso rispetto alle tabelle al forno su disco. Le tabelle basate su disco sono le tabelle tradizionali con cui tutti abbiamo lavorato nel corso degli anni. SQL Server 2014 ha introdotto tabelle ottimizzate per la memoria . SQL Server 2019 può gestire alcuni metadati di allocazione in tabelle ottimizzate per la memoria.

Un'altra modifica è stata apportata in SQL Server 2019 per aiutare con le modifiche PFS simultanee, che è in genere ciò che i conflitti per la struttura in memoria nell'allocazione stanno PAGELATCH_*aspettando.

2. Che dire di hot spotting rende le cose molto peggio in tempdb?

Niente di IMHO. Sì, TempDB ha più elementi che possono causare scritture su di esso senza essere utilizzati direttamente in modo da poter ostacolare alcuni elementi. Tuttavia, un database di utenti molto impegnato in termini di velocità di modifica dei dati è altrettanto negativo. Non è limitato a solo TempDB.

3. Quali cose specifiche nel DB peggiorerebbero molto?

Mi piace molto l'analogia di Aaron! Questa è l'essenza di ciò che sta succedendo. Ciò che peggiora davvero è l'allocazione e il tracciamento dello spazio per gli oggetti nel database. Se il tuo database utente è prevalentemente statico (basso tasso di modifica) o il tuo TempDB non viene realmente utilizzato, non noterai nulla. Se, tuttavia, è un server abbastanza occupato, è possibile avviare o aggravare le attese di pagelatch che potrebbero portare al blocco dei convogli.

Aaron ha già sottolineato che nella versione precedente ci sono flag di traccia per assicurarsi che vengano utilizzate estensioni uniformi e che tutti i file in un filegroup crescano insieme (Aaron sottolinea 1117 e 1118 che sono NOP nel 2016+). L'altra cosa che vorrei sottolineare di nuovo è che questo non è solo per TempDB ma per qualsiasi database, e il layout fisico dovrebbe essere pensato a seconda delle esigenze.

Questo non è solo per problemi di hot spot ma è applicabile ad altre parti del sistema come backup / ripristino, gestione dei file, frammentazione dei metadati del filesystem, ecc., Che possono essere tutti aiutati da avere più file.

È possibile visualizzare la contesa della struttura di allocazione cercando a waitresourcein una pagina PFS (che è la pagina 1 e quindi ogni 8088 pagine). Se vedi che tutto nello stesso file (2: file: pagina), sai che sta succedendo.