¿Cómo puedo saber POR QUÉ un inserto en una tabla determinada es lento?

29

Sé que un INSERT en una tabla SQL puede ser lento por varias razones:

Existencia de disparadores de inserción en la mesa
Muchas restricciones forzadas que deben verificarse (generalmente claves foráneas)
La página se divide en el índice agrupado cuando se inserta una fila en el medio de la tabla
Actualización de todos los índices no agrupados relacionados
Bloqueo de otra actividad en la mesa
Mal tiempo de respuesta de escritura de E / S
... algo que me perdí?

¿Cómo puedo saber cuál es el responsable en mi caso específico? ¿Cómo puedo medir el impacto de las divisiones de página frente a las actualizaciones de índice no agrupadas frente a todo lo demás?

Tengo un proceso almacenado que inserta alrededor de 10,000 filas a la vez (desde una tabla temporal), lo que toma alrededor de 90 segundos por cada 10k filas. Eso es inaceptablemente lento, ya que hace que otros spids se agoten.

He mirado el plan de ejecución, y veo la tarea INSERTAR ÍNDICE CLUSIFICADO y todas las BÚSQUEDAS DE ÍNDICE de las búsquedas de FK, pero todavía no me dice con certeza por qué lleva tanto tiempo. Sin desencadenantes, pero la tabla tiene un puñado de teclas F (que parecen estar indexadas correctamente).

Esta es una base de datos SQL 2000.

— BradC
fuente

¿Tiene habilitado el autoexpand en sus archivos de datos? Eso puede causar problemas de rendimiento con la configuración predeterminada.

— Larry Coleman

¿Estamos hablando de usar un perfilador? msdn.microsoft.com/en-us/library/ms187929.aspx

— Incognito

@Larry: los archivos de datos tienen un espacio libre significativo, por lo que no creo que el crecimiento de los archivos de datos sea un problema. Sin embargo, es bueno agregarlo a la lista de "cosas para verificar".

— BradC

@ user210: el perfil de la finalización de la declaración solo me muestra que tardó 90 segundos, no me dice POR QUÉ. A menos que haya otros eventos que creas que serían más reveladores.

— BradC

10

Algunas cosas que puedes mirar ...

Reduzca el tamaño del lote de 10000 a algo más pequeño, como 2000 o 1000 (no dijo qué tan grande es el tamaño de su fila).

Intente activar IO Stats para ver cuánto IO están tomando las búsquedas FK.

¿Cuál es la espera causada cuando ocurre la inserción (master.dbo.sysprocesses)?

Comencemos aquí y veamos a dónde vamos.

— mrdenny
fuente

2

Bajar el tamaño del lote sí ayuda (1000 registros toman ~ 25 segundos). Es probable que sea nuestra "solución" actual. Veré si puedo determinar las estadísticas de IO y las esperas (el cliente ejecuta el trabajo a pedido cuando tiene un archivo que procesar, por lo que no siempre puedo predecir cuándo se ejecutará realmente el trabajo).

— BradC

7

Puntilla,

Debe examinar las estadísticas de espera para su consulta. Con SQL2000 puede usar la sintaxis DBCC SQLPERF ("waitstats") para obtener esos detalles.

— SQLRockstar
fuente

6

Puedo decir lo que estoy buscando al analizar el rendimiento de una consulta. Quizás ayude.

analizar el plan de ejecución de consultas y verificar escaneos de índice, escaneos de tablas, uso de funciones convert_implicit para tipos de datos sql, paralelismo.
ejecute la consulta con SET STATISTICS IO ON y SET STATISTICS TIME ON para ver el tiempo de ejecución y leer / escribir io para cada inserción.
compruebe el tiempo de espera de sysprocesses para su sesión spid.
ejecute profiler y seleccione la plantilla estándar. seleccione lo siguiente: Estadísticas de rendimiento (si se repite, su plan se compila muchas veces, no es bueno), RPC: completado, SQL: completado por lotes y SQL: inicio por lotes. Agregue a ellos los recuentos de filas de columnas para ver exactamente el número de filas en el lote. Filtre los resultados para ver solo su consulta.
finalmente, recopile el contador de expectativa de vida útil de la página de Windows y, si está por debajo de 300 (5 min), el SQL tiene poca memoria. También recopile contadores de disco: longitud de la cola del disco , Tiempo de disco (unidad de archivos de datos), Tiempo de disco (unidad de archivos de registro) para ver si hay presión sobre los discos.

— yrushka
fuente

5

Intenta usar:

SET STATISTICS IO ON

y

SET STATISTICS PROFILE ON

ESTADÍSTICAS IO

Puede ser útil para decirle en qué tablas está realizando la mayor cantidad de escaneos de tablas, lecturas lógicas y lecturas físicas (uso estos tres para centrarme en qué parte del plan de consulta necesita más ajustes)

PERFIL ESTADÍSTICO

Principalmente devolverá el plan de consulta en formato tabular, luego puede mirar en las columnas IO y CPU lo que está costando la mayor cantidad en la consulta (¿es el escaneo de la tabla en su tabla temporal frente al tipo que hace para insertar en su clave agrupada, etc.)

— Andrew Bickerton
fuente