Optimización del Desempeño

Existen muchas razones por las que los usuarios del motor de la base de datos pudieran experimentar altos tiempos de respuesta pero en general podemos decir que las causas tienen que ver ya sea con cuellos de botella en los recusos del sistema (procesador, la memoria o el sistema de discos), o bien problemas de configuración del motor de la base de datos.

Tanto Windows como SQL Server ofrecen varias herramientas que pueden ser utilizadas para identificar areas problemáticas. Las herramientas más comunes a utilizar son: Performance Monitor, SQL Server Profiler, comandos DBCC y vistas dinámicas en memoria (DMVs). A continuación hablaremos sobre las causas mas comunes que resultan en recursos sobre cargados y las distintas opciones para resolver el problema.

Cuello de Botella: El Procesador

La forma más fácil de identificar si el procesador representa un problema es utilizando los contadores que ofrece el Monitor del Desempeño de Windows (Performance Monitor). Si el contador Processor:%Processor Time muestra valores sostenidos por arriba del 80%, entonces el procesador está sobre cargado y será necesario determinar si es posible reducirle la carga o si se tendrá que adquirir un procesador más potente o procesadores adicionales.

Antes de disponerse a comprar mas hardware es importante analizar qué rutinas son las que hacen el mayor uso del procesador para ver si es posible optimizarlas, ya sea reprogramándolas usando una mejor arquitectura o bien cambiando aquellos parámetros de configuración que pudieran impactarlas positivamente. Ahora bien, desde el punto de vista de SQL Server, cuales son las actividades o tareas que hacen más uso del procesador y como pueden detectarse?

Sin duda, unas de las causas principales son la compilación y la re-compilación de queries y frecuentemente los problemas de esta índole pueden detectarse consultando la vista dinámica sys.dm_exec_query_stats. En lo que respecta a la compilación, ésta vista almacena en memoria un número o “firma” que SQL Server calcúla para cada consulta (query) utilizando las letras y caracteres que la conforman, de tal forma que cuando dos consultas o más comparten la misma firma éstas pudieran convertirse en la misma consulta si se utilizaran parámetros en lugar de valores literales. Por ejemplo, si se reemplazáran los valores literales por parámetros, las siguientes consultas compartirían la misma firma ya que lo único que es distinto entre ellas son precisamente los valores literales:

Select * from sys.objects where object_id=500

Select * from sys.objects where object_id=100

Cabe señalar que el cálculo de la firma para las consultas ignora diferencias menores tales como espacios en blanco, usos de mayúsculas o la utilzación de nombres completos de objetos en vez de nombres simples.

Si al consultar la vista sys.dm_exec_query_stats nos damos cuenta que un alto número de consultas comparten la misma firma (es decir, tienen el mismo valor en la columna query_hash) entonces tales consultas son muy buenas candidatas para ser parametrizadas en vez de usar valores literales. En caso de que ésto no sea posible debido a no tener acceso al código o por razones legales relacionadas con contratos de servicio o de uso del software, entonces es recomendable considerar forzar la parametrización a nivel servidor utilizando el comando:

ALTER DATABASE TuBasedeDatos SET PARAMETERIZATION FORCED

La re-compilación puede presentarse debido a cambios en la estructura de la base de datos, cambios en las estadísticas de los objetos, cambios en las tablas temporales o bien por la recompilación manual de procedimientos almacenados (stored procedures). Para detectar su presencia podemos utilizar los siguientes contadores del Monitor del Desempeño de Windows (Performance Monitor):

SQL Sever: SQL Statistics: Batch Requests/Sec

SQL Server:SQL Statistics: SQL Compilations/Sec

SQL Server:SQL Statistics: SQL Recompilations/Sec

Si los contadores muestran nivels altos, entonces habrá que utilizar SQL Server Profiler para investigar más afondo e identificar cuáles procedimientos almacenados se recompilan frecuentemente y porqué.

This entry was posted in Optimización. Bookmark the permalink.

Leave a Reply