Resulta emocionante, y es lo que pretendo trasladar en este artículo, la idea de disponer de un repositorio centralizado de awr de todas las bases de datos Oracle de la compañía.

Realmente pienso… cómo has podido vivir sin uno?!

Para entender qué nos puede aportar comienzo explicando qué es AWR.

AWR es una de las herramientas más potentes de las que dispone Oracle para realizar un seguimiento y diagnósticos del rendimiento de nuestras bases de datos Oracle.

Su funcionamiento consiste en ir tomando información del rendimiento de la base de datos en periodos regulares, por defecto cada hora y retención de 8 días, de las siguientes fuentes:

  • Estadísticas a nivel de objeto, tanto de acceso como estadísticas de uso.
  • Time Model Statistics (V$SYS_TIME_MODEL y V$SESS_TIME_MODEL)
  • Estadísticas de sisrtema y de sesión (V$SYSSTAT y V$SESSTAT)
  • ASH (Active Session History)
  • Consultas SQL con carga alta en el sistema

Por defecto dicha información se encontraría en el SYSAUX de cada una de ellas, lo cual nos acaba llevando mayor tiempo de backup, mayor tiempo de upgrade y mayor ocupación de espacio de almacenamiento, además de poder impactar en el en rendimiento de producción la consulta de dicha información.

Recordemos que para poder beneficiarnos de AWR precisaremos que las bases de datos sean Enterprise Edition con diagnostics + tuning pack.

Conociendo ya qué es AWR ahora pensamos, qué ventajas puede aportarme un repositorio centralizado de AWR?

  • Liberar espacio y eliminar impacto de rendimiento en los sistemas de producción.
  • Retención INIFINITA si queremos (es configurable). Tranquilidad! existe particionamiento de la información por dbid y snap_id de las tablas WRH$ (DBA_HIST_) 🙂
  • Consultar la información directamente y poder cruzar entre bases de datos. Pongamos un ejemplo: inspeccionar y comparar la información relativa a un sql_id particular, como consumo de cpu, IO o plan de ejecución, entre preproducción y producción.
  • Comparar el rendimiento entre periodods del sistema en producción… hasta años atrás!
  • Ver evolución del rendimiento de las distintas bases de datos en el tiempo, pudiendo agregar ésta según nuestra necesidades.
  • El repositorio de AWR podrá ser una base de datos single instance, sin licenciamiento adicional.
  • Podrá ser fuente de información para ADDM, ASH analytics…

Cómo funciona?

awrw-art1-jpeg

El proceso de funcionamiento es muy simple, mediante una serie de jobs que resultan en procesamiento ETL. Describo las fases:

  • Extracción de la información de AWR (ficheros dmp) en origen.
  • Transferencia. Un job de EM transferirá dicha información a intervalos regulares uns staging area en el host de AWR Warehouse, en el cual será procesada
  • Carga. Un job de base de datos cargará dicha información de forma regular de forma incremental (asergurándose que se importan todos los snapshots que no han sido aun cargados)

No hace falta decir que dicha información puede ser explotada a través de CloudControl, además de poder crear tus propios informes de rendimiento según las necesidades del negocio 🙂