J'ai couru dans la question décrit ici plusieurs fois dans notre projet actuel et j'aimerais comprendre comment cela se passe et comment l'empêcher à l'avenir.
DBA_SUMMARIES
Et pourquoi les entrées sont-elles créées pour les MV d'un utilisateur?Le principal problème est que les privilèges SYSDBA
sont nécessaires pour supprimer le résumé contradictoire. Étant donné que nous n'avons pas de compte SYSDBA
sur l'instance cible, nous ne pouvons pas recréer notre MVS sans avoir une personne sur l'équipe de support de DB.
Tous les pointeurs à la documentation et si quelqu'un peut expliquer quelle est la logique derrière DBA_SUMMARIES
est et comment je peux empêcher cette question de se produire, ce serait génial.
La version Oracle sur laquelle nous avons observé ceci est 11.2.0.1.0 (sur 64bit Linux), nous n'avons pas de contrat de support et donc aucun accès à Oracle Support.
mise à jour/solution
Grâce à la réponse de Jack ci-dessous, j'ai pu contourner le problème, car il semble que nous ayons vraiment frappé le bug qu'il a mentionné. Lorsque je dépose d'abord tous tous les index sur le MV, je ne reçois pas le message d'erreur et je suis capable de recréer le MV comme prévu (il ne s'affiche pas dans USER_OBJECTS
plus après avoir été abandonné).
C'est comme ça que je le fais maintenant (coupé pour la brièveté):
SET serveroutput ON
SET echo ON
DECLARE
CURSOR mv_indexes
IS
SELECT 'DROP INDEX '
|| index_name AS stmt
FROM user_indexes
WHERE table_name = 'MV_NAME'
AND table_owner = 'USER';
BEGIN
FOR ix IN mv_indexes
LOOP
dbms_output.put_line('Executing: ' || ix.stmt);
EXECUTE immediate ix.stmt;
END LOOP;
END;
/
DROP materialized VIEW MV_NAME;
SELECT * FROM user_objects WHERE object_name = 'MV_NAME';
CREATE materialized VIEW MV_NAME ..
CREATE INDEX ix_someindex ON MV_NAME (..);
CREATE INDEX..
J'ai eu le même problème. Trouvé dans metalink et cela a fonctionné pour moi:
connect /as sysdba
drop summary owner.mv_name;
connect owner/pwd
create materialized view ...;
Cela fonctionnera cette fois.
Merci, M.