Bom dia! Agradeço as alternativas mas não tem nenhuma das suas suposições aplicadas a este caso, eu verifiquei todos os objetos que poderiam ser dependentes mas nenhum estão inválidos, simulei o ambiente criando MV minhas, criei as tabelas e criei a MV sobre essas tabelas para realizar os teste, pensando que poderia ser algo assim, porem a MV ficou invalida também, só que não pelo refresh, e sim quando insiro um valor na tabela(acabei descobrir isso, que não é pelo refresh), qualquer insert feito ou alteração realizada na tabela está deixando a MV invalida.
Essas tabelas não tem dependência nenhumas, não tem problema com permissão de role, simplesmente foram criadas para fazer esse TESTE, e deu o mesmo erro. Verifiquei na Internet vi que tem muitos deste problema, mas as soluções são paleativas e não definitivas. Gostaria de saber se alguém já passou por isso e pode me orientar, pensei em ser um BUG, pois só ocorre quando a MV tem JOIN relacionados, elas funcionam normalmente, mas ficam invalidas. Agradeço atenção. Abraços a todos. Em 13 de janeiro de 2015 06:45, jlchia...@yahoo.com.br [oracle_br] < oracle_br@yahoogrupos.com.br> escreveu: > > > Eu consigo pensar nas seguintes possibilidades : > > a. Qualquer um dos objetos referenciados pela mv foi alterado por DDL e/ou > se tornou inválido por alterações/recompilações nas dependências deles, aí > a mv fica inválida também > > ou > > b. A MV ** não é ** de REFRESH ON COMMIT, aí OBVIAMENTE qualquer operação > (DML inclusive!!) deixou os dados/estrutura da mv diferentes dos > dados/estrutura nas tabelas/objetos referenciados pela mv e assim causa > status de invalid na mv : vide nota metalink "After DML on the Master > Table(s) of Local Materialized View, USER_MVIEWS.COMPILE_STATE becomes > 'NEEDS_COMPILE' and USER_OBJECTS.STATUS becomes 'INVALID'" (Doc ID 264036.1) > > ou > > c. os privilégios foram dados via ROLE, aí a recompilação não os rechonece > : vide nota "Compile Makes Materialized View Invalid When Access to Master > Table Granted Via Role" (Doc ID 781255.1) > > e variações destes temas.... Principalmente se não há DBA fixo nesse seu > cliente, eu ** suspeitaria ** da alternativa a acima : tipicamente num caso > desses é a farra do boi, neguim sai alterando tabelas a qquer minuto, sem > planejar, sem saber quais objs dependem dela, e sem avisar ninguém... Mas > levante a situação exata e a analise para saber exatamente o que está > causando e assim poder propor um fix, que MUITO PROVAVELMENTE será de > procedimento, não me parece ser ** nenhum ** tipo de BUG ou Problema > Técnico no database, parece ser mesmo é erro humano ou ignorância dos > Conceitos de mv... > > []s > > Chiappa > > -- Abraços, Mária Cristina E-mail: mariancrist...@gmail.com MSN: mcristinasil...@hotmail.com -- "O começo é a parte mais importante do trabalho." - Platão
