Re: [oracle_br] RES: Inconsistência em tabelas des normalizadas: replicação ?
Buenas Ederson As mensagens não estão desabilitadas; o único commit está após o bloco onde sempre as 3 tabelas são manipuladas. Acho que o mais interessante ainda, é que na tabela de auditoria que montei aparece que o update "duplicado", apareceu vários segundos após os outros, depois também de outros updates corretos. Ou seja, parece um "comando perdido" sendo executado fora de hora. Assim, novamente não vejo outro local que pudesse estar causando o erro, exceto a replicação. E aí voltaria a minha dúvida original. De qualquer maneira, agradeço a todos que tentaram dar uma pista para a solução deste problema. Se alguém estiver disposto a dar uma olhada com um pouco mais de profundidade, eu posso mandar em PVT o código que faz as alterações e a listagem da tabela de auditoria, onde aparece a alteração "fantasma". Grato a todos Marcel . - Original Message - From: "Ederson" <[EMAIL PROTECTED]> To: Sent: Monday, July 25, 2005 2:05 PM Subject: [oracle_br] RES: Inconsistência em tabelas desnormalizadas: replicação ? Marcel, Com certeza o Forms é diferente na forma de trabalhar das outras linguagens visuais. Mas mesmo usando campos Based_Table, não deveria haver problemas de dados, pois se houver alteração nos campos de tela e vc mudar de Camvas/Window ou fechar, acontece um evento do Forms que dá mensagem de Changed-values, e como é default receber a mensagem, vc saberia. Caso os desenvolvedores tenham desabilitado as mensagens, o programa poderia estar passando por cima de avisos, mas só aconteceria uma gravação se o valor chegasse na variável em um ponto do programa que haja um commit. Difícil acreditar que um programa de faturamento esteja ruim assim. Estou usando o [EMAIL PROTECTED], veja informações do produto em: http://www.unimix.com.br/replic.html Um dos desenvolvedores do [EMAIL PROTECTED], o Sr.Renan Medeiros, participa da nossa lista. Ederson Elias de Oliveira DBA Oracle Setransp - GO --- _ De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Marcel Enviada em: segunda-feira, 25 de julho de 2005 13:16 Para: oracle_br@yahoogrupos.com.br Assunto: Re: [oracle_br] RES: Inconsistência em tabelas desnormalizadas: replicação ? Buenas Ederson Realmente, a alteração da replicação Multimaster para Snapshot Read-only reduziu bastante o problema. Só que eu esperava que os mesmos acabassem, o que não ocorreu. O Salvio sugeriu a reescrita da aplicação como não base table, sugerindo que algum evento do Form possa estar sendo disparado sem que eu consiga ter percebido ou identificado. É uma hipótese que eu não havia pensado. Qual foi o produto que vocês adotaram para a replicação? []'s Marcel . __ Histórico: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ Falar com os Moderadores:([EMAIL PROTECTED]) Dorian Anderson Soutto - Fernanda Damous - Alisson Aguiar __ Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
Re: [oracle_br] RES: Inconsistência em tabelas des normalizadas: replicação ?
Buenas Ederson Realmente, a alteração da replicação Multimaster para Snapshot Read-only reduziu bastante o problema. Só que eu esperava que os mesmos acabassem, o que não ocorreu. O Salvio sugeriu a reescrita da aplicação como não base table, sugerindo que algum evento do Form possa estar sendo disparado sem que eu consiga ter percebido ou identificado. É uma hipótese que eu não havia pensado. Qual foi o produto que vocês adotaram para a replicação? []'s Marcel . - Original Message - From: "Ederson" <[EMAIL PROTECTED]> To: Sent: Monday, July 25, 2005 10:03 AM Subject: [oracle_br] RES: Inconsistência em tabelas desnormalizadas: replicação ? Marcel, Estou há pouco tempo na empresa atual, e quando cheguei, me deparei com um ambiente com replicação multimaster. Havia uma série de problemas que aconteciam devido o problema das transações não serem cronologicamente respeitadas. Isto causava perdas de informações, pois poderiam haviam dois updates no mesmo registro que deveria ser respeitado a cronologia, e o último continha a informação atual. Porém, devido à não-serialização da transação, como vc bem lembrou, era aplicado no banco remoto, em primeiro lugar, aquela que deveria ser o último valor, e em seguida, a transação mais antiga chegava e sobescrevia o valor, retornando a informação ao valor anterior, ficando assim o(s) banco(s) com informações diferentes. Havia tb o problema da transação com muitas linhas, que a replicação multimaster considera como "uma transação com muitas linhas" e não conseguia fazer a mesma remotamente na mesma ordem, então eram feitas as transações com "uma ou poucas linhas" primeiro, contudo estas transações com poucas linhas alteravam registros que já haviam sido alterados pela transação grande. Novamente, a informação última (atual) era perdida. Fora os problemas de sincronia, também deparei com uma grande fragilidade no "esquema" de replicação, pois haviam as famosas "regras de resolução de conflitos" que tinham que tratar diferenças entre registros, já que a replicação Oracle sempre sobescreve o registro inteiro e não apenas o atributo alterado, o que NOVAMENTE causava diferenças e problemas. Sem contar os problemas de paralisação da replicação quando caía link ou quando acumulava muitos erros ... A boa notícia é que resolvi todos estes problemas TROCANDO a replicação Oracle Multi-Master por um produto de terceiros especializado em replicação, que garante a serialização da informação e não possui a idéia de "resolução de conflitos" simplesmente porque não há conflitos. Neste produto, a transação com muitas linhas ao enviar um "commit", o banco inicia a escrita nas tabelas locais, e isto faz com que a replicação "colete" de cada tabela replicada, o comando sql nela aplicado, gravando em uma tabela própria que era descarregada no banco remoto e uma trigger local se encarregava de executar as linhas na ordem correta. Desta forma, a replicação fica transparente e independente da aplicação, como deve ser. Se quiser mais informações, estou à disposição. Ederson Elias de Oliveira DBA Oracle Setransp - GO --- -Mensagem original- De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Marcel Enviada em: segunda-feira, 25 de julho de 2005 08:48 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Inconsistência em tabelas desnormalizadas: replicação ? Prezados senhores(as) Antecipadamente peço desculpas pela extensão da descrição do problema, mas é na tentativa de ser o mais claro possível. Estou trabalhando com um sistema legado que possui 3 tabelas de estoque desnormalizadas, da seguinte forma (as chaves primárias compostas estão identificadas pela #): - Tabela ESTOQUE # Id, # Empresa, # DataFabricacao, # Valor, Qtd - Tabela SITUACAO_EST # Sit_Id, # Sit_Empresa, # Sit_DataFabricacao, # Sit_Valor, # Situacao, Qtd - Tabela CLASSE_SIT_EST # Cl_Sit_Id, # Cl_Sit_Empresa, # Cl_Sit_DataFabricacao, # Cl_Sit_Valor, # Cl_Situacao, # Classe, Qtd Um exemplo: podemos ter: Na tabela ESTOQUE, o seguinte material (uma camisa, cuja Id = CAM01): - id = CAM01, empresa = ABC, data = 01/01/2005, valor = 10, qtd = 500 Na tabela SITUACAO_EST, o material acima estaria distribuído assim: - CAM01, ABC, 01/01/2005, 10, situacao = DISPONIVEL, 300 - CAM01, ABC, 01/01/2005, 10, TRANSITO, 200 Na tabela CLASSE_SIT_EST, o material acima estaria distribuído assim: - CAM01, ABC, 01/01/2005, 10, DISPONIVEL, classe = 1, 250 - CAM01, ABC, 01/01/2005, 10, DISPONIVEL, 2, 50 - CAM01, ABC, 01/01/2005, 10, TRANSITO, 1, 200 Ou seja, o material id = CAM01, empresa = ABC, data = 01/01/2005, valor = 10 tem que somar 500 em cada uma das tabelas. Quando uma GUIA é emitida, o material sai da situação DISPONIVEL e passa para TRANSITO. Assim, no exemplo acima, existe uma guia em aberto com 200 camisas. Ao QUITAR uma guia, a quantidade em TRANSITO é zerada e a quantidade correspondente
Re: [oracle_br] RES: Inconsistência em tabelas des normalizadas: replicação ?
Eu seiestou de brincadeira... Renan Medeiros Coordenador de Suporte/Treinamento/Pré-venda Unimix Tecnologia Ltda 0 xx 61 9994 0586 0 xx 61 3201 - Original Message - From: Ederson To: oracle_br@yahoogrupos.com.br Sent: Monday, July 25, 2005 10:27 AM Subject: [oracle_br] RES: Inconsistência em tabelas desnormalizadas: replicação ? Renan, não há problemas nisto por aqui, mas como pode ver, o Marcel está passando por aqueles problemas que não tenho saudades ... Ederson Elias de Oliveira DBA Oracle Setransp - GO --- _ De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Renan da Silveira Medeiros Enviada em: segunda-feira, 25 de julho de 2005 10:22 Para: oracle_br@yahoogrupos.com.br Assunto: Re: [oracle_br] RES: Inconsistência em tabelas desnormalizadas: replicação ? Fala meu caro Ederson, td bem por ai ? E os problemas de replicaçÃO ? risos... Um grande abraço. Renan Medeiros Coordenador de Suporte/Treinamento/Pré-venda Unimix Tecnologia Ltda 0 xx 61 9994 0586 0 xx 61 3201 - Original Message - From: Ederson To: oracle_br@yahoogrupos.com.br Sent: Monday, July 25, 2005 10:03 AM Subject: [oracle_br] RES: Inconsistência em tabelas desnormalizadas: replicação ? Marcel, Estou há pouco tempo na empresa atual, e quando cheguei, me deparei com um ambiente com replicação multimaster. Havia uma série de problemas que aconteciam devido o problema das transações não serem cronologicamente respeitadas. Isto causava perdas de informações, pois poderiam haviam dois updates no mesmo registro que deveria ser respeitado a cronologia, e o último continha a informação atual. Porém, devido à não-serialização da transação, como vc bem lembrou, era aplicado no banco remoto, em primeiro lugar, aquela que deveria ser o último valor, e em seguida, a transação mais antiga chegava e sobescrevia o valor, retornando a informação ao valor anterior, ficando assim o(s) banco(s) com informações diferentes. Havia tb o problema da transação com muitas linhas, que a replicação multimaster considera como "uma transação com muitas linhas" e não conseguia fazer a mesma remotamente na mesma ordem, então eram feitas as transações com "uma ou poucas linhas" primeiro, contudo estas transações com poucas linhas alteravam registros que já haviam sido alterados pela transação grande. Novamente, a informação última (atual) era perdida. Fora os problemas de sincronia, também deparei com uma grande fragilidade no "esquema" de replicação, pois haviam as famosas "regras de resolução de conflitos" que tinham que tratar diferenças entre registros, já que a replicação Oracle sempre sobescreve o registro inteiro e não apenas o atributo alterado, o que NOVAMENTE causava diferenças e problemas. Sem contar os problemas de paralisação da replicação quando caía link ou quando acumulava muitos erros ... A boa notícia é que resolvi todos estes problemas TROCANDO a replicação Oracle Multi-Master por um produto de terceiros especializado em replicação, que garante a serialização da informação e não possui a idéia de "resolução de conflitos" simplesmente porque não há conflitos. Neste produto, a transação com muitas linhas ao enviar um "commit", o banco inicia a escrita nas tabelas locais, e isto faz com que a replicação "colete" de cada tabela replicada, o comando sql nela aplicado, gravando em uma tabela própria que era descarregada no banco remoto e uma trigger local se encarregava de executar as linhas na ordem correta. Desta forma, a replicação fica transparente e independente da aplicação, como deve ser. Se quiser mais informações, estou à disposição. Ederson Elias de Oliveira DBA Oracle Setransp - GO --- [As partes desta mensagem que não continham texto foram removidas] __ Histórico: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ Falar com os Moderadores:([EMAIL PROTECTED]) Dorian Anderson Soutto - Fernanda Damous - Alisson Aguiar __ -- Links do Yahoo! Grupos a.. Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ b.. Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] c.. O uso que você faz do Yahoo! Grupos está sujeito aos Termos do Serviço do Yahoo!. [As partes desta mensagem que não continham texto foram removidas]
Re: [oracle_br] RES: Inconsistência em tabelas des normalizadas: replicação ?
Fala meu caro Ederson, td bem por ai ? E os problemas de replicaçÃO ? risos... Um grande abraço. Renan Medeiros Coordenador de Suporte/Treinamento/Pré-venda Unimix Tecnologia Ltda 0 xx 61 9994 0586 0 xx 61 3201 - Original Message - From: Ederson To: oracle_br@yahoogrupos.com.br Sent: Monday, July 25, 2005 10:03 AM Subject: [oracle_br] RES: Inconsistência em tabelas desnormalizadas: replicação ? Marcel, Estou há pouco tempo na empresa atual, e quando cheguei, me deparei com um ambiente com replicação multimaster. Havia uma série de problemas que aconteciam devido o problema das transações não serem cronologicamente respeitadas. Isto causava perdas de informações, pois poderiam haviam dois updates no mesmo registro que deveria ser respeitado a cronologia, e o último continha a informação atual. Porém, devido à não-serialização da transação, como vc bem lembrou, era aplicado no banco remoto, em primeiro lugar, aquela que deveria ser o último valor, e em seguida, a transação mais antiga chegava e sobescrevia o valor, retornando a informação ao valor anterior, ficando assim o(s) banco(s) com informações diferentes. Havia tb o problema da transação com muitas linhas, que a replicação multimaster considera como "uma transação com muitas linhas" e não conseguia fazer a mesma remotamente na mesma ordem, então eram feitas as transações com "uma ou poucas linhas" primeiro, contudo estas transações com poucas linhas alteravam registros que já haviam sido alterados pela transação grande. Novamente, a informação última (atual) era perdida. Fora os problemas de sincronia, também deparei com uma grande fragilidade no "esquema" de replicação, pois haviam as famosas "regras de resolução de conflitos" que tinham que tratar diferenças entre registros, já que a replicação Oracle sempre sobescreve o registro inteiro e não apenas o atributo alterado, o que NOVAMENTE causava diferenças e problemas. Sem contar os problemas de paralisação da replicação quando caía link ou quando acumulava muitos erros ... A boa notícia é que resolvi todos estes problemas TROCANDO a replicação Oracle Multi-Master por um produto de terceiros especializado em replicação, que garante a serialização da informação e não possui a idéia de "resolução de conflitos" simplesmente porque não há conflitos. Neste produto, a transação com muitas linhas ao enviar um "commit", o banco inicia a escrita nas tabelas locais, e isto faz com que a replicação "colete" de cada tabela replicada, o comando sql nela aplicado, gravando em uma tabela própria que era descarregada no banco remoto e uma trigger local se encarregava de executar as linhas na ordem correta. Desta forma, a replicação fica transparente e independente da aplicação, como deve ser. Se quiser mais informações, estou à disposição. Ederson Elias de Oliveira DBA Oracle Setransp - GO --- -Mensagem original- De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Marcel Enviada em: segunda-feira, 25 de julho de 2005 08:48 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Inconsistência em tabelas desnormalizadas: replicação ? Prezados senhores(as) Antecipadamente peço desculpas pela extensão da descrição do problema, mas é na tentativa de ser o mais claro possível. Estou trabalhando com um sistema legado que possui 3 tabelas de estoque desnormalizadas, da seguinte forma (as chaves primárias compostas estão identificadas pela #): - Tabela ESTOQUE # Id, # Empresa, # DataFabricacao, # Valor, Qtd - Tabela SITUACAO_EST # Sit_Id, # Sit_Empresa, # Sit_DataFabricacao, # Sit_Valor, # Situacao, Qtd - Tabela CLASSE_SIT_EST # Cl_Sit_Id, # Cl_Sit_Empresa, # Cl_Sit_DataFabricacao, # Cl_Sit_Valor, # Cl_Situacao, # Classe, Qtd Um exemplo: podemos ter: Na tabela ESTOQUE, o seguinte material (uma camisa, cuja Id = CAM01): - id = CAM01, empresa = ABC, data = 01/01/2005, valor = 10, qtd = 500 Na tabela SITUACAO_EST, o material acima estaria distribuído assim: - CAM01, ABC, 01/01/2005, 10, situacao = DISPONIVEL, 300 - CAM01, ABC, 01/01/2005, 10, TRANSITO, 200 Na tabela CLASSE_SIT_EST, o material acima estaria distribuído assim: - CAM01, ABC, 01/01/2005, 10, DISPONIVEL, classe = 1, 250 - CAM01, ABC, 01/01/2005, 10, DISPONIVEL, 2, 50 - CAM01, ABC, 01/01/2005, 10, TRANSITO, 1, 200 Ou seja, o material id = CAM01, empresa = ABC, data = 01/01/2005, valor = 10 tem que somar 500 em cada uma das tabelas. Quando uma GUIA é emitida, o material sai da situação DISPONIVEL e passa para TRANSITO. Assim, no exemplo acima, existe uma guia em aberto com 200 camisas. Ao QUITAR uma guia, a quantidade em TRANSITO é zerada e a quantidade correspondente é abatida na tabela ESTOQUE. Ou seja, ao quitar a gui
