Olá Eriovaldo! A coluna FAILURES está = 0 sim, hoje eu percebi que não é mesmo refresh que a faz ficar invalida, e sim a quando ocorre algum insert ou update em alguma tabela que a view utiliza. E se você recompilar, ela fica valida novamente, porém quando ocorre alguma alteração ou inserção ela volta novamente a ficar invalida.
Quanto aos dados, eu analisei e atualiza corretamente, só que o me intriga é está invalida, pois para um sistema de monitoramento que temos aqui internamente, ele nos alerta como se estivesse com se esse cliente estivesse com esse erro, sempre. Em 13 de janeiro de 2015 08:37, Eriovaldo Andrietta ecandrie...@gmail.com [oracle_br] <oracle_br@yahoogrupos.com.br> escreveu: > > > Olá, > > Mária Cristina, > > 1.) Se você olhar a coluna user_jobs.failure e a mesma estiver com 0 > (zero) significa que o refresh da mview está acontecendo sem erros e o > resultado esperado está garantido. > > 2.) Já vi uma análise desse tipo onde esse INVALID significa que os dados > deste objetos não são mais válidos, pois alguma das tabelas envolvidas foi > alterada. Para comprovar isso, execute o refresh da mview e veja de > imediato se ela fica válida, e logo em seguida altere alguma tabela que > está na mview e veja o que acontece. > > Espero que isso ajude. > > Eriovaldo > > > > Em 13 de janeiro de 2015 07:48, Mária Cristina Silva Stricker > mariancrist...@gmail.com [oracle_br] <oracle_br@yahoogrupos.com.br> > escreveu: > >> >> >> 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 >> >> > > -- Abraços, Mária Cristina Cel: 031-8883-5543 E-mail: mariancrist...@gmail.com MSN: mcristinasil...@hotmail.com -- "O começo é a parte mais importante do trabalho." - Platão
