Troubleshooting daily on Oracle Systems, Linux & more !
Hoy tuve un problema en produccion en un Exadata X5, con 18 cores CPUS en cada nodo miembro del RAC.
Pude visualizar que estos eventos ocurrian por que estaban siendo generados por los procesos ora_e000, ora_e001 , ora_e0002, ora_e0003 y ora_e0004.
La base de datos en cuestion es una oracle database 11.2.0.4
Asi mismo revise que el mismo evento ocurria para las dos otras instancias que tenia en la maquina de computo.
[oracle@exaxxxxxx.com.ar] /home/oracle > ps -ef | grep -i e00 oracle 24719 14021 0 13:28 pts/0 00:00:00 grep -i e00 oracle 42114 1 0 Feb16 ? 00:00:31 ora_e000_ARDOP2 oracle 42118 1 0 Feb16 ? 00:00:33 ora_e001_ARDOP2 oracle 42120 1 0 Feb16 ? 00:00:33 ora_e002_ARDOP2 oracle 42122 1 0 Feb16 ? 00:00:33 ora_e003_ARDOP2 oracle 42124 1 0 Feb16 ? 00:04:37 ora_e004_ARDOP2 oracle 118746 1 0 Mar29 ? 00:00:00 ora_e000_ARTOP2 oracle 118748 1 0 Mar29 ? 00:00:00 ora_e001_ARTOP2 oracle 118750 1 0 Mar29 ? 00:00:00 ora_e002_ARTOP2 oracle 118752 1 0 Mar29 ? 00:00:00 ora_e003_ARTOP2 oracle 118754 1 0 Mar29 ? 00:00:07 ora_e004_ARTOP2 oracle 172631 1 0 Feb23 ? 00:00:27 ora_e000_NTTOP2 oracle 172633 1 0 Feb23 ? 00:00:27 ora_e001_NTTOP2 oracle 172635 1 0 Feb23 ? 00:00:27 ora_e002_NTTOP2 oracle 172637 1 0 Feb23 ? 00:00:28 ora_e003_NTTOP2 oracle 172639 1 0 Feb23 ? 00:03:59 ora_e004_NTTOP2
Vemos el consumo de CPU de los procesos en un nodo sin transacciones: Read more of this post
En el día de hoy estuve revisando un Exadata X5, en el cual pudimos verificar que no estaba cumpliendo con las políticas recomendadas para el tamaño de REDO, para las maquinas de computo 
Oracle Exadata Machine.
Oracle, en su documentación oficial, recomienda que el tamaño de los REDOLOG file deben ser >= 4GB y < 32GB.
Como detalle, es importante saber que no es ideal superar la marca de los 32GB , salvo que se lo requiera el soporte de Oracle.
Esta recomendacion surge, por que la máquina Exadata puede soportar una tasa extrema de I/O.
Con la última versión de Exadata X-6, se pueden realizar operaciones de I/O de lectura de base de datos de 5 KB hasta 8 GB, o operaciones de escritura de flash de 8 MB de 5 MB por segundo por rack completo.
SQL> SELECT a.group#,
b.STATUS,
a.MEMBER,
b.BYTES/1024/1024 "Size (Mb)"
FROM gv$logfile a,
gv$log b
WHERE a.group# = b.group# ;
GROUP# STATUS MEMBER Size (Mb)
---------- ---------------- -------------------------------------------------------------------------------- ----------
1 INACTIVE +RECO_EXA/AMX/onlinelog/AMX_redolog_t1g1m2.log 512
1 INACTIVE +DATA_EXA/AMX/onlinelog/AMX_redolog_t1g1m1.log 512
1 INACTIVE +RECO_EXA/AMX/onlinelog/AMX_redolog_t1g1m2.log 512
1 INACTIVE +DATA_EXA/AMX/onlinelog/AMX_redolog_t1g1m1.log 512
...
...
6 INACTIVE +DATA_EXA/AMX/onlinelog/AMX_redolog_t2g6m1.log 512
6 INACTIVE +RECO_EXA/AMX/onlinelog/AMX_redolog_t2g6m2.log 512
6 INACTIVE +DATA_EXA/AMX/onlinelog/AMX_redolog_t2g6m1.log 512
6 INACTIVE +RECO_EXA/AMX/onlinelog/AMX_redolog_t2g6m2.log 512
48 rows selected.
SQL>
Idealmente, los archivos de registro de REDO on line deben tener el mismo tamaño y estar configurados para cambiar aproximadamente una vez por hora durante la actividad normal.
Es semana tuve una visita en un cliente que debia resolver ciertos problemas de performance relacionados al tiempo de acceso al disco.
Sabiendo que nos podiamos encontrar con diferentes tipos de storage, fui preparado.
Mi sorpresa fue al conoce la noticia que esto ocurria en un Exadata. La experiencia me llevo por el camino de hacer un check general del equipo.
Entre el set list para comenzar con un analisis de performance del Exadata, revise cada uno de los siguientes puntos:
Iremos viendo el resto de los puntos en los siguientes posteos de Exadata. Read more of this post
Buenas Tardes Amigos, esta semana estuve en un cliente donde pude observar en sus instalaciones muchos issues o configuraciones no correctas.
No es culpa del cliente en ningun momento, solamente verifico que parte del equipo tenia muchos erroes de conceptos acerca de Golden Gate como de otros productos.
En parte de mis experiencias, esta semana tuvimos que recuperar varias replicaciones por caidas de plataformas con Golden Gate que no tenian monitoreo ni contaban con politicas de backup adecuadas.
En parte de la recuperacion de las replicas, una en particular debimos hacer nuevamente los Initial Load de tablas, ya que no se encontraban los trails necesarios para aplicar.
Por parte de uno de los DBA locales surgio el siguiente cuestionamiento:
Que debemos utilizar para la comenzar la replica ?? AFTERCSN o ATCSN ??
Y mi respuesta fue:
Cuando instanciamos una nueva base de datos TARGET, con datos provenientes de un SOURCE database, el proceso de REPLICAT debe coincidir y ser coherente con el methodo que elegimos para realizar el INITIAL LOAD.
Por ello:
Juan Andres
