Início / dba / Perguntas / 5047
Accepted
Matt M
Asked: 2011-08-26 12:03:03 +0800 CST

Restrições confiáveis ​​e NÃO PARA REPLICAÇÃO

  • 772

Versão e compilação: SQL Server 2005 SP4 (9.0.5000)

Como uma espécie de isenção de responsabilidade, estou fazendo esta pergunta para gerar alguma discussão e/ou debate sobre o assunto. Não sei se realmente existe uma resposta correta, ou se a resposta correta é um grande e gordo "Depende". Como tal, serei muito lento em aceitar uma resposta, a menos que sejam apresentadas evidências definitivas que não possam ser contestadas pela visão oposta.

O problema lida com o OBJECTPROPERTY CnstIsNotTrusted e o OBJECTPROPERTY CnstIsNotRepl e como eles se relacionam. A propriedade CnstIsNotTrusted é controlada com WITH CHECK|NOCHECK ao adicionar ou verificar uma restrição. A propriedade CnstIsNotTrusted significa que a restrição foi habilitada sem verificar as linhas existentes; portanto, a restrição pode não ser verdadeira para todas as linhas. Quando true, a restrição não pode ser usada para otimização de consulta. Por exemplo, eu tenho uma tabela Person com uma restrição de verificação em LastName garantindo LastName LIKE 'Mc%'. Se CnstIsNotTrusted = 1, se eu pesquisar LastName = 'Smith', o plano de consulta ainda precisará verificar/buscar o índice. Se CnstIsNotTrusted = 0, o plano de execução nem tocará na tabela. Isso foi comprovado aqui:

https://sqlserverfast.com/blog/hugo/2007/03/can-you-trust-your-constraints/

O OBJECTPROPERTY CnstIsNotRepl (NOT FOR REPLICATION em DDL) impõe que a restrição não será verificada durante as sincronizações de replicação. Mais precisamente, o lado do editor será verificado, mas o lado do assinante não. Isso garante que a mesma restrição não seja verificada mais de uma vez. No entanto, usar NOT FOR REPLICATION tornará sua restrição não confiável.

Minha pergunta é, vale a pena os ciclos extras de CPU não usar NOT FOR REPLICATION, para às vezes receber um plano de execução mais eficiente?

sql-server database-design

1 respostas

  1. Best Answer

    NOT FOR REPLICATION foi indicado para este cenário:

    1. Você tem uma tabela Order com uma tabela FK to Person.
    2. A tabela de pedidos está na publicação nº 1 e a tabela de pessoas está na publicação nº 2.
    3. O pub Order e o pub Person acontecerão em horários diferentes. Portanto, se alguns novos registros estavam na tabela Order foram replicados para o assinante e a tabela Person estava sem a pessoa para a qual o novo Order era, você não deseja que a inserção de replicação falhe no assinante. Em vez disso, pode-se confiar que o novo registro de Pessoa será desativado em algum momento porque o FK foi usado no Editor.
    4. No assinante, se você inserir um registro de Pedido, o FK verificará se o registro de Pessoa existe.

    Eu sempre seguiria essa política e usaria NOT FOR REPLICATION apenas para fins de FKs relacionados a tabelas em diferentes publicações, e não para fins de otimização do plano de consulta.

    • 3

relate perguntas