Fazer alterações de esquema em bancos de dados de publicação

A replicação dá suporte a uma ampla gama de alterações de esquema em objetos publicados. Quando você faz qualquer uma das seguintes alterações de esquema no objeto publicado apropriado em um Publicador do Microsoft SQL Server, essa alteração é propagada por padrão para todos os Assinantes do SQL Server:

• ALTER TABLE

• ALTER TABLE SET LOCK ESCALATION não deverá ser usado se a replicação de alteração de esquema estiver habilitada e uma topologia incluir o SQL Server 2005 ou o SQL Server Compact 3.5 Subscribers.ALTER VIEW

• ALTER PROCEDURE

• ALTER FUNCTION

• ALTERAR TRIGGER

  ALTER TRIGGER só pode ser usado para gatilhos de linguagem de manipulação de dados [DML], pois os gatilhos de linguagem de definição de dados [DDL] não podem ser replicados.

Para replicação transacional e replicação de mesclagem, as alterações de esquema são propagadas incrementalmente quando o Agente de Distribuição ou o Agente de Mesclagem é executado. Para replicação de instantâneo, as alterações de esquema são propagadas quando um novo instantâneo é aplicado no Destinatário. Na replicação de instantâneo, uma nova cópia do esquema é enviada ao Subscrevedor sempre que a sincronização ocorre. Portanto, todas as alterações de esquema (não apenas as listadas acima) para objetos publicados anteriormente são propagadas automaticamente com cada sincronização.

Para obter informações sobre como adicionar e remover artigos de publicações, consulte Adicionar artigos e remover artigos de publicações existentes.

Para replicar alterações de esquema

As alterações de esquema listadas acima são replicadas por padrão. Para obter informações sobre como desabilitar a replicação de alterações de esquema, consulte Replicar Alterações de Esquema.

Considerações sobre alterações de esquema

Tenha em mente as considerações a seguir ao replicar alterações de esquema.

Considerações gerais

• As alterações de esquema estão sujeitas a quaisquer restrições impostas pelo Transact-SQL. Por exemplo, ALTER TABLE não permite alterar colunas de chave primária.

• O mapeamento de tipo de dados é executado apenas para o instantâneo inicial. As alterações de esquema não são mapeadas para versões anteriores de tipos de dados. Por exemplo, se a instrução ALTER TABLE ADD datetime2 column for usada no SQL Server 2012, o tipo de dados não será convertido para nvarchar assinantes do SQL Server 2005. Em alguns casos, as alterações de esquema são bloqueadas no Publicador.

• Se uma publicação estiver definida para permitir a propagação de alterações de esquema, as alterações de esquema serão propagadas independentemente de como a opção de esquema relacionada é definida para um artigo na publicação. Por exemplo, se você selecionar não replicar restrições de chave estrangeira para um artigo de tabela, mas emitir um comando ALTER TABLE que adiciona uma chave estrangeira à tabela no Publicador, a chave estrangeira será adicionada à tabela no Assinante. Para evitar isso, desabilite a propagação de alterações de esquema antes de emitir o comando ALTER TABLE.

• As alterações de esquema devem ser feitas somente no Publicador, não nos Assinantes (incluindo Assinantes que republicam). A replicação de mesclagem impede mudanças no esquema do Assinante. A replicação transacional não impede as alterações, mas as alterações podem fazer com que a replicação falhe.

• As alterações propagadas para um Assinante que republica são, por padrão, propagadas para seus Assinantes.

• Se a alteração do esquema fizer referência a objetos ou restrições existentes no Publicador, mas não no Assinante, a alteração do esquema terá êxito no Publicador, mas falhará no Assinante.

• Todos os objetos no Subscriber referenciados quando uma chave estrangeira é adicionada devem ter o mesmo nome e proprietário que o objeto correspondente no Publisher.

• Não há suporte para adicionar, remover ou alterar índices explicitamente. Há suporte para índices criados implicitamente para restrições (como uma restrição de chave primária).

• Não há suporte para alteração ou remoção de colunas de identidade gerenciadas por replicação. Para obter mais informações sobre o gerenciamento automático de colunas de identidade, consulte Replicar Colunas de Identidade.

• Não há suporte para alterações de esquema que incluem funções não determinísticas porque podem resultar em dados no Publicador e no Assinante diferentes (conhecidos como não convergência). Por exemplo, se você emitir o seguinte comando no Publicador: ALTER TABLE SalesOrderDetail ADD OrderDate DATETIME DEFAULT GETDATE(), os valores serão diferentes quando o comando for replicado para o Assinante e executado. Para obter mais informações sobre funções não determinísticas, consulte funções determinísticas e não determinísticas.

