REL- 414Planes de ejecución IIEnrique Catalá BañulsMentor – Área relacionalMCT – MCTS – MCITP – MAP 2010ecatala@solidq.com
Objetivos de la sesiónα Comprendamos estadísticasα Esa magiaα Operadores β   Spool β   Stream aggregateα Escenarios avanza...
La magiaConceptos estadísticos básicosα Densidad β    Medida de cuantos duplicados hay por columna β    Densidad = 1/frecu...
Estadísticas y planes de ejecución
Planes de ejecución¿Qué es eso?Sentencia SQL                    Plan de ejecución                    Mágia                ...
La magiaSimplificationα Se detectan contradiccionesα Se reescribe la consulta simplificada  β   Agrupación de joins según ...
La magiaTrivial Planα Existen consultas tan simples, que no es necesario      optimizacion alguna  β    Solo tienen un pla...
La magiaExplorationα Stage 0 β   Reglas básicas de evaluacion usando hash y nested join β   Si el coste del plan es menor ...
La magia…Timeout!!α Pero cuidado porque en cada join, se incrementa   exponencialmente el nº de soluciones posibles
La magiaSELECT                                                       QueryAverage(Rating)                         Query   ...
Estimacion de costesα El optimizador utiliza dos tipos de clave β   Tiempo E/S: Coste de leer páginas de un subsistema de ...
Las malas estadísticas hacen explotar nuestras SANTimeouts
Operadores
OperadoresStream Aggregateα Agrupa filas por una o varias columnas para aplicar  funciones de agregado.α La entrada del op...
OperadoresSpoolsα Existen varios tipos según su especializaciónα Todos ellos hacen lo mismo conceptualmente β    Leen toda...
SpoolsRow count spoolα Escanea el input contando cuantas filas hay, devolviendo  el nº SIN DATOSα Se usa preferiblemente e...
SpoolsEager/Lazy Index Spoolα index spool β     Se suele llamar indice al vuelo porque crea un indice al vuelo con lo     ...
Worktables¿Qué son? ¿debemos temerlos?α Los worktables son objetos temporales creados por SQL        Server producidos por...
Stream aggregateSpool operators• Row Count Spool• Table Spool• Eager/Lazy Spool• Index Spool
Escenarios avanzadosContradiction detectionα En las fases de simplificacion a la hora de trabajar el query  optimizer se p...
Escenarios avanzadosParticionadoα Internamente, existe una columna PartitionID que        se crea al particionarα       Au...
Escenarios avanzadosServidores vinculadosα Grave problema de rendimiento «desapercibido»α Un login de servidor vinculado d...
Escenarios avanzadosFuncionesα Podemos definir las funciones de usuario en: β   Funciones inline β   Funciones multi-state...
Escenarios avanzadosParalelismoα Existen los mismos operadores para planes de ejecución  paralelosα Se identifican con una...
Escenarios avanzadosParalelismoα En sistemas OLTP puros, se suele premiar serializabilidad    β    Pocos sistemas son OLTP...
ParalelismoMetodos para controlarloα Configuracion de servidor «Max degree of parallelism» β   Valor predeterminado a 0 β ...
ParalelismoBeneficiosα Mejora prácticamente lineal con el nº de CPU para   operaciones parallel scans
ParalelismoInconvenientesα Las esperas se propagan con facilidad debido al modelo   productor-consumidor
Escenarios avanzadosParalelismo: Recomendacionesα No hay una solución maestra!!α Si observas esperas CXPACKET reduce MAXDO...
Si quieres disfrutar de las mejores sesiones denuestros mentores de España y Latino América,             ésta es tu oportu...
Upcoming SlideShare
Loading in …5
×

Planes de ejecución II

873 views

Published on

Cuando te enfrentas a problemas de rendimiento en SQL Server, debes optimizar consultas, y para optimizar consultas debes conocer qué hace dicha consulta en detalle, para ver dónde está comportándose de forma indebida. En esta sesión, nos centraremos en planes de ejecución no triviales para entender el funcionamiento de los mismos y de esta forma, poder optimizarlos. En esta sesión, se parte de la base de que el alumno conoce como trabajar con planes de ejecución y el funcionamiento de los operadores mas comunes. Si no es así, recomendamos asistir previamente a la sesión FUNDAMENTALS: Planes de ejecución I

