Menu de navegação

[rmanParticipante]

Olá,

O que vocês acham sobre visão materializada + dblink como solução de integração de sistema ? Alguém utiliza isso como solução ?

Essa é uma proposta para evitar trabalhar com exportação/importação de arquivo.

Uma dúvida, se o banco de dados de origem ficar off, é possível ainda continuar a consultar o destino normalmente ? Lembrando que é materializada…

Outra coisa, se o destino ficar off, quando ele voltar vai haver a sincronização de forma automática ?

[Regis AraujoParticipante]

Rman, bom dia.!

Qual a versão dos bancos?

Vc precisa ter quantas tabelas “sincronizadas”?

O que vc pode fazer é criar uma replicação entre estes sites.. onde a mesma pode ser unidirecional ou bidirecional…

Como vc falou de views, vc pode utilizar o Advanced Replication.

De uma lida neste link.. ele mostra como criar uma replicação usando Materialized Views..

http://docs.oracle.com/cd/B28359_01/ser … reppit.htm

Atualmente eu trabalho com este tipo de replicação e também com replicação via Streams..

Pelo que vc relatou, se for usado replicação via materialized view, sim, se o target cair.. quando voltar atualiza e vice-versa…

Abraços..!

[rmanParticipante]

@Thunder_Catz

Os bancos estão em 10g R2 (10.2.0.4.0)

Quando a origem cair, o destino continua normalmente, o que é afetado é apenas a sincronização ?

É em torno umas 10 tabelas.

Inicialmente foi trabalhado visão + dblink, mas acharam que estava lento, então foi proposto visão materializada + dblink.

O ideal seria apenas visão + dblink, pois só é leitura, e não ocupa espaço em disco, existe algo que melhore o desempenho do dblink ?

[Regis AraujoParticipante]

Ola Rman..!

Então.. com View se a origem cair o destino não encontra mais os dados.. pois quando o select é em cima da view, o oracle simplesmente executa o comando q está abaixo dela..

Quando é materialized view, ai existe uma outra “tabela” com os dados.. então desta maneira se a origem cair o destino funciona normalmente.. somente terá os dados desatualizados.. quando a origem retornar.. basta fazer o refresh da MV que os dados faltantes serão atualizados, porém quando estiver havendo a atualização haverá a lentidão..

Com MV o impacto é menor, pois vai depender do tipo de refresh q vc optou quando criou a MV. Caso vc opte por criar uma replicação via MV, vc pode configurar os grupos de replicação de acordo com sua necessidade.. se a atualização nas tabelas origens for constante mas em pouquissima quantidade, vc vai poder configurar como tempo de atualização a cada 1 hora ou menos, mas se a atualização nestas tabelas for constante e com muita quantidade, vc pode optar por atualiza-la com um intervalo maior, garantindo assim um tempo de “lentidão” menor..

Não tem uma maneira de melhorar o desempenho do DBLINK, pois está atrelado a sua banda, melhorando a banda de comunicação melhora o DBLINK..

Atualmente utilizo este tipo de replicação em algumas tabelas que são atualizadas em lote mas apenas 1 vez ao dia.. para as demais tabelas que são atualizadas constantemente eu uso a replicação via Oracle Streams.. porém minha replicação é bi-direcional e preciso destes dados online em todos os sites..!!!

Abraços..!

[rmanParticipante]

@Thunder_Catz

O que você me diz da opção ON COMMIT da visão materializada ? Com isso ficaria praticamente on line ? A cada commit os dados são replicados ?

Essa integração é para o sistema de geoprocessamento.

[Regis AraujoParticipante]

@Rman <— (vou começar a usar isto.. kkkk) Boa tarde..!

Sim, com a opção fast REFRESH FAST ON COMMIT você terá a atualização efetuada a cada commit, não precisará rodar a atualização manualmente, desta maneira terá as duas tabelas sincronizadas quase que online.. Pois isto vai depender do tamanho da atualização..

Na MV quando vc realiza um comando DML, o Oracle joga os dados alterados para a MVLOG da tabela que é uma fila de comandos a serem replicados.. se sua tabela for alterada em lote constantemente e sua banda não for muito alta, poderá ocorrer um atraso na replicação, como também uma lentidão na consulta..

É uma otima opção para sincronização de ambientes!

Mas com esta opção.. a tabela origem não poderá sofrer uma transação distribuida.. pois dará erro..

Abraços..!

[rmanParticipante]

@Thunder_Catz

Pensando em REFRESH FAST ON COMMIT, aquela pergunta que eu fiz ainda continua valida ?

Se a origem ou destino ficar off, quando voltar como é feita a sincronização ? Pensando que é feita através do COMMIT, o COMMIT gerado no momento o destino estava off não foi, quando ele irá ser replicado ?

[Regis AraujoParticipante]

@Rman

A atualização será efetuada após a comunicação ser reestabelecida e houver outro commit na tabela origem, pois como havia dito, os comandos ficarão “enfileirados” na MVLOG, mas eu prefiro sempre neste tipo de situação rodar uma atualização manualmente, dependendo da tabela rodar até mesmo um COMPLETE.

Eu gosto sempre de realizar testes, você pode fazer um teste primeiro. Cria uma nova entrada no TNSNAMES do banco destino para o banco origem.. cria uma tabela no banco origem e faz a MV no destino.. Comenta esta entrada no TNSNAMES e faz inserts|update|delete no banco origem.. vai no banco destino e pesquisa estes registros.. depois descomenta a entrada no TNSMAMES, realiza uma nova alteração no banco origem e novamente consulta a tabela no banco destino.

Você ira verificar que a atualização foi efetuada.

Desta maneira vc poderá ate mesmo testar outras formar de REFRESH e verificar qual é a melhor estratégia.

Abraços..

[Autor]

Posts