• É recomendável que as restrições sejam nomeadas explicitamente. Se uma restrição não for nomeada explicitamente, o SQL Server gerará um nome para a restrição e esses nomes serão diferentes no Publicador e em cada Assinante. Isso pode causar problemas durante a replicação de alterações de esquema. Por exemplo, se você excluir uma coluna no Publicador e uma restrição dependente for removida, a replicação tentará remover a restrição no Assinante. A queda no Assinante falhará porque o nome da restrição é diferente. Se a sincronização falhar devido a um problema de nomenclatura de restrição, exclua manualmente a restrição no lado do Assinante e execute novamente o Merge Agent.

• Se uma tabela for publicada para replicação, não será possível alterar uma coluna nessa tabela para um tipo de dados XML se um instantâneo de publicação já tiver sido gerado para alterar a coluna, primeiro você deverá remover a replicação.

• A leitura não confirmada não é um nível de isolamento com suporte ao fazer DDL em uma tabela publicada.

• SET CONTEXT_INFO não deve ser usado para modificar o contexto de transações em que as alterações de esquema são executadas em objetos publicados.

Adicionando colunas

• Para adicionar uma nova coluna a uma tabela e incluir essa coluna em uma publicação existente, execute ALTER TABLE <Table> ADD <Column>. Por padrão, a coluna é replicada para todos os Assinantes. A coluna deve permitir valores NULL ou incluir uma restrição padrão. Para obter mais informações sobre como adicionar colunas, consulte a seção "Replicação de Mesclagem" neste tópico.

• Para adicionar uma nova coluna a uma tabela e não incluir essa coluna em uma publicação existente, desabilite a replicação de alterações de esquema e execute ALTER TABLE <Table> ADD <Column>.

• Para incluir uma coluna existente em uma publicação existente, use sp_articlecolumn (Transact-SQL), sp_mergearticlecolumn (Transact-SQL), ou a caixa de diálogo Propriedades da Publicação – <Publicação>.

  Para obter mais informações, consulte Definir e modificar um filtro de coluna. Isso exigirá que as assinaturas sejam reinicializadas.

• Não há suporte para a adição de uma coluna de identidade a uma tabela publicada, pois ela pode resultar em não convergência quando a coluna é replicada para o Assinante. Os valores na coluna de identidade no Publicador dependem da ordem em que as linhas da tabela afetada são armazenadas fisicamente. As linhas podem ser armazenadas de forma diferente no Assinante; portanto, o valor da coluna de identidade pode ser diferente para as mesmas linhas.

Descartando colunas

• Para remover uma coluna de uma publicação existente e excluir a coluna da tabela no Publisher, execute ALTER TABLE <Table> DROP <Column>. Por padrão, a coluna é removida da tabela em todos os Assinantes.

• Para remover uma coluna de uma publicação existente, mas manter a coluna na tabela do Publicador, use sp_articlecolumn (Transact-SQL), sp_mergearticlecolumn (Transact-SQL), ou a caixa de diálogo Propriedades da Publicação – <Publicação>.

  Para obter mais informações, consulte Definir e modificar um filtro de coluna. Isso exigirá que um novo instantâneo seja gerado.

• A coluna a ser descartada não pode ser usada nas cláusulas de filtro de qualquer artigo de qualquer publicação no banco de dados.

• Ao remover uma coluna de um artigo publicado, leve em consideração quaisquer restrições, índices ou propriedades da coluna que possam afetar o banco de dados. Por exemplo:

  • Você não pode excluir colunas usadas em uma chave primária de artigos em publicações transacionais, porque elas são usadas pela replicação.

  • Você não pode remover a coluna rowguid de artigos em publicações de mesclagem ou a coluna mstran_repl_version de artigos em publicações transacionais que dão suporte à atualização de assinaturas, pois elas são usadas pela replicação.

  • As alterações de índice não são propagadas para assinantes: se você remover uma coluna no publicador e um índice dependente for descartado, a remoção do índice não será replicada. Você deve remover o índice no Assinante antes de remover a coluna no Publicador, para que a remoção da coluna seja bem-sucedida quando ela for replicada do Publicador para o Assinante. Se a sincronização falhar por causa de um índice no Assinante, remova o índice manualmente e execute o Merge Agent novamente.

  • As restrições devem ser explicitamente nomeadas para permitir a remoção. Para obter mais informações, consulte a seção "Considerações Gerais" anteriormente neste tópico.

