Utilizando el plan cache para optimizar procesos de
•
0 recomendaciones•955 vistas
Presentación donde se emplean todas las bondades del Plan Cache que nos brinda SQL Server para fortalecer las ejecuciones de las consultas en nuestros escenarios de datos.
Recomendados
Recomendados
Más contenido relacionado
Similar a Utilizando el plan cache para optimizar procesos de
Similar a Utilizando el plan cache para optimizar procesos de (20)
Más de John Bulla
Más de John Bulla (20)
Último
Último (20)
Utilizando el plan cache para optimizar procesos de
- 1. Utilizando el Plan Cache para optimizar procesos de consultas John Alexander Bulla Torres - @johnbulla PASS – Regional Mentor Latam DPA - SolidQ http://geeks.ms/blogs/johnbulla - http://www.bdotnet.org
- 2. AGENDA • 00:00 - 00:05 Bienvenida/ Introducción moderador • 00:05 - 00:45 Presentación por el Speaker • 00:45 - 00:55 P&R Moderadas por el anfitrión • 00:55 - 01:00 Agradecimientos y cierre Gracias por Asistir
- 3. Asistencia Técnica • Asegúrate que todos estén en modo Mudo. • Por favor descarguen el cliente de Live Meeting. El cliente WEB no soporta Audio. • Clic en feedback (Parte superior derecha) y cambia tu estatus de color en caso de requerir apoyo del moderador. • Si tienes alguna pregunta, escríbela en el área de Preguntas & Respuestas.
- 4. Mantente conectado con nosotros • Te podrás registrar en todas las sesiones que tenemos planificadas a través de nuestro link http://bit.ly/SQLPASSVENEZUELA. • Cualquier cambio/actualización los mantenemos informados a través de nuestro sitio web www.venezuela.sqlpass.org y a través de nuestra cuenta en las redes sociales • Puedes contactarnos o escribir algo en Twitter a través de la cuenta @sqlpassve o postea con el tag #SQLPASSVE • Si tienes Facebook puedes seguirnos en la página de https://www.facebook.com/sqlpassvzla #SQLPASSVE
- 5. AGRADECIMIENTOS Agradecemos a nuestros patrocinadores por el apoyo a este evento y a SQL PASS VENEZUELA – Caracas Chapter José Redondo (Líder del Capítulo)
- 6. Capítulo SQL PASS Venezuela Caracas Chapter Líder: José G. Redondo López 4 miembros coordinadores y +15 colaboradores Somos una comunidad técnica de profesionales de SQL Server ubicada en la ciudad de Caracas, Venezuela Nos unimos con el fin de conectar, aprender y compartir nuestra experiencia en el campo profesional bajo la plataforma de datos SQL Server a través del intercambio de conocimientos e información apoyándonos para ello en eventos en línea, presenciales, uso de redes sociales, eventos regionales y locales. Trabajamos a la par con Microsoft y sus asociados para influenciar en la evolución de los productos y servicios de SQL Server. www.venezuela.sqlpass.org
- 8. AGENDA
- 9. INTRODUCCIÓN • Query Batch, Script, Batch Terminator
- 11. PLAN DE EJECUCIÓN • Table Scan
- 12. PLAN DE EJECUCIÓN • Clustered Index Scan
- 13. PLAN DE EJECUCIÓN • Clustered Index Seek
- 14. PLAN DE EJECUCIÓN • Index Seek
- 15. PLAN DE EJECUCIÓN • Index Scan
- 16. PLAN DE EJECUCIÓN • Joins (Neested Loop Join, Merge Join y Hash Join)
- 17. PLAN DE EJECUCIÓN • Agregaciones (Stream Aggregate, Hash Match)
- 18. PLAN DE EJECUCIÓN • Sort
- 20. PLAN CACHE • Parte de la memoria SQL Server que almacena los planes de ejecución que han sido preparados por el optimizador de consultas. Los planes de ejecución se utilizan para SQL Server ejecute sentencias SQL.
- 21. PLAN CACHE • sys.dm_exec_cached_plans • All Plans • Size • Use count • sys.dm_exec_query_plan(plan_handle) • Table Valued Function • SHOWPLAN XML as XML • sys.dm_exec_text_query_plan(plan_handle,0,-1) • Table Valued Function • SHOWPLAN XML as text
- 22. sys.dm_exec_cached_plans • Devuelve una fila para cada plan de consulta que SQL Server almacena en caché para agilizar la ejecución. Puede usar esta vista de administración dinámica para ver los planes de consulta almacenados en caché, el texto de las consultas almacenadas en caché, la cantidad de memoria que ocupan los planes y el contador de reutilización de los planes almacenados en caché. • bucketid, refcounts, usecounts, size_in_bytes, memory_object_address, c acheobjtype, objtype, plan_handle, pool_id
- 23. sys.dm_exec_query_plan(plan_handle) • Devuelve el plan de presentación en formato XML para el lote especificado por el identificador del plan. Este plan especificado por el identificador del plan puede estar almacenado en caché o ejecutándose. • dbid, objectid, number, encrypted, query_plan
- 24. sys.dm_exec_text_query_plan • Devuelve el plan de presentación en formato de texto para un lote Transact-SQL o para una instrucción concreta dentro del mismo. Este plan de consulta especificado por el identificador del plan puede estar almacenado en caché o ejecutándose. Esta función con valores de tabla es similar a sys.dm_exec_query_plan (Transact-SQL), pero tiene las diferencias siguientes: • El resultado del plan de consulta se devuelve en formato de texto. • El resultado del plan de consulta no está limitado en tamaño. • Se pueden especificar instrucciones individuales dentro del lote. • dbid, objectid, number, encrypted, query_plan
- 26. Resumen • Query Batch, Script, Batch Terminator • Planes de Ejecución • Plan Cache
- 28. RECURSOS Dissecting SQL Server Execution Plans By Grant Fritchey http://bit.ly/ebookPlanEjecucion SQL Server Execution Plans By Grant Fritchey http://bit.ly/ebookSQLPlanEjecucion
- 29. RECURSOS Inside the SQL Server Query Optimizer By Benjamin Nevarez http://www.benjaminnevarez.com/
- 32. Los invitamos al Charlotte, NC Octubre 15 -18 http://www.sqlpass.org/summit/2013/
- 33. Aplicando AlwaysOn Availability Groups en escenarios reales Fecha: Miercoles, Agosto 28 de 2013 - 12:30 Hora Venezuela Speaker: Edinson Medina. Regístrese en: http://bit.ly/SQLPASSVENEZUELA Descripción: Suministrar y consolidar las nuestras bondades de Alta Disponibilidad ofrecida por SQL Server 2012 a las empresas de hoy. Próximo Webcast
- 34. Muchas gracias por su participación
Notas del editor
- Un lote de consultas es un conjunto de instrucciones Transact-SQL que se envían a SQL Server para su ejecución en una sola llamada. Un lote puede contener uno o más estados, tales como los siguientes:• SELECT, INSERT, UPDATE, DELETE y MERGE• llamadas a procedimientos almacenados (EXEC)• Transact-SQL estructuras de control, como SET, IF, WHILE, DECLARE• instrucciones DDL como CREATE, DROP y ALTER• Estados de DCL como GRANT, DENY y REVOKEUna secuencia de comandos es un conjunto de uno o más lotes de consulta, separados por un terminador de lote. El más común terminador de lote es la palabra "GO". Es importante entender que el separador de lotes no es una instrucción de Transact-SQL y no tiene ningún significado para el motor de base de datos. Por ejemplo, considere el siguiente script: FiguraEl scritp contiene dos lotes. Cuando esta secuencia de comandos se ejecuta con una herramienta cliente como SQL Server Management Studio (SSMS), lo que podría parecer que la totalidad de la secuencia de comandos se envía al servidor para la ejecución, pero este no es el caso. SSMS divide la secuencia de comandos en lotes mediante la localización de la palabra. Líneas 1 a 3 se envían al motor de base de datos para ser ejecutado. Cuando finaliza la ejecución, las líneas 5 a 7 se envían al motor de base de datos para ser ejecutado.
- ELPlan de ejecución es el conjunto de pasos que tiene que realizar el motor para ejecutar la consulta.Cada vez que se ejecuta una consulta en un motor de bases de datos, el lote se compila en un plan e internamente se ejecutan una serie de operaciones, que varían según la consulta, los datos y obviamente, el motor de base de datos.
- Significa que el motor tiene que leer toda la tabla. Esto solo puede suceder cuando la tabla es Heap (o sea, no tiene un índice clustered). En algunos casos, cuando es una tabla chica, un TableScan es la mejor opción, ya que produce poco overhead. De hecho la tabla puede tener índices y sin embargo el SQL elige usar un tablescan porque sería más rápido. Pero cuando la tabla es más grande, no debería haber TableScan, ya que es muy costoso. Para solucionar este problema, hay ver si la tabla tiene índices y si se están usando correctamente. Lo importante es prestarle atención cuando vemos un tableScan. Muchas veces, nuestro problemas de performance pasan por ahí.
- Esta operación es muy similar a un tablescan. El motor recorre toda la tabla. La diferencia entre uno y otro, es que el ClusteredIndexScan se realiza en una tabla que tiene un índice Clustered y el TableScan en una tabla que no tiene este tipo de indice.Otra vez tenemos que evaluar si esta opción es la que realmente queremos. Muchas veces, por un mal uso de los índices, se ejecuta esta operación, cuando en realidad queríamos otra más eficiente.
- Si vemos esta operación, en general, podemos estar contentos. Significa que el motor está usando efectivamente el índice Clustered de la tabla.
- Aquí también si vemos esta operación, podemos estar contentos. Es similar que el ClusteredIndexSeek, pero con la diferencia de que se usa un indice Non Clustered.
- Aquí también si vemos esta operación, podemos estar contentos. Es similar que el ClusteredIndexSeek, pero con la diferencia de que se usa un indice Non Clustered.
- Un join es la relación entre 2 tablas. SQL tiene tres tipos de joins. NeestedLoopJoin, MergeJoin y Hash Join. Dependiendo de las características de la consulta y de la cantidad de registros, el motor puede decidir uno u otro.Ninguno es peor o mejor “per se”. Todo depende de las características de la consulta y del volumen de datos.NeestedLoopJoin: Suele ser generalmente el más frecuente. Es también el algoritmo más simple de todo. Este operador fisico es usado por el motor cuando tenemos un join entre 2 tablas y la cantidad de registros es relativamente baja. Tambien aplica con cierto tipo de joins (crossjoins por ejemplo).MergeJoin: Otro de los tipos de join que existen. Generalmente se usa cuando las cantidades de registros a comparar son relativamente grandes y están ordenadas. Aun si no están ordenadas, el motor puede predecir que es más rápido ordenar la tabla y hacer el mergejoin que hacer un NeestedLoopJoin. En muchas situaciones es frecuente ver que una consulta anteriormente usaba NeestedLoopJoin y en algún momento paso a usar un MergeJoin. La razón de esto, es porque el volumen de datos aumento y por lo tanto, es mas optimo usar un Mergejoin.Hash Join: Otro tipo más de join que existe. Mientras que los LoopJoins trabajan bien para conjuntos chicos de datos y los mergejoin para conjuntos moderados de datos, el hash join es especialmente útil en grandes conjuntos de datos, generalmente en datawarehouses. Este operador es mucho mas paralelizable y escalable. También se usa generalmente cuando las tablas relacionadas no tienen índice en ninguna de los campos a comparar. Hay que prestar atención si vemos este tipo de operaciones, ya que puede significar un mal uso de los índices. Sin embargo, los hash joins consumen mucha memoria y SQL Server tiene un límite en la cantidad de operaciones de este tipo que puede efectuar simultáneamente.
- Agregaciones:Las agregaciones refieren a agrupar un conjunto grande de datos en un conjunto de datos más chico.StreamAggregate: Este tipo de operaciones ocurre cuando hay se llama a un función de agregación, como MIN, COUNT, MAX, SUM, etc. El operador StreamAggregate requiere que la información esté ordenada por las columnas dentro de sus grupos. Primero, el optimizador ordenará si los datos no están ordenados por un operador Sort anterior. En cierta manera, el StreamAggregate es similar al MergeJoin, en cuanto a en que situaciones se produce.Hash Match (Aggregate): Hay que tener cuidado cuando vemos este operador. Esta operación también ocurre cuando se llama a funciones de agregación del tipo MIN, COUNT, AVG, etc. Así como el StreamAggregate es comparable al MergeJoin, el Hash Match Aggregate es similar al Hash Join. Lo que hace internamente es armar una tabla de hash. En situaciones donde la cantidad de registros es elevada o no se están indexadas las columnas por las cuales agrupa la consulta, el motor del SQL va a elegir esta operación.
- Agregaciones:Las agregaciones refieren a agrupar un conjunto grande de datos en un conjunto de datos más chico.StreamAggregate: Este tipo de operaciones ocurre cuando hay se llama a un función de agregación, como MIN, COUNT, MAX, SUM, etc. El operador StreamAggregate requiere que la información esté ordenada por las columnas dentro de sus grupos. Primero, el optimizador ordenará si los datos no están ordenados por un operador Sort anterior. En cierta manera, el StreamAggregate es similar al MergeJoin, en cuanto a en que situaciones se produce.Hash Match (Aggregate): Hay que tener cuidado cuando vemos este operador. Esta operación también ocurre cuando se llama a funciones de agregación del tipo MIN, COUNT, AVG, etc. Así como el StreamAggregate es comparable al MergeJoin, el Hash Match Aggregate es similar al Hash Join. Lo que hace internamente es armar una tabla de hash. En situaciones donde la cantidad de registros es elevada o no se están indexadas las columnas por las cuales agrupa la consulta, el motor del SQL va a elegir esta operación.
- La compilación es el proceso de crear un plan elaborado a partir de un lote de consultas.Cuando el motor de base de datos se inicia la ejecución de un plan elaborado, en primer lugar comprueba que el plan sigue siendo válido y óptima. Si cualquiera de estas comprobaciones falla, la declaración correspondiente al plan de consulta o el lote completo se compila de nuevo. Estas compilaciones son conocidos como "recopilaciones".La elaboración de los planes de ejecución es una operación relativamente costosa, así que los desarrolladores del producto hicieron un intento de evitar estas costosas operaciones, realizando almacenamiento en caché de los planes compilados en una región de memoria de SQL Server denominada el plan cache. Si necesita otro lote de consultas para ser ejecutado, SQL Server busca en la caché del plan para posibles oportunidades de reutilización del plan. Si se logra la reutilización del plan, se evitan los costos de compilación.
- La compilación es el proceso de crear un plan elaborado a partir de un lote de consultas.Cuando el motor de base de datos se inicia la ejecución de un plan elaborado, en primer lugar comprueba que el plan sigue siendo válido y óptima. Si cualquiera de estas comprobaciones falla, la declaración correspondiente al plan de consulta o el lote completo se compila de nuevo. Estas compilaciones son conocidos como "recopilaciones".