¿RECOMPILAR Es Realmente Tan Malo?

Heh He en lo de DBCC FREEPROCCACHE y con el entendimiento de que mi servidor probablemente no esté cerca de un lugar donde causaría una preocupación real, tenemos una mezcla pesada entre OLTP y grandes ejecuciones de procesamiento, especialmente durante el día. Lleva demasiado tiempo aislar cada procedimiento almacenado que necesita una recompilación, por lo que uso DBCC FREEPROCCACHE en mi caja de producción de vez en cuando sin efectos nocivos graves y limpia una gran cantidad de pecados de inmediato. YMMV pero, para mí, usar DBCC FREEPROCCACHE no es el no-no que todos hacen que sea.

En cuanto a las recompilaciones, estoy de acuerdo. No son necesariamente el pecado que mucha gente quiere que creas. Son especialmente útiles en algunas de esas grandes ejecuciones de procesamiento en las que se necesita una recompilación para que el registro funcione al mínimo.

Ha pasado un tiempo desde que miré nuestra situación de recompilación en el trabajo, pero teníamos un proceso que «solo» tardaba 100 ms en ejecutarse, lo que también pensé que estaba tomando demasiado tiempo, pero no pude lograr que la administración se moviera a pesar de que expliqué las decenas de miles de veces que se estaba golpeando cada hora. Luego hice un análisis de recompilación y la maldita cosa no solo se recompilaba CADA vez que se llamaba, sino que tardaba entre 2 y 22 segundos en recompilarse cada vez con un promedio de 20 segundos. Una vez que hice mis ajustes al código bastante corto en el proc, no solo desaparecieron las recompilas, sino que la ejecución ahora se mide en ms de un solo dígito. No lo sabía, pero esto también resolvió un punto de dolor importante en los tiempos de retorno en el suelo para una pantalla en particular en la aplicación que usaba el proc.

En cuanto a los «avances» que se les ocurrieron en esta área para 2017 y 2019, tengo mucho miedo de mudarme del 2016. Todavía estoy sufriendo de algunos de los «avances» que se les ocurrieron en 2014 y 2016. Sin embargo, no nos dan muchas opciones cuando se trata de actualizar. Uno de esos «avances» es «Inserciones rápidas». La mayoría de la gente no lo sabe porque sus rutinas de mantenimiento de índices ocultan el error que tiene al asignar una extensión completa sin buscar extensiones parcialmente vacías ya existentes, incluso si está insertando una fila proverbial de «1 byte». Gracias a Dios por TF 692.

Los cambios que hicieron para TempDB son bastante buenos, pero no permitir siquiera una excursión temporal para desequilibrar el tamaño de los archivos ha matado a un montón de cosas que estábamos haciendo debido a otro error incrustado en SET IDENTITY INSERT EN el que se ordena toda la transferencia de datos en TempDB, aunque no es necesario debido a la presencia de un Índice Agrupado y un Registro mínimo.

Desearía que MS dejara de hacer «mejoras» y comenzara a arreglar en serio las «mejoras» que ya han hecho.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *