Event Monitor (EMON) Slave Process Constantly Consuming CPU

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

Busco evidencia por medio de Cloud Control en la seccion de Performance Home

Vemos el consumo de CPU de los procesos en un nodo sin transacciones:

El consumo de CPU, disparado por el proceso EMON:

Revisando en Oracle Support, me encuentro con que existe un bug no publicado, “Bug 9735536

En la misma hace mencion y referencia a que ello impacta de las version 11.2.0.3 hasta la 12.1.0.2

Resolucion

Existen dos tipos de soluciones:

La solucion para la version 11.2.0.3:

Aplicar un workaround, haciendo un kill de los procesos E00*

Ejemplo:

Identificar el proceso

ps -ef | grep -i e00

Matar el proceso:

kill -9

Ejecucion del Proceso en ambos casos:

[oracle@exa2adbadm02] /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

[oracle@exa2adbadm02] /home/oracle > kill -9 42114 42118 42120 42122 42124 118746 118748 118750 118752 118754 172631 172633 172635 172637 172639

El proceso slave conocido como EMON, se restarteara immediatamente que sea requerido, liberando el consumo d CPU.

El consumo en la etapa de accion del bug y la manera en que desciende cuando aplico el workaround por kill.

Para resolver este problema de manera estatica y definitiva

version 11.2.0.3

Se debe aplicar el Patch 9735536: E/H: SLOW DCN SUBSCRIBERS CAUSE EMON TO BLOCK OTHER SESSIONS.

No hay que aplicar ningun tipo de cambio undescore. Pay Attention !!

version 11.2.0.4 o superior

La solucion estatica para las versiones 11.2.0.4 a version 12.1.0.2 es un workaround:

SQL> alter system set "_client_enable_auto_unregister"=true scope=spfile sid='*';

System altered.

Reinicio la Base de datos (En mi caso es un RAC  de dos nodos):

srvctl stop database -d 
srvctl start database -d 
srvctl status database -d 
srvctl status service -d 

Reviso la aplicacion del parametro

SQL> sho parameter _client_enable_auto_unregister

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
_client_enable_auto_unregister       boolean     TRUE
SQL>

Espero les sea de utilidad !!