Optimiza tus queries desde abajo

1. Enrique Catalá Bañuls MAP/MCT/MCITP/MCTS Optimiza tus queries desde abajo

2. • Ingeniero Informático • Mentor en Solid Quality Mentors • Microsoft Active Professional 2010 • Microsoft Certified Trainer • Microsoft Certified IT Professional – Database Developer 2008 – Database Administrator 2008 • Arquitecto de entre otros Health Check y SCODA ¿Quién es Enrique Catala?

3. Agenda Optimiza desde abajo SQLU Summit • Entender el motor de consulta relacional • Planes de ejecución – Leer planes de ejecución – Foco especial en los operadores join • Trucos prácticos – Estrategias y situaciones que conviene conocer

4. El optimizador de consultas SQLU Summit • Encargado de planificar la navegación de los datos almacenados físicamente • Debe tener numerosas variables en cuenta: – ¿Qué objetos están involucrados? – ¿Qué tamaño tienen? (si son tablas) – ¿Qué índices y estadísticas hay definidos para ellos? – ¿Cómo está dispuesta la información físicamente? – ¿Qué operadores se utilizarán? – … • Puede producir N^n soluciones posibles • Es el culpable de que en cada versión, nuestro código sea más rápido.

5. Query plan vs execution context SQLU Summit • Query plan (conocido como «plan de ejecución») – Método de acceso (El «algoritmo» por decirlo de alguna forma) – Depende del patrón de consulta – Solo lectura y reentrables – Compartido con múltiples usuarios – Dos versiones en ocasiones • Versión en serie • Versión paralela • Execution context (conocido como «contexto de ejecucion») – Lo que se ejecuta finalmente y obtiene resultados – Depende de los valores de parámetros – Son reutilizables pero no reentrables – Dependen completamente del user token y login token • Mismos parámetros crean execution contexts diferentes con distintos usuarios

6. ¿Se puede descartar un plan de ejecución? SQLU Summit • El valor de un plan de ejecución que se decrementa, se calcula en nº de ticks y tiene un valor máximo de 31, de forma que: – COSTE = (coste E/S) + (coste cambio contexto CPU) + (coste memoria) – Siendo • Dos operaciones E/S = 1 tick (máximo 19) • Dos cambios de contexto CPU = 1 tick (máximo 8) • 128kb necesario = 1 tick (máximo 4) – Para ad-hoc siempre es 0 y se incrementa en 1 cada vez que se reutiliza • A partir de 2005 existe separación data-cache y plan-cache y lazywritter solo decrementa data-cache por lo que… – Tan pronto se llega al 50% del tamaño disponible para el buffer pool, el siguiente plan de ejecución nuevo que entra en el plan-cache, decrementa una unidad el contador de todos los planes de ejecución que existan en el plan-cache. – Si se llega al 75% del tamaño, se activa un gestor de recursos que decrementa el contador de todos los planes de ejecución en 1

7. ¿Qué afecta a los planes de ejecución? SQLU Summit • Tipo de ejecución – Consultas ad-hoc – Procedimientos almacenados • Tienen en cuenta – Valores dados a los filtros y variables en su creación – Estadísticas • No tienen en cuenta – Bloqueos en curso – Uso de memoria en curso • Les afecta y mucho la presión de CPU select occurrence from sys.dm_exec_query_optimizer_info where counter = 'timeout'

8. Nested loops SQLU Summit • Pseudocódigo • Operador join mas simple • Doble bucle • … R1 inner join R2 … for each row R1 in the outer table for each row R2 in the inner table if R1 joins with R2 return (R1, R2)

9. Hash join SQLU Summit • Ejecución en dos fases – Build: Cálculo de clave hash del inner – Prueba: Lee la outer, crea su hash y compara con hash precalculado en fase build • Si se estima menos memoria para hash, aparecen los hash warnings y carga en tempdb for each row R1 in the build table begin calculate hash value on R1 join key(s) insert R1 into the appropriate hash bucket end for each row R2 in the probe table begin calculate hash value on R2 join key(s) for each row R1 in the corresponding hash bucket if R1 joins with R2 return (R1, R2) end

