SQL Server: tablas temporales frente a tablas físicas

14

Hay un movimiento en marcha en mi lugar de trabajo para alejarme del uso de tablas #temp y, en su lugar, usar tablas físicas permanentes con SPID. Siempre que uno hubiera INSERTADO previamente en una tabla #temp, ahora INSERT INTO dbo.MyPermanentTable (SPID, ...) VALUES (@@SPID, ...)se requiere una, junto con un conjunto de DELETE FROM dbo.MyPermanentTable WHERE SPID = @@SPIDdeclaraciones al comienzo de, por ejemplo, un procedimiento almacenado. Además, no hace falta decir que en cualquier lugar donde se usen estas 'tablas permanentes para almacenar datos temporales', hay que tener cuidado de incluir a WHERE SPID = @@SPID.

La lógica detrás del movimiento hacia esta práctica es que mejorará el rendimiento general del servidor en el que se ejecutan las consultas (al reducir la E / S y la contención en tempdb). No estoy interesado en este enfoque por varias razones: es feo, potencialmente peligroso y parece que puede dañar el rendimiento de esas consultas que usan el nuevo esquema.

¿Alguien tiene alguna experiencia con este o enfoques similares para eliminar las tablas #temp?

sql-server performance Will A
fuente

Respuestas:

18

Se puede demostrar con bastante facilidad que no reducirá IO ni contención, sino que aumentará ambos.

  • IO : cada fila insertada, leída o eliminada de una tabla #temp ahora se insertará, leerá o eliminará de la tabla @@ SPID. Pero cada fila será más ancha con una columna @@ SPID adicional, por lo tanto, el número de páginas necesarias aumentará ligeramente y el IO será mucho más grande. Pero lo que es más importante, la caída de una tabla #temp y la inicialización de una nueva tabla #temp de una sesión por una sesión ahora tendrán que ser simuladas con a DELETE FROM @@spidTable WHERE spid = @@SPID, y así la operación de truncar / crear (es decir, operaciones de administración de extensión de página) se transformará en operaciones de fila, incomparablemente más lento.
  • Contención : cada exploración que usaba bloqueos de página en la tabla #temp ahora tendrá el potencial de bloquear una página con filas spid no relacionadas, creando así una contención previamente inexistente. Cada actualización que hace más que alcanza el umbral de escalado del bloqueo tiene la oportunidad de escalar el bloqueo al bloqueo de la tabla y, por lo tanto, bloquear cualquier otro spid.

Entonces, si bien es cierto que no alcanzará la mítica contención IAM / SGAM / GAM en tempdb, la única razón por la que esto sucedería es porque sus operaciones se volverán mucho más lentas debido a la IO extra extra y la contención adicional.

Remus Rusanu
fuente
Estoy totalmente de acuerdo con lo anterior Remus, y gracias por una excelente respuesta. El problema es que estamos causando un supuesto impacto en el rendimiento de aplicaciones de terceros (con varias bases de datos en un servidor en el que tenemos una base de datos propia; necesitamos realizar consultas frente a sus datos). Todavía creo que tienes razón, mente: en lo que respecta a E / S, esperaría que el nuevo enfoque tenga un rendimiento considerablemente peor que antes, en lo que respecta a la contención, desde el punto de vista temporal, las cosas serán mejores, desde el nuestro, algo peor.
Will A
¿Cuántos archivos tempdb tienes? La configuración estándar realmente no se escala en absoluto: debe tener varios archivos tempdb dile y log, uno por núcleo de procesador visible (2 cada uno si es hyper-v).
TomTom el
1
Debe leer estos dos artículos: sqlskills.com/BLOGS/PAUL/post/… y sqlskills.com/BLOGS/PAUL/post/… ya que abordan los problemas de escalabilidad tempdb más comunes.
Remus Rusanu
@ TomTom whoa, whoa. Múltiples archivos de registro? De Verdad?
Aaron Bertrand
5

Esto parece una solución drástica. Hay muchos artículos en línea sobre cómo reducir la contención de tempdb (y optimizar su uso). ¿Su organización ha examinado a fondo esa vía?

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

etc.


fuente
+1 completamente de acuerdo: optimice tempdb, no reinvente la rueda ya que su implementación será peor. :)
Estoy totalmente de no seguir este camino si no es justificable, gracias por la información, Ben. Investigaré y haré sugerencias a nuestro DBA según corresponda.
Will A
2

Me parece que deberías solucionar los problemas de rendimiento dentro de tempDB, hay algunas sugerencias aquí

SPE109
fuente
Parece útil: gracias SPE109, comprobaré esto y haré recomendaciones a nuestro DBA según corresponda.
Will A