Le scritture su TempDB comportano sempre una scrittura fisica effettiva su disco o le scritture TempDB sono memorizzate nella cache da SQL Server per la scrittura ritardata come nella cache del file system di Windows?
Lo fanno sempre? Assolutamente no. Lo fanno mai? Sì, ma non a causa del meccanismo tipico. Il riferimento qui è Cosa fa il checkpoint per tempdb? .
In un sistema "ben educato", le scritture su un file di database utente avvengono sul checkpoint. In un sistema mal comportato, le scritture si verificheranno anche quando il lazywriter deve scaricare le pagine dal pool di buffer per fare spazio ad altre pagine.
Un checkpoint viene eseguito solo per tempdb quando il file di registro tempdb raggiunge il 70% pieno, questo per evitare che il registro tempdb cresca se possibile (tenere presente che una transazione di lunga durata può ancora contenere l'ostaggio del registro e impedirne la cancellazione , proprio come in un database utente).
Ma non è necessario scaricare tempdb su disco, poiché il ripristino di emergenza non viene mai eseguito su tempdb, ma viene sempre ricreato all'avvio.
Tempdb non viene ripristinato in caso di arresto anomalo, quindi non è necessario forzare le pagine tempdb sporche su disco, tranne nel caso in cui il processo lazywriter (parte del pool buffer) debba fare spazio per le pagine di altri database.
Questo notevolmente (è stata una sorpresa per me) è l'unico meccanismo mediante il quale le pagine tempdb verranno scritte su disco. In caso di pressione del pool buffer, le pagine tempdb potrebbero essere scaricate sul disco. In caso contrario, non dovrebbe verificarsi.
Modifica: discutibile se "mal comportato" è una descrizione appropriata per un database utente che sta scrivendo pagine al di fuori del checkpoint. Forse insolito, atipico o semplicemente non ideale?
Modifica aggiuntiva (seguenti commenti / chat con @PaulWhite):
L'evidente omissione sopra è che le tabelle temporanee non sono l'unica fonte di traffico tempdb. Citando da Comprensione degli eventi di hash, ordinamento e scambio :
Alcune operazioni di esecuzione delle query di SQL Server sono calibrate per funzionare al meglio utilizzando una quantità (piuttosto) grande di memoria come memoria intermedia. Lo Strumento per ottimizzare le query sceglierà un piano e stimerà i costi in base a questi operatori utilizzando questo blocco memoria. Ma questa è, ovviamente, solo una stima. All'esecuzione le stime potrebbero rivelarsi errate e il piano deve continuare nonostante non disponga di memoria sufficiente. In tal caso, questi operatori si riversano sul disco.
Avevo erroneamente supposto che il meccanismo alla base di una scrittura fisica per un'operazione di sversamento fosse esattamente lo stesso descritto in precedenza, ovvero il lazywriter che obbligava le pagine tempdb a disco a causa della pressione sul pool di buffer (causata dalla fuoriuscita).
@PaulWhite ha spiegato dove avevo sbagliato (grazie Paul!):
Penso che tu stia chiedendo perché l'attività fisica del tempdb si verifica quando una query supera la sua concessione di memoria nello spazio di lavoro, piuttosto che usare semplicemente tempdb-in-memory Se lo facesse, la query userebbe più memoria della sua concessione, sconfiggendo il punto di limitare la memoria concede in primo luogo.
Gli sversamenti sono davvero speciali nella scrittura fino allo stoccaggio. L'attività fisica del tempdb viene osservata durante uno sversamento, anche di fronte a una gran quantità di memoria libera e pressione zero su tempdb.
Paul mi ha anche indicato il suo post sul blog Advanced TSQL Tuning: Why Internals Knowledge Matters, che include script di esempio per dimostrare gli sversamenti, per coloro che vogliono approfondire.