none
Replicação Transacional - Opção "Replicate Schema Changes" - Não replica ADD COLUMN RRS feed

  • Pergunta

  • Olá pessoal.

    Estou realizando uma atualização do meu banco de dados que é replicado com 5 assinantes. Tem uma alteração de tabela, ADD COLUMN, que ela foi executada no publish normalmente, porém, essa coluna não foi para os assinantes.

    Alguns outros ADD COLUMN foram, mas outros não foram... Já verifiquei de tudo aqui, inclusive as tabelas de sistema mas não tem diferença nenhuma.

    A minha opção "replicate schema changes" das propriedades do publish está True... já joguei pra false e depois true novamente e nada...

    Já tentei até alterar as procs de sistema, jogar uns PRINT pra ver o que acontece mas ele não deixa..

    Debuguei na mão mesmo executando os selects e nada...

    Alguém já viu isso alguma vez????

    Por sorte esses campos são de funcionalidades do sistema que meu cliente replicado não vai usar já, mas se utilizar, as informações não serão transportadas...

    Todos os servidores estão com SQL 2008 Std 10.50.4000

    Vlw pela ajuda!


    André Duarte

    quinta-feira, 20 de março de 2014 03:00

Respostas

  • Fala Júnior.

    O que parecia estranho, enfim consegui decifrar.

    No meu sistema aqui, eu implementei uma auditoria no banco de dados, tudo por fora do sistema. Triggers vinculadas às tabelas que armazenam tudo o que está acontecendo nelas, inclusive as ação por fora do sistema, direto pelo BD.

    Nessa minha estrutura eu utilizo o CONTEXT_INFO que diz pra mim, dentro daquela conexão tudo o que foi alterado, e pra preencher o context_info, fiz uma trigger ON ALL SERVER FOR LOGON que assim que um usuário já se conecta no banco de dados, já seta um novo context_info na conexão, e a partir daí tudo o que for alterado eu registro.

    Passei um profiler no meu alter table no publish e fui seguindo as execuções feitas nas tabelas de sistema. Nesse profiler foi executada a proc sys.sp_MStran_altertable, que dentro dela foi chamada a proc  sys.sp_MScheckcontext_bypasswholeddleventbit que tem uma variavel @is_biton como output.

    Não entendi nada pra que serve esse @is_biton, mas dentro da proc ela pega o primeiro byte do context_info, faz uma comparação e retorna 0 ou 1. Como meu context_info já foi preenchido, dependendo do valor o @is_biton retorna 1 e sai fora da proc, sem falar pra replicação enviar esse novo campo para os Assinantes... 

    É mole???

    Ou seja... Se você usa CONTEXT_INFO na sua aplicação, dependendo de como usa, não vai funcionar sua alteração de esquema.

    Pra testar, na mesma conexão que não estava funcionando, zerei meu context_info e o campo replicou que foi uma beleza!

    Bom... vou ter que lembrar sempre do context_info para alterações de estrutura ou arrumar uma outra forma de interligar as execuções por conexão no meu banco!

    Vlw pela ajuda, e se souber pra que serve esse @is_biton, fala pra gente!

    Abraços.


    André Duarte

    • Marcado como Resposta André Duarte sexta-feira, 20 de junho de 2014 15:55
    sexta-feira, 20 de junho de 2014 15:55

Todas as Respostas

  • André,

    Sinceramente não me lembro de ter visto isso!!! Parece ser uma falha que pode ter ocorrido durante o processamento dos scripts de configuração da replicação.

    Você falou da opção "replicate schema changes", mesmo fazendo o reprocessamento dos scripts de replicação a estrutura continuou totalmente diferente?


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    sexta-feira, 21 de março de 2014 18:29
    Moderador
  • Fala Junior, blz?

    Bom... ontem eu peguei esse problema pra ver e depois de duas semanas, com alguns snapshots executados e restart de servidor, pra minha surpresa, realizei o drop da coluna e depois o add novamente, e agora foi.

    Muito estranho!

    Durante essas duas semanas que passou eu tive problemas com essas colunas onde um assinante que criei novo acabou pegando essa coluna como replicada, então o assinante mandava a informação porém as procs do publish não estavam preparadas, ai eu ficava adicionando e retirando esses parâmetros... um rolo total.

    Agora parece que está tudo certo... o SQL que ficou meio perdido mesmo!

    Motivo: desconhecido!

    Acho que vou pegar como pré-requisito para realizar as alterações um restart do servidor, pra garantir.


    André Duarte

    sábado, 5 de abril de 2014 13:00
  • André,

    Obrigado pelo retorno, realmente é algo bem fora do comum, estranho a parte de replicação no SQL Server esta bem consolidada e evoluída nestas últimas versões.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    sexta-feira, 11 de abril de 2014 17:33
    Moderador
  • Fala Júnior.

    O que parecia estranho, enfim consegui decifrar.

    No meu sistema aqui, eu implementei uma auditoria no banco de dados, tudo por fora do sistema. Triggers vinculadas às tabelas que armazenam tudo o que está acontecendo nelas, inclusive as ação por fora do sistema, direto pelo BD.

    Nessa minha estrutura eu utilizo o CONTEXT_INFO que diz pra mim, dentro daquela conexão tudo o que foi alterado, e pra preencher o context_info, fiz uma trigger ON ALL SERVER FOR LOGON que assim que um usuário já se conecta no banco de dados, já seta um novo context_info na conexão, e a partir daí tudo o que for alterado eu registro.

    Passei um profiler no meu alter table no publish e fui seguindo as execuções feitas nas tabelas de sistema. Nesse profiler foi executada a proc sys.sp_MStran_altertable, que dentro dela foi chamada a proc  sys.sp_MScheckcontext_bypasswholeddleventbit que tem uma variavel @is_biton como output.

    Não entendi nada pra que serve esse @is_biton, mas dentro da proc ela pega o primeiro byte do context_info, faz uma comparação e retorna 0 ou 1. Como meu context_info já foi preenchido, dependendo do valor o @is_biton retorna 1 e sai fora da proc, sem falar pra replicação enviar esse novo campo para os Assinantes... 

    É mole???

    Ou seja... Se você usa CONTEXT_INFO na sua aplicação, dependendo de como usa, não vai funcionar sua alteração de esquema.

    Pra testar, na mesma conexão que não estava funcionando, zerei meu context_info e o campo replicou que foi uma beleza!

    Bom... vou ter que lembrar sempre do context_info para alterações de estrutura ou arrumar uma outra forma de interligar as execuções por conexão no meu banco!

    Vlw pela ajuda, e se souber pra que serve esse @is_biton, fala pra gente!

    Abraços.


    André Duarte

    • Marcado como Resposta André Duarte sexta-feira, 20 de junho de 2014 15:55
    sexta-feira, 20 de junho de 2014 15:55