Contención DDL en TempDB

Tengo un SQL Server 2005 Standard x64 que está experimentando problemas con la contención TempDB DDL en los últimos meses. El servidor experimentará contención en el recurso de espera 2: 1: 103 (el tipo de espera es PAGELATCH_EX).

El problema parece ocurrir esporádicamente cuando el servidor está bajo una carga decente. He estado monitoreando la tasa de "Tablas temporales para la destrucción" y puede saltar a más de 5,000 durante los momentos en que tenemos problemas de PAGELATCH_EX en 2: 1: 103. Por lo que he leído, este contador debería ser 0 la mayoría de las veces, pero el nuestro parece permanecer entre 300-1100 la mayoría de las veces. El contador solo va a 0 cuando hay muy pocos usuarios en el sistema.

¿Cómo puedo reducir lo que está causando la disputa DDL en tempdb sin tener que buscar una aguja en una pila de heno?

He visto este mismo problema y la revisión que finalmente se lanzó para solucionarlo fue en realidad un resultado directo de mi caso con Microsoft CSS. No hay un artículo de KB público para la solución. Asegúrese de haber aplicado el Service Pack 4 y la actualización acumulativa más reciente a SQL Server (en el momento de la redacción, es la Actualización acumulativa n. ° 3 (9.00.5259) ).

Hasta que se lanzó la revisión, la sugerencia de Microsoft era simplemente dejar de crear tablas #temp (al igual que KB # 916086 ). Dado que esto habría significado una reescritura sustancial de docenas y docenas de procedimientos de informes, la solución en mi caso (independientemente de las marcas de seguimiento o el diseño del archivo temporal) fue reiniciar nuestro clúster cada dos fines de semana. Yuck

Para rastrear el uso de tempdb, existen varios scripts que pueden ayudar, por ejemplo, vea sp_whoIsActive de Adam Machanic , específicamente:

• sp_whoisactive: análisis de la contención de Tempdb
• ¿Cómo identificar qué consulta está llenando el registro de transacciones tempdb?

Y también este script (y los de los comentarios) de @SQLSoldier:

• Desglosando la contención de TempDB

Me aseguraría de que todos sus cursores estén usando LOCAL STATIC READ_ONLY FORWARD_ONLY(vea esto y esto ), y vea si hay consultas costosas conocidas que hagan un uso extensivo de #temp tables / @table variables, CTE, o puedan contener tipos innecesarios o conducir a combinaciones hash ... todo lo cual puede contribuir al problema (dudo que encuentre una causa de oro). La solución de barrido más fácil como punto de partida para "ganar dinero" será utilizar opciones de cursor adecuadas y económicas en lugar de los valores predeterminados.

Mientras tanto, (a) instalaría CU # 3 y (b) llamaría a PSS. Dígales que busca una solución muy específica que ya ha sido confirmada como un error y lanzada a otros usuarios como una revisión privada: "VSTS # 109112 - La caída diferida de la tabla temporal no escala para ciertas cargas de trabajo". Es posible que deba pagar la tarifa del caso inicialmente pero, dado que se trata de un error, el cargo debe reembolsarse.

Probablemente necesite trazar la bandera 1118

Vea primero los mitos de Paul Randal sobre tempdb , y también su artículo TF 1118

El TF se describe aquí en KB 328551

No tengo experiencia directa en esto, pero suena como lo que he leído.

Supongo que ya ha dividido sus archivos de datos TempDB para tratar de aliviar la contención (a través de la preproducción, obviamente, primero). Si eres más valiente, considera la marca de seguimiento a la que Paul Randal se refiere automáticamente: http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(1230) -tempdb-should-always-have-one-data-file-per-processor-core.aspx

En términos de lo que está causando el dolor, debe hacer un trabajo de investigación:

• ¿Esto acaba de comenzar a ocurrir? ¿que ha cambiado?
• ¿El servidor está bajo presión de memoria, por lo que hay que hacer algo en TempDB?
• ¿hay algún proceso de DBA como CheckDB o reindexación en línea en ejecución?
• ¿Se utilizan niveles de aislamiento más exóticos o un agente de servicios? echar un vistazo a sys.databases

Hay una buena consulta en la parte inferior de este documento de Microsoft TempDB para intentar averiguar qué está usando tempdb: http://technet.microsoft.com/en-gb/library/cc966545.aspx

Si todavía está buscando rastrear esto, recientemente tuve un problema de rendimiento similarmente extraño con las caídas de tablas síncronas. Si tiene un gran número de bases de datos (> 100 más o menos) en una instancia sql que ejecuta SQL 2005 y tiene muchas instrucciones de creación y caída de la tabla temporal, puede obtener caídas lentas de la tabla temporal. Verificar el recuento de filas devuelto por sys.dm_db_index_usage_stats puede descartar esto de inmediato como el culpable.

El artículo de KB describe el problema. http://support.microsoft.com/kb/2003031

El rendimiento de la consulta disminuye cuando sys.dm_db_index_usage_stats tiene un gran número de filas

Considere el siguiente escenario:

En Microsoft SQL Server 2005, con frecuencia realiza operaciones DDL que implican la eliminación y recreación de muchas tablas (especialmente tablas temporales en la base de datos tempdb). Tiene una gran cantidad de entradas (100,000 o más) en la vista de administración dinámica (DMV) sys.dm_db_index_usage_stats.

Tomado de mi respuesta aceptada a esta pregunta. Hay algunos detalles más allí también. La tabla de temperatura lenta cae en sql 2005