Início / dba / Perguntas / 54536
Accepted
Onion-Knight
Asked: 2013-12-06 11:07:55 +0800 CST

Comportamento da coluna de identidade após a replicação

  • 772

Digamos que temos dois servidores: Servidor A e Servidor B. Os dados estão sendo replicados (replicação transacional vanilla) de A para B.

Para uma das Tabelas, temos os seguintes dados:

Server A   - Server B
=========    =========

ID|Content   ID|Content
----------   ----------
1 | ...      1 | ...
2 | ...      2 | ...
  ...         ...
98| ...      98| ...
99| ...      99| ...

Depois de um tempo, excluímos os dados antigos:

Server A   - Server B
=========    =========

ID|Content   ID|Content
----------   ----------
50| ...      50| ...
51| ...      51| ...
  ...         ...
98| ...      98| ...
99| ...      99| ...

Agora, alteramos a ordem de replicação, agora o servidor B está replicando para o servidor A.

A questão é:

Eu esperava que novos dados adicionados ao Servidor B (e depois replicados para o Servidor A) continuassem usando a coluna ID (Iria para 100, 101, 102, ...). Em vez disso, notei que começa em 1.

A questão é:

Como o banco de dados lidará com isso quando o ID finalmente atingir 50? O banco de dados começará a lançar violações de chave primária ou perceberá o que está acontecendo e pulará do ID 49 para o ID 100?

Se ele começar a gerar violações de chave primária, existe um comando que possamos usar para informar ao servidor B que ele deve começar no ID 100? E em caso afirmativo, esse comando pode ser executado durante a replicação de dados?

sql-server t-sql

1 respostas

  1. Best Answer

    Depois de mudar para um mestre diferente, você deve propagar novamente o valor de identidade, caso contrário, obterá duplicatas na coluna id. Use a DBCC CHECKIDENTdeclaração.

    DBCC CHECKIDENT ( 'dbo.ITest', reseed, 1000 ) ;

    A escolha do número pode ser automatizada usando uma SELECT MAX( TID )consulta e colocando o número retornado em uma string SQL dinâmica. Isso deve ser colocado em uma transação serializável para garantir que nenhuma outra sessão insira novas linhas enquanto esta sessão está propagando novamente o valor (obrigado David). Além disso, o mestre não deve ser alterado durante a redistribuição.

    Uma maneira de lidar com isso pode ser criar domínios de identidade não sobrepostos. No ServerA, crie a coluna de identidade como identity ( 1, 2 )e no ServerB como identity (2, 2 ). Dessa forma, as inserções do ServidorA serão 1, 3, 5… e as inserções do ServidorB serão 2, 4, 6… Claro, se você quiser criar um terceiro servidor, estará perdido. :-)

    Melhor ainda, não use identityem uma situação multimestre. Ele não fornece nenhuma prevenção de duplicatas. Em vez disso, use um identificador exclusivo ou um identificador gerado pelo aplicativo.

    • 2

relate perguntas