Regenerar el EMC en una 10g es siempre una caja de sorpresas. Como vimos en una entrada anterior la base de datos se pone en modo quiesce al menos hasta una version de parcheado , pero ¨que ocurre si el tiempo pasa y pasa y el proceso no avanza
oracle@server:emca -repos recreate STARTED EMCA at Jun 4, 2012 10:13:56 AM EM Configuration Assistant, Version 10.2.0.1.0 Production Copyright (c) 2003, 2005, Oracle. All rights reserved. Enter the following information: Database SID: ORCL Listener port number: 1521 Password for SYS user: Password for SYSMAN user: Do you wish to continue? [yes(Y)/no(N)]: Y Jun 4, 2012 10:14:11 AM oracle.sysman.emcp.EMConfig perform INFO: This operation is being logged at /opt/oracle/product/10.2.0/db_1/cfgtoollogs/emca/produccion/emca_2012-06-04_10-13-56-AM.log. Jun 4, 2012 10:14:11 AM oracle.sysman.emcp.EMReposConfig dropRepository INFO: Dropping the EM repository (this may take a while) ...
Como deciamos en la entrada anterior, muchas veces la instancia se pone en modo «quiesce», pero , puede haber sesiones que no le dejen ponerse en ese modo, y por eso no pueda ser capaz de eliminar el repositorio.
Si miramos la sesion en la que estamos haciendo el vmos que esta en un evento de espera ‘wait for possible quiesce finish’
mediante la consulta :
Select p.spid, s.osuser, s.machine, s.username, s.sid, s.serial# from v$session s, v$process p where p.addr = s.paddr and s.sid in (select sid from v$lock where type = 'TX');
podemos ver que sesiones son y hacer lo que queramos con ellas ( matarlas o esperar ).
En mi experiencia, las veces que me ha ocurrido la solución ha pasado por hacer estos procesos en una ventana programada en horario en el que no haya usuarios, ya que, cuando la base de datos tiene este tipo de sesiones no suele ser algo excpcional, sino que suele ser parte de la carga habitual de la base de datos y este tipo de sesiones irán apareciendo una tras otra entorpeciendo el proceso de regeneracion de la consola
Como siempre, la solucion la tenía Oracle en la nota [152819.1]