Planes de ejecución II
Upcoming SlideShare
Loading in...5
×
 

Planes de ejecución II

on

  • 1,118 views

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á ...

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

Statistics

Views

Total Views
1,118
Views on SlideShare
1,118
Embed Views
0

Actions

Likes
0
Downloads
13
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Planes de ejecución II Planes de ejecución II Presentation Transcript

  • 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 avanzados β Contradiction detection β Particionado β Funciones β Servidores vinculados β Optimizacion por estadísticas
  • 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
  • Estadísticas y planes de ejecución
  • Planes de ejecución¿Qué es eso?Sentencia SQL Plan de ejecución Mágia Optimizador de consultas
  • 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
  • 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í
  • 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)
  • La magia…Timeout!!α Pero cuidado porque en cada join, se incrementa exponencialmente el nº de soluciones posibles
  • 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
  • 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
  • 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 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
  • 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)
  • 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
  • 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)
  • 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
  • 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 puede descartar directamente la ejecucionα Se sabe claramente que ha ocurrido porque aparece el operador Constant Scan
  • 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!!!
  • 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
  • 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
  • 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»
  • 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
  • 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
  • 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 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
  • 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/