Mejora la velocidad de eliminación para SQL Server


12

Tenemos una gran base de datos de producción, su tamaño es de alrededor de 300 GB. ¿Existe algún enfoque para mejorar el rendimiento de una consulta de eliminación? En este momento, la velocidad de eliminación es de entre 1-10k por minuto, es muy lenta para nosotros.


2
1000 filas por minuto suena extremadamente lento. ¿Estás experimentando bloqueo? ¿O es tan lento seleccionar las filas también, lo que sugiere una necesidad de índice?
James Z

Probablemente tenga que crear un índice para cubrir sus criterios de eliminación.
Ginden

66
No hay suficientes detalles para dar una respuesta. ¿Qué consulta ejecutas? ¿Tiene índices en las columnas de criterios involucradas (si las hay)? ¿Tienes disparadores al eliminar? ...
Sébastien Sevrin

3
¿Estás tratando de eliminar mil millones de filas a la vez? ¿Es posible que esté esperando el crecimiento automático después del crecimiento automático después del crecimiento automático? (Es más que probable que sea la actividad de registro lo que está esperando, no la actividad de eliminación real.) Vea este artículo ...
Aaron Bertrand

3
También. ¿Alguna restricción de clave externa? Proporcione la definición completa de la tabla, la consulta y el plan de ejecución.
Martin Smith

Respuestas:


20

Si está tratando de eliminar una gran cantidad de filas en una sola declaración, es probable que esté esperando la actividad de registro. Así que puedes:

  1. Asegúrese de que su registro tenga el tamaño adecuado para que los eventos de crecimiento no lo retrasen. Con los valores predeterminados, su registro probablemente comience en 1 MB con un crecimiento del 10%. Los eventos de crecimiento son caros, y si está registrando incluso 10 GB de eliminaciones, esto destruirá el rendimiento no solo ahora sino también en el futuro (debido a lo que esto hace con los VLF).
  2. Si está eliminando toda la tabla, use TRUNCATEo DROP/ CREATE.
  3. Si está eliminando la mayor parte de la tabla, use SELECT INTOpara colocar los datos que desea mantener en otra tabla, luego TRUNCATE, mueva la porción pequeña hacia atrás. (O simplemente suelte la tabla anterior, cambie el nombre de la nueva y vuelva a aplicar restricciones / permisos, etc.)
  4. En primer lugar, minimice el impacto del inicio de sesión eliminando los datos en fragmentos en lugar de todos a la vez. Ver este artículo . También puede considerar cambiar temporalmente a una recuperación simple, de modo que solo tenga que CHECKPOINTborrar el registro en lugar de realizar copias de seguridad del registro, pero debe asegurarse de volver a configurarlo y realizar una nueva copia de seguridad completa para reiniciar la cadena de registro .

+1, de mi parte por un excelente artículo. Esto me ha ayudado en el pasado a hacer que nuestros desarrolladores entiendan la operación de eliminación cuando simplemente nos siguen buscando la lentitud y el crecimiento en el archivo de registro.
KASQLDBA

Además, si hay índices innecesarios, soltarlos aumentará la velocidad de eliminación. Nuevamente, si elimina todos o casi todos los datos, soltar todos los índices primero y crearlos nuevamente después puede tener un buen impacto.
Tony Hinkle

3
@Tony eliminar el índice también debe estar registrado (al igual que crearlo), por lo que puede ser solo una cuestión de cuándo desea pagar ese costo. Sin pruebas, no estoy convencido de que haya una gran ventaja para el escenario de eliminación (como lo sería para insertar / actualizar), a menos que tenga índices que no va a mantener después.
Aaron Bertrand

¿La desactivación temporal de las restricciones de FK puede mejorar la consulta?
Lev Z

3

Hay alguna pista, pero ¿qué versión estás usando? ¿Es la edición empresarial? De todas formas:

  1. Si puede, mueva el registro de transacciones a un disco más rápido
  2. Analiza el dónde . ¿Utilizará un índice para identificar registros para eliminar? Si no, ¿puedes agregar un índice?
  3. ¿Tiene algún índice en la tabla que pueda soltar? Si es así, déjelos.
  4. ¿Tiene claves foráneas frente a esta tabla? Estos realmente pueden ralentizar su eliminación.
  5. Si tiene una edición empresarial y el cuello de botella es el disco IO, una compresión a nivel de fila puede brindarle un poco de ayuda (o no, dependiendo de sus datos)
  6. ¿Puedes dividir la mesa? Los índices locales y la caída de particiones pueden ser más rápidos.
  7. Investigue dónde está el cuello de botella a través del monitor de actividad.

Agregue detalles, cuando trabaja con una gran base de datos no hay una sola respuesta válida.


0

Debería intentar eliminarlos parte por parte, probablemente eliminando en bucle, cada iteración de eliminación es su propia transacción y luego borrando el registro al final de cada iteración de bucle.

Además, necesitaría encontrar el número que va a utilizar como valor en bloque para eliminar los registros. Requiere una prueba exhaustiva, sería mejor si puede probar primero el valor del fragmento en UAT.

Sobre cómo proceder, lo referiría a Separar grandes operaciones de eliminación en fragmentos


0

eliminar puede ser lento si la tabla grande tiene clave foránea recursiva.

si es así, encuentre el momento oportuno, desactive los servicios dependientes, desactive la clave externa recursiva, realice una eliminación masiva y luego restaure la clave externa nuevamente.


Este fue exactamente mi caso. Es un poco arriesgado desactivar la restricción, pero la eliminación pasó de 1 fila / segundo a 500 / segundo
Jurion

0

Agregando algunos puntos más ...

  1. Intente verificar si el predicado tiene un índice y también vea las estadísticas.
  2. Si está eliminando una gran cantidad de filas y tampoco desea la opción de tabla temporal. Ve por la tablockopción.
  3. Vea si tiene algún desencadenante, específicamente después de eliminarlo.

Para obtener más ayuda, publique la consulta que está utilizando, la información de la tabla más cualquier información de bloqueo.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.