Category: Tuning / Performance

Script para monitorear estadísticas de sistema históricas



Tal como lo vimos en un post anterior, el hecho de poder analizar algún problema en nuestra base de datos y dar una recomendación acertada , siempre pasa por analizar todas las aristas posibles, para que no nos pase lo que le sucede a muchos DBAs, que hablan, hablan, hablan y al final, el disparo a la bandada les sirve (a algo le apuntan), la idea es ser precisos y para ello, el análisis es quien nos llevará a la gloria



Este post habla de las estadísticas de sistema y lo fácil y rápido que resulta al momento de realizar análisis sobre nuestra base de datos

El script que se debe ejecutar lo pueden ubicar en la siguiente ruta
Estadistica_sistema_tabulado.sql

El modo de ejecución es simplemente una llamada a SQL*Plus , con lo cual aparecerá lo siguiente

SQL> start estadistica_sistema_tabulado.sql

Puede consultar todas las estadisticas de sistema disponibles en la siguiente vista
SELECT name FROM V$SYSSTAT ORDER BY name

Ingrese texto para buscar estadistica de sistema :

Se ingresa un patrón de búsqueda para la estadistica de sistema, por ejemplo al ingresar la palabra redo se filtran las estadisticas de sistema que sean similares y les mostrará por pantalla lo siguiente

----- (texto cortado) -----
redo size
redo size for direct writes
redo size for lost write detection
redo subscn max counts
redo synch time
redo synch writes
redo wastage
redo write broadcast ack count
redo write broadcast ack time
redo write time

Ingrese nombre de estadistica de sistema :

Se ingresa el nombre de la estadistica de sistema completo, por ejemplo "redo size" y pedirá el número de días a analizar y el intervalo

Ejemplo :

Ingrese nombre de estadistica de sistema : redo size
Ingrese numero de dias a analizar : 10
Ingrese intervalo de horas a medir : 1

Después de lo anterior , nos arroja información tabulada proveniente de las tablas históricas del AWR



Y podemos proceder a generar nuestro magnífico gráfico (en este caso un RAC)

Temas relacionados
<<<<<>>>>>>>>>>>>>>

Espero les sirva :)

by Ligarius
22.11.15. 17:58:03. 350 words, 1838 views. Categories: Tuning / Performance ,

Scripts para monitorear eventos de espera históricos



Cuando se realiza un análisis en una base de datos Oracle no podemos realizar una sugerencia si sólo conocemos un punto de análisis, no podemos ver un AWR de las 09:00 a 10:00 de la mañana y decir cual es el problema , esto le suele suceder a muchas personas que por analizar un punto dan las recomendaciones, pues muchas veces son comportamientos normales y los problemas van por otro lado.

Lo que se debe hacer es analizar la curva de comportamiento de alguna estadística de Oracle y chequear su comportamiento histórico, para poder realizar este análisis es que les muestro unas consultas entretenidas que todo buen cocinero DBA debe tener y usar (por supuesto) ;D




Para poder consultar sobre eventos de la espera en la base de datos, ejecutamos la siguiente consulta
Eventos_espera_tabulado.sql

El modo de ejecución es simplemente una llamada a SQL*Plus , con lo cual aparecerá lo siguiente

SQL> start eventos_espera.sql

Puede consultar todos los eventos de espera disponibles en la siguiente vista
SELECT name FROM V$EVENT_NAME ORDER BY name

Ingrese texto para buscar evento de espera :

Se ingresa un trozo del evento de espera, por ejemplo al ingresar la palabra log se filtran los eventos de espera que sean similares y los mostrará por pantallarong>log

----- (texto cortado) -----
log file sync
log switch/archive
log write(even)
log write(odd)
logout restrictor
recovery area: computing applied logs
simulated log write delay
switch logfile command

35 rows selected.

Ingrese nombre de evento de espera :

Se ingresa el nombre del evento de espera completo, por ejemplo log file sync y pedirá el número de días a analizar y el intervalo

Ejemplo :

Ingrese nombre de evento de espera : log file sync
Ingrese numero de dias a analizar : 10
Ingrese intervalo de horas a medir : 1

Después de lo anterior , nos arroja información tabulada proveniente de las tablas históricas del AWR

center



Y podemos proceder a generar nuestro magnífico gráfico

center

Espero les sirva para poder analizar su base de datos ;)

by Ligarius
13.11.15. 08:57:39. 347 words, 1512 views. Categories: Tuning / Performance ,

Información importante en AWR : Operating System Statistics



Una parte importante para analizar en un reporte de AWR , es lo que corresponde a estadísticas de Sistema Operativo, aunque esto se puede sacar de múltiples formas, como por ejemplo el comando sar, prstat, top , etc,etc.

