SQL Server: Optimización de consultas eficaces
Concéntrese en el ajuste de las consultas para optimizar realmente el rendimiento de SQL Server y administrar las cargas de trabajo en forma eficiente.
Extraído de "SQL Server DMV Starter Pack", publicado por libros de la puerta roja (2010).
Glenn Berry, Luis Davidson y Tim Ford
Optimización de consultas es el corazón y alma de optimizar el rendimiento de SQL Server. Si la carga de trabajo típico consta de las consultas ineficientes o mal diseñado, experimentará problemas de rendimiento y escalabilidad. Si las consultas son más largos, más numerosos y más complejo que es necesario, se consumen más recursos de CPU durante la ejecución.
Por consiguiente, ellos también tardará más en ejecutar. Consultas mal diseñado, junto con un error al hacer un buen uso de índices, dar lugar a SQL Server leer más datos que es necesario. Esto produce un retraso evidente en rendimiento y tiempo de ejecución.
Si SQL Server lee datos de la caché del búfer, se conoce como E/s lógicas. Esto puede ser una operación costosa desde un punto de vista de rendimiento. Si los datos no están en la memoria y debe leerse del disco (o si es necesario escribir datos), trata de E/s física y es incluso más caro.
Cuestiones de tamaño
Si tiene numerosas consultas que devuelven grandes cantidades de datos, podría provocar que la presión de memoria en la caché del búfer. Esto resultará en datos de baja SQL Server de la caché, que a su vez, afectará al rendimiento de otras consultas.
La "regla de oro" de las consultas SQL bien diseñadas es devolver que más datos que usted realmente no necesitan. Es conveniente SQL Server a pasar a través de los datos algunas veces como sea posible y utilice lógica basada en conjunto para manipular esos datos en el conjunto de resultados que necesita.
Analizar y optimizar las instrucciones de SQL no es una operación de "alta simultaneidad" ". SQL Server almacena planes para consultas previamente ejecutadas en un área de memoria compartida llamado caché del plan. Cada vez que envíe una consulta para su ejecución, SQL Server comprueba la caché del plan para ver si puede utilizar un plan existente para ejecutar la consulta. Cada vez que no encuentra a una coincidencia, a continuación, analiza, optimiza y genera un plan para la consulta enviada. Se trata de un proceso intensivo de CPU.
Además, cada vez que lo hace, SQL Server adquiere pestillos de la caché del plan para proteger el área relevante de la memoria de otras actualizaciones. Las consultas de SQL Server más ad hoc, sin parámetros significan más planes de uso único en la caché. Esto se traduce en un mayor consumo de recursos de CPU y pestillos absorbente durante el análisis. En última instancia, ésta puede resultar en un sistema que no son escalable. Las consultas SQL bien diseñadas promoverá la reutilización del plan ("analizar una vez, utilizar muchas veces") en la mayor medida posible.
Diseño con el tiempo en mente
En última instancia, si la carga de trabajo consta de las consultas mal diseñadas, hará que las operaciones de E/s innecesarias. La sobrecarga de CPU y memoria se ralentiza el funcionamiento y tiempos de ejecución será lentas. La situación empeorará a medida que crece el número de usuarios. Sus solicitudes se forzará a esperar para tener acceso a los recursos compartidos que están acaparando las consultas diseñadas de manera incorrecta.
Por el contrario, si se puede minimizar el número de instrucciones de SQL individuales que necesita para realizar un trabajo determinado, a continuación, también puede minimizar el trabajo realizado por cada una de las instrucciones de SQL individuales. Es mucho más probable que dispone de un sistema de SQL Server rápido y flexible, que escalará correctamente como el número de usuarios y que crece la carga de trabajo general.
Un enfoque que se utiliza a menudo para optimizar el rendimiento consiste en recuperar una lista de "Top 10" de las consultas más lentas que forman parte de la carga de trabajo normal, todos los días en la instancia de SQL Server y, a continuación, ajustarlos, uno por uno. Rastrear las sesiones, las solicitudes y consultas dentro de su infraestructura de SQL Server que consumen el más recursos y tardan más tiempo para ejecutar.
Un enfoque ligeramente más científico podría comenzar a los niveles inferiores, buscando áreas específicas donde SQL Server está experimentando la presión del recurso. Comprobación para determinar donde están esperando procesos veces inusualmente extensos para que alguna otra acción completar antes de continuar. De este modo, puede averiguar si el componente principal del tiempo de ejecución lento es el tiempo de CPU (si el sistema está limitado en CPU) o tiempo gastado en espera de E/s (si el sistema está enlazado-O) y así sucesivamente.
A continuación, puede trabajar desde allí a las solicitudes que hacen que la contención de recursos. Haber aislado las consultas con problemas, puede encontrar una manera de reducir la cantidad de trabajo que se realiza. Este proceso implica el ajuste de las instrucciones de SQL y las consultas o agregar índices. Si todo lo demás falla, puede aumentar la capacidad mediante la compra de más capacidad de disco/memoria/CPU.
.png)
.png)
.png)
Glenn Berrytrabaja como arquitecto de base de datos en las tecnologías de NewsGator en Denver, Colorado Es un MVP de SQL Server y tiene una colección completa de las certificaciones de Microsoft, incluyendo MCITP, MCDBA, MCSE, MCSD, MCAD y MCT, que demuestra que le gusta hacer pruebas.
**Luis Davidson**ha sido en la industria de TI durante 16 años como desarrollador de la base de datos corporativa y arquitecto. Ha sido un MVP de SQL Server durante seis años y ha escrito cuatro libros sobre el diseño de base de datos. Actualmente, es el arquitecto de datos y a veces DBA para la red de difusión cristiana, apoyar a las oficinas de playa Virginia, Virginia y Nashville, Tennessee
**Timothy Ford**es MVP de SQL Server y ha trabajado con SQL Server durante más de 10 años. Es el principal DBA y expertos para la plataforma de SQL Server para la salud del espectro. Ha sido escrito acerca de la tecnología desde el año 2007 para una variedad de sitios Web y mantiene su propio blog en thesqlagentman.com, que cubren los temas de desarrollo así como teletrabajo y profesional a SQL.
Obtener más información sobre "SQL Server DMV Starter Pack" en red-gate.com/our-company/about/book-store.