10. Merge join SQLU Summit • Pseudocódigo versión uno a muchos • Lee simultáneamente las dos entradas get first row R1 from input 1 get first row R2 from input 2 while not at the end of either input begin if R1 joins with R2 begin return (R1, R2) get next row R2 from input 2 end else if R1 < R2 get next row R1 from input 1 else get next row R2 from input 2 end

11. Operadores de join SQLU Summit • Nested Loops: – Útiles para conjuntos pequeños de resultados. – Su eficiencia depende del producto de tabla inner (arriba) * tabla outer (abajo) – Puede escupir resultados inmediatamente – soporta cualquier tipo de join – Es el que más frecuentemente se encuentra – Es altamente ineficiente si los conjuntos de datos son grandes • Merge join: – Util para conjuntos relativamente medianos de resultados. – Es el mejor cuando hablamos de grandes valores de datos en tabla inner y outer porque su eficiencia depende de la suma de filas de ambas tablas – Puede escupir resultados inmediatamente – Solo soporta equijoin – Los datos deben ser ordenados "the inputs to the merge join must be sorted on the join keys. For example, if we have a join predicate “T1.a = T2.b,” table T1 must be sorted on T1.a and table T2 must be sorted on T2.b" • Hash join: – Util para grandes conjuntos de resultados no ordenados y cuando la tabla que manda (inner) tiene sustancialmente menos filas que la dependiente. – Hasta no estar todo calculado, no escupe resultados – Ineficiente si las dos tablas son muy grandes – Su existencia indica: • Falta un índice o el que existe no nos sirve • Falta WHERE • Alguna condicion no satisface al indice (en caso de haberlo) por culpa de algun calculo o algo... Podemos forzar su uso

12. ¿Qué información me da un operador? SQLU Summit

14. Herramientas de análisis de rendimiento SQLU Summit • Monitor de rendimiento • SQL Server profiler – Trazas de servidor • DMVs y DMFs • Eventos extendidos • Books Online 

15. Mejorar escenarios ad-hoc (I) SQLU Summit • Optimize for ad-hoc workloads – A nivel de instancia de SQL Server – Solo útil para consultas ad-hoc livianas – Almacena un pequeño código auxiliar en lugar del plan completo – Minimiza presión sobre el cache de planes de ejecución – Solo si se detecta reutilización, se recompila y almacena en cache

16. Mejorar escenarios ad-hoc (II) SQLU Summit • Force parametrization – A nivel de base de datos – Ocurre por cada statement. Cada batch puede tener múltiples statements autoparametrizados – Fuerza la parametrización de toda sentencia SELECT, UPDATE, INSERT y DELETE – En ciertos escenarios, mejora enormemente el rendimiento a base de reutilización de planes de ejecución • PRECAUCIÓN: Testear siempre el entorno antes de poner en producción. Puede que salgamos perdiendo…¿alguien sabe por qué?  Excepciones  Statements dentro de SP, funciones,…  Si ANSI_PADDING o ANSI_NULL = OFF  Statements que referencian variables  Statements en cursor

18. Vaciar plan cache SQLU Summit • ALTER DATABASE [dbName] SET ONLINE • ALTER DATABASE [dbName] SET OFFLINE • ALTER DATABASE [dbName] SET READ_ONLY • ALTER DATABASE [dbName] SET READ_WRITE • ALTER DATABASE [dbName] MODIFY NAME = [SomeDB_Name] • ALTER DATABASE [dbName] MODIFY FILEGROUP Test1FG1 DEFAULT • ALTER DATABASE [dbName] MODIFY FILEGROUP Test1FG1 READ_WRITE • ALTER DATABASE [dbName] MODIFY FILEGROUP Test1FG1 READ_ONLY • ALTER DATABASE [dbName] COLLATE Collation_Name • DROP DATABASE [db_Snapshot_Name] • DBCC FREEPROCCACHE • DBCC FREESYSTEMCACHE • • OJO: En SQL Server 2005 RTM y SP1, DBCC CHECKDB limpia el plan cache PARA LA INSTANCIA DE SQL SERVER!!!