Replicação transacional

• As alterações de esquema são propagadas para Assinantes que estão executando versões anteriores do SQL Server, porém a instrução DDL deve conter apenas a sintaxe que é compatível com a versão usada pelo Assinante.

  Se o Assinante republicar dados, as únicas alterações de esquema com suporte são adicionar e remover uma coluna. Essas alterações devem ser feitas no Publicador usando sp_repladdcolumn (Transact-SQL) e sp_repldropcolumn (Transact-SQL), e não pela sintaxe DDL ALTER TABLE.

• As alterações de esquema não são replicadas para assinantes que não são do SQL Server.

• As alterações de esquema não são propagadas de editores que não pertencem ao SQL Server.

• Não é possível alterar exibições indexadas replicadas como tabelas. Visões indexadas que são replicadas como visões indexadas podem ser alteradas, mas alterá-las fará com que se tornem visões regulares, em vez de visões indexadas.

• Se a publicação suportar atualizações imediatas ou em fila de assinaturas, o sistema deve ser colocado em estado de repouso antes de fazer alterações de esquema: todas as atividades na tabela publicada devem ser interrompidas no Publicador e nos Assinantes, e as alterações de dados pendentes devem ser propagadas ativamente para todos os nós. Depois que as alterações de esquema forem propagadas para todos os nós, as operações poderão ser retomadas nas tabelas publicadas.

• Se a publicação estiver em uma topologia ponto a ponto, o sistema deve ser suspenso antes de fazer alterações no esquema. Para obter mais informações, confira Como confirmar uma topologia de replicação (Programação Transact-SQL de replicação).

• Adicionar uma coluna de timestamp a uma tabela e mapear o timestamp para binário(8) faz com que o artigo seja reinicializado para todas as assinaturas ativas.

Replicação de mesclagem

• Como a replicação de mesclagem lida com alterações de esquema é determinada pelo nível de compatibilidade da publicação e se o instantâneo está definido como modo nativo (padrão) ou modo de caractere:

  • Para replicar alterações de esquema, o nível de compatibilidade da publicação deve ser pelo menos 90RTM. Se os Assinantes estiverem executando versões anteriores do SQL Server ou o nível de compatibilidade for menor que 90RTM, você poderá usar sp_repladdcolumn (Transact-SQL) e sp_repldropcolumn (Transact-SQL) para adicionar e soltar colunas. No entanto, esses procedimentos são preteridos.

  • Se você tentar adicionar a um artigo existente uma coluna com um tipo de dados que foi introduzido no SQL Server 2008, o SQL Server terá o seguinte comportamento:

    	100RTM, instantâneo nativo	100RTM, resumo de caractere	Todos os outros níveis de compatibilidade
    hierarchyid	Permitir alteração	Bloquear alteração	Bloquear alteração
    geography e geometry	Permitir alteração	Permitir alteração1	Bloquear alteração
    filestream	Permitir alteração	Bloquear alteração	Bloquear alteração
    date, time, datetime2e datetimeoffset	Permitir alteração	Permitir alteração1	Bloquear alteração

    ¹ Assinantes do SQL Server Compact convertem esses tipos de dados no assinante.

• Se ocorrer um erro ao aplicar uma alteração de esquema (como um erro resultante da adição de uma chave estrangeira que referencia uma tabela não disponível no Assinante), a sincronização falhará e a assinatura deverá ser reinicializada.

• Se uma alteração de esquema for realizada em uma coluna envolvida em um filtro de junção ou filtro parametrizado, é necessário reinicializar todas as assinaturas e regenerar o instantâneo.

• A replicação de mesclagem fornece procedimentos armazenados para ignorar alterações de esquema durante a solução de problemas. Para obter mais informações, consulte sp_markpendingschemachange (Transact-SQL) e sp_enumeratependingschemachanges (Transact-SQL).

Consulte Também

ALTERAR TABELA (Transact-SQL)
ALTER VIEW (Transact-SQL)
ALTER PROCEDURE (Transact-SQL)
ALTER FUNCTION (Transact-SQL)
ALTER TRIGGER (Transact-SQL)
Publicar dados e objetos de banco de dados
Regenerar procedimentos transacionais personalizados para refletir alterações de esquema