Contesa DDL su TempDB

Ho un SQL Server 2005 Standard x64 che sta riscontrando problemi con la contesa DDL TempDB negli ultimi mesi. Il server riscontrerà contesa sulla risorsa wait 2: 1: 103 (il tipo wait è PAGELATCH_EX).

Il problema sembra verificarsi sporadicamente quando il server è sotto carico decente. Ho monitorato il tasso di "tabelle temporanee per la distruzione" e può passare a oltre 5.000 volte durante i periodi in cui abbiamo problemi di PAGELATCH_EX su 2: 1: 103. Da quello che ho letto questo contatore dovrebbe essere 0 la maggior parte delle volte, ma il nostro sembra rimanere da 300 a 1100 la maggior parte delle volte. Il contatore va a 0 solo quando ci sono pochissimi utenti sul sistema.

Come posso restringere ciò che sta causando la contesa DDL su tempdb senza dover cercare un ago in una pila di fieno?

Ho visto questo problema e l'aggiornamento rapido che è stato infine rilasciato per risolverlo era in realtà un risultato diretto del mio caso con Microsoft CSS. Non esiste un articolo KB pubblico per la correzione. Assicurati di aver applicato il Service Pack 4 e l'aggiornamento cumulativo più recente a SQL Server (al momento della scrittura, si tratta dell'aggiornamento cumulativo n. 3 (9.00.5259) ).

Fino al rilascio dell'aggiornamento rapido, il suggerimento di Microsoft era di interrompere semplicemente la creazione di tabelle #temp (in modo molto simile KB # 916086 ). Poiché ciò avrebbe comportato una sostanziale riscrittura di dozzine e dozzine di procedure di segnalazione, la soluzione nel mio caso (indipendentemente dai flag di traccia o dal layout del file temporaneo) è stata quella di riavviare il nostro cluster ogni due fine settimana. Che schifo.

Per rintracciare l'utilizzo di tempdb, ci sono diversi script che possono aiutare, ad esempio vedere sp_whoIsActive di Adam Machanic , in particolare:

• sp_whoisactive: analisi del conflitto Tempdb
• Come identificare quale query sta riempiendo il registro delle transazioni tempdb?

E anche questo script (e quelli nei commenti) da @SQLSoldier:

• Abbattere la contesa TempDB

Vorrei assicurarmi che tutti i tuoi cursori stiano usando LOCAL STATIC READ_ONLY FORWARD_ONLY(vedi questo e questo ) e vedere se ci sono query costose conosciute che fanno ampio uso di tabelle #temp / variabili @table, CTE, o possono contenere ordinamenti non necessari o portare a hash join ... tutto ciò può contribuire al problema (dubito che troverai una causa d'oro). La correzione più semplice come punto di partenza "bang-for-your-buck" sarà quella di utilizzare le opzioni del cursore appropriate ed economiche al posto delle impostazioni predefinite.

Nel frattempo vorrei (a) installare CU # 3 e (b) chiamare PSS. Di 'loro che stai cercando una correzione molto specifica che è già stata confermata come un bug e rilasciata ad altri utenti come hotfix privato: "VSTS # 109112 - Il drop differito della tabella temporanea non viene ridimensionato per determinati carichi di lavoro". All'inizio potresti dover pagare la tassa del caso ma, poiché si tratta di un bug, l'addebito dovrebbe essere rimborsato.

Probabilmente avrai bisogno del flag di traccia 1118

Guarda prima i miti di Paul Randal su tempdb e i suoi articolo TF 1118

Il TF è descritto qui in KB 328551

Non ho esperienza diretta di questo, ma sembra quello che ho letto

Presumo che tu abbia già diviso i tuoi file di dati TempDB per cercare di alleviare la contesa (prima ovviamente tramite la pre-produzione). Se sei più coraggioso, considera il flag di traccia a cui Paul Randal si riferisce autorevolmente: http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(1230) -tempdb-dovrebbe-sempre-avere-un-dati-file-per-processore core.aspx

In termini di ciò che sta causando il dolore, è necessario svolgere alcune attività investigative:

• è appena iniziato a verificarsi? cosa è cambiato?
• il server è sotto pressione della memoria, quindi è necessario eseguire ordinamenti in TempDB?
• ci sono processi DBA come CheckDB o reindicizzazione online in esecuzione?
• vengono utilizzati livelli di isolamento più esotici o broker di servizi? dai un'occhiata ai database sys

C'è una bella query nella parte inferiore di questo documento Microsoft TempDB per provare a capire cosa sta usando tempdb: http://technet.microsoft.com/en-gb/library/cc966545.aspx

Se stai ancora cercando di rintracciarlo, di recente ho avuto un problema di prestazioni altrettanto strano con i drop di tabella sincroni. Se si dispone di un numero elevato di database (> 100 o giù di lì) su un'istanza sql che esegue SQL 2005 e si dispone di molte istruzioni per la creazione e l'eliminazione delle tabelle temporanee, è possibile ottenere riduzioni delle tabelle temporanee lente. Il controllo del conteggio delle righe restituito da sys.dm_db_index_usage_stats può escluderlo immediatamente come colpevole.

L'articolo di KB descrive il problema. http://support.microsoft.com/kb/2003031

Le prestazioni della query diminuiscono quando sys.dm_db_index_usage_stats ha un numero elevato di righe

Considera il seguente scenario:

In Microsoft SQL Server 2005, si eseguono frequentemente operazioni DDL che comportano l'eliminazione e la ricreazione di molte tabelle (in particolare tabelle temporanee nel database tempdb). È presente un numero elevato di voci (100.000 o più) nella vista di gestione dinamica sys.dm_db_index_usage_stats (DMV).

Tratto dalla mia risposta accettata a questa domanda. Ci sono anche alcuni dettagli in più. La tabella delle temperature lente si riduce a sql 2005