Share This
Contacto
Desplazarse hacia abajo
Categorias
//Análisis rápido y confiable para encontrar causas de fallas en Oracle

Análisis rápido y confiable para encontrar causas de fallas en Oracle


En este artículo, establecemos las características de un recopilador de datos adecuado para la recopilación continua de datos, así como el tipo de información que necesita para realizar de manera efectiva análisis de causa raíz de los problemas de rendimiento de la base de datos de Oracle. También examinamos por qué Trace Event 10046 y Oracle Statspak no cumplen con nuestros criterios.

Características de un recopilador de datos de rendimiento de Oracle adecuado

Debe poder mirar hacia atrás en el tiempo para descubrir qué hizo cada proceso en primer plano en la base de datos. Los hechos deberían conducirlo al problema en la base de datos o ayudarlo a probar que el problema es externo. Si los hechos revelan que el problema está fuera de la base de datos, puede usar estos hechos para alentar a los otros equipos a revisar sus procesos y sistemas y evitar señalar con el dedo a la base de datos. La siguiente es nuestra lista recomendada de características del recopilador de datos:

  • Metodología basada en Waits: los análisis de causa raíz dependen en gran medida de los datos de eventos de espera a nivel de sesión. Por lo tanto, el recopilador de datos elegido debe suscribirse a Oracle Wait Interface.
  • Granularidad a nivel de sesión: los análisis de causa raíz del rendimiento también requieren datos sin procesar (de bajo nivel) a nivel de sesión. Los datos resumidos a nivel de sesión tienen algún valor, pero la granularidad a nivel de instancia es demasiado gruesa y no es adecuada para este propósito.
  • Siempre activo y con poca sobrecarga: debido a que nadie sabe cuándo ocurrirá un problema de rendimiento, el recopilador de datos debe estar funcionando en todo momento (es decir, recolección continua o muestreo). El recopilador también debe poder monitorear simultáneamente todas las conexiones de base de datos en primer plano. Por lo tanto, la baja sobrecarga de procesamiento es extremadamente importante.
  • Repositorios históricos: los repositorios son importantes porque le permiten mirar hacia atrás en el tiempo para descubrir lo que sucedió en la base de datos, al igual que las cintas de vigilancia en las que confían los investigadores para resolver un crimen o un misterio. Debe tener un repositorio separado para sesiones o conexiones, eventos de espera y declaraciones SQL. Hay más discusión sobre los repositorios en la sección «Muestreo de rendimiento mediante el procedimiento PL/SQL».

Por qué Trace Event 10046 no es un recopilador de datos adecuado

El evento de rastreo 10046, que no debe confundirse con los eventos de espera, es la mejor utilidad para rastrear procesos, sin excepción. El archivo de seguimiento contiene información sobre sentencias SQL, análisis y ejecuciones, variables de vinculación y eventos de espera. Puede rastrear procesos en primer plano y en segundo plano con él. Es perfecto para el seguimiento ad hoc cuando necesita información de tiempo de ejecución en el nivel granular más bajo y ha establecido el marco de tiempo de seguimiento.

Sin embargo, la instalación de rastreo 10046 no cumple con el requisito de sobrecarga baja y siempre activo establecido en la sección anterior. Hay dos razones principales por las que no puede utilizar esta función de rastreo como un recopilador de datos de rendimiento continuo:
  • Genera demasiados datos. Los datos detallados que ofrece son sinónimo de gran volumen, especialmente en los niveles 8 y 12. La cantidad de datos de rastreo generados en estos niveles puede consumir rápidamente todo el espacio en su directorio UDUMP/BDUMP. Por este motivo, el evento de seguimiento 10046 rara vez se habilita a nivel de instancia. Si es así, es solo por un breve momento, generalmente a pedido y orientación del soporte de Oracle. Olvídese de habilitar esto para todos los procesos las 24 horas del día, los 7 días de la semana. Ni siquiera es práctico rastrear una sesión de larga duración de principio a fin. Debe ser muy selectivo sobre cuándo comenzar y detener el rastreo, lo que significa que debe tener una idea aproximada de cuándo surgirá el problema.
  • Es caro, La exhaustividad de esta función de seguimiento es sinónimo de gastos generales. La sobrecarga degradará aún más el rendimiento de un proceso que ya funciona lentamente.
Además de estos motivos, existen otros motivos por los que el evento de seguimiento 10046 no es adecuado para la tarea, incluidos los siguientes:
  • A pesar de la gran cantidad de datos generados en los niveles 8 y 12, todavía no es suficiente. Solo encontrará datos de eventos sin procesar en el archivo de seguimiento. Es posible que vea algo como “ESPERE #12: nam=’db archivo disperso leído’ ela= 0 p1=106 p2=60227 p3=8”. Obviamente, no es fácil de usar y no hay una interpretación de valor agregado. Tiene que traducir manualmente P1 y P2 para descubrir el nombre del objeto, lo cual es una tarea laboriosa, especialmente cuando hay muchos objetos presentes. Además, las traducciones realizadas a posteriori pueden ser erróneas si el objeto se cae y/o el mismo espacio es ocupado por otro objeto. Tampoco hay referencias cruzadas en el archivo de rastreo. Por ejemplo, cuando hay una espera de puesta en cola, el archivo de seguimiento registra los valores P1, P2 y P3 para el evento de puesta en cola, pero no hay datos sobre la sesión de bloqueo o la instrucción SQL que ejecuta el bloqueador. En este caso, solo obtienes la mitad de la historia.
  • Dependiendo de la versión de Oracle, los archivos de rastreo pueden ser propensos a errores y no siempre son confiables. Considere el siguiente fragmento de un archivo de seguimiento del evento 10046 que pertenece al proceso DBWR en la versión 9.2.0.1.0 de Oracle. Observe los valores negativos de P1. (Este error se solucionó en 9.2.0.4.)
  • Quizás el mayor inconveniente con la función de seguimiento de eventos 10046 es que no es práctico como un recolector de datos en curso, aunque es técnicamente posible.

Por qué Statspack no es un recopilador de datos adecuado

Oracle Corporation introdujo Statspack en Oracle 8.1.6 como una herramienta para recopilar y almacenar datos de rendimiento. Statspack proporciona datos de diagnóstico a nivel de instancia, que son demasiado gruesos para el análisis de causa raíz. Aunque es posible tomar instantáneas a nivel de sesión con Statspack, no está diseñado para rastrear cada conexión de base de datos. Por lo tanto, no consideramos a Statspack como un recopilador de datos adecuado. Para obtener más información sobre por qué Statspack no es adecuado para recopilar datos de rendimiento a nivel de sesión, consulte el documento técnico «Alternativas 10046» en www.ioug.org.

  • 90 views
  • 0 Comment

Leave a Reply

Tu dirección de correo electrónico no será publicada.

Comentarios recientes

    Verifications

    Verification Verification Verification

    Un poco sobre nosotros…

    Fundado en el 2015 estamos ubicados en la Cd de Monterrey, NL DBA/Developers ha logrado posicionarse como una consultora de tecnología, innovación, desarrollo, implementación, y soporte, líder en el área de bases de datos

    DBA Developeres 2021 / All rights reserved.

    Contacto
    Close
    Abrir chat
    1
    ¿Necesitas ayuda?
    Envíanos un mensaje
    Hola 🖐
    ¿En que podemos ayudarte?