Suddivisione di TempDB in file multipli pari al numero di CPU

L'articolo SQL Server tempdb Best Practices Increase Performance suggerisce che dovrei suddividere tempdbin un numero di file uguale al numero di core. Quindi per 4 core ottieni 4 file.

Avendo il numero maggiore di file, è possibile aumentare il numero di operazioni di I / O fisiche che SQL Server può inviare al disco in qualsiasi momento. Più I / O che SQL Server può spingere al livello del disco, più veloce verrà eseguito il database. Con i database standard, SQL Server può memorizzare nella cache una grande quantità di dati necessari. A causa della natura high-write di tempdb, i dati devono essere scritti sul disco prima di poter essere salvati nella memoria cache.

Anche se suona bene in teoria, è davvero così buono come un'ottimizzazione generale? È qualcosa che può applicarsi solo a sistemi specifici in cui l'IO è molto elevato?

Un rapporto da 1/4 a 1/2 volte il numero di file di dati TempDB rispetto ai core della macchina è stato a lungo la raccomandazione ...

Ma ora c'è una guida ancora migliore. A PASS nel 2011, il mio caro amico Bob Ward, che è il migliore nel supporto del prodotto SQL, ha scelto una nuova formula: se hai meno di 8 core, usa #files = #cores. Se hai più di 8 core, usa 8 file e se vedi un conflitto in memoria, aggiungi altri 4 file alla volta. [link]

L'ultima frase è sempre stata pertinente. Se non vedi la contesa, perché aggiungere altri file? Per giocare in sicurezza, la maggior parte aggiungerà 2-4 file come punto di partenza per la maggior parte delle build, ma oltre a ciò, misurare e reagire.

Come la maggior parte delle linee guida generali , è una semplificazione eccessiva nella sua luce più positiva. Nel migliore dei casi, è un buon punto di partenza (a condizione che non si mantenga il rapporto 1: 1 core: file di dati con una grande quantità di core).

Non vi è alcuna sostituzione per la progettazione corretta e il monitoraggio e il monitoraggio di base adeguati . Il motivo dietro avere più file di dati per tempdb è ridurre e mitigare la contesa della pagina di allocazione. Esistono numerosi post pubblicati su come monitorare questa tesi e agire di conseguenza. Di seguito sono riportate alcune risorse:

Abbattimento del conflitto TempDB (parte 1)
Abbattimento del conflitto TempDB (parte 2)
Analisi della contesa Tempdb
Ottimizzazione della configurazione tempdb con SQL Server 2012 Eventi estesi

Ma per rispondere alla tua domanda, no, questa non è una parte difficile da configurare e dimenticare di tempdb .