¡Caminando hacia el éxito!

Aprende en Comunidad

Avalados por :

Atualização do ASE 15.7 no srv_a: Solução para transações duplicadas sem aumentar o número de geração

  • Creado 01/03/2024
  • Modificado 01/03/2024
  • 4 Vistas
0
Cargando...

Olá,

Temos a seguinte configuração para replicar entre os servidores de dados srv_a e srv_b (usando os servidores de replicação rep_a e rep_b):

-) replicação: srv_a <---> rep_a <---> rep_b <----> srv_b

-) replicação bidirecional utilizando msa: com definições de replicação de base de dados e inscrições de base de dados em ambos os sites (ou seja, em ambas as direções)

-) utilizado como sistema ativo/passivo com srv_b sendo o servidor ativo.

srv_a é ASE 12.5.4 (solaris sparc/2K páginas), srv_b é ASE 15.7 (solaris intel/4K páginas).

Quero atualizar srv_a para ASE 15.7.

Isto é o que fiz:

-) criar um novo servidor 15.7, definir as bases de dados, carregar um dump de srv_b nele, desabilitar os agentes de replicação.

-) excluir as inscrições de base de dados em ambas as direções.

-) parar srv_a, renomear e reiniciar o novo servidor com nome srv_a.

para cada base de dados:

-) criar uma inscrição de base de dados de b para a usando um marcador de dump

-) fazer dump da base de dados em srv_b e carregar em srv_a.

o dump contém a configuração de replicação de srv_b, então isso deve ser alterado na configuração de srv_a:

-) sp_config_rep_agent $db, 'connect dataserver', 'srv_a'

-) sp_config_rep_agent $db, 'rs servername', 'rep_a'

-) dbcc settrunc('ltm', 'ignore')

-) dbcc settrunc('ltm', 'valid')

-) dbcc settrunc('ltm', 'end')

e em rssd_db de rep_a:

-) rs_zeroltm srv_a, $db

-) então iniciar o repagent e retomar a conexão.

-) finalmente, criar uma inscrição de base de dados de a para b.

O resultado é que a replicação de b para a funciona bem (o que é bom porque é de ativo para passivo),

mas a replicação de a para b não está funcionando.

Usei sysadmin dump_queue para ver o que está na fila estável, e parece que as transações em srv_a não estão chegando à fila estável.

Ao ler a documentação, me deparei com a descrição dos números de geração.

Normalmente são incrementados para evitar que após restaurar um banco de dados principal, as transações sejam consideradas duplicadas.

A coluna Duplicados na saída do admin who, sqm está aumentando.

Como não consegui encontrar o que estava causando o problema, pensei em tentar configurar o número de geração, e adicionei:

-) dbcc settrunc('ltm', 'gen_id', 1)

após o comando settrunc('ltm', 'ignore') na descrição anterior.

Quando fiz isso, a replicação de srv_a para srv_b começou a funcionar.

Não entendo por que isso está acontecendo e por que as transações estão sendo consideradas duplicadas.

Também quero evitar aumentar o número de geração, há alguma solução sem fazer isso?

Obrigado,

Luc.

Pedro Pascal
Se unió el 07/03/2018
Pinterest
Telegram
Linkedin
Whatsapp

2 Respuestas

0
Cargando...

Obrigado pelas suas respostas Mark e Mikael.

Modifiquei meus scripts para obter o ID de geração atual do comando gettrunc e aumentá-lo em um, agora faz parte dos comandos que ajustam os parâmetros do repagent após carregar um banco de dados (como alterar o nome do repserver que gerencia o repagent).

Converti 4 servidores com um total de 48 bancos de dados sem problemas adicionais. Ficam 2 por fazer.

Este fim de semana, estou trabalhando em nosso servidor principal com 54 bancos de dados replicados. Para concluir o trabalho o mais rápido possível, terei que deixá-lo funcionando sem supervisão durante a noite, então não quis complicar mais indo tão longe a ponto de desconectar as conexões.

Luc.

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...


°Olá Luc!

Estamos utilizando exatamente a mesma configuração de MSA.

°Experimentamos exatamente o mesmo problema com as IDs de geração aqui no início, e foi realmente um incômodo!

Mas decidimos em uma fase inicial que, para não termos que nos preocupar com elas, eliminamos "tudo" relacionado a esse tópico quando precisamos materializar e configurar um banco de dados/tópico do "zero". Dessa forma, sempre começamos com gen_id 0.

Portanto, não só eliminamos as assinaturas, mas também todos os nossos rep_agents, descrições, conexões, etc. para cada banco de dados/tópico que materializamos.

E desde então, não precisamos mais nos preocupar.

/Mike

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019

contacto@primeinstitute.com

(+51) 1641 9379
(+57) 1489 6964

© 2024 Copyright. Todos los derechos reservados.

Desarrollado por Prime Institute

¡Hola! Soy Diana, asesora académica de Prime Institute, indícame en que curso estas interesado, saludos!
Hola ¿Puedo ayudarte?