Aprender a optimizar las consultas SQL y comprender los planes de ejecución: ¿recursos?

8

Me encuentro escribiendo más y más consultas SQL en el trabajo (principalmente Oracle 11g, pero algunos SQL Server 2005-2008) y he comenzado a crear algunas vistas bastante complejas para el resto del equipo de analistas.

En su mayoría, todos corren bastante bien, pero algunos no tan bien. Entonces...

  • ¿Cómo aprendo a ajustar mis consultas?
  • ¿Debo aprender a leer / actuar en los planes de ejecución?

Y...

  • ¿Qué libros / sitios web puede recomendar para aprender sobre el ajuste de consultas SQL 1) en general 2) específicamente para Oracle 11g?

Tenemos algunos buenos DBA aquí, pero están demasiado saturados para ayudarnos a ajustar cada consulta que escribimos.

La mayoría de los libros que he encontrado en Amazon para Oracle parecen estar orientados a la optimización general de la base de datos y / o fueron escritos hace 8-10 años.

Gracias amablemente por tu consejo :)

Tommy O'Dell
fuente
Para SQL Server, el libro de Grant: simple-talk.com/sql/performance/execution-plan-basics
Aaron Bertrand

Respuestas:

7

Diría que aprender a entender los planes explicados es una habilidad vital para ayudarlo a optimizar las declaraciones SQL. El libro de Christian Antognini, Solución de problemas de rendimiento de Oracle , me ha sido muy útil para detallar cómo funcionan, así como para explicar cómo abordar la optimización de la base de datos. Si bien tiene algunos años, aún aprenderá mucho de lo que sigue siendo relevante.

Si avanzas más, puedes mirar los libros de Jonathan Lewis, pero estos son más detallados, por lo que probablemente no sean un buen punto de partida. Oracle Fundamentals, basado en costos, es bastante antiguo ahora, pero gran parte aún es relevante. Todavía no he leído Oracle Core: aspectos internos esenciales para la resolución de problemas , pero ha recibido buenas críticas de la comunidad de Oracle.

Como está en 11g, si tiene consultas que demoran más de unos segundos, definitivamente recomendaría mirar el monitor SQL en tiempo real (suponiendo que tenga la licencia adecuada). Como su nombre indica, muestra el progreso de una instrucción SQL en tiempo real, desglosando cuánto tiempo ha tomado cada operación con los detalles de las filas obtenidas hasta el momento. También mantiene los detalles de las consultas ejecutadas recientemente por un corto tiempo para que pueda ver cómo sus cambios afectan una declaración.

Documentación de Oracle SQL Monitoring: http://docs.oracle.com/cd/E11882_01/server.112/e16638/instance_tune.htm#PFGRF94543

Aprender a ajustar las consultas es algo que llevará tiempo y práctica. Algunas cosas que he aprendido:

  • Escriba consultas para obtener la menor cantidad de filas posible lo antes posible (por ejemplo, no desea escanear por completo una tabla de 10 millones de filas si solo necesita 100 filas de ella)
  • Verifique que el número de filas esperadas en cada paso de un plan de explicación (esperado) coincida con las devueltas en el plan de ejecución real. Cuando estos son órdenes de magnitud diferentes, es probable que el optimizador no elija el "mejor" plan.
  • Comprenda los principios de una buena indexación: cómo funcionan y cuándo deberían / ​​no deberían usarse al ejecutar una consulta ( Richard Foote tiene un blog muy detallado sobre los índices en Oracle)

En su mayoría, aprenderá escribiendo consultas, mirando los planes de explicación (esperados) y comparándolos con los planes de ejecución reales (ya sea mediante el seguimiento de la consulta o utilizando el monitor SQL). Luego vuelva a escribir la consulta, agregue / elimine índices, etc. y vea cómo afecta los planes y los tiempos de ejecución

Chris Saxon
fuente
1

Como está buscando información específica de Oracle, recomendaría el blog Ask Tom en Oracle. En general, creo que encontrará que el consejo es no ajustar la consulta. Obtendrá buenos consejos sobre cómo escribir una consulta que el optimizador puede optimizar. La documentación de Oracle también está en línea , y generalmente busco información actualizada sobre Oracle. No he trabajado con SQLServer, así que no tengo ninguna recomendación para ello.

No he visto muchas novedades en el campo de la optimización de consultas en los últimos años. El gran cambio es la desaprobación del optimizador basado en reglas, con el que apenas recuerdo haber trabajado. Sin embargo, entiendo que SQLServer todavía utiliza un optimizador basado en reglas, por lo que comprender sus reglas puede ayudar.

Una herramienta en la que puede editar una consulta, ejecutarla y generar un plan de explicación ayuda a comprender qué cambios le dan una consulta que funciona bien. He tenido buenos resultados con AquaData Studio, y realmente me gusta su vista de árbol. El desarrollador SQL también debería hacerlo.

Al igual que con cualquier optimización, debe tener datos cuantitativos sobre su rendimiento. Luego puede determinar si realmente lo optimizó.

Cómo optimizar una consulta depende en parte de cómo el analizador construye y optimiza la consulta. En mayor medida, depende de la distribución de los datos que está consultando. En una base de datos Oracle, si el conjunto de resultados constituye el cuatro por ciento o más de una tabla y se distribuye aleatoriamente, un escaneo de tabla suele ser más rápido que un índice.

He trabajado para optimizar las consultas de un equipo de desarrolladores. Solo dos o tres consultas al año requieren una optimización seria. La mayoría de las consultas son lo suficientemente simples como para no necesitar optimización. El resto generalmente podría manejarse agregando rutas de unión faltantes.

Para Oracle hay tres configuraciones ajustables que pueden afectar significativamente el rendimiento. Los costos de las búsquedas de índice y datos interactúan para cambiar las condiciones bajo las cuales se utilizará o no un índice in. Estos dos pueden ajustarse por sesión. Los valores predeterminados a menudo no son óptimos. El otro valor controla cuántas alternativas intentará el optimizador. Aumentar este valor a menudo ayuda.

La optimización se ve significativamente afectada por la distribución de datos y el volumen. Al optimizarlo, es mejor usar una copia de la base de datos de producción, o al menos una base de datos con la misma distribución de datos y volúmenes. He roto gravemente el entorno de prueba, optimizando una consulta para la base de datos de órdenes de producción. Las bases de datos de prueba y desarrollo tenían una distribución de datos significativamente diferente, lo que hizo que la consulta fallara incluso con significativamente menos datos.

BillThor
fuente
Es posible que desee considerar poner más sustancia aquí. Esto en realidad está en el límite "no es una respuesta" tal como está actualmente.
JNK