Pero como está disponible en Oracle a través de un reporte de AWR, sería necesario que supieramos al menos de que se trata, he acá un pequeño resumen de lo que significa ese bloque de datos.

Un ejemplo de estadísticas de sistema operativo



1.- AVG_BUSY_TIME = Es el cálculo de BUSY_TIME/NUM_CPUS
2.- AVG_IDLE_TIME = Es el cálculo de IDLE_TIME/NUM_CPUS
3.- AVG_IOWAIT_TIME = Es el cálculo de IOWAIT_TIME/NUM_CPUS
4.- AVG_SYS_TIME = Es el cálculo de SYS_TIME/NUM_CPUS
5.- AVG_USER_TIME = Es el cálculo de USER_TIME/NUM_CPUS

6.- BUSY_TIME = Es un tiempo equivalente a %usr + %sys en un comando sar , la diferencia está que el comando sar lo expresa en porcentajes y acá se expresa en unidades.
7.- IDLE_TIME = Es un tiempo equivalente a %idle en un comando sar, la diferencia está que el comando sar lo expresa en porcentajes y acá se expresa en unidades.
8.- IOWAIT_TIME = Es un tiempo equivalente a %wio en un comando sar, la diferencia está que el comando sar lo expresa en porcentajes y acá se expresa en unidades.
9.- SYS_TIME = Es un tiempo equivalente a %sys en un comando sar, la diferencia está que el comando sar lo expresa en porcentajes y acá se expresa en unidades.
10.- USER_TIME = Es un tiempo equivalente a %usr en un comando sar, la diferencia está que el comando sar lo expresa en porcentajes y acá se expresa en unidades.

%usr : Es el porcentaje de tiempo de la CPU que es gastada en procesos de usuarios, como aplicaciones , shell scripts o interactuando con el usuario
%idle : Es el porcentaje de tiempo de la CPU en que no hay ninguna actividad .
%wio : Es el porcentaje de tiempo de la CPU en que se está a la espera de una lectura o escritura de un bloque en sistema operativo, por ejemplo, tratando de leer un disco.
%sys : Este porcentaje de tiempo de uso de la CPU está relacionado a la ejecución de las tareas de Kernel (S.O.).


Esta información puede ser obtenida con el comando sar, ejemplo sar -u 1 10 , quiere decir que sacará estadísticas de sistema operativo cada 1 segundo , 100 repeticiones.

Salida de referencia :

$ sar -u 1 10

HP-UX Poseus B.11.31 U ia64 08/26/13

13:00:46 %usr %sys %wio %idle
13:00:47 89 6 5 0
13:00:48 81 4 15 0
13:00:49 78 13 9 0
13:00:50 78 21 1 0
13:00:51 76 22 2 0
13:00:52 85 13 2 0
13:00:53 88 7 5 0
13:00:54 75 11 13 1
13:00:55 61 8 29 2
13:00:56 57 4 35 4

Average 77 11 12 1


11.- LOAD = Significado no es claro, por ende se deja de lado en los análisis (incluso esto aparece en las notas oficiales de Oracle)

12.- OS_CPU_WAIT_TIME = El tiempo de espera en las colas de ejecución (dato no claro de acuerdo a las notas de Oracle)
13.- RSRC_MGR_CPU_WAIT_TIME = Tiempo de espera en los Resource Manager
14.- PHYSICAL_MEMORY_BYTES = Total de memoria usada
15.- NUM_CPUS = Número de CPUs reportadas por el Sistema Operativo

Casi todas las cantidades expresadas están en centésimas segundos...por ende si se requiere cambiar para llevar a porcentajes, se puede hacer de la siguiente forma.

ELAPSED TIME = SYS_TIME + USER_TIME + IDLE_TIME + IOWAIT_TIME

O sea

ELAPSED TIME = 39948702 + 6304516 + 74707066 + 0
ELAPSED TIME = 120960284


El cálculo de "ELAPSED TIME" debe ser muy parecido a la cantidad de segundos que fueron contemplados dentro del informe de AWR, esto lo podemos ver al inicio del reporte

Snap Id Snap Time Sessions Cursors/Session
Begin Snap: 41607 05-Aug-13 00:00:24 1913 3.0
End Snap: 41628 05-Aug-13 21:00:19 51 3.3
Elapsed: 1,259.91 (mins)
DB Time: 1,116.03 (mins)

"ELAPSED TIME" = (Cantidad de minutos desde el Snap inicial al final) * 60 seg. por minuto * Número de CPUs
"ELAPSED TIME" = 1259.91 * 60 * 16
"ELAPSED TIME" = 1209513.6


