Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Aplica-se a: 
SQL ServerAzure SQL Managed Instance
A replicação oferece suporte a uma ampla variedade 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 Microsoft SQL Server Publisher, 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 alterações de esquema estiver ativada e uma topologia incluir SQL Server 2005 (9.x) ou SQL Server Compact 3.5 Subscribers.ALTER VIEW
ALTER PROCEDURE
ALTER FUNCTION
ALTER TRIGGER
ALTER TRIGGERpodem ser usados apenas para gatilhos de linguagem de manipulação de dados (DML) porque os gatilhos da linguagem de definição de dados (DDL) não podem ser replicados.
Important
Deve fazer alterações de esquema nas tabelas utilizando Transact-SQL ou Objetos de Gestão do SQL Server (SMO). Quando faz alterações de esquema no SQL Server Management Studio, o Management Studio tenta remover e recriar a tabela. Não podes eliminar objetos publicados, por isso a alteração do esquema falha.
Para replicação transacional e replicação de fusão, as alterações de esquema são propagadas de forma incremental quando o Distribution Agent ou Merge Agent é executado. Para a replicação de snapshots, as alterações de esquema propagam-se quando um novo snapshot é aplicado ao Subscritor. Na replicação instantânea, uma nova cópia do esquema é enviada ao Assinante cada vez que ocorre a sincronização. Portanto, todas as alterações de esquema (não apenas as mencionadas anteriormente) para objetos previamente publicados são automaticamente propagadas a cada sincronização.
Para informações sobre adicionar e remover artigos de publicações, veja Adicionar Artigos e Eliminar Artigos de Publicações Existentes.
Para replicar alterações de esquema
As alterações de esquema listadas anteriormente são replicadas por predefinição. Para informações sobre como desativar a replicação de alterações de esquema, veja Replicar Alterações de Esquema.
Considerações para alterações de esquema
Tenha em mente as seguintes considerações 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 TABLEnão permite alterar as colunas principais.O mapeamento de tipos de dados ocorre apenas para o instantâneo inicial. As alterações de esquema não correspondem a versões anteriores dos tipos de dados. Por exemplo, se usar
ALTER TABLE ADD datetime2 columnno SQL Server 2012 (11.x), o tipo de dado não se traduz para nvarchar para subscritores do SQL Server 2005 (9.x). Em alguns casos, as alterações de esquema são bloqueadas no Publisher.Se definir uma publicação para permitir a propagação de alterações de esquema, ela propaga alterações de esquema, independentemente de como define a opção de esquema relacionada para um artigo na publicação. Por exemplo, se optar por não replicar restrições de chave estrangeira para um artigo de uma tabela, mas depois executar um comando
ALTER TABLEque adiciona uma chave estrangeira à tabela no Publicador, a chave estrangeira é adicionada à tabela no Subscritor. Para evitar este comportamento, desative a propagação das alterações no esquema antes de emitir oALTER TABLEcomando.Faça alterações de esquema apenas no Publisher, não nos Subscritores (incluindo a republicação dos Subscritores). A replicação de fusão impede alterações de esquema no Assinante. A replicação transacional não impede as alterações, mas estas podem causar o fracasso da replicação.
As alterações propagadas para um Subscritor de republicação são, por defeito, propagadas para os seus Subscritores.
Se a alteração de esquema fizer referência a objetos ou restrições existentes no Publisher mas não no Subscritor, a alteração de esquema tem sucesso no Publisher mas falha no Assinante.
Todos os objetos no Subscritor que referencias ao adicionar uma chave estrangeira devem ter o mesmo nome e proprietário do objeto correspondente no Publisher.
A adição, eliminação ou alteração explícita de índices não é replicada. É necessário executar qualquer alteração que envolva um índice explícito em cada conjunto de réplicas individualmente. São suportados índices criados implicitamente para restrições (como uma restrição de chave primária).
Não é suportado alterar ou eliminar colunas de identidade geridas pela replicação. Para mais informações sobre a gestão automática das colunas de identidade, consulte Replicar Colunas de Identidade.
Alterações de esquema que incluem funções não determinísticas não são suportadas porque podem resultar em dados no Publisher e no Subscritor a serem diferentes (referidas como não-convergência). Por exemplo, se emitir o seguinte comando no Publicador:
ALTER TABLE SalesOrderDetail ADD OrderDate DATETIME DEFAULT GETDATE(), os valores são diferentes quando o comando é replicado no Subscritor e executado. Para mais informações sobre funções não determinísticas, veja Funções Determinísticas e Não Determinísticas.Especifique explicitamente as restrições de nome. Se não nomeares explicitamente uma restrição, o SQL Server gera um nome para essa restrição, e esses nomes são diferentes no Publisher e em cada assinante. Esta diferença pode causar problemas durante a replicação das alterações de esquema. Por exemplo, se eliminar uma coluna no Publisher e uma restrição dependente for eliminada, a replicação tenta eliminar a restrição no Assinante. A queda no Subscritor falha porque o nome da restrição é diferente. Se a sincronização falhar devido a um problema de nomenclatura de restrições, elimine manualmente a restrição no Assinante e depois execute novamente o Merge Agent.
Se publicares uma tabela para replicação, não podes alterar uma coluna nessa tabela para um tipo de dados XML se já geraste um snapshot de publicação. Para alterar a coluna, deve primeiro remover a replicação.
Read uncommitted não é um nível de isolamento suportado ao executar DDL numa tabela publicada.
Não use SET CONTEXT_INFO para modificar o contexto das transações em que alterações de esquema são feitas contra objetos publicados.
Adicionar colunas
Para adicionar uma nova coluna a uma tabela e incluir essa coluna numa publicação existente, execute
ALTER TABLE <Table> ADD <Column>. Por predefinição, a coluna é replicada para todos os Subscritores. A coluna deve permitir valoresNULLou ter um valor predefinido. Para mais informações sobre a adição de colunas, consulte a secção "Merge Replication" neste artigo.Para adicionar uma nova coluna a uma tabela e não incluir essa coluna numa publicação existente, desative a replicação das alterações de esquema e execute
ALTER TABLE <Table> ADD <Column>.Para incluir uma coluna existente numa 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 mais informações, veja Definir e Modificar um Filtro de Coluna. Esta ação requer que as subscrições sejam reinicializadas.
A adição de uma coluna de identidade a uma tabela publicada não é suportada, pois pode resultar em não-convergência quando a coluna é replicada para o Subscritor. Os valores na coluna de identidade no Publisher dependem da ordem em que as linhas da tabela afetada são fisicamente armazenadas. As linhas podem ser armazenadas de forma diferente no Assinante; portanto, o valor da coluna de identidade pode ser diferente para as mesmas linhas.
Eliminar colunas
Para retirar uma coluna de uma publicação existente e retirar a coluna da tabela no Publisher, execute
ALTER TABLE <Table> DROP <Column>. Por predefinição, a coluna é depois removida da tabela de todos os Subscritores.Para remover uma coluna de uma publicação existente, mas manter a coluna na tabela no Publicador, utilize sp_articlecolumn (Transact-SQL), sp_mergearticlecolumn (Transact-SQL) ou a caixa de diálogo Propriedades da Publicação - <Publicação>.
Para mais informações, veja Definir e Modificar um Filtro de Coluna. Esta ação requer gerar um novo snapshot.
Não pode usar a coluna para inserir as cláusulas de filtro de qualquer artigo de qualquer publicação na base de dados.
Ao eliminar uma coluna de um artigo publicado, considere quaisquer restrições, índices ou propriedades da coluna que possam afetar a base de dados. Por exemplo:
Não se podem eliminar colunas usadas numa chave primária de artigos em publicações transacionais, porque a replicação utiliza-as.
Não podes eliminar a
rowguidcoluna dos artigos em publicações de fusão nem amstran_repl_versioncoluna dos artigos em publicações transacionais que suportam a atualização de subscrições, porque a replicação os utiliza.As alterações no índice não são propagadas aos Subscritores. Se eliminares uma coluna no Publicador e um índice dependente for eliminado, a eliminação do índice não é replicada. Deve eliminar o índice no Assinante antes de eliminar a coluna no Publicador, para que a eliminação da coluna seja bem-sucedida quando for replicada do Publicador para o Assinante. Se a sincronização falhar devido a um índice existente no Assinante, elimine manualmente o índice e depois execute novamente o Merge Agent.
Dê nomes explícitos às restrições para as poder eliminar. Para mais informações, consulte a secção "Considerações Gerais" anteriormente neste artigo.
Replicação transacional
As alterações de esquema são propagadas para Subscritores com versões anteriores do SQL Server, mas a instrução DDL deve incluir apenas a sintaxe suportada pela versão utilizada no Assinante.
Se o Assinante republicar dados, as únicas alterações de esquema suportadas são adicionar e eliminar uma coluna. Faça estas alterações no Publisher usando sp_repladdcolumn (Transact-SQL) e sp_repldropcolumn (Transact-SQL) em vez da
ALTER TABLEsintaxe DDL.As alterações de esquema não são replicadas para assinantes que não sejam do SQL Server.
As alterações de esquema não são propagadas por editores que não sejam SQL Server.
Não podes alterar vistas indexadas que são replicadas como tabelas. Pode alterar vistas indexadas que são replicadas como vistas indexadas, mas alterá-las faz com que se tornem vistas regulares em vez de visualizações indexadas.
Se a publicação suportar atualizações imediatas ou subscrições de atualização em fila de espera, coloque o sistema em estado de inatividade antes de fazer alterações ao esquema: pare toda a atividade na tabela publicada no Publicador e nos Subscritores e propague as alterações de dados pendentes para todos os nós. Após as alterações de esquema se propagarem para todos os nós, a atividade pode ser retomada nas tabelas publicadas.
Se a publicação estiver numa topologia peer-to-peer, coloque o sistema em pausa antes de fazer alterações no esquema. Para obter mais informações, consulte desativar uma topologia de replicação (replicação Transact-SQL programação).
Adicionar uma coluna timestamp a uma tabela e mapear o timestamp para
binary(8)faz com que o artigo seja reinicializado para todas as subscrições ativas.
Replicação de mesclagem
A forma como a replicação da fusão lida com alterações de esquema depende do nível de compatibilidade de publicação e se o snapshot está definido para modo nativo (padrão) ou modo de carácter:
Para replicar alterações de esquema, defina o nível de compatibilidade de publicação para, pelo menos, 90RTM. Se os Subscritores usarem versões anteriores de 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, estes procedimentos estão obsoletos.
Se tentar adicionar a um artigo existente uma coluna com um tipo de dado introduzido no SQL Server 2008 (10.0.x), o SQL Server apresenta o seguinte comportamento:
100RTM, instantâneo nativo 100RTM, instantâneo da personagem Todos os outros níveis de compatibilidade hierarchyid Permitir a mudança Bloquear alteração Bloquear alteração Geografia e geometria Permitir a mudança Permitir mudança* Bloquear alteração filestream Permitir a mudança Bloquear alteração Bloquear alteração date, time, datetime2 e datetimeoffset Permitir a mudança Permitir mudança* Bloquear alteração *Os subscritores do SQL Server Compact convertem estes tipos de dados no Subscritor.
Se ocorrer um erro ao aplicar 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 falha e a subscrição deve ser reinicializada.
Se for feita uma alteração de esquema numa coluna envolvida num filtro de junção ou filtro parametrizado, deve reinicializar todas as subscrições e regenerar o snapshot.
A replicação por fusão fornece procedimentos armazenados para saltar alterações de esquema durante a resolução de problemas. Para mais informações, veja sp_markpendingschemachange (Transact-SQL) e sp_enumeratependingschemachanges (Transact-SQL).