Ótimo! Mto obg pela sugestão! Fiz diversos testes e sofri alguns problemas. Na verdade eu tinha esquecido de citar que a master table está em uma máquina diferente da máquina onde se encontra a view materializada.
Não consegui tornar a view ON COMMIT. Nesse caso é retornado o erro: ORA-12054: cannot set the ON COMMIT refresh attribute for the materialized view. Outro problema é que criei a view materialized log e tornei a minha view REFRESH FAST. Mas simplesmente não atualiza quando eu faço qualquer mudança na table master, embora tenha executado um CONSIDER FRESH. Gostaria de atualizar a minha mv incrementalmente visto que os dados a serem carregados são numerosos. Desde já agradeço! --- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <[EMAIL PROTECTED]> escreveu > > Desconheço uma documentação porque é algo meio óbvio, derivam dos > conceitos de vm e trigger as vantagens da vm sobre o trigger para > replicação oracle -> oracle : > > a. um trigger dispara NO MOMENTO em que houve o INSERT/UPDATE/DELETE, > onerando portanto o DML já no momento da execução, enquanto a vm (se > for refresh on commit) só dispara o processo de refresh em tempo de > commit, após portanto o processamento (já que pro recomendação o > commit é a última coisa na transação) > > b. falando em overhead, se possível a mv pode ser refrescada de tempos > em tempos apenas, a cada X minutos digamos, FORA da transação que > ocorreu, o que diminui AINDA MAIS (praticamente ZERA) o impacto na > transação original > > c. a vm não trabalha com registro a registro, mas sim com uma QUERY > que é executada por trás dela, tal query pode ter (por exemplo) GROUP > BYs (já guardando os dados agrupados/somados o que precisar), > enquanto que triggers NECESSARIAMENTE são FOR EACH ROW... Até se pode > ter a trigger enfiando os registros individuais numa tabela stage que > depois vc "massageia" via outra rotina, mas isso implica em mais > espaço em disco, mais escrita, mais overhead pro banco, mais trabalho > pro programador... > > d. a vm tem o materialized view log, que possui colunas indicando o > último refresh e algumas infos administrativas do tipo, sem requerer > programação alguma, triggers (claro) podem ter isso desde que vc sente > e programe > > ==> então pra mim é claro : sempre usar VMs, desde que : > > - a sua versão de banco permita > - a sua query respeite as regras de complexidade para fast refresh > (refresh completo da vm a cada atualização via de regra já eleimina > MUITAS das vantagens da vm) > - vc não viole as limitações (de datatype e algumas outras) da vm > > imho trigger pra replicação de dados só mesmo se esses pre-reqs não > são atendidos, aí sim... > > []s > > Chiappa > --- Em oracle_br@yahoogrupos.com.br, "zidvlauns" <zidvlauns@> escreveu > > > > Olá! > > > > Alguém tem alguma documentação sobre o que compensa mais usar para > > fazer uma replicação de dados entre esquemas: view materialida ou > trigger? > > > > Desde já obg! > > >
