Fazer alterações de esquema em bancos de dados de publicação
Aplica-se a: 
SQL Server Instância Gerenciada de SQL do Azure
A replicação oferece suporte para um amplo intervalo de alterações de esquema para objetos publicados. Quando você faz qualquer uma das seguintes alterações de esquema no objeto publicado apropriado em um Fornecedor 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 da alteração de esquema estiver habilitada e uma topologia incluir SQL SQL Server 2005 (9.x) ou SQL Server Compact 3.5 Subscribers.
ALTER VIEW
ALTER PROCEDURE
ALTER FUNCTION
ALTER TRIGGER
ALTER TRIGGER pode ser usado somente para gatilhos DML [linguagem de manipulação de dados], pois os gatilhos DDL [linguagem de definição de dados] não podem ser replicados.
Importante
As alterações de esquema para tabelas devem ser feitas usando-se Transact-SQL ou SMO ( SQL Server Management Objects). Quando alterações de esquema forem feitas no SQL Server Management Studio, o Management Studio tenta descartar e recriar a tabela. Não é possível descartar objetos publicados; portanto, há falha na alteração de esquema.
Para replicação transacional e replicação de mesclagem, alterações de esquema são propagadas de forma incremental quando o Distribution Agent ou o Merge Agent são executados. Para replicação de instantâneo, alterações de esquema são propagadas quando um instantâneo novo for aplicado ao Assinante. Em replicação de instantâneo, uma cópia nova do esquema é enviada ao Assinante a cada vez que ocorrer sincronização. Assim, todas as alterações de esquema (não apenas aquelas listadas acima) para objetos previamente publicados são propagadas automaticamente com cada sincronização.
Para obter informações sobre como adicionar e remover artigos de publicações, consulte Adicionar 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 Replicate Schema Changes.
Considerações para alterações de esquema
Lembre-se das seguintes considerações ao replicar alterações de esquema.
Considerações gerais
As alterações de esquema estão sujeitas a qualquer restrição imposta por Transact-SQL. Por exemplo, ALTER TABLE não lhe permite ALTER colunas de chave primária.
O mapeamento de tipo de dados só é executado 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 columnfor usada no SQL Server 2012 (11.x), o tipo de dados não será convertido em nvarchar para assinantes do SQL Server 2005 (9.x). Em alguns casos, as alterações de esquema são bloqueadas no Publicador.Se uma publicação é definida para permitir a propagação de alterações de esquema, alterações de esquema são propagadas independentemente de como a opção de esquema correspondente é 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 então emitir um comando ALTER TABLE que adiciona uma chave estrangeira à tabela no Publicador, a chave estrangeira será acrescentada à 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 em Assinantes (inclusive Assinantes de republicação). Replicação de mesclagem evita alterações de esquema no Assinante. Replicação transacional não evita as alterações, mas as alterações podem levar à falha da replicação.
Alterações propagadas para um Assinante de republicação são, por padrão, propagadas para seus Assinantes.
Se a alteração de esquema faz referência a objetos ou restrições existentes no Publicador mas não no Assinante, a alteração de esquema tem êxito no Publicador mas não no Assinante.
Todos os objetos no Assinante que são referenciados ao se adicionar uma chave estrangeira devem ter o mesmo nome e proprietário que o objeto correspondente no Publicador.
Adicionar, descartar ou alterar explicitamente índices não são replicados e qualquer alteração que envolva um índice explícito precisará ser executada em cada conjunto de réplicas individualmente. Índices criados implicitamente para restrições (como uma restrição de chave primária) têm suporte.
Não há suporte ao se alterar ou descartar 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.
As alterações de esquema que incluem funções não determinísticas não têm suporte, pois podem resultar em dados diferentes no Publicador e no Assinante (o que é chamado de não convergência). Por exemplo, se você emitir o seguinte comando no Publicador:
ALTER TABLE SalesOrderDetail ADD OrderDate DATETIME DEFAULT GETDATE(), os valores são diferentes quando o comando é replicado para o Assinante e executado. Para obter mais informações sobre funções não determinísticas, consulte Deterministic and Nondeterministic Functions.Recomenda-se que restrições sejam nomeadas explicitamente. Se uma restrição não for nomeada explicitamente, 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ê descartar uma coluna no Publicador e uma restrição dependente for descartada, a replicação tentará descartar a restrição no Assinante. O descarte no Assinante irá falhar porque o nome da restrição é diferente. Se a sincronização falhar devido a um problema de nomeação de restrição, descarte manualmente a restrição no Assinante e, então, execute novamente o Merge Agent.
Se uma tabela é publicada para replicação, não é possível alterar uma coluna naquela tabela para um tipo de dados XML se um instantâneo de publicação já tiver sido gerado. Para alterar a coluna, você deve primeiramente remover a replicação.
Leitura não confirmada não é um nível de isolamento com suporte ao fazer o 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 sem incluir essa coluna em uma publicação existente, desabilite a replicação de alterações de esquema e, em seguida, 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 colunas. Isso exigirá que as assinaturas sejam reinicializadas.
Não há suporte para adicionar uma coluna de identidade a uma tabela publicada, pois isso pode resultar em não convergência quando a coluna é replicada no Assinante. Os valores na coluna de identidade no Publicador dependerão da ordem em que as linhas para a tabela afetada forem armazenadas fisicamente. As linhas podem ser armazenadas de forma diversa no Assinante; assim, 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 remover a coluna da tabela no Publicador, execute ALTER TABLE <Table> DROP <Column>. Por padrão, a coluna é então descartada da tabela em todos os Assinantes.
Para remover uma coluna de uma publicação existente, mas manter a coluna na tabela no 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 colunas. Isso exigirá a geração de um instantâneo novo.
A coluna a ser descartada não pode ser usada nas cláusulas de filtro de nenhum artigo de nenhuma publicação no banco de dados.
Ao descartar uma coluna de um artigo publicado, considere quaisquer restrições, índices ou propriedades da coluna que possam afetar o banco de dados. Por exemplo:
Não é possível descartar colunas usadas em uma chave primária de artigos em publicações transacionais, uma vez que elas são usadas pela replicação.
Não é possível descartar a coluna rowguid de artigos em publicações de mesclagem ou a coluna mstran_repl_version de artigos em publicações transacionais que suportam assinaturas de atualização, uma vez que elas são usadas pela replicação.
As alterações de índices não são propagadas para Assinantes: se você descartar uma coluna no Publicador e um índice dependente for descartado, o índice descartado não será replicado. Deve-se descartar o índice no Assinante antes de descartar as colunas no Publicador, de forma que o descarte da coluna tenha êxito quando for replicado do Publicador para o Assinante. Se a sincronização falhar devido a um índice no Assinante, descarte manualmente o índice e, então, execute novamente o Merge Agent.
Restrições devem ser explicitamente nomeadas para permitir que sejam descartadas. 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, mas a instrução DDL deverá incluir apenas sintaxe que tenha suporte da versão do Assinante.
Se o Assinante republicar dados, as únicas alterações de esquema com suporte incluem adicionar e descartar uma coluna. Essas alterações devem ser feitas no Publicador usando sp_repladdcolumn (Transact-SQL) e sp_repldropcolumn (Transact-SQL) em vez da sintaxe ALTER TABLE DDL.
Não são replicadas alterações de esquema a Assinantes de não SQL Server.
As alterações de esquema não são propagadas de Publicadores não SQL Server.
Não é possível alterar exibições indexadas que são replicadas como tabelas. Exibições indexadas que são replicadas como exibições indexadas podem ser alteradas, mas sua alteração irá fazer com que sejam exibições regulares e não exibições indexadas.
Se a publicação oferecer suporte à atualização imediata ou a assinaturas de atualização enfileirada, o sistema deverá ser confirmado antes que sejam feitas alterações de esquema: toda atividade na tabela publicada deve ser interrompida no Publicador e nos Assinantes, e as alterações de dados pendentes deverão ser propagadas para todos os nós. Depois que as alterações de esquema tenham se propagado para todos os nós, a atividade pode ser retomada nas tabelas publicadas.
Se a publicação estiver em uma topologia ponto a ponto, o sistema deve ser confirmado antes que sejam feitas alterações de esquema. Para obter mais informações, confira Como confirmar uma topologia de replicação (Programação Transact-SQL de replicação).
O adição de uma coluna de carimbo e o mapeamento do carimbo para binário(8) levam o artigo a ser reinicializado para todas as assinaturas ativas.
Replicação de mesclagem
A maneira como a replicação de mesclagem trata alterações de esquema é determinada pelo nível de compatibilidade da publicação e pela definição do instantâneo 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 ou o nível de compatibilidade for inferior a 90RTM, você poderá usar sp_repladdcolumn (Transact-SQL) e sp_repldropcolumn (Transact-SQL) para adicionar e remover colunas. Porém, estes procedimentos não são recomendados.
Se você tentar adicionar a um artigo existente uma coluna com um tipo de dados que foi lançado no SQL Server 2008 (10.0.x), o SQL Server terá o seguinte comportamento:
100RTM, instantâneo nativo 100RTM, instantâneo 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ção* Bloquear alteração fluxo de arquivos Permitir alteração Bloquear alteração Bloquear alteração date, time, datetime2e datetimeoffset Permitir alteração Permitir alteração* Bloquear alteração *Os Assinantes do SQL Server Compact convertem estes tipos de dados no Assinante.
Se um erro ocorrer ao ser aplicada uma alteração de esquema (como um erro resultante da adição de uma chave estrangeira que faz referência a 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 feita em uma coluna envolvida em um filtro de junção ou filtro com parâmetros, deve reinicializar-se todas as assinaturas e gerar novamente o instantâneo.
A replicação de mesclagem leva os procedimentos armazenados a 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).