Como ya tenemos "ELAPSED TIME" derivado del cálculo de SYS_TIME + USER_TIME + IDLE_TIME + IOWAIT_TIME , podemos realizar los cálculos del porcentaje...

ELAPSED TIME = 120960284


Ejemplo

%busy ={(BUSY_TIME / "ELAPSED TIME" )} * 100
%busy ={([USER_TIME + SYS_TIME] / "ELAPSED TIME" ) } * 100
%busy = {([6304516 + 39948702] / 120960284)} * 100
%busy = {46253218 / 120960284} * 100
%busy = 0.38 * 100
%busy = 38


En Oracle 12c , se agrega un nuevo bloque de datos en el AWR, la información que aquí aparece es similar a la salida del comando "sar -u" y muestra la carga que tuvo la base de datos
a nivel de CPU

Espero les sirva

by Ligarius
26.08.13. 16:00:12. 726 words, 6539 views. Categories: Tuning / Performance, Oracle 12c ,

Active Session History (ASH) performed an emergency flush



Viendo un Oracle RAC versión 11.2.0.3 me percaté de este error en el archivo de alertas, pues bien lo que hice fue analizarlo un poco, he acá las conclusiones.


Foto de Quito , lugar que conoceré en Noviembre ;)

Este mensaje de warning se produce en versiones desde la 11.2.0.2 de Oracle Enterprise Edition y significa única y exclusivamente que Active Session History para su porción de memoria ASH tiene un tamaño muy pequeño para la cantidad de sesiones activas que se están produciendo, por ende tiene que vaciarla y dejarla en blanco para todos los nuevos registros, con esto se puede información histórica relacionada con el ASH (estadísticas de performance relacionadas a los usuarios)

Este error se puede pasar por alto, ya que indica que hubo un aumento significativo de las sesiones..si el error persiste, se puede realizar algo para evitar que aparezca en el archivo de alertas y gatille todos nuestros procesos de monitoreo.

Error textual desde el archivo de alertas

Tue Jul 23 10:14:38 2013
Active Session History (ASH) performed an emergency flush. This may mean that ASH is undersized. If emergency flushes are a recurring iss
ue, you may consider increasing ASH size by setting the value of _ASH_SIZE to a sufficiently large value. Currently, ASH size is 13421772
8 bytes. Both ASH size and the total number of emergency flushes since instance startup can be monitored by running the following query: select total_size,awr_flush_emergency_count from v$ash_info;



Imagen de cantidad de sesiones en una instancia Oracle

Un síntoma relacionado al error, es por ejemplo una alta cantidad de usuarios activos , que va aumentando de forma exponencial.

Si queremos saber cuanto es el tamaño destinado al buffer ASH en memoria, pues podemos ejecutar la siguiente consulta

select total_size/1024/1024 Mb ,
awr_flush_emergency_count
from v$ash_info;

Nos muestra el tamaño del ASH y nos nuestra cuanta veces ha realizado un flush desde esta porción de memoria desde el último Startup

¿Cómo se soluciona este problema?
Para darle una solución al tema, se debe modificar el parámetro oculto _ash_size , pero como recomendación siempre háganlo a través de Soporte de Oracle, ya que como saben , la modificación de parámetros ocultos no está soportada.

El valor que se le debe asignar al parámetro es un 50% del valor actual y el comando sería algo así

alter system set "_ash_size"=valor 50% superior al existente scope=spfile;

Nota1 : Este cambio debe ser realizado con el usuario SYS
Nota2 : El ASH Buffer reside dentro de la Shared Pool


Espero les sirva


by Ligarius
23.07.13. 12:19:33. 442 words, 9539 views. Categories: Tuning / Performance, Oracle11gR2 ,

Oracle 12c New Features : Movimiento de datafiles ONLINE



En Oracle 11gr2 y versiones más antiguas de Oracle para poder mover un datafile de ubicación , teníamos que dejar el datafile OFFLINE, copiar por sistema operativo o RMAN y hacer un ALTER DATABASE RENAME.

Pues bien , una nueva característica en Oracle 12c, nos permite realizar este movimiento en línea sin que nuestros aplicativos tengan que sufrir una pérdida de servicios.



El formato del comando

ALTER DATABASE MOVE DATAFILE 'origen' to 'destino';

He aquí un ejemplo :

1.- Chequeo mis datafiles, su status y el tamaño (Puede apreciarse que no es instancia productiva :) )

