Obrigado por todas as explicações Chiappa, vou analizar tudo e ver qual solução é a melhor para meu caso.
Luiz ________________________________ From: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] On Behalf Of jlchiappa Sent: quarta-feira, 7 de novembro de 2007 22:08 To: oracle_br@yahoogrupos.com.br Subject: [oracle_br] Re: Ajuda com materialized view --- Em oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> , "Luiz Ribeiro" <[EMAIL PROTECTED]> escreveu > > Bom dia. > > > > O que eu queria ao utilizar a materialized view era que a mesma tivesse o mesmo comportamento de uma tabela sincronizada por um trigger no insert, delete e update, ou seja, após cada alteração na tabela origem, se em seguida eu fizer um select na view, os dados estivessem atualizados. Como eu falei em outra msg, ** não é assim ** que a MV funciona, uma MV ou se atualiza ON COMMIT, ou ON DEMMAND, caso este que vc pode ter um job refrescando a mv a cada x minutos ou vc pode fazer refresh manual. > > > > Consegui fazer com que a view seja atualizada somente com um um refresh complete, Colega, vc ** leu ** o manual de DW e o SQL reference ?? neles são ESPECIFICADAS as restrições que impedem uma MV de ser FAST refresh, entre elas : "If you specify REFRESH FAST, Oracle performs further verification of the query definition to ensure that fast refresh can be performed if any of the detail tables change. These additional checks are: * A materialized view log must be present for each detail table. * The rowids of all the detail tables must appear in the SELECT list of the materialized view query definition. * If there are no outer joins, you may have arbitrary selections and joins in the WHERE clause. However, if there are outer joins, the WHERE clause cannot have any selections. Further, if there are outer joins, all the joins must be connected by ANDs and must use the equality (=) operator. * If there are outer joins, unique constraints must exist on the join columns of the inner table. For example, if you are joining the fact table and a dimension table and the join is an outer join with the fact table being the outer table, there must exist unique constraints on the join columns of the dimension table. If some of these restrictions are not met, you can create the materialized view as REFRESH FORCE to take advantage of fast refresh when it is possible. If one of the tables did not meet all of the criteria, but the other tables did, the materialized view would still be fast refreshable with respect to the other tables for which all the criteria are met. A materialized view log should contain the rowid of the master table. It is not necessary to add other columns." ==> veja lá se não é isso.... > Muito obrigado a todos, mas acho que vou ter que partir para os triggers de sincronização mesmo. veja, as triggers ** necessariamente ** disparam a cada DML, no caso de rollback as alterações TEM que serem desfeitas, e ** ainda por cima ** tudo isso via dblink, a não ser que vc tenha uma rede muito muito boa eu sinceramente ** DUVIDO ** que a trigger vá te dar performance melhor.... Pensando em performance, sem dúvida a recomendação (se os seus datatypes permitem, se o banco está em archive mode, etc, etc) seria vc considerar replicação de logs via stream ou mesmo CDC (Change data Capture), se for 10g, no 10g a CDC é feita só se mineirando os log files ao invés de ficar mandando registros inteiros pela rede, é bem mais performática, mas tem as suas restrições.... []s Chiappa [As partes desta mensagem que não continham texto foram removidas]
