Estadísticas
Las estadísticas son sentencias sobre patrones observados en datos de rendimiento SQL históricos que son consistentes con determinados tipos de problemas o eventos interesantes. Estos Insights se calculan diariamente, y en particular, no son declaraciones de hechos, sino señales indirectas que son consistentes con ciertos tipos de hechos.
Por ejemplo, la información detallada de plan change busca una secuencia de observaciones con un hash de plan seguido de una secuencia de observaciones con otro hash de plan, para un SQL_ID determinado diariamente. Esto es consistente con el caso común del optimizador de consultas que utiliza un único plan para SQL_ID y, a continuación, cambia a otro plan. Es imperfecto porque los datos recopilados solo registran el plan en uso en el momento de la recopilación, cada 30 minutos. Es posible que se hayan utilizado muchos planes que no se hayan registrado, pero ese no es el caso común.
- Estadísticas a nivel de flota
- Estadísticas a nivel de bases de datos
- Estadísticas a nivel de SQL
Estas regiones de widgets le permiten explorar y comprobar rápidamente las estadísticas en un solo lugar, con un simple widget de comunicación visual estandarizado. En estas estadísticas, los indicadores de color muestran los siguientes estados:
- Gris: Insight no detectado.
- Azul: Insight detectado, probablemente no problemático.
- Naranja: Insight detectado, podría ser problemático.
| Análisis detallado | Casos prácticos | Análisis y salida | Notas: |
|---|---|---|---|
| Cambios de plan | ¿Alguna base de datos tiene más de unos pocos cambios de plan?
¿Cuántos? |
Recuento de bases de datos con estadísticas de cambio de plan a lo largo del período. | Indicador de estado de mosaico de estadísticas:
La ausencia de cambios en el plan debe indicar estabilidad en la carga de trabajo si las tasas de ejecución siguen siendo similares. |
| Flujos de invalidación | ¿Alguna base de datos ha experimentado una recompilación extensa de SQL/PLSQL debido a la invalidación de objetos?
¿Cuántos? |
Recuento de bases de datos con al menos un día en el período en el que la visión de tormenta de invalidación era verdadera. | Indicador de estado de mosaico de estadísticas:
Los niveles excesivos e inesperados de invalidaciones SQL pueden estar relacionados con eventos y pueden hacer un uso intensivo de la CPU. Los niveles de invalidación crónicamente altos pueden inducir una carga innecesaria en la base de datos. |
| Duplicados que comparten cursores | ¿Alguna base de datos tiene aplicaciones que no comparten cursores y desperdician CPU?
¿Cuántos? |
Recuento de bases de datos en las que la información de uso compartido del cursor era verdadera durante el período de tiempo. | Indicador de estado de mosaico de estadísticas:
|
| SQL en proceso de degradación |
¿Tiene alguna base de datos SQL que pueda estar degradándose con el tiempo? ¿Cuántos? |
Recuento de bases de datos que tienen al menos un valor SQL_ID en el que la información SQL degradante fue verdadera durante el período. | Indicador de estado de mosaico de estadísticas:
|
Estadísticas de nivel de base de datos
| Análisis detallado | Casos de Uso | Análisis y salida | Notas: |
|---|---|---|---|
| Tendencia de degradación | ¿Tiene la base de datos algún SQL que muestre una degradación del rendimiento durante el período de tiempo?
¿Cuántos? |
Recuento del número de SQL_ID con estadísticas de tendencia de rendimiento degradantes durante el período de tiempo. | Calculado por base de datos (todas las instancias combinadas)
Indicador de estado de mosaico de estadísticas:
|
| Mejora de la tendencia | ¿Tiene la instancia de base de datos algún SQL que muestre una mejora del rendimiento durante el período de tiempo?
¿Cuántos? |
Recuento del número de SQL_ID con mejora de las estadísticas de tendencias de rendimiento durante el período. |
Calculado por base de datos (todas las instancias combinadas) Indicador de estado de mosaico de estadísticas:
|
| Cambios de plan degradado | ¿Han visto las instancias de base de datos algún cambio en el plan que haya degradado el rendimiento en el período de tiempo?
¿Cuántos? |
Recuento del número de SQL_ID con estadísticas de cambio de plan único que se considera degradado en el período de tiempo | El total estimado de segundos adicionales por día guardado se calcula para clasificar esta base de datos frente a otras.
Indicador de estado de mosaico de estadísticas:
NOTA: los cambios de plan son por instancia |
| Cambios de plan mejorado | ¿Han visto las instancias de base de datos algún cambio en el plan que haya mejorado el rendimiento en el período de tiempo?
¿Cuántos? |
Recuento del número de SQL_ID con estadísticas de cambio de plan único que se considera mejoradas en el período de tiempo | El total estimado de segundos guardados por día se calcula para clasificar esta base de datos en comparación con otros.
Indicador de estado de mosaico de estadísticas:
NOTA: los cambios de plan se realizan por instancia |
| Flujo de invalidación | ¿Se ha producido una invalidación y recompilación generalizadas de SQL en la instancia de base de datos durante el período de tiempo? | Recuento del número de días en los que al menos el 20% del total de SQL recopilado también se ha invalidado ese día. | Esta es una verdadera información de nivel de base de datos, ya que se refiere a todo el SQL recopilado de las instancias de base de datos por día.
Indicador de estado de mosaico de estadísticas:
|
| Nuevo SQL | ¿La base de datos ha realizado algún trabajo nuevo en el período de tiempo?
¿Qué SQL y cuánto trabajo? |
Recuento del número de SQL_ID con registro de hora de recopilación inicial en el período de tiempo. | Puede que SQL no sea realmente nuevo en la base de datos, solo nuevo en Ops Insights.
Indicador de estado de mosaico de estadísticas:
|
Estadísticas a nivel de SQL
| Análisis detallado | Casos prácticos | Análisis y salida | Notas: |
|---|---|---|---|
| Tendencia de rendimiento | ¿La latencia de ejecución de SQL ha variado de forma consistente con el tiempo durante el período?
Los planes de ejecución pueden ser sensibles a la ampliación o contratación de tamaños de datos. |
Señales verdaderas para cualquier SQL_ID donde la regresión lineal sobre latencias medias agregadas observadas en el período de tiempo explica al menos 1⁄2 de la varianza (R2 >0,5) en la latencia media agregada, Y el cambio porcentual en la línea de regresión lineal supera +/- 20% | Mínimo de 5 observaciones por SQL_ID necesario para la regresión.
Indicador de estado de mosaico de estadísticas:
El límite del 20 % debe tenerse en cuenta en el contexto del período de tiempo seleccionado. Calculado por base de datos (instancias combinadas). |
| Variabilidad de rendimiento | ¿SQL mostró una gran variación en las latencias medias agregadas? | Señales verdaderas para un SQL_ID cuando el rango de latencias medias agregadas dividido por la latencia media agregada general es superior al 25 %. | Se requiere un mínimo de 5 observaciones.
Indicador de estado de mosaico de estadísticas:
Más significativo para una ejecución más prolongada y SQL ejecutado con menos frecuencia.
|
| Único cambio de plan | ¿Ha mostrado SQL un cambio de plan en la base de datos durante el período?
¿El cambio en el plan afectó al rendimiento? ¿Cuánto? |
Indicador de que el ID de SQL seleccionado ha producido un único cambio de plan diario durante el período. El último cambio de plan se utiliza para determinar la degradación o mejora. | Se requiere un mínimo de 5 observaciones.
Indicador de estado de mosaico de estadísticas:
La información del plan se muestra y no se completa. Se calcula por instancia, ya que las distintas instancias pueden tener planes diferentes. |
| Varios planes | ¿Se ejecutó SQL en varios planes en la base de datos durante el período de tiempo? | Señales verdaderas cuando el recuento de valores hash de plan distintos para SQL_ID supera 1. | La información del plan se muestra y no está completa, por lo que podría haber más planes que los recopilados.
Señalará con un solo cambio de plan. Indicador de estado de mosaico de estadísticas:
Calculado por base de datos (instancias combinadas). |
| Duplicados que comparten cursores |
¿Hay SQL que pueda compartir el análisis y la optimización salvo para el no uso de variables de enlace?
¿Cuánto exceso de CPU se desperdicia? |
Señales verdaderas cuando el recuento de SQL_ID distintos que comparten la misma firma de coincidencia forzada es > 1. | Calculado por instancia de base de datos.
Indicador de estado de mosaico de estadísticas:
Solo incluye SQL_ID con ejecuciones = 1.
La CPU de análisis en exceso estimada se calcula como SUM (tiempo medio de análisis pesado): AVG (tiempo medio de análisis pesado) sobre la base de que el análisis pesado es toda la CPU y el tiempo medio de análisis pesado no es un promedio, ya que las ejecuciones son 1 para todo el SQL. Lo anterior es probablemente una estimación muy baja del total de CPU perdidas porque no se habrán recopilado muchos duplicados que se ejecutaron. |