FILE_NAME                                                   ;STATUS   ;        GB
------------------------------------------------------------;---------;----------
C:\APP\INMETRICS-HECTOR\ORADATA\PROD\UNDOTBS01.DBF          ;AVAILABLE;,708007813
C:\APP\INMETRICS-HECTOR\ORADATA\PROD\SYSAUX01.DBF           ;AVAILABLE;,693359375
C:\APP\INMETRICS-HECTOR\ORADATA\PROD\SYSTEM01.DBF           ;AVAILABLE; ,76171875
C:\APP\INMETRICS-HECTOR\ORADATA\PROD\USERNEW01.DBF          ;AVAILABLE;,004882813
C:\APP\INMETRICS-HECTOR\ORADATA\PROD\EXAMPLE.DBF            ;AVAILABLE;         1


2.- Ejecuto el comando para realizar el movimiento

16:58:00 SQL> alter database move datafile 2 to 'c:\app\inmetrics-hector\oradata\prod\examplenew011.dbf';

Database altered.

Elapsed: 00:01:27.73

Muestro los tiempos sólo para tener una idea y proyectar algún movimiento a futuro, 1GB en 1,5 minutos app


3.- Vuelvo a consultar mis datafiles y realmente aparece el nuevo datafile y mientras se hacía el movimiento , se puede consultar la tabla y los aplicativos sin problemas.

FILE_NAME                                                   ;STATUS   ;        GB
------------------------------------------------------------;---------;----------
C:\APP\INMETRICS-HECTOR\ORADATA\PROD\UNDOTBS01.DBF          ;AVAILABLE;,708007813
C:\APP\INMETRICS-HECTOR\ORADATA\PROD\SYSAUX01.DBF           ;AVAILABLE;,693359375
C:\APP\INMETRICS-HECTOR\ORADATA\PROD\SYSTEM01.DBF           ;AVAILABLE; ,76171875
C:\APP\INMETRICS-HECTOR\ORADATA\PROD\USERNEW01.DBF          ;AVAILABLE;,004882813
C:\APP\INMETRICS-HECTOR\ORADATA\PROD\EXAMPLENEW01.DBF       ;AVAILABLE;         1


Si quisiera hacer un movimiento de un datafile que se encuentre en modo OFFLINE, daría un error como el que sigue

23:12:55 ORACLE> alter database move datafile 2 to 'c:\app\inmetrics-hector\oradata\prod\examplenew01.dbf';
alter database move datafile 2 to 'c:\app\inmetrics-hector\oradata\prod\examplenew01.dbf'
*
ERROR at line 1:
ORA-01135: el archivo 2 accedido para LMD/consulta está offline
ORA-01110: archivo de datos 2: 'C:\APP\INMETRICS-HECTOR\ORADATA\PROD\EXAMPLE.DBF'

Elapsed: 00:00:00.15


Algunas consideraciones y observaciones a tener en cuenta :

- Este comando es extremadamente útil para realizar el movimiento de un datafile desde un storage a otro

- Con este comando se puede un datafile desde Filesystem a ASM y viceversa

- Al momento de ejecutar el comando , Oracle genera una copia del datafile en la nueva ruta o con el nuevo nombre que se le indica, una vez completada la instrucción se borra el datafile antiguo, sólo en ambiente Windows el datafile antiguo se deja y se debe eliminar en forma manual

- Se debe considerar el mismo espacio libre que el datafile que se está queriendo mover, dado que Oracle generará una copia del datafile , haciendo el parangón, es como el REBUILD INDEX ONLINE

- Las bases de datos Standby no se ven afectadas por un comando para mover un datafile , ni la primaria se ve afectada cuando se mueve un datafile en la Standby, funcionan como 2 entes diferentes.

- Si queremos ocupar un FLASHBACK hasta antes del cambio del datafile, el datafile seguirá estando en la ruta nueva, pero los datos cambiarán, o sea, el datafile no se reubica en la nueva posición

- Sólo se pueden mover de está forma los datafiles ONLINE, si los datafiles están OFFLINE arroja un error y se tiene que ocupar otro mecanismo

- El tema de performance debiese ser analizado más en profundidad, no creo que el tema sea total y absolutamente inocuo para el aplicativo, por lo menos en las pruebas realizadas, no encontré grandes diferencias de tiempo en las consultas que se ejecutaron antes, durante y después del movimiento del datafile en forma ONLINE.

- Si estamos en un ambiente UNIX, se puede ocupar la claúsula KEEP con lo cual al realizar la copia no se elimina el datafile antiguo, sólo se mantiene en la ruta nueva, el formato del comando

ALTER DATABASE MOVE DATAFILE 'nombre datafile' to 'nueva ruta datafile' KEEP;



by Ligarius
17.07.13. 09:55:05. 670 words, 2685 views. Categories: Tuning / Performance, Oracle 12c ,

1 2 3 4 5 6 7 8 >>