Faça alterações de esquemas em bancos de dados de publicações

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 ESCALATIONnão deve ser usado se a replicação de mudança de esquema estiver ativada e a topologia incluir SQL Server 2005 (9.x) ou SQL Server Compact 3.5 Subscribers.

  • ALTER VIEW

  • ALTER PROCEDURE

  • ALTER FUNCTION

  • ALTER TRIGGER

    ALTER TRIGGER podem ser usados apenas para gatilhos de linguagem de manipulação de dados (DML) porque gatilhos da linguagem de definição de dados (DDL) não podem ser replicados.

Importante

Você deve fazer alterações no esquema das tabelas usando o Transact-SQL ou os Objetos de Gerenciamento do SQL Server (SMO). Quando você faz alterações de esquema no SQL Server Management Studio, o Management Studio tenta eliminar e recriar a tabela. Você não pode descartar objetos publicados, então a mudança de esquema falha.

Para replicação transacional e replicação de mesclagem, alterações de esquema são propagadas de forma incremental quando o Agente de Distribuição ou o Agente de Mesclagem 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. Portanto, todas as alterações de esquema (não apenas as listadas anteriormente) em objetos publicados anteriormente são automaticamente propagadas a 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 anteriormente 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 mudanças 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 permite alterar colunas de chave primária.

  • O mapeamento de tipos de dados ocorre apenas para o snapshot inicial. Alterações de esquema não correspondem a versões anteriores dos tipos de dados. Por exemplo, se você usa ALTER TABLE ADD datetime2 column no SQL Server 2012 (11.x), o tipo de dado não se traduz para nvarchar para assinantes do SQL Server 2005 (9.x). Em alguns casos, as alterações de esquema são bloqueadas no Publicador.

  • Se você definir uma publicação para permitir a propagação de alterações de esquema, ela propaga alterações de esquema, independentemente de como você definiu a opção de esquema relacionada para um artigo na publicação. Por exemplo, se você optar por não replicar restrições de chave estrangeira para um artigo de tabela, mas depois emitir um comando ALTER TABLE que adiciona uma chave estrangeira à tabela no Editor, a chave estrangeira será adicionada à tabela no Assinante. Para evitar esse comportamento, desative a propagação das mudanças no esquema antes de emitir o ALTER TABLE comando.

  • Faça alterações de esquema apenas no Publisher, não no Assinantes (incluindo republicar Assinantes). Replicação de mesclagem evita alterações de esquema no Assinante. A replicação transacional não impede as mudanças, mas elas podem causar a 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 Publisher, mas não no Assinante, a mudança de esquema tem sucesso no Publisher, mas falha no Assinante.

  • Todos os objetos no Assinante referenciados por você ao se adicionar uma chave estrangeira devem ter o mesmo nome e proprietário que o objeto correspondente no Publicador.

  • A adição, eliminação ou alteração explícita de índices não é replicada. Você precisa executar qualquer alteração que envolva um índice explícito 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 para alterar ou eliminar colunas de identidade gerenciadas pela replicação. Para obter mais informações sobre o gerenciamento automático de colunas de identidade, consulte Replicar colunas de identidade.

  • Mudanças de esquema que incluem funções não determinísticas não são suportadas porque podem resultar em dados no Publisher e no Assinante sendo diferentes (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.

  • Especifique explicitamente as restrições de nome. Se você não nomear explicitamente uma restrição, o SQL Server gera um nome para a restrição, e esses nomes são diferentes no Publisher e em cada assinante. Essa diferença pode causar problemas durante a replicação de mudanças de esquema. Por exemplo, se você eliminar uma coluna no Publisher e uma restrição dependente for eliminada, a replicação tenta eliminar a restrição no Assinante. O descarte no Assinante falha 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 Agente de Mesclagem.

  • Se você publicar uma tabela para replicação, não poderá alterar uma coluna dessa tabela para o tipo de dados XML se você já tiver gerado um instantâneo da publicação. Para alterar a coluna, você deve primeiro remover a replicação.

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

  • Não use SET CONTEXT_INFO para modificar o contexto de transações onde alterações de esquema são realizadas contra 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 NULL valores ou incluir uma restrição padrão. Para mais informações sobre como adicionar colunas, veja a seção "Replicação de Fusão" neste artigo.

  • Para adicionar uma nova coluna a uma tabela e não incluir essa coluna em uma publicação existente, desative a replicação das mudanças de esquema e então 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. Essa ação exige que as assinaturas sejam reinicializadas.

  • Adicionar uma coluna de identidade a uma tabela publicada não tem suporte, pois isso pode resultar em falta de 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 diversa no Assinante; assim, o valor da coluna de identidade pode ser diferente para as mesmas linhas.

Removendo colunas

  • Para remover uma coluna de uma publicação existente e retirar a coluna da tabela no Publisher, 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. Essa ação requer gerar um novo snapshot.

  • Você não pode usar a coluna para inserir as cláusulas de filtro de qualquer artigo de qualquer publicação no banco de dados.

  • Ao eliminar uma coluna de um artigo publicado, considere 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 dos artigos de publicações transacionais, porque a replicação as usa.

    • Você não pode remover a coluna rowguid dos artigos em publicações de mesclagem nem a coluna mstran_repl_version dos artigos em publicações transacionais que oferecem suporte a assinaturas atualizáveis, porque a replicação as usa.

    • As alterações no índice não são propagadas para os Assinantes. Se você remover uma coluna no Publicador e um índice dependente for removido, a remoção do índice não será replicada. 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 Agente de Mesclagem.

    • Restrições de nomes explicitas para que você possa eliminá-las. Para mais informações, veja a seção "Considerações Gerais" anteriormente neste artigo.

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 aceitas são adicionar e remover uma coluna. Faça essas alterações no Publisher usando sp_repladdcolumn (Transact-SQL) e sp_repldropcolumn (Transact-SQL) em vez da ALTER TABLE sintaxe DDL.

  • Não são replicadas alterações de esquema a Assinantes de não SQL Server.

  • Alterações de esquema não são propagadas a partir de Publicadores que não sejam do SQL Server.

  • Você não pode alterar visões indexadas que são replicadas como tabelas. Você pode alterar visualizações indexadas que são replicadas como visualizações indexadas, mas alterá-las faz com que se tornem vistas regulares em vez de visualizações indexadas.

  • Se a publicação oferecer suporte a atualizações imediatas ou a assinaturas com atualização em fila, coloque o sistema em estado de quiescência antes de fazer alterações de esquema: interrompa toda a atividade na tabela publicada no Publicador e nos Assinantes, e propague as alterações de dados pendentes para todos os nós. Após as alterações no esquema serem propagadas para todos os nós, as atividades podem ser retomadas nas tabelas publicadas.

  • Se a publicação estiver em uma topologia peer-to-peer, coloque o sistema em pausa 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).

  • O adição de uma coluna de carimbo e o mapeamento do carimbo para binary(8) levam o artigo a ser reinicializado para todas as assinaturas ativas.

Replicação por mesclagem

  • Como a replicação de mescla lida com as mudanças de esquema depende do nível de compatibilidade de publicação e se o snapshot está configurado para modo nativo (padrão) ou modo de caractere:

    • Para replicar mudanças de esquema, defina o nível de compatibilidade de publicação para pelo menos 90RTM. Se assinantes usarem versões anteriores do SQL Server ou o nível de compatibilidade for inferior a 90RTM, use sp_repladdcolumn (Transact-SQL) e sp_repldropcolumn (Transact-SQL) para adicionar e eliminar colunas. No entanto, esses procedimentos estão obsoletos.

    • 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 do personagem Todos os outros níveis de compatibilidade
      hierarchyid Permitir alteração Bloquear alteração Bloquear alteração
      geografia e geometria 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).

Conteúdo relacionado

  • Última atualização em