2010-11-12 7 views
5

Je suis en train de ré-initialiser un Oracle DB et je vois l'erreur suivante:Impossible de supprimer un utilisateur qui est actuellement connecté

[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 

Le problème est que PERSONNE NE est connecté: c'est un instance sur mon ordinateur local, pas de connexions extérieures et juste redémarré et n'ont pas exécuté toute autre chose. La seule chose à laquelle je peux penser est qu'Oracle peut avoir une tâche d'arrière-plan (nettoyage) en cours qui cause ce problème, mais je n'ai aucune idée de comment trouver/gérer cela. Des idées?

Mise à jour: ce script tombe réellement et ré-initialise un tas de tables, et après avoir essayé de relancer quelques fois, je reçu le message d'erreur même mais sur une table différente: Failed to execute: drop user csmy cascade. Après quelques essais supplémentaires, il est passé à un autre utilisateur: Failed to execute: drop user deb cascade. Quelque chose semble bloquer ces tableaux, un à la fois, dans l'ordre alphabétique!

Mise à jour 2: après ré-exécution du script environ 15 fois - à chaque fois à défaut à une table un peu plus loin dans l'alphabet - il a obtenu tout le long et les choses fonctionnent. J'aimerais toujours savoir exactement ce qui s'est passé - ma meilleure supposition est un processus de base Oracle, mais je n'ai aucune idée de comment vérifier.

Mise à jour 3: Je suis tombé sur cette même question à nouveau la dernière fois que je re-couru le script, cette fois à défaut sur l'utilisateur « cap ». Pour essayer quelque chose de nouveau, j'ai démarré sqlplus et j'ai exécuté manuellement la commande drop user cap cascade et, voilà, ça a très bien fonctionné. J'ai essayé le script et il a couru à la fin. Par conséquent, étant donné que la suppression manuelle d'un utilisateur fonctionne sans problèmes, je suspecte fortement que le script lui-même soit à blâmer.

+1

Si la commande 'drop user cap cascade' fonctionne (vraisemblablement de sql * plus) et que votre script a des problèmes, il serait utile de voir votre script. –

Répondre

1

Le script utilise-t-il la même connexion? Est-il tentant de supprimer simultanément plusieurs utilisateurs?

Il semble que s'il rencontre une erreur, il continue simplement à l'étape suivante.

Il peut y avoir des dépendances entre des objets dans des schémas différents qui peuvent empêcher un objet dans le schéma A d'être supprimé jusqu'à ce qu'un objet du schéma B soit supprimé. Par conséquent, si vous ne parvenez pas à supprimer le schéma A initialement, mais à réussir une nouvelle tentative si le schéma B a été supprimé.

+0

Il a toujours échoué en essayant de supprimer un utilisateur, donc je ne vois pas comment les dépendances auraient de l'importance. Il échouerait également plusieurs fois sur le même utilisateur avant de se déplacer aléatoirement sur un autre plus tard dans l'alphabet. Je vais regarder dans le script pour voir ce qui se passe avec les connexions et s'il y a des demandes simultanées. –

1

Avez-vous demandé à v $ session de voir qui est connecté? Vous pourriez avoir une application qui s'exécute quelque part qui se reconnecte automatiquement. Vous pouvez toujours démarrer la base de données en mode restreint ou ne pas démarrer l'écouteur et exécuter votre script à partir d'une connexion locale.

0
  1. Vérifiez que toutes les connexions se sont correctement fermées en cas d'exception.

  2. Regardez les propriétés de connexion JDBC. Si le regroupement de connexions ou la mise en cache est activé, certaines connexions de l'exécution précédente peuvent encore être actives.

0

Sans voir votre script, il est difficile de dire exactement ce qui se passe. Mais je peux vous assurer que la base de données elle-même ne se connecte jamais à des utilisateurs spécifiques.Ce que vous pouvez faire est de laisser votre code se connecter (je suppose que votre code s'exécute comme un utilisateur DBA) et faire une boucle sur tous les utilisateurs que vous souhaitez abandonner. Pour chaque, émettez REVOKE CREATE SESSION FROM Cela désactive la connexion pour que tout code mystérieux ne puisse pas se connecter.

+0

Merci pour la suggestion. Je vais donner un coup de feu la prochaine fois. –

0

Peut-être, si vous aviez essayé

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

(pour chaque session de l'utilisateur que vous essayez de tomber) avant de laisser tomber l'utilisateur, il aurait travaillé?

Il suffit de deviner.

Questions connexes