Weblog de Fernando Jose Andrade

Update!

Esto tiene una solución mas sencilla que la anterior. Simplemente hay que seguir los siguientes pasos:

• Bajar la consola como el usario oracle con el comando: emctl stop dbconsole.
• Conectarse a la base de datos con sqplus como el usario SYSMAN y ejecutar el comando: execute MGMT_PAF_UTL.STOP_DAEMON;
• Conectarse a la base de datos con sqplus como el usario SYSMAN ejecutar el comando: execute MGMT_PAF_UTL.START_DAEMON;
• Levantamos la consola como el usuario oracle con el comando: emctl start dbconsole.

El primer comentario lo expone claramente, pero muchas personas me preguntan lo mismo, asi que lo documento aquí.

Links:
http://forums.oracle.com/forums/thread.jspa?messageID=2207494&#2207494
http://edin.no-ip.com/content/100-cpu-usage-overhead-running-em-dbconsole-11g-debian-sid

—-> old post:

Si tienes una instalación nueva de 11g el CPU se pone al 100% por un problema con un trabajo de mantenimiento. La query siguiente pone el CPU a tope.

SELECT EXECUTION_ID, STATUS, STATUS_DETAIL
FROM MGMT_JOB_EXEC_SUMMARY
WHERE JOB_ID = :B3 AND TARGET_LIST_INDEX = :B2 AND EXPECTED_START_TIME = :B1

Al parecer un workaround simple es borrar el trabajo PROVISIONING DAEMON de la tabla sysman.mgmt_job. Por lo pronto el bug se presenta sobre entornos con máquinas virtuales.

La solución de los foros de OTN:

bajar el oem ( emctl stop dbconsole)

create table mgmt_job_bad as select * from sysman.mgmt_job where job_name = ‘PROVISIONING DAEMON’;
delete from sysman.mgmt_job where job_name = ‘PROVISIONING DAEMON’;
commit;

subir el oem (emctl start dbconsole)

Por lo pronto este workaround y a esperar el parche.

Un pequeño post informativo, este mes (Noviembre 2009) estoy muy ocupado. Lamento si no puedo responder los comentarios rápidamente. En Diciembre regreso con fuerza al mundo online.
Slds

FJA