Diagnostico y resolución de problemas en sql server
•Als PPTX, PDF herunterladen•
0 gefällt mir•2,925 views
En mi día a día como consultor me encuentro con una gran variedad de problemas relacionados directa o indirectamente con SQL Server. El diagnóstico de las causas reales de estos problemas suele requerir analizar tanto el hardware como el software de la plataforma. Presentar el diagnóstico y la resolución de problemas reales así como los procesos y herramientas utilizadas es el objetivo de esta sesión.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Diagnostico y resolución de problemas en sql server
Ähnlich wie Diagnostico y resolución de problemas en sql server (20)
Mehr von SpanishPASSVC
Mehr von SpanishPASSVC (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Diagnostico y resolución de problemas en sql server
- 1. Diagnostico y resolución de problemas en SQL Server 30-04-2014 Enrique Catalá Bañuls MVP | MCT | MCITP | MCTS Mentor SolidQ PASS Spain, Guse.NET (@enriquecatala) www.enriquecatala.com
- 2. Agenda 2 1. Diagnostico de problemas en SQL Server • Waitstats • Caché de procesos • Tempdb • Indexación • Detección de consultas ineficientes 2. Resolución de problemas reales • Particionado y agregaciones • Paralelismo y consumos de CPU • Serialización en vistas indexadas • Encriptación
- 3. Diagnostico de problemas Herramientas 3 Extended events Performance monitor Profiler DMVs • Waits statistics • FileIO Revisión completa con HealthCheck
- 4. Waitstats Caso real 4 CXPACKET, 54% LATCH_EX, 17% ASYNC_NETWORK_IO, 9% PAGEIOLATCH_SH, 6% WRITELOG, 5% SOS_SCHEDULER_YIELD, 3% Total esperas CXPACKET LATCH_EX ASYNC_NETWORK_IO PAGEIOLATCH_SH WRITELOG SOS_SCHEDULER_YIELD BACKUPIO SLEEP_BPOOL_FLUSH CMEMTHREAD LCK_M_U PAGEIOLATCH_EX BACKUPBUFFER sys.dm_os_latch_stats
- 5. Cache de procesos Estado inicial 5 Cacheobjecttype ObjType Nº de entradas % de entradas Memoria (kb) % uso memoria Compiled Plan Proc 39.727 9,77 317.816 9,77 Compiled Plan Trigger 153 0,04 1.224 0,04 Compiled Plan Adhoc 294.421 72,43 2.355.368 72,43 Compiled Plan Prepared 56.607 13,93 452.856 13,93 Extended Proc Proc 19 0 152 0 Parse Tree UsrTab 139 0,03 1.112 0,03 Parse Tree Check 110 0,03 880 0,03 Parse Tree View 15.379 3,78 123.032 3,78 10% 0% 72% 14% 0% 0% 0% 4% % 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
- 6. Caché de procesos Estado inicial 6 15183 planes de ejecución con una única entrada 1172Mb de 3560Mb no se reutilizan
- 7. Caché de procesos Solución “de emergencia” propuesta 7 “optimize for adhoc workload” “forced parametrization” para las BBDD relevantes
- 8. Cache de procesos Después del cambio 8 Cacheobjecttype ObjType Nº de entradas % de entradas Memoria (kb) % uso memoria Compiled Plan Proc 49668 10,78 397344 10,8 Compiled Plan Trigger 24 0,01 192 0,01 Compiled Plan Adhoc 198899 43,17 1591192 43,25 Compiled Plan Prepared 191353 41,54 1530824 41,61 Extended Proc Proc 11 0 88 0 Parse Tree View 20337 4,41 162696 4,42 Parse Tree Check 48 0,01 384 0,01 Parse Tree UsrTab 673 0,15 5384 0,15
- 9. Cache de procesos Después del cambio 9 uses number_ocurrenciescacheobjtype percentage_uses percentage_memory_KB 1 6583 Compiled Plan 10,56 30,57 1 6 Parse Tree 0,01 0,01 1 13123 Compiled Plan Stu 21,05 0,00 2 3525 Compiled Plan 5,66 8,04 2 653 Parse Tree 1,05 2,36 3 2710 Compiled Plan 4,35 4,69 3 11 Parse Tree 0,02 2,85 3 1 Compiled Plan Stu 0,00 0,02 4 139 Parse Tree 0,22 0,43 4 2163 Compiled Plan 3,47 0,00 5 1998 Compiled Plan 3,21 1,98 5 41 Parse Tree 0,07 0,34 6 3578 Compiled Plan 5,74 2,03 6 333 Parse Tree 0,53 1,06 6 2 Extended Proc 0,00 0,00 7 2164 Compiled Plan 3,47 1,49 7 14 Parse Tree 0,02 0,04 8 1010 Compiled Plan 1,62 0,90 8 118 Parse Tree 0,19 0,36 9 1113 Compiled Plan 1,79 0,81 9 8 Parse Tree 0,01 0,02 10 836 Compiled Plan 1,34 0,68
- 10. Caché de procesos Forced parametrization 10 “forced parametrization” no siempre ayuda Ejemplo: Número de parámetros variable Select * from tabla where param1 in (1,2,3,...,10) and param2 in (1,2,3,...,10) and param3 in (1,2,3,...,10) 1000 parametrizaciones posibles baja probabilidad de reutilización del plan
- 11. Caché de procesos Forced parametrization 11 “forced parametrization” no siempre ayuda (II) Ejemplo: Rangos de fechas Select * from tabla where fechainicio between '20130601' and '20130602' SPs / Optimize for / Optimize for unknown / Planes de guiado…
- 12. Tempdb Mala configuración ¿Alguien sabe a qué es esto debido? 12
- 13. Indexacion Cuando 5437 índices duplicados no usados…deberían decirnos “BASTA!” 13
- 14. Detección de consultas ineficientes ¿Por qué es importante? TSQL-CSI 14 El escenario siempre es tan complejo que nadie sabe la causa de dónde está el problema Método infalible: La agregación de consultas • Encontrar patrones T-SQL que producen mayor presión a SQL Server • No buscamos la consulta lenta, buscamos el patrón de consultas que mas hace sufrir al servidor Generalmente el cliente siempre se lleva sorpresas Consulta A: Tiempo de ejecución 5s y 5 ejecuciones en 10 minutos Consulta B: Tiempo de ejecución 300ms y 1000 ejecuciones en 10 minutos
- 15. Detección de consultas ineficientes ¿En qué nos fijamos? TSQL-CSI 15 11% 1% 18% 69% 0% 0% 0% 1% % of memory used Compiled Plan Proc Compiled Plan Trigger Compiled Plan Adhoc Compiled Plan Prepared 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
- 16. Agenda 16 1. Diagnostico de problemas en SQL Server • Waitstats • Caché • Tempdb • Indexación • Detección de consultas ineficientes 2. Resolución de problemas reales • Particionado y agregaciones • Paralelismo y consumos de CPU • Serialización en vistas indexadas • Encriptación
- 18. Vistas indexadas 18 Queries de tipo analítico sobre un modelo normalizado • Data marts • Data warehouses • Data mining Operaciones candidatas • Joins y agregaciones de tablas grandes • Agregaciones dinámicas sobre agregaciones previas Evaluar el coste/beneficio
- 19. Serialización en vistas indexadas 19 Una vista indexada es un tipo de índice muy distinto al resto Escenarios con un ratio de lectura respecto a escrituras elevado Si es posible, reducir la vista indexada a un subconjunto de la vista original • Disminuir el número de tablas implicadas en la vista suele reducir la frecuencia de actualización de ésta Potenciales zonas críticas + serialización de las actualizaciones • Escenarios con escritura controlada Concurrencia baja • Importante si la operación forma parte de otro proceso más complejo • Timeout Rollback Reintentos = Combinación explosiva
- 20. Vistas indexadas Resultados demo (Tamaño del batch y número de vistas) 21
- 25. Vistas indexadas Resultados vistas indexadas 26 Si tenemos vistas indexadas • Si las inserciones son de 1 única fila • Tiempo de respuesta empeorará con la concurrencia • Especialmente comparados con el escenario sin vista indexada • Tiempo total disminuirá con mayores grados de concurrencia • Conclusión: Nos conviene paralelizar si el tiempo total del proceso es crítico • Si las inserciones son de bastantes filas (>1000) • Tiempo respuesta muy variable si añadimos concurrencia • Tiempo total muy similar entre distintos grados de concurrencia • Zona crítica tiene un peso importante en el plan de ejecución • Conclusión: Conviene orquestar y serializar las operaciones
- 26. Vistas indexadas Recomendaciones vistas indexadas 27 Minimizar su uso dentro de lo posible Utilizarlas únicamente en escenarios muy favorables a su uso • Tener claras sus limitaciones e impacto en operaciones DML • Utilizar la herramienta apropiada ETL+DW, Analysis services, PowerPivot … Reducir la concurrencia de las operaciones masivas • Procesos batch/sincronizados • Utilizar una vista indexada particionada y alineada (2008+) • Muy restrictivo Alineación de todos índices/tablas, agregar solo a nivel de 1 partición • No suele ser aplicable cuando queremos agrupaciones distintas • Crear un particionado no nativo adaptado a la carga
- 27. Vistas indexadas Esquema de un único nivel 28 Tabla particionada Vista indexada particionada Tabla 1 Vista indexada 1 Insert1 Tabla 2 Tabla 3 Tabla 4 Vista indexada 2 Vista indexada 3 Vista indexada 4 Vista particionada Insert2 Insert3 Insert4
- 28. Vista particionada Esquema de dos niveles 29 Tabla 1 Vista indexada 3_1 Insert1 Tabla 2 Tabla 3 Tabla 4 Vista indexada 3_2 Vista indexada 4_1 Vista indexada 4_2 Vista particionada Insert2 Insert3 Insert4 Vista indexada 1_1 Vista indexada 1_2 Vista indexada 2_1 Vista indexada 2_2
- 29. Encriptación Clásica y transparente (TDE) 30 TDE • Sencilla de implementar, activar y listo • Rendimiento bueno si tenemos que encriptar toda la base de datos • No permite trasladar a la capa de aplicación la encriptación de datos Clásica • Mayor coste de CPU en el servidor de base de datos escalabilidad • Encriptación en la capa de negocio • Dificultad para implementar los cambios en código necesarios • Problemas si los campos encriptados se usan en búsquedas • Indexación alternativa
- 30. Encriptación clásica 31 Service master key Master Key Certificate • DECRYPTBYCERT • ENCRYPTBYCERT • Encriptación asimétrica no recomendable por rendimiento Symmetric Key OPEN SYMMETRIC KEY + CLOSE SYMMETRIC KEY • DECRYPTBYKEY • ENCRYPTBYKEY DecryptByKeyAutoCert • Equivale a OPEN SYMMETRIC KEY + DECRYPTBYKEY + CLOSE SYMMETRIC KEY • Ojo con encapsularla dentro de una función escalar y llamarla N veces
- 31. DEMO 32 Técnicas de indexación con columnas encriptadas
- 32. Indexación de columnas encriptadas Resultados demo 33 Con una buena estrategia auxiliar, el coste de desencriptar un registro es casi despreciable
- 33. Indexación de columnas encriptadas Resultados demo 34 Para rangos con muchos registros el rendimiento va a ser un problema
- 34. Manténgase conectado a nosotros! 35 Visítenos en http://globalspanish.sqlpass.org /SpanishPASSVC lnkd.in/dtYBzev
- 35. Programa de Reconocimiento Programa de Voluntario Sobresaliente • PASS le invita a nominar a su voluntario favorito para ser “Voluntario Sobresaliente del Mes” • Enviar nominaciones en todo momento a: VolunteerRecognition@sqlpass.org Favor proveer: • Información de contacto del nominado, • una lista breve de los programas de PASS que a participado el nominado • los años que lleva activo en la comunidad • una corta descripción por el cual considera que esta persona debe ser reconocida • Los nominados seleccionados serán anunciados en la edición del boletín PASS Connector y recibirán un certificado de apreciación.
- 36. JOIN US for our second annual event to get the best learning for analyzing, managing, and sharing business information and insights through the Microsoft Data Platform of technologies.
- 37. http://www.sqlpass.org/summit/2014 November 4 - 7 | Seattle, WA
- 38. Manténganse Conectados! • Solicite su suscripción gratuita en sqlpass.org • Linked In: Professional Association for SQL Server • Facebook: Professional Association for SQL Server Group • Twitter: @SQLPASS • The PASS Blog: sqlpass.org
Hinweis der Redaktion
- Todo esto en healthcheck
- RUBENLa primera de ellas está relacionada con el grado de paralelismo que hay configurado en SQL Server. Este tipo de espera indica que el servidor está esperando demasiado tiempo a realizar sincronización de consultas paralelas, lo cual suele ser síntoma de que el grado de paralelismo de las consultas no está ajustado correctamente. La máquina de producción tiene 4 nodos NUMA por lo que se recomienda 16/4 = establecer el grado de paralelismo a 4 para evitar que en el caso de tener que crear un plan de ejecución paralelo, que se acceda fuera del nodo NUMA para realizar esa sincronización de threads.No es raro tampoco que existan esperas por LATCH_EX (esperas por latch exclusivas en memoria) puesto que es habitual ver este tipo de espera en sistemas que sufren excesivo paralelismo. Este valor suele indicar también contención en las primitivas de sincronización de memoria. Su valor disminuirá también cuando se configure el grado máximo de paralelización.ASYNC_NETWORK_IO esta asociado a latencia de la red. Este tipo de esperas suceden cuando la red no es capaz de dar soporte a la demanda de transferencia de datos que requiere SQL Server. También sucede cuando se están enviando demasiados datos, lo cual hace que el cliente no los pueda procesar, o porque hay algún problema de red entre el servidor y algún cliente. Este tipo de esperas están relacionados directamente con aplicaciones que no utilizan paginación (esto es, devuelven un gran volumen de información, a pesar de que solo utilizan un pequeño conjunto de ellos). La única manera de mejorar esto es que se comience a plantear una arquitectura pensada con paginación en las consultas.Cabe mencionar que una vez se eliminen de la ecuación CXPACKET (al disminuir el grado de paralelismo en la instancia) aparecerán otros como el SOS_SCHEDULER_YIELD. Esta espera indica que se han producido esperas por competición de ciclos de CPU por cargas bulk load que se ejecutan en el mismo SQL_OS. Se recomienda por tanto validar si existe algún solapamiento de cargas masivas que superan el nº de cores del servidor. Puede que se trate simplemente de cambiar horas de planificación de las mismas. En cualquier caso, habría que mejorar el grado de paralelismo y disminuir CXPACKET, lo cual puede modificar el esquema anterior y que aparezcan otros tipos de esperas. Ver el siguiente punto.
- ENRIQUEImaginemos que entramos a realizar un tuning y vemos esto.¿qué propondrías? Pues lo primero es mirar cuantos planes de ejecución NO se están reutilizando, para ver la memoria malgastadaEn primer lugar, llama la atención que existe un 72% de uso de memoria destinado a planes de ejecución ad-hoc. Esto es debido efectivamente a que existe una grandísima cantidad de consultas que las aplicaciones generan y lanzan al vuelo y sin parametrizar.Esta situación conlleva los siguientes problemas:Uso ineficiente de la memoria ( excesivo trasiego )Una consulta genera su plan de ejecución utilizando CPU y requiriendo memoria para ello.Se resuelve la consultaLa memoria no se vuelve a reutilizar, pasando a un round-robin que va “envejeciendo” los planes de ejecución no reutilizados.Tiempo de respuesta a peticiones más elevado de lo necesario, puesto que consultas que podrían reutilizar el plan de ejecución no lo están haciendo por realizarse de forma ad-hoc.En definitiva, el servidor de base de datos no será capaz de escalar correctamente ante un incremento de carga posible futuro.
- ENRIQUE¿qué podemos hacer al ver esto?“optimizefor ad hoc workload” a nivel de instancia, reducirá el consumo de cada entrada ad hoc a 300 bytes. Solo en el caso de que SQL Server detecte que la entrada se reutiliza, pasará a almacenar su plan de ejecución. De esta forma, no evitamos recompilaciones, sino reducir todo lo que podamos desde configuración de servidor, la información no reutilizable de esos 1172Mb.
- ENRIQUEEn la línea del punto anterior, existe una opción a nivel de base de datos que fuerza la parametrización de consultas ad hoc que llegan a la base de datos, para que sea SQL Server el que automáticamente haga dicha labor por nosotros. Desgraciadamente existen numerosas restricciones para ello que impiden normalmente el beneficio asociado a dicha característica (sigue siendo imprescindible que sea la aplicación quien prepare las consultas mediante sp_executesql) por lo que su aplicación no debe tomarse como algo a tener siempre presente.De esta forma, se obtuvo una lista con las bases de datos que mayor número de planes de ejecución no reutilizados tenían, así como la memoria que se ocupaba en cada uno de ellos obteniéndose la siguiente tabla
- ENRIQUE% de memoria ocupada por planes de ejecución ad-hoc ha disminuidoal 43% debido en gran parte a que la memoria ocupada por planes de ejecución con 1 solo uso ahora ocupa mucho menos (300bytes). Por otro lado, debido a la parametrización forzada, se ha incrementado la memoria de planes de ejecución preparados, lo cual es también buena noticia.ahora existen 13123 entradas como “Compiled Plan Stub”, que son precisamente los planes de ejecución de 1 solo uso que han pasado a ocupar 300 bytes (por eso tan poca utilización de memoria aunque sean el 21% de las entradas de caché)
- ENRIQUEvemos que ahora existen 13123 entradas como “Compiled Plan Stub”, que son precisamente los planes de ejecución de 1 solo uso que han pasado a ocupar 300 bytes (por eso tan poca utilización de memoria aunque sean el 21% de las entradas de caché)Desgraciadamente, seguimos viendo como existe un 30% de la memoria destinada a planes de ejecución, a planes de ejecución que no se reutilizan (1 solo uso). Estos planes de ejecución son aquellos planes de ejecución que por su propia definición, no se pueden parametrizar automáticamente (existen numerosas restricciones). Para eliminar el problema, la única solución pasa ya por tanto por la recodificación de las aplicaciones que hacen uso de ejecución de código dinámico, para su parametrización.
- RUBENExplicar que el objetivo es buscar que se reutilicen los planes
- RUBENExplicar que el objetivo es buscar que se reutilicen los planes y que el plan sea suficientemente bueno
- RUBENWe pay attention that tempdb has a good number of files (8 files) but as you can see, only the first file (tempdev) is used…and is heavily usedAction: Put the same initial size to all the tempdb files and restart SQL Server
- ruben
- RUBEN Detección de patrones de consulta ineficientesLa primera y más importante tarea que debe llevarse a cabo a la hora de optimizar un sistema es encontrar qué hay que optimizar, puesto que en la mayoría de situaciones, el escenario es tan complejo que nadie a priori sabe donde está la raíz del problema y por tanto qué hay que mejorar.En este apartado, vamos a centrarnos en el análisis de qué peticiones están produciendo mayor carga en el servidor y por tanto, dónde debemos centrar nuestra atención.Uno de las primeras acciones que realizamos desde SolidQ cuando realizamos un proyecto de optimización de base de datos, consiste en lo que denominamos “agregación de consultas”.
- RUBEN
- 00:05Comentar que la zona crítica de actualización afecta mucho más que los índices normales ya que acaba actualizando un resultado agrupado que puede incluir información de muchas filas en unaConcurrencia de operaciones con muchas filas hace que las actualizaciones de las vistas indexadas acaben
- Con batch de 1 fila, la concurrencia mejora el tiempo total en todos los casos
- Con batch de 100, no hay una mejora clara con concurrenciaCon 10000 la concurrencia empeora el tiempo total
- Desviación típica aumenta con la concurrenciaEspecialmente cuando hay vistas indexadas
- TimeoutsRollbacksReintentos