Published in: Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
873
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
24
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Planes de ejecución II

  1. 1. REL- 414Planes de ejecución IIEnrique Catalá BañulsMentor – Área relacionalMCT – MCTS – MCITP – MAP 2010ecatala@solidq.com
  2. 2. Objetivos de la sesiónα Comprendamos estadísticasα Esa magiaα Operadores β Spool β Stream aggregateα Escenarios avanzados β Contradiction detection β Particionado β Funciones β Servidores vinculados β Optimizacion por estadísticas
  3. 3. La magiaConceptos estadísticos básicosα Densidad β Medida de cuantos duplicados hay por columna β Densidad = 1/frecuencia γ Alta densidad -> poco valor únicoα Frecuencia β Numero de valores únicos en una columnaα Selectividad β Tambien es medida de unicidad γ Alta selectividad -> pocos valores β Se suele utilizar para representar predicadosα Cardinalidad β Es el concepto clave que hay que entender y surge de todos los anteriores β Número de filas devueltos por un operador β Esto nos dara idea de por qué no va bien un plan de ejecucion
  4. 4. Estadísticas y planes de ejecución
  5. 5. Planes de ejecución¿Qué es eso?Sentencia SQL Plan de ejecución Mágia Optimizador de consultas
  6. 6. La magiaSimplificationα Se detectan contradiccionesα Se reescribe la consulta simplificada β Agrupación de joins según su cardinalidad β Se encuentran contradicciones en consultas que impidan su funcionamiento
  7. 7. La magiaTrivial Planα Existen consultas tan simples, que no es necesario optimizacion alguna β Solo tienen un plan de ejecución válido β No se leen ni las estadísticasα Su «Query tree» está prefijado y si aparece, simplemente se evalua su plan único sin másα Si una consulta se optimiza y después se determina que es trivial, siguientes consultas similares serán tratadas así
  8. 8. La magiaExplorationα Stage 0 β Reglas básicas de evaluacion usando hash y nested join β Si el coste del plan es menor a 0.2 usar este planα Stage 1 β Explorar mas reglas incluso alterando el orden de los join if(best_plan_for_now.cost<1) return(best_plan_for_now) else if(MAXDOP>1 and best_plan.cost > threshold for parallelism) return(MIN(create_paralel_plan().cost, best_plan_for_now))α Stage 2 β Explorar todas las opciones y optar por el plan menos costoso tras un nº limitado de exploracionesα CUIDADO, TIEMPO LIMITADO!!! (timeout)
  9. 9. La magia…Timeout!!α Pero cuidado porque en cada join, se incrementa exponencialmente el nº de soluciones posibles
  10. 10. La magiaSELECT QueryAverage(Rating) Query Parser ExecutionFROM Reviews Optimizer EngineWHERE MID = 932 Avg (Rating) or Avg_agg Avg_agg [Cnt, Sum] [Cnt, Sum] Select Index Lookup MID = 932 Filter MID = 932 MID = 932 Reviews Scan MID Index Logical operator tree Reviews Reviews Query Plan #1 Query Plan #2 11
  11. 11. Estimacion de costesα El optimizador utiliza dos tipos de clave β Tiempo E/S: Coste de leer páginas de un subsistema de disco β Tiempo CPU: Coste de aplicar predicados y tuplas en memoria
  12. 12. Las malas estadísticas hacen explotar nuestras SANTimeouts
  13. 13. Operadores
  14. 14. OperadoresStream Aggregateα Agrupa filas por una o varias columnas para aplicar funciones de agregado.α La entrada del operador, requiere la entrada ordenada por las columnas de agrupación β Si no lo están, se forzará un operador Sort como entradaα Generalmente se pueden optimizar con índices nonclustered usando columnas incluidas
  15. 15. OperadoresSpoolsα Existen varios tipos según su especializaciónα Todos ellos hacen lo mismo conceptualmente β Leen todas las filas de un input β Las almacenan en memoria o en disco β Permiten a otros operadores leer de dicha cacheα Sirven generalmente para: β Optimizacion de escenarios donde una subexpresion compleja se utiliza varias veces β Mantenimiento de la consistencia transaccional: Aseguran que leen toda la entrada antes de devolver salidaα Curiosidad: El common subexpression spool es el único operador que puede enchufar datos a varios operadores diferentes a la vez β Aunque realmente se realiza en serie (1 llena, los demas consumen secuencialmente)
  16. 16. SpoolsRow count spoolα Escanea el input contando cuantas filas hay, devolviendo el nº SIN DATOSα Se usa preferiblemente en NOT EXISTα Es la alternativa eficiente de un Left anti semi join
  17. 17. SpoolsEager/Lazy Index Spoolα index spool β Se suele llamar indice al vuelo porque crea un indice al vuelo con lo que entraα Lazy spool β Se suele llamar así (lazy = lento), porque cachea el resultado de ejecución INMEDIATAMENTE anterior γ Cuando la siguiente fila tiene el mismo valor, el valor se toma de lazy index spool (Rewind) γ Cuando la siguiente fila difiere, se intenta obtener del acumulado que existe en lazy index spool, pero si no, se intenta mirar en los operadores anteriores (Rebind)
  18. 18. Worktables¿Qué son? ¿debemos temerlos?α Los worktables son objetos temporales creados por SQL Server producidos por: β Spooling, para almacenamiento de datos intermedios durante consultas β DBCC CHECKDB o DBCC CHECKTABLE β Trabajo con XML o variables varchar(max) β Procesamiento de objetos Service broker β Trabajo con cursores keyset o estaticosα Ocurren en tempdbα Sus metadatos estan en memoria pero sus datos pueden estar en tempdbα Son objetos internos
  19. 19. Stream aggregateSpool operators• Row Count Spool• Table Spool• Eager/Lazy Spool• Index Spool
  20. 20. Escenarios avanzadosContradiction detectionα En las fases de simplificacion a la hora de trabajar el query optimizer se puede descartar directamente la ejecucionα Se sabe claramente que ha ocurrido porque aparece el operador Constant Scan
  21. 21. Escenarios avanzadosParticionadoα Internamente, existe una columna PartitionID que se crea al particionarα Aumento de rendimiento es interesante en operaciones de agregado y operadores tipo Scan β Búsquedas adaptadas al particionado β Estrategias de plan de ejecución en paraleloα Vistas de índices alineadas con el particionado β Alternancia junto con la partición β Cambio sencillo entre particionesα Múltiples hilos en consultas que involucran recorridos de más de una partición β SQL Server 2005 solo 1 hilo, cuidado!!!
  22. 22. Escenarios avanzadosServidores vinculadosα Grave problema de rendimiento «desapercibido»α Un login de servidor vinculado debe ser sysadmin, db_owner o db_ddadminα Si no lo es, no se pueden utilizar las estadísticasα Se estima un valor no real de las estadísticas para el plan de ejecución
  23. 23. Escenarios avanzadosFuncionesα Podemos definir las funciones de usuario en: β Funciones inline β Funciones multi-statementα Tendamos a eliminar las funciones…¿pero todas?α Problema: β No son visibles en los planes de ejecución gráficos β Producen malísimas estimaciones estadísticas que derivan en inadecuados usos de NESTED LOOPS β El código se interpreta en cada llamada (si no se usa bien) β Por último y más importante: NO ES POSIBLE PARALELISMO
  24. 24. Escenarios avanzadosParalelismoα Existen los mismos operadores para planes de ejecución paralelosα Se identifican con una doble flechaα Solo se opta por ellos cuando el plan de ejecución supera su coste «cost threshold of parallelism»
  25. 25. Escenarios avanzadosParalelismoα En sistemas OLTP puros, se suele premiar serializabilidad β Pocos sistemas son OLTP purosα SQL Server por defecto utiliza todos los cores disponibles para resolver planes de ejecución paralelosα La idea es utilizar los cores extras, para reducir el tiempo de respuesta utilizando multiples cpus β El tiempo computacional suele ser mas elevado, pero el tiempo efectivo suele ser menor
  26. 26. ParalelismoMetodos para controlarloα Configuracion de servidor «Max degree of parallelism» β Valor predeterminado a 0 β En el 99% de escenarios se debe ajustarα Configuraicon de servidor «Cost threshold of parallelism» β Valor predeterminado a 5 β No suele ser habitual modificarloα Cláusula MAXDOP β Modifica el comportamiento puntual de la cláusula a la que se aplica β Imprescindible en escenarios donde se ha ajustado «Max degree of parallelism»α Resource Governor β A traves de la configuración MAXDOP del workload group se puede/debe ajustar siempre que toquemos «Max degree of parallelism» β Nos ayudará a predefinir configuraciones MAXDOP
  27. 27. ParalelismoBeneficiosα Mejora prácticamente lineal con el nº de CPU para operaciones parallel scans
  28. 28. ParalelismoInconvenientesα Las esperas se propagan con facilidad debido al modelo productor-consumidor
  29. 29. Escenarios avanzadosParalelismo: Recomendacionesα No hay una solución maestra!!α Si observas esperas CXPACKET reduce MAXDOP β En OLTP puro pensar en 1 suele ser correctoα Considera Resource Governorα Si ves planes de ejecucion suboptimos, considera actualizar estadísticasα Re escribe la consulta para hacerla mas eficiente
  30. 30. Si quieres disfrutar de las mejores sesiones denuestros mentores de España y Latino América, ésta es tu oportunidad. http://summit.solidq.com/madrid/

×