Compartilhar via


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

A replicação oferece suporte para um amplo intervalo de alterações de esquema para objetos publicados. Ao fazer qualquer uma das seguintes alterações de esquema no objeto publicado adequado em um Publicador do Microsoft SQL Server, a alteração é propagada por padrão a 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 Server 2005 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 DLL [linguagem de definição de dados] não podem ser replicados.

Observação importanteImportante

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 em SQL Server Management Studio, 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 de transação 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 Adicionando artigos e descartando 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 os tópicos a seguir:

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 column for usada no SQL Server 2008, o tipo de dados não será convertido em nvarchar para Assinantes do SQL Server 2005. 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 de transação 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.

  • Não há suporte ao se adicionar, descartar ou alterar índices explicitamente. Í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 Colunas de identidade de replicação.

  • 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 Funções determinísticas e não determinísticas.

  • 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 for publicada para replicação, não será possível alterar uma coluna dessa tabela para um tipo de dados XML, se um instantâneo de publicação já tiver sido gerado para alterar a coluna, você deverá primeiro remover a replicação. Para obter mais informações, consulte Removendo a replicação.

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

Adicionando colunas

  • Para adicionar uma nova coluna a uma tabela e incluir aquela coluna em uma publicação existente, execute ALTER TABLE <Tabela> ADD <Coluna>. 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 aquela coluna em uma publicação existente, desabilite a replicação de alterações de esquema e, então, execute ALTER TABLE <Tabela> ADD <Coluna>.

  • 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 de Publicação - <Publicação>.

    Para obter mais informações, consulte Como definir e modificar um filtro de coluna (Programação Transact-SQL de replicação) e Como definir e modificar um filtro de coluna (SQL Server Management Studio). Isso exigirá que as assinaturas sejam reinicializadas.

  • Não há suporte para adição de uma coluna de identidade a uma tabela publicada porque isso pode resultar em não convergência quando a coluna for replicada para o 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 diferente no Assinante; assim, o valor para a coluna de identidade pode ser diferente para as mesmas linhas.

Descartando colunas

  • Para descartar uma coluna de uma publicação existente e descartar a coluna da tabela no Publicador, execute ALTER TABLE <Tabela> DROP <Coluna>. Por padrão, a coluna é então descartada da tabela em todos os Assinantes.

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

    Para obter mais informações, consulte Como definir e modificar um filtro de coluna (Programação Transact-SQL de replicação) e Como definir e modificar um filtro de coluna (SQL Server Management Studio). 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 dão suporte à atualização de assinaturas, 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 de transação

  • As alterações de esquema são propagadas para Assinantes que estão executando versões anteriores de 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 deveriam 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 non-SQL.

  • 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 tiverem sido propagadas para todos os nós, a atividade pode ser retomada nas tabelas publicadas.

  • Edições anteriores do SQL Server exigiam que as publicações em topologias ponto a ponto fossem fechadas para novas sessões antes de fazer alterações no esquema. A partir do SQL Server 2008, não é mais necessário fechar a publicação para novas sessões, a não ser conforme descrito em outro lugar desta seção.

  • A adição de uma coluna de carimbo de data/hora a uma tabela e o mapeamento do carimbo de data/hora para binary(8) fazem com que o artigo seja 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 Assinantes estiverem executando versões anteriores do SQL Server ou o nível de compatibilidade for menor do que 90RTM, você pode usar sp_repladdcolumn (Transact-SQL) e sp_repldropcolumn (Transact-SQL) para adicionar e descartar 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, 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ção1

      Bloquear alteração

      filestream

      Permitir alteração

      Bloquear alteração

      Bloquear alteração

      date, time, datetime2 e datetimeoffset

      Permitir alteração

      Permitir alteração1

      Bloquear alteração

      1 Os Assinantes do SQL Server Compact convertem estes tipos de dados no Assinante.

    Para obter mais informações sobre a compatibilidade de publicações, consulte a seção “Nível de compatibilidade para publicações de mesclagem” em Usando várias versões do SQL Server em uma topologia de replicação.

  • 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 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).

Histórico de alterações

Conteúdo atualizado

Foi adicionada uma consideração de Replicação Transacional. Topologias ponto a ponto não precisam ser fechadas para novas sessões para cada alteração de esquema.