SQL Server - Tabelle temporanee e fisiche

14

Nel mio posto di lavoro è in atto un movimento per allontanarmi dall'uso delle tabelle #temp e invece di utilizzare tabelle fisiche permanenti con SPID. Ogni volta che uno avrebbe precedentemente INSERITO IN una tabella #temp, ora INSERT INTO dbo.MyPermanentTable (SPID, ...) VALUES (@@SPID, ...)è richiesto - insieme a un mucchio di DELETE FROM dbo.MyPermanentTable WHERE SPID = @@SPIDistruzioni all'inizio di una procedura memorizzata. Inoltre, è ovvio che ovunque si utilizzino queste "tabelle permanenti per l'archiviazione di dati temporanei", bisogna fare attenzione a includere a WHERE SPID = @@SPID.

La logica alla base di questa pratica è che migliorerà le prestazioni generali del server su cui sono in esecuzione le query (riducendo l'I / O e la contesa in tempdb). Non sono appassionato di questo approccio per una serie di motivi: è brutto, potenzialmente pericoloso e sembra che potrebbe danneggiare le prestazioni di quelle query che utilizzano il nuovo schema.

Qualcuno ha esperienza con questo o simili approcci per eliminare le tabelle #temp?

sql-server performance

— Will A
fonte

18

Si può dimostrare abbastanza facilmente che non ridurrà IO né contesa, ma aumenterà entrambi.

IO : Ogni riga inserita, letta o eliminata da una tabella #temp verrà ora inserita, letta o eliminata dalla tabella @@ SPID. Ma ogni riga sarà più ampia con un'ulteriore colonna @@ SPID, quindi il numero di pagine necessarie aumenterà leggermente e l'IO sarà sempre leggermente più grande. Ma ancora più importante, la caduta di una tabella #temp e l'inizializzazione di una nuova tabella #temp di una sessione da parte di una sessione dovranno ora essere simulati con un'operazione DELETE FROM @@spidTable WHERE spid = @@SPID, e quindi troncare / creare operazioni (cioè operazioni di gestione dell'estensione della pagina) saranno trasformate nelle operazioni di fila, incomparabile più lento.
Contesa : ogni scansione che utilizzava i blocchi di pagina nella tabella #temp ora può bloccare una pagina con righe spid non correlate, creando in tal modo contese inesistenti. Ogni aggiornamento che fa di più e raggiunge la soglia di escalation del blocco ha la possibilità di inoltrare il blocco al blocco della tabella e quindi bloccare ogni altro spid.

Quindi, mentre è vero che non colpirai la mitica contesa IAM / SGAM / GAM in tempdb, l'unica ragione per cui questo potrebbe accadere è perché le tue operazioni diventeranno molto più lente a causa di un IO aggiuntivo e di una contesa extra.

— Remus Rusanu
fonte

Sono totalmente d'accordo con quanto sopra Remus - e grazie per l'eccellente risposta. Il problema è che stiamo causando un presunto hit delle prestazioni su applicazioni di terze parti (con diversi database su un server su cui abbiamo un nostro database - dobbiamo eseguire query rispetto ai loro dati). Continuo a pensare che tu abbia ragione, mente - I / O saggio mi aspetterei che il nuovo approccio si comportasse in modo considerevolmente peggiore di prima - saggia la contesa, dal punto di vista dei tempdbs le cose andranno meglio - dal nostro, un po 'peggio.

— Will A

Quanti file tempdb hai? La configurazione standard non si ridimensiona affatto: dovresti avere più file di file e log tempdb, uno per core del processore visibile (2 ciascuno se hyper-v).

— TomTom,

1

È necessario leggere questi due articoli: sqlskills.com/BLOGS/PAUL/post/… e sqlskills.com/BLOGS/PAUL/post/… poiché risolvono i problemi di scalabilità tempdb più comuni.

— Remus Rusanu,

@TomTom whoa, whoa. Più file di registro? Veramente?

— Aaron Bertrand

5

Sembra una soluzione drastica. Ci sono molti articoli online sulla riduzione della contesa tempdb (e sull'ottimizzazione del suo utilizzo) - la tua organizzazione ha esaminato a fondo quella strada?

http://www.sql-server-performance.com/tips/tempdb_p1.aspx

http://www.sqlservercentral.com/blogs/robert_davis/archive/2010/03/05/Breaking-Down-TempDB-Contention.aspx

http://searchsqlserver.techtarget.com/tip/Optimize-tempdb-in-SQL-Server-by-striping-and-splitting-to-multiple-files

eccetera.

+1 è completamente d'accordo: ottimizza tempdb, non reinventare la ruota poiché l'implementazione sarà peggiore. :)

Sto tutti per non seguire questo percorso se non è giustificabile - grazie per le informazioni Ben - Esaminerò e fornirò suggerimenti al nostro DBA come appropriato.

— Will A

2

Mi sembra che dovresti risolvere i problemi di prestazioni all'interno di tempDB, ci sono alcuni suggerimenti qui

— SPE109
fonte

Sembra utile - grazie a SPE109, controllerò questo e farò raccomandazioni al nostro DBA, se del caso.

— Will A