Interpretación del AWR de Oracle - Parte1

La primera pantalla importante del AWR es sobre el "Load Profile":

De la anterior informacion se destaca:

Se observa que existe mucha lectura lógica pero pocos cambios en los bloques

Logical read (blocks):             594.9             890.3                   

       Block changes:              17.2              25.7                  

Physical read (blocks):            53.7              80.3                   

Se observa que no es una base de datos warehouse debido a la cantidad de SQL Work Area que existe, en una WHouse se observaría mucha Work Area debido a que un alto numero de operaciones y ordenaciones se llevan a cabo. A su vez esto indica que hay poco trabajo de ordenación de sentencias SQL:

SQL Work Area (MB):               0.1               0.1 

Llamadas de usuario, parseos, ejecuciones, transacciones y rollbacks son informacion importante:

User calls:              40.1              60.1                   

Parses (SQL):            15.6              23.4                    

Executes (SQL):          20.2              30.3                   

Rollbacks:               0.0               0.0                   

Transactions:            0.7                 -         

En un sistema OLTP (Online Transaction Processing) podriamos esperar muchas lecturas logicas, pocas lecturas fisicas, muchas "user calls", muchos "parses" y muchas ejecuciones así como rollbacks y transacciones

En un sistema Warehouse, se esperaría que las "user calls" y los "parses" sean bajos, sin embargo las transacciones son de "larga corrida".

De la anterior seccion destacamos:

"Buffer hit" 

Si se observa que los valores de "buffer nowait" y "Buffer hit" son inferiores a 95%, debemos investigar si los bloques de datos (data block buffers) estaban siendo correctamente usados y si estos deben incrementarse.

"Library hit percentage" 

Si está bajo, podriamos incrementar el shared pool o implementar en la codificacion el uso de variables "bind".

"Redo NoWait" 

Indica que tan eficiente es el trabajo de los "buffer redo" y como estos estan siendo utilizados. Si el porcentaje es bajo entonces se requiere un tunning de esos componentes.

“Soft parse” 

indica cuan a menudo las sentencias SQL son encontradas en los caches de los cursores. Esta estadística es directamente relacionada al uso correcto de las variables bind; El “soft-parse debe redondear al 100%. “Hard-parses” causan recursividad de sentencias SQL y son más costosas en procesamiento.

·      “Non-parse CPU %”

Indica cuanto tiempo el CPU esta gastando en procesar nuestra solicitud vrs cuanto tiempo esta gastando haciendo otras cosas como recursividad SQL. Si el porcentaje es bajo, revise la sección “parse related percentages”; cuando este porcentaje es bajo indica que el sistema gasta mucho tiempo en procesar SQL y no hay mucho tiempo para procesar trabajo real.

Un ejemplo de este parámetro:

Supongamos  lo siguiente: 

% Non­Parse CPU	98.07%
Parse CPU to Parse Elapsed %	26.87%

Si observamos el "% Non­Parse CPU" en 98.07% eso significa que solo el 1.03% del total de CPU está "parseando". Aunque reduzcamos el "Parse CPU to Parse Elapsed %" al imposible valor de 0, lo único que ganamos es 1% extra CPU overall. Por eso debemos buscar los fallos del CPU en otro lado.

"Parse CPU to Parse Elapsed":

Un valor bajo para este parametro indica problemas de "latches", investigue la contencion en la library cache y los shared pool latches.

La información de CPU muestra cuan eficientemente está la instancia utilizando recursos de CPU.

· La instancia utiliza el total de CPU disponible únicamente para 3.0% del tiempo.
· De ese 3.0% utiliza 59.5% para procesamiento.
· Un 0% está utilizado para administración de recursos.

Según Oracle se debería utilizar el 60% de la memoria solo en Oracle Database

· De acuerdo a la estadística, la memoria utilizada por la instancia es de un 17.86 %  muy lejos del 60%.
· El SGA se encuentra estable con 536 Megas
· El PGA se mantiene en 195Megas, sin embargo de las 8:00 am a las 11:00 am (horas de los snapshots del AWR) creció de un 195.3 a un 195.4 Megas. Este crecimiento debido a las operaciones en la base de datos

Busque los Tablespaces con mayor cantidad de lecturas y escrituras.

Busque los que muestran un alto “high average read miliseconds” también “High number of buffer waits” ya que altos valores para lecturas y buffers indican estrés I/O y posible necesidad de memoria para la instancia.

No copyright infringement is intended. For study purposes only.