O que acontece do ponto de vista do SAP/Sybase Replication Server (SRS)?

Depende da versão do SRS e de como os DBAs configuraram a instância do SRS.

Antes do SRS 15.2, o DELETE 'vazio' não causaria problemas, ou seja, o DELETE seria emitido no destino, nenhuma linha encontrada/afetada e o SRS continuaria a processar a próxima transação.

A chave aqui é que uma instrução DELETE que não encontra nenhuma linha para excluir apenas é concluída com sucesso (ou seja, sem erro), com @@rowcount=0.

NOTA: A mesma 'lógica' se aplica a UPDATEs, INSERT/SELECTs e SELECT/INTOs que são concluídos com sucesso, mas não afetam nenhuma linha.

NOTA: A mesma 'lógica' se aplica a instruções DML que são concluídas com êxito, mas afetam um número diferente de linhas.

Com o SRS 15.2+, uma classe de erro do servidor de replicação foi introduzida com a ênfase principal em observar quando as transações afetam um número diferente de linhas no destino ... e quando esse problema ocorre para gerar um erro (por exemplo, 5185) e suspender o DSI conexão.

Cada transação proveniente da origem é marcada com o número de linhas afetadas. Se a transação, quando aplicada ao destino, afetar um número diferente de linhas, o SRS (por padrão) suspenderá o DSI e despejará uma mensagem de erro no log de erros.

O DBA pode modificar o comportamento de incompatibilidade de contagem de linhas padrão atribuindo uma ação diferente ao número de erro correspondente na classe de erro do servidor de replicação (consulte o comando assign action para obter mais detalhes).

Obviamente (?) o DBA deve pesquisar quaisquer erros de incompatibilidade de contagem de linhas para determinar se eles estão corretos/válidos ou se indicam um problema com o destino fora de sincronia com a origem.

Outros cenários que o DBA gostaria de investigar podem incluir:

• procs armazenados replicados que não afetam o mesmo conjunto de linhas no destino
• strings de função personalizada que modificam uma transação de forma a (explicitamente) modificar o número de linhas afetadas no destino
• falta de uma chave primária para uma tabela

Lembre-se de que, embora o SRS seja usado rotineiramente para manter um banco de dados de DR/backup sincronizado com o banco de dados primário, o SRS também pode ser usado para:

• distribuir subconjuntos de dados (modelo de distribuição)
• consolidar dados (modelo de roll-up)
• manter dados históricos/de auditoria (por exemplo, converter DELETEs/UPDATEs para salvar a imagem 'antiga' de dados em uma tabela de histórico)
• propagar sub/superconjuntos de dados por requisitos de aplicativo

O resultado líquido é que a ocorrência de incompatibilidades de contagem de linhas pode ou não ser aceitável ... tudo depende dos ambientes SRS individuais.

Em Control Row Count Validation no Replication Server Administration Guide Volume 2:

Desabilite a validação de contagem de linhas para todas as conexões de banco de dados, digite:

configurar o servidor de replicação definido dsi_row_count_validation para 'off'

Você deve suspender e retomar todas as conexões de banco de dados com o Replication Server após executar configurar o servidor de replicação com dsi_row_count_validation. A alteração na configuração entra em vigor depois que você retoma as conexões de banco de dados.

Habilite a validação de contagem de linhas para uma conexão específica — banco de dados pubs2 no servidor de dados SYDNEY_DS, digite:

altere a conexão com SYDNEY_DS.pubs2 defina dsi_row_count_validation como 'on'

Você não precisa suspender e retomar uma conexão de banco de dados ao definir dsi_row_count_validation para a conexão; o parâmetro entra em vigor imediatamente. No entanto, a nova configuração afeta o lote de objetos replicados que o Replication Server processa após a execução do comando. A alteração da configuração não afeta o lote de objetos replicados que o Replication Server está processando no momento.

Acho que talvez, a versão mais antiga do repserver exija a suspensão/retomada do DSI depois de fazer a alteração específica do DSI.