19. Compilaciones y recompilaciones SQLU Summit • Hay que evitar siempre compilaciones y recompilaciones – Consumo excesivo de CPU y memoria – Mayor tiempo de respuesta

21. Agregación de consultas SQLU Summit • Es lo que debemos hacer siempre de cara a una primera optimización. • Antes de SQL Server 2008 – Procesos externos como nuestro HealthCheck • A partir de SQL Server 2008 – Ahora además, podemos hacer uso de DMVs • Sys.dm_exec_query_stats • Columnas – Query_hash » Hash calculado en la consulta…util para identificar consultas con lógica similar (lo que hace HealthCheck) » Util para buscar consultas con literales diferentes – Query_plan_hash » Hash calculado del plan de ejecución » Util para buscar planes de ejecución similares – NOTA: esto solo captura desde la última ejecución de SQL Server

22. Un ejemplo de lo que debemos buscar SQLU Summit 11% 1% 18% 69% 0% 0% 0% 1% % of memory used Compiled Plan Proc Compiled Plan Trigger Compiled Plan Adhoc Compiled Plan Prepared Extended Proc Proc Parse Tree UsrTab Parse Tree Check Parse Tree View Database Name Cached Pages Memory (MB) BBDD1 588.870 4600,55 BBDD2 98.906 772,7 tempdb 2.889 22,57 msdb 1.149 8,98 BBDD3 327 2,55 BBDD4 174 1,36 BBDD5 138 1,08 master 54 0,42 BBDD6 35 0,27 BBDD7 30 0,23 model 1 0,01 AdventureWorks 1 0,01 ReportServer 1 0,01 AdventureWorksDW 1 0,01 ReportServerTempDB 1 0,01

23. Indexación SQLU Summit • Tareas que debemos realizar – Búsqueda de índices faltantes – Búsqueda de índices que no se usan – Búsqueda de índices duplicados – Comparación de índices clústered vs nonclustered – Quitar siempre key y RID lookups • Filtrar índices si es necesario • No aplicar funciones a columnas de índice • No utilizar predicados tipo like ‘%...’ • Cuidado con los predicados: (a,b) requiere buscar por a como mínimo. • Pregunta: ¿En un índice definido por la tupla (a,b), si no se hace referencia a «a», se utilizará el índice?

24. Los 10 mandamientos del rendimiento SQLU Summit • Amaras a los procedimientos almacenados sobre todas las cosas • No aplicarás una función de SQL server en vano • Santificarás los índices • Honrarás las claves ajenas y las restricciones check • SI matarás a cursores y consultas ad-hoc • Cometerás agregación de consultas • No robarás ciclos de CPU mediante recompilaciones • No levantarás tablas variables cuando deberían ser temporales • No consentirás el uso de query hints sin conocimiento de causa • No codiciaras un SELECT *

25. Mas información • El rincón del DBA – http://blogs.solidq.com/ElRinconDelDBA/Home.aspx • BI Corner – http://blogs.solidq.com/BICorner/Home.aspx • SolidQ SharePoint Team Blog – http://blogs.solidq.com/sharepoint • CuevaNet – http://blogs.solidq.com/cuevanet • Todos los Blogs – http://blogs.solidq.com

27. 24 HOP LATAM - PATROCINADORES http://www.idera.com/

Optimiza tus queries desde abajo

Optimiza tus queries desde abajo

Recommended

More Related Content

Similar to Optimiza tus queries desde abajo

Similar to Optimiza tus queries desde abajo(20)

More from Enrique Catala Bañuls

More from Enrique Catala Bañuls(20)

Recently uploaded

Recently uploaded(11)

Optimiza tus queries desde abajo