Avoiding Recompiles in SQL Server

Otra ponencia extremadamente específica. Personalmente, creo que Greg Low (consultor de Readify, MVP, MSDN Regional Director, etc.) no es quizás de los mejores ponentes, pero hay que reconocer que los conocimientos los tiene…

Bien, algunas ideas que dio Greg... Desde hace unas cuantas versiones de SQL Server, es de todos conocido que antes de ejecutar un Stored Procedure, el motor lo compila, lo cual significa elegir un plan de ejecución. Tras la compilación, los Stored Procedure se almacenan en una cache de forma que se reutiliza el plan de ejecución siempre que se puede y se evita su recompilación.

SQL2005 incorpora algunas mejoras en este tema. Por ejemplo, la recompilación a nivel de sentencia en vez de a nivel de batch. Aún y así, hay muchos casos en que no se usa la cache entre llamadas, por ejemplo las consultas “ad-hoc” requieren que el texto sea exactamente el mismo (SQL Server es “case sensitive” y “space sensitive”). Por tanto hay que estudiar los accesos de nuestras aplicaciones con cuidado, ya que fácilmente se puede incurrir en recompilaciones...

De hecho, el mecanismo en el que se basa la cache de SQL Server es complejo. Parte del concepto de coste en “ticks”, y según se reutiliza un Stored Procedure, y en función de los costes que supone su compilación, se incrementa o decremente el coste, jugando entre 0 y 31 "ticks".

La verdad es que hay muchos aspectos que pueden intervenir en la recompilación de sentencias. La explicación de Greg, bastante exhaustiva, hizo que nos diésemos cuenta de la complejidad de la situación. No puedo decir más que si queremos optimizar nuestros accesos a base de datos en este punto, vale la pena estudiar con detalle las posibilidades…