Re: RES: [oracle_br] Triggers de replicação.
É que é uma tabela de clientes, e tenho que ter as duas identicas nas duas instancias diferentes e não há a possibilidade de ter uma unica tabela. - Original Message - From: Celso Henrique Souza To: oracle_br@yahoogrupos.com.br Sent: Wednesday, May 23, 2007 9:00 AM Subject: Res: RES: [oracle_br] Triggers de replicação. tente inativar a trigger Celso Henrique O. Souza - Mensagem original De: Fabio Santos <[EMAIL PROTECTED]> Para: oracle_br@yahoogrupos.com.br Enviadas: Terça-feira, 22 de Maio de 2007 19:36:03 Assunto: RES: [oracle_br] Triggers de replicação. pelo o que entendi, vc quer manter sempre duas tabelas iguais. se elas serao sempre as duas iguais, porque existir as duas e nao apenas uma? -Mensagem original- De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Eduardo Enviada em: terça-feira, 22 de maio de 2007 17:40 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Triggers de replicação. Olá galera, Tenho 1 triggers q replica dados de uma tabela p/ outra. Tipo tabela1 p/ tabela2. Tenho q fazer o inverso agora, mas trava tudo. Com certeza é pq uma trigger dispara a outra. Como resolvo isso ? Aguarda a ajuda dos amigos... Edu... [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas] >Apostilas » Dicas e Exemplos » Funções » Mundo Oracle » Package » Procedure » Scripts » Tutoriais acesse: http://www.oraclebr.com.br/codigo/ListaCodigo.php -- >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -- >O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: http://www.oraclebr.com.br/ -- Links do Yahoo! Grupos __ Fale com seus amigos de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/ [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas]
Re: RES: [oracle_br] Triggers de replicação.
Amigos... Obrigado pelas explicações, vou tentar fazer o correto mesmo... valeu mesmo... - Original Message - From: jlchiappa To: oracle_br@yahoogrupos.com.br Sent: Wednesday, May 23, 2007 2:28 PM Subject: Re: RES: [oracle_br] Triggers de replicação. Colega, sendo ou não sistema fechado, o que é errado é errado, no way, triggers absolutamente NÂO SÃO recomendáveis pra replicação, MONTES de efeitos colaterais possíveis 9sendo essa questão de disparo recursivo UM deles), se vc quer fazer algo direito nas condições atuais AO MENOS alguma mudança na aplicação (criação de objetos como update materialized view, alteração de colunas, criação de sinônimos, uso de API, o que for) vc TEM QUE ter Quanto à pergunta, não, não há nenhuma maneira nativa - vc em tese vc até poderia instrumentar a aplicação para que além de fazer o INSERT na tabela remota sinalizasse isso em algum lugar (arquivo, tabela, o que for) acessível ao outro banco, mas NOVAMENTE caímos na tecla de alteração de aplicação... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "Eduardo" <[EMAIL PROTECTED]> escreveu > > Jlchiappa, > > Concordo plenamente com vc que e uma logica errada. Mas e que o sistema e fechado e ja tentei brigar com os desenvolvedores unificar isso, mas sem sucesso ainda. Vou analisar tudo que vc falou e pensar em alguma coisa, mas vai ter que ser on-line, a diferenca ai e que nao vou ter DELETE, somente INSERT E UPDATE nas duas tabelas. Essa ideia do Fernando p/ identificar se vem da trigger o pedido de INSERT E UPDATE acho que resolveria,a droga é que não posso mexer na estrutura dessas tabelas. Será que tem alguma forma nativa de saber se o pedido DML´s vem da trigger ? > > > edu... > > > > - Original Message - > From: jlchiappa > To: oracle_br@yahoogrupos.com.br > Sent: Wednesday, May 23, 2007 1:41 PM > Subject: Re: RES: [oracle_br] Triggers de replicação. > > > Bota complexo nisso, Fernandes Eduardo, pra vc entender, pense > por exemplo no seguinte caso, ao mesmo tempo o banco A pede um update > na tabela e o banco B pede um delete, COMO que vc vai permitir que > ambos executem são coisas EXCLUDENTES, vc não pode updatear o que > está sendo deletado, é óbvio... Conflitos desse tipo é o que torna > replicação onde ambos os lados podem fazer DMLs algo muuuito > complexo - a tua abordagem de triggers é realmente, completamente > ilógica, veja só : o banco A tem um trigger de INSERT na tabela T que > faz insert na tabela T do banco B, E no banco B temos trigger que > faz INSERT no A - ora, quando alguém mandar um insert no banco A > (digamos), a trigger disparou e enviou um comando INSERT no B, ocorre > que B recebendo o insert a trigger de insert dispara , que manda um > INSERT no A, trigger do A dispara , manda INSERT no B, trigger N > dispara Sacou a MONSTRUOSIDADE que vc tem feita aí ??? Só podia > MESMO dar errado, vc tem em mãos uma lógica SEM A MENOR lógica... > Bem, já que vc está escrevendo algo eu SUPONHO que : > > - vc tem dblink entre os bancos (óbvio) > - hoje as duas tabelas são EXATAMENTE iguais > - e que as features de replicação nativas do banco (inclusive > replicação master/master) não podem ser usadas por algum motivo > > OBS : E vc diz que não pode ter uma tabela só (o que seria *** MESMO > *** o mais fácil, eu tentaria MESMO batalhar por isso, mostre e > explique pro teu cliente a complicação que é), vamos assumir que seja > assim. .. > > Muito bem, nesse cenário de duas tabs, vc tem duas possibilidades > principais, SERIALIZAÇÃO e ROTINA DE ATUALIZAÇÂO. Serialização seria > algo do tipo : o dono das tabelas NÃO DÁ grants de > INSERT/UPDATE/DELETE pra ninguém, ao invés da GRANT de execute em > APIs (rotinas PL/SQL) apropriadas (uma pra INSERT, outra pra UPDATE e > outra pra DELETE, digamos), e nessas rotinas antes de executar o DML > vc manda um SELECT FROM tabela FOR UPDATE no registro da tabela local > que está sendo alterado E um SELECT FROM [EMAIL PROTECTED] FOR > UPDATE na tabela remota para esse mesmo registro, se conseguiu lockar > ambos blz, vc manda o DML no registro local E no registro do bd > remoto, se não conseguiu locar ambos os registros vc manda um erro > pro usuário e manda o usuário pesquisar de novo daqui a pouco, > trazendo assim a info refrescada, E refazer a operação passando os > eventuais novos valores lidos pra API, e assim vai até conseguir. > Já Atualização é a mais complexa, é o que outros colegas sugeriram, > seria vc ter algum tipo de LOG das operações (n
Re: RES: [oracle_br] Triggers de replicação.
Colega, sendo ou não sistema fechado, o que é errado é errado, no way, triggers absolutamente NÂO SÃO recomendáveis pra replicação, MONTES de efeitos colaterais possíveis 9sendo essa questão de disparo recursivo UM deles), se vc quer fazer algo direito nas condições atuais AO MENOS alguma mudança na aplicação (criação de objetos como update materialized view, alteração de colunas, criação de sinônimos, uso de API, o que for) vc TEM QUE ter Quanto à pergunta, não, não há nenhuma maneira nativa - vc em tese vc até poderia instrumentar a aplicação para que além de fazer o INSERT na tabela remota sinalizasse isso em algum lugar (arquivo, tabela, o que for) acessível ao outro banco, mas NOVAMENTE caímos na tecla de alteração de aplicação... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "Eduardo" <[EMAIL PROTECTED]> escreveu > > Jlchiappa, > > Concordo plenamente com vc que e uma logica errada. Mas e que o sistema e fechado e ja tentei brigar com os desenvolvedores unificar isso, mas sem sucesso ainda. Vou analisar tudo que vc falou e pensar em alguma coisa, mas vai ter que ser on-line, a diferenca ai e que nao vou ter DELETE, somente INSERT E UPDATE nas duas tabelas. Essa ideia do Fernando p/ identificar se vem da trigger o pedido de INSERT E UPDATE acho que resolveria,a droga é que não posso mexer na estrutura dessas tabelas. Será que tem alguma forma nativa de saber se o pedido DML´s vem da trigger ? > > > edu... > > > > - Original Message - > From: jlchiappa > To: oracle_br@yahoogrupos.com.br > Sent: Wednesday, May 23, 2007 1:41 PM > Subject: Re: RES: [oracle_br] Triggers de replicação. > > > Bota complexo nisso, Fernandes Eduardo, pra vc entender, pense > por exemplo no seguinte caso, ao mesmo tempo o banco A pede um update > na tabela e o banco B pede um delete, COMO que vc vai permitir que > ambos executem são coisas EXCLUDENTES, vc não pode updatear o que > está sendo deletado, é óbvio... Conflitos desse tipo é o que torna > replicação onde ambos os lados podem fazer DMLs algo muuuito > complexo - a tua abordagem de triggers é realmente, completamente > ilógica, veja só : o banco A tem um trigger de INSERT na tabela T que > faz insert na tabela T do banco B, E no banco B temos trigger que > faz INSERT no A - ora, quando alguém mandar um insert no banco A > (digamos), a trigger disparou e enviou um comando INSERT no B, ocorre > que B recebendo o insert a trigger de insert dispara , que manda um > INSERT no A, trigger do A dispara , manda INSERT no B, trigger N > dispara Sacou a MONSTRUOSIDADE que vc tem feita aí ??? Só podia > MESMO dar errado, vc tem em mãos uma lógica SEM A MENOR lógica... > Bem, já que vc está escrevendo algo eu SUPONHO que : > > - vc tem dblink entre os bancos (óbvio) > - hoje as duas tabelas são EXATAMENTE iguais > - e que as features de replicação nativas do banco (inclusive > replicação master/master) não podem ser usadas por algum motivo > > OBS : E vc diz que não pode ter uma tabela só (o que seria *** MESMO > *** o mais fácil, eu tentaria MESMO batalhar por isso, mostre e > explique pro teu cliente a complicação que é), vamos assumir que seja > assim. .. > > Muito bem, nesse cenário de duas tabs, vc tem duas possibilidades > principais, SERIALIZAÇÃO e ROTINA DE ATUALIZAÇÂO. Serialização seria > algo do tipo : o dono das tabelas NÃO DÁ grants de > INSERT/UPDATE/DELETE pra ninguém, ao invés da GRANT de execute em > APIs (rotinas PL/SQL) apropriadas (uma pra INSERT, outra pra UPDATE e > outra pra DELETE, digamos), e nessas rotinas antes de executar o DML > vc manda um SELECT FROM tabela FOR UPDATE no registro da tabela local > que está sendo alterado E um SELECT FROM [EMAIL PROTECTED] FOR > UPDATE na tabela remota para esse mesmo registro, se conseguiu lockar > ambos blz, vc manda o DML no registro local E no registro do bd > remoto, se não conseguiu locar ambos os registros vc manda um erro > pro usuário e manda o usuário pesquisar de novo daqui a pouco, > trazendo assim a info refrescada, E refazer a operação passando os > eventuais novos valores lidos pra API, e assim vai até conseguir. > Já Atualização é a mais complexa, é o que outros colegas sugeriram, > seria vc ter algum tipo de LOG das operações (numa outra tabela, num > arquivo, via FLAG, o que for), log esse sequencial e disponível a > AMBOS os bancos, que a cada período (no fim do dia, talvez) seria > aplicado com a aplicação OFFLINE. > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, "FERNANDES Marco A SOFTTEK" >escreveu > > > > Eduardo, &g
Re: RES: [oracle_br] Triggers de replicação.
Jlchiappa, Concordo plenamente com vc que e uma logica errada. Mas e que o sistema e fechado e ja tentei brigar com os desenvolvedores unificar isso, mas sem sucesso ainda. Vou analisar tudo que vc falou e pensar em alguma coisa, mas vai ter que ser on-line, a diferenca ai e que nao vou ter DELETE, somente INSERT E UPDATE nas duas tabelas. Essa ideia do Fernando p/ identificar se vem da trigger o pedido de INSERT E UPDATE acho que resolveria,a droga é que não posso mexer na estrutura dessas tabelas. Será que tem alguma forma nativa de saber se o pedido DML´s vem da trigger ? edu... - Original Message - From: jlchiappa To: oracle_br@yahoogrupos.com.br Sent: Wednesday, May 23, 2007 1:41 PM Subject: Re: RES: [oracle_br] Triggers de replicação. Bota complexo nisso, Fernandes Eduardo, pra vc entender, pense por exemplo no seguinte caso, ao mesmo tempo o banco A pede um update na tabela e o banco B pede um delete, COMO que vc vai permitir que ambos executem são coisas EXCLUDENTES, vc não pode updatear o que está sendo deletado, é óbvio... Conflitos desse tipo é o que torna replicação onde ambos os lados podem fazer DMLs algo muuuito complexo - a tua abordagem de triggers é realmente, completamente ilógica, veja só : o banco A tem um trigger de INSERT na tabela T que faz insert na tabela T do banco B, E no banco B temos trigger que faz INSERT no A - ora, quando alguém mandar um insert no banco A (digamos), a trigger disparou e enviou um comando INSERT no B, ocorre que B recebendo o insert a trigger de insert dispara , que manda um INSERT no A, trigger do A dispara , manda INSERT no B, trigger N dispara Sacou a MONSTRUOSIDADE que vc tem feita aí ??? Só podia MESMO dar errado, vc tem em mãos uma lógica SEM A MENOR lógica... Bem, já que vc está escrevendo algo eu SUPONHO que : - vc tem dblink entre os bancos (óbvio) - hoje as duas tabelas são EXATAMENTE iguais - e que as features de replicação nativas do banco (inclusive replicação master/master) não podem ser usadas por algum motivo OBS : E vc diz que não pode ter uma tabela só (o que seria *** MESMO *** o mais fácil, eu tentaria MESMO batalhar por isso, mostre e explique pro teu cliente a complicação que é), vamos assumir que seja assim. .. Muito bem, nesse cenário de duas tabs, vc tem duas possibilidades principais, SERIALIZAÇÃO e ROTINA DE ATUALIZAÇÂO. Serialização seria algo do tipo : o dono das tabelas NÃO DÁ grants de INSERT/UPDATE/DELETE pra ninguém, ao invés da GRANT de execute em APIs (rotinas PL/SQL) apropriadas (uma pra INSERT, outra pra UPDATE e outra pra DELETE, digamos), e nessas rotinas antes de executar o DML vc manda um SELECT FROM tabela FOR UPDATE no registro da tabela local que está sendo alterado E um SELECT FROM [EMAIL PROTECTED] FOR UPDATE na tabela remota para esse mesmo registro, se conseguiu lockar ambos blz, vc manda o DML no registro local E no registro do bd remoto, se não conseguiu locar ambos os registros vc manda um erro pro usuário e manda o usuário pesquisar de novo daqui a pouco, trazendo assim a info refrescada, E refazer a operação passando os eventuais novos valores lidos pra API, e assim vai até conseguir. Já Atualização é a mais complexa, é o que outros colegas sugeriram, seria vc ter algum tipo de LOG das operações (numa outra tabela, num arquivo, via FLAG, o que for), log esse sequencial e disponível a AMBOS os bancos, que a cada período (no fim do dia, talvez) seria aplicado com a aplicação OFFLINE. []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "FERNANDES Marco A SOFTTEK" <[EMAIL PROTECTED]> escreveu > > Eduardo, > seu caso é bem crítico... duas tabelas iguais, as duas online, > as duas recebem comandos INS, DEL, UPD... complicado. > E ainda não pode unificar ! piorou ! > > Uma coisa é certa ! trigger fazendo atualização cruzada > não vai funcionar mesmo !!! sem dúvida ! > > O ideal seria centralizar a atualização ! atualizar apenas em > uma delas e replicar pra outra... minimiza muito o trampo ! > > Agora, solução sempre tem ! opção sempre tem ! e cada caso > se resolve de forma específica... respostas genéricas apenas dão > uma noção pra onde vc deve atirar. > > Uma opção seria, cria um terceira tabela que controla a atualização. > Ou seja, nela vc coloca apenas a chave e uma ou duas colunas de > controle. E coloca um processo à parte, pode ser um job ou outra > coisa, que rode de tempos em tempos (sem muita defasagem) pra > ler a tabela de controle e atualizar as tabelas. > Nessa tabela de controle vc colocaria além da chave de atualização, > uma coluna com o controle, tipo um flag (bandeirinha) que sinaliza > em qual sentido deve ser a atualização e se está pendente ou realizada. >
Re: RES: [oracle_br] Triggers de replicação.
tipo um flag (bandeirinha) que sinaliza > > em qual sentido deve ser a atualização e se está pendente ou > realizada. > > Por exemplo, vc cria uma coluna CHAR(1) com uma espécie de > protocolo: > > A - atualizar tabela 1 com dados da tabela 2, status pendente > > B - atualizar tabela 2 com dados da tabela 1, status pendente > > C - atualizada tabela 1 com dados da tabela 2, status realizado > > D - atualizada tabela 2 com dados da tabela 1, status realizado > > sendo que este últimos poderia não existir e nesse caso vc apenas > apagaria > > estes registros, ou seja, se existe é pq está pendente... caso > contrário > > já apagaria da tabela... tudo depende se vc vai precisar de > auditoria e > > histórico das transações. > > > > Espero ter dado mais um pouco de luz ! risos > > > > Abraço, > > Marco. > > > > > > > > From: oracle_br@yahoogrupos.com.br > [mailto:[EMAIL PROTECTED] On Behalf Of PUB: Eduardo > > Sent: quarta-feira, 23 de maio de 2007 10:55 > > To: oracle_br@yahoogrupos.com.br > > Subject: Re: RES: [oracle_br] Triggers de replicação. > > > > > > > > É que é uma tabela de clientes, e tenho que ter as duas identicas > nas duas instancias diferentes e não há a possibilidade de ter uma > unica tabela. > > > > - Original Message - > > From: Celso Henrique Souza > > To: oracle_br@yahoogrupos.com.br <mailto:oracle_br% > 40yahoogrupos.com.br> > > Sent: Wednesday, May 23, 2007 9:00 AM > > Subject: Res: RES: [oracle_br] Triggers de replicação. > > > > tente inativar a trigger > > > > Celso Henrique O. Souza > > > > - Mensagem original > > De: Fabio Santos mailto:santos%40brassites.com.br> > > > Para: oracle_br@yahoogrupos.com.br <mailto:oracle_br% > 40yahoogrupos.com.br> > > Enviadas: Terça-feira, 22 de Maio de 2007 19:36:03 > > Assunto: RES: [oracle_br] Triggers de replicação. > > > > pelo o que entendi, vc quer manter sempre duas tabelas iguais. se > elas > > serao sempre as duas iguais, porque existir as duas e nao apenas > uma? > > > > -Mensagem original- > > De: oracle_br@yahoogrupos.com.br <mailto:oracle_br% > 40yahoogrupos.com.br> [mailto:oracle_br@yahoogrupos.com.br > <mailto:oracle_br%40yahoogrupos.com.br> ] > > Em nome de Eduardo > > Enviada em: terça-feira, 22 de maio de 2007 17:40 > > Para: oracle_br@yahoogrupos.com.br <mailto:oracle_br% > 40yahoogrupos.com.br> > > Assunto: [oracle_br] Triggers de replicação. > > > > Olá galera, > > > > Tenho 1 triggers q replica dados de uma tabela p/ outra. Tipo > tabela1 p/ > > tabela2. > > Tenho q fazer o inverso agora, mas trava tudo. Com certeza é pq uma > > trigger dispara a outra. Como resolvo isso ? > > > > Aguarda a ajuda dos amigos... > > > > Edu... > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > >Apostilas » Dicas e Exemplos » Funções » Mundo Oracle » Package » > Procedure » Scripts » Tutoriais acesse: > http://www.oraclebr.com.br/codigo/ListaCodigo.php > <http://www.oraclebr.com.br/codigo/ListaCodigo.php> > > -- > > >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e > de inteira responsabilidade de seus remetentes. > > Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ > <http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/> > > -- > > >O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: > http://www.oraclebr.com.br/ <http://www.oraclebr.com.br/> > > -- > > Links do Yahoo! Grupos > > > > __ > > Fale com seus amigos de graça com o novo Yahoo! Messenger > > http://br.messenger.yahoo.com/ <http://br.messenger.yahoo.com/> > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > >
Re: RES: [oracle_br] Triggers de replicação.
Bota complexo nisso, Fernandes Eduardo, pra vc entender, pense por exemplo no seguinte caso, ao mesmo tempo o banco A pede um update na tabela e o banco B pede um delete, COMO que vc vai permitir que ambos executem são coisas EXCLUDENTES, vc não pode updatear o que está sendo deletado, é óbvio... Conflitos desse tipo é o que torna replicação onde ambos os lados podem fazer DMLs algo muuuito complexo - a tua abordagem de triggers é realmente, completamente ilógica, veja só : o banco A tem um trigger de INSERT na tabela T que faz insert na tabela T do banco B, E no banco B temos trigger que faz INSERT no A - ora, quando alguém mandar um insert no banco A (digamos), a trigger disparou e enviou um comando INSERT no B, ocorre que B recebendo o insert a trigger de insert dispara , que manda um INSERT no A, trigger do A dispara , manda INSERT no B, trigger N dispara Sacou a MONSTRUOSIDADE que vc tem feita aí ??? Só podia MESMO dar errado, vc tem em mãos uma lógica SEM A MENOR lógica... Bem, já que vc está escrevendo algo eu SUPONHO que : - vc tem dblink entre os bancos (óbvio) - hoje as duas tabelas são EXATAMENTE iguais - e que as features de replicação nativas do banco (inclusive replicação master/master) não podem ser usadas por algum motivo OBS : E vc diz que não pode ter uma tabela só (o que seria *** MESMO *** o mais fácil, eu tentaria MESMO batalhar por isso, mostre e explique pro teu cliente a complicação que é), vamos assumir que seja assim. .. Muito bem, nesse cenário de duas tabs, vc tem duas possibilidades principais, SERIALIZAÇÃO e ROTINA DE ATUALIZAÇÂO. Serialização seria algo do tipo : o dono das tabelas NÃO DÁ grants de INSERT/UPDATE/DELETE pra ninguém, ao invés da GRANT de execute em APIs (rotinas PL/SQL) apropriadas (uma pra INSERT, outra pra UPDATE e outra pra DELETE, digamos), e nessas rotinas antes de executar o DML vc manda um SELECT FROM tabela FOR UPDATE no registro da tabela local que está sendo alterado E um SELECT FROM [EMAIL PROTECTED] FOR UPDATE na tabela remota para esse mesmo registro, se conseguiu lockar ambos blz, vc manda o DML no registro local E no registro do bd remoto, se não conseguiu locar ambos os registros vc manda um erro pro usuário e manda o usuário pesquisar de novo daqui a pouco, trazendo assim a info refrescada, E refazer a operação passando os eventuais novos valores lidos pra API, e assim vai até conseguir. Já Atualização é a mais complexa, é o que outros colegas sugeriram, seria vc ter algum tipo de LOG das operações (numa outra tabela, num arquivo, via FLAG, o que for), log esse sequencial e disponível a AMBOS os bancos, que a cada período (no fim do dia, talvez) seria aplicado com a aplicação OFFLINE. []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "FERNANDES Marco ASOFTTEK" <[EMAIL PROTECTED]> escreveu > > Eduardo, > seu caso é bem crítico... duas tabelas iguais, as duas online, > as duas recebem comandos INS, DEL, UPD... complicado. > E ainda não pode unificar ! piorou ! > > Uma coisa é certa ! trigger fazendo atualização cruzada > não vai funcionar mesmo !!! sem dúvida ! > > O ideal seria centralizar a atualização ! atualizar apenas em > uma delas e replicar pra outra... minimiza muito o trampo ! > > Agora, solução sempre tem ! opção sempre tem ! e cada caso > se resolve de forma específica... respostas genéricas apenas dão > uma noção pra onde vc deve atirar. > > Uma opção seria, cria um terceira tabela que controla a atualização. > Ou seja, nela vc coloca apenas a chave e uma ou duas colunas de > controle. E coloca um processo à parte, pode ser um job ou outra > coisa, que rode de tempos em tempos (sem muita defasagem) pra > ler a tabela de controle e atualizar as tabelas. > Nessa tabela de controle vc colocaria além da chave de atualização, > uma coluna com o controle, tipo um flag (bandeirinha) que sinaliza > em qual sentido deve ser a atualização e se está pendente ou realizada. > Por exemplo, vc cria uma coluna CHAR(1) com uma espécie de protocolo: > A - atualizar tabela 1 com dados da tabela 2, status pendente > B - atualizar tabela 2 com dados da tabela 1, status pendente > C - atualizada tabela 1 com dados da tabela 2, status realizado > D - atualizada tabela 2 com dados da tabela 1, status realizado > sendo que este últimos poderia não existir e nesse caso vc apenas apagaria > estes registros, ou seja, se existe é pq está pendente... caso contrário > já apagaria da tabela... tudo depende se vc vai precisar de auditoria e > histórico das transações. > > Espero ter dado mais um pouco de luz ! risos > > Abraço, > Marco. > > > > From: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] On Behalf Of PUB: Eduardo > Sent: quarta-feira, 23 de maio de 2007 10:55 > To
RES: [SPAM] Re: RES: [oracle_br] Triggers de replicação.
Se voce diz que não há possibilidade de ter apenas uma entao vou pressupor desse ponto. Bom, se você puder alterar a estrutura da tabela, pode fazer o seguinte: - Crie um campo nomeCampo nas duas tabelas. Esse campo irá dizer se o conteúdo é original de uma instancia ou da outra. Na trigger, vc verifica: IF nomeCampo IS NULL THEN -- insere na outra instancia insert into outrainstancia.tabela (..., nomeCampo) values (..., 'instanciaX') ELSE -- nao insere na outra instancia END IF; assim vc só irá inserir dados que não venham a pedido da trigger. Outra forma se tiver chave primaria: - faz uma query e verifica se o registro já existe. Se não existir, inclui. Lembre que todos esses tratamentos provavelmente também existir para delete e update. Abraços, Fabio Santos MSN: [EMAIL PROTECTED] Tel (47) 9601-4524 -- Estúdio Interativo http://www.estudiointerativo.com [EMAIL PROTECTED] Tel: (47) 3028-8821 (21) 4063-8634 -Mensagem original- De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Eduardo Enviada em: quarta-feira, 23 de maio de 2007 10:55 Para: oracle_br@yahoogrupos.com.br Assunto: [SPAM] Re: RES: [oracle_br] Triggers de replicação. É que é uma tabela de clientes, e tenho que ter as duas identicas nas duas instancias diferentes e não há a possibilidade de ter uma unica tabela. - Original Message - From: Celso Henrique Souza To: oracle_br@yahoogrupos.com.br Sent: Wednesday, May 23, 2007 9:00 AM Subject: Res: RES: [oracle_br] Triggers de replicação. tente inativar a trigger Celso Henrique O. Souza - Mensagem original De: Fabio Santos <[EMAIL PROTECTED]> Para: oracle_br@yahoogrupos.com.br Enviadas: Terça-feira, 22 de Maio de 2007 19:36:03 Assunto: RES: [oracle_br] Triggers de replicação. pelo o que entendi, vc quer manter sempre duas tabelas iguais. se elas serao sempre as duas iguais, porque existir as duas e nao apenas uma? -Mensagem original- De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Eduardo Enviada em: terça-feira, 22 de maio de 2007 17:40 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Triggers de replicação. Olá galera, Tenho 1 triggers q replica dados de uma tabela p/ outra. Tipo tabela1 p/ tabela2. Tenho q fazer o inverso agora, mas trava tudo. Com certeza é pq uma trigger dispara a outra. Como resolvo isso ? Aguarda a ajuda dos amigos... Edu... [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas] >Apostilas » Dicas e Exemplos » Funções » Mundo Oracle » Package » Procedure » Scripts » Tutoriais acesse: http://www.oraclebr.com.br/codigo/ListaCodigo.php -- >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -- >O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: http://www.oraclebr.com.br/ -- Links do Yahoo! Grupos __ Fale com seus amigos de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/ [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas]
Re: RES: [oracle_br] Triggers de replicação.
um dblink não resolve esse tipo de problema? On 5/23/07, Eduardo <[EMAIL PROTECTED]> wrote: > > É que é uma tabela de clientes, e tenho que ter as duas identicas nas > duas instancias diferentes e não há a possibilidade de ter uma unica tabela. > > - Original Message - > From: Celso Henrique Souza > To: oracle_br@yahoogrupos.com.br > Sent: Wednesday, May 23, 2007 9:00 AM > Subject: Res: RES: [oracle_br] Triggers de replicação. > > tente inativar a trigger > > Celso Henrique O. Souza > > - Mensagem original > De: Fabio Santos <[EMAIL PROTECTED] > > Para: oracle_br@yahoogrupos.com.br > Enviadas: Terça-feira, 22 de Maio de 2007 19:36:03 > Assunto: RES: [oracle_br] Triggers de replicação. > > pelo o que entendi, vc quer manter sempre duas tabelas iguais. se elas > serao sempre as duas iguais, porque existir as duas e nao apenas uma? > > -Mensagem original- > De: oracle_br@yahoogrupos.com.br [mailto: > oracle_br@yahoogrupos.com.br ] > Em nome de Eduardo > Enviada em: terça-feira, 22 de maio de 2007 17:40 > Para: oracle_br@yahoogrupos.com.br > Assunto: [oracle_br] Triggers de replicação. > > Olá galera, > > Tenho 1 triggers q replica dados de uma tabela p/ outra. Tipo tabela1 p/ > tabela2. > Tenho q fazer o inverso agora, mas trava tudo. Com certeza é pq uma > trigger dispara a outra. Como resolvo isso ? > > Aguarda a ajuda dos amigos... > > Edu... > > [As partes desta mensagem que não continham texto foram removidas] > > [As partes desta mensagem que não continham texto foram removidas] > > >Apostilas » Dicas e Exemplos » Funções » Mundo Oracle » Package » > Procedure » Scripts » Tutoriais acesse: > http://www.oraclebr.com.br/codigo/ListaCodigo.php > -- > >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de > inteira responsabilidade de seus remetentes. > Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ > -- > >O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: > http://www.oraclebr.com.br/ > -- > Links do Yahoo! Grupos > > __ > Fale com seus amigos de graça com o novo Yahoo! Messenger > http://br.messenger.yahoo.com/ > > [As partes desta mensagem que não continham texto foram removidas] > > [As partes desta mensagem que não continham texto foram removidas] > > > -- "Os erros podem ser transformados em acertos quando com eles se aprende. Não existe a segurança do acerto eterno." [As partes desta mensagem que não continham texto foram removidas]
