2010-11-12 22 views
5

Estoy tratando de reiniciar una base de datos Oracle y estoy viendo el siguiente error:No se puede quitar un usuario que está conectado actualmente

[sql] Failed to execute: drop user conns cascade 
    [sql] java.sql.SQLException: ORA-01940: cannot drop a user that is currently connected 
    [sql] Failed to execute: create user conns identified by conns default tablespace tbs_conns temporary tablespace temp1 
    [sql] java.sql.SQLException: ORA-01920: user name 'CONNS' conflicts with another user or role name 

El problema es que NADIE está conectado: se trata de una instancia en mi computadora local, no hay conexiones externas y yo solo reiniciado y no he ejecutado nada más. Lo único que se me ocurre es que Oracle podría tener alguna tarea en segundo plano (¿limpieza?) Que está causando este problema, pero no tengo ni idea de cómo encontrarlo/gestionarlo. ¿Algunas ideas?

actualización: este script en realidad cae y reinicia un montón de mesas, y después de tratar de volver a ejecutar un par de veces, me dieron el mismo mensaje de error pero en una mesa diferente : Failed to execute: drop user csmy cascade. Después de algunos intentos más, se movió aún a otro usuario: Failed to execute: drop user deb cascade. ¡Algo parece estar bloqueando estas tablas, una a la vez, en orden alfabético!

Actualización 2: después de volver a ejecutar la secuencia de comandos unas 15 veces, cada vez que falla en una tabla un poco más adelante en el alfabeto, ha llegado hasta el final y las cosas están funcionando. Todavía me encantaría saber exactamente qué sucedió, mi mejor estimación es algún proceso de fondo de Oracle, pero no tengo ni idea de cómo verificarlo.

Actualización 3: Volví a encontrar con este mismo problema la última vez que volví a ejecutar el script, esta vez fallando en el "límite" del usuario. Para probar algo nuevo, inicié sqlplus y ejecuté manualmente el comando drop user cap cascade y, he aquí, funcionó bien. Probé el script y se ejecutó hasta su finalización. Por lo tanto, dado que eliminar manualmente a un usuario funciona sin problemas, sospecho fuertemente que el script en sí tiene la culpa.

+1

Si funciona el comando 'drop user cap cascade' (presumiblemente de sql * plus) y su script tiene problemas, entonces sería útil ver su script. –

Respuesta

1

¿El script usa la misma conexión? ¿Está intentando los principales usuarios múltiples caer simultáneamente?

Parece que se produce un error, simplemente continúa con el siguiente paso.

Puede haber dependencias entre objetos en diferentes esquemas que pueden impedir que un objeto en el esquema A se descarte hasta que se descarte un objeto en el esquema B. Como resultado, es posible que no se suelte el esquema A inicialmente, pero se logre un reintento si se ha descartado el esquema B.

+0

Siempre falló al tratar de dejar caer a un usuario, por lo que no veo cómo las dependencias importarían. También fallaría varias veces en el mismo usuario antes de pasar aleatoriamente a otro más adelante en el alfabeto. Buscaré en el script para ver qué sucede con las conexiones y si hay solicitudes simultáneas. –

1

¿Ha consultado desde v $ session para ver quién está conectado? Es posible que tenga una aplicación ejecutándose en algún lugar que se vuelva a conectar automáticamente. Siempre puede iniciar la base de datos en modo restringido o no iniciar el oyente y ejecutar su secuencia de comandos desde una conexión local.

0
  1. Compruebe si todas las conexiones se cerraron correctamente en caso de excepción.

  2. Mire las propiedades de conexión JDBC. Si la agrupación de conexiones o el almacenamiento en caché permitieron que algunas conexiones de la ejecución anterior aún estén activas.

0

Sin consultar su script es difícil saber exactamente qué sucede. Pero puedo asegurarle que la base de datos en sí misma nunca se conecta a usuarios específicos.

Lo que puede hacer es dejar que su código inicie sesión (supongo que su código se ejecuta como un usuario de DBA) y recorrer todos los usuarios que desea eliminar. Para cada una, emita REVOKE CREATE SESSION FROM . Esto inhabilita el inicio de sesión por lo que cualquier código misterioso no podrá conectarse.

+0

Gracias por la sugerencia. Voy a dar una oportunidad la próxima vez. –

0

Tal vez, si se hubiera tratado de un

ALTER SYSTEM DISCONNECT SESSION '<sid>,<serial#>' IMMEDIATE 

(para cada sesión del usuario intenta quitar) antes de caer al usuario, hubiera funcionado?

Sólo conjeturas.

Cuestiones relacionadas