Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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 SETLOCK ESCALATION não deve ser usado se a replicação de alterações de esquema estiver habilitada e uma topologia incluir SQL Server 2005 (9.x) ou Assinantes do SQL Server Compact 3.5.
ALTER VIEW
ALTER PROCEDURE
ALTER FUNCTION
ALTER TRIGGER
ALTER TRIGGER pode ser usado somente 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.
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 Agente de Distribuição ou o Agente de Mesclagem são executados. Para replicação por instantâneo, as alterações de esquema são propagadas quando um novo instantâneo é aplicado no assinante. Na replicação de instantâneo, uma nova cópia do esquema é enviada ao Assinante cada vez que a sincronização ocorre. 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 permite alterar colunas de chave primária.
O mapeamento de tipos 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 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ê optar por não replicar restrições de chave estrangeira para um artigo da tabela, mas depois emitir um comando ALTER TABLE que adicione 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 ALTER TABLE comando.
As alterações de esquema devem ser feitas somente no Publicador, não nos Assinantes (inclusive os Assinantes de republicação). A replicação de mesclagem impede 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.
As alterações propagadas para um Assinante de republicação também 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 adicionar uma chave estrangeira devem ter o mesmo nome e o mesmo proprietário que os objetos correspondentes no Publicador.
A adição, a remoção ou a alteração explícita de índices não é replicada, e qualquer alteração que envolva um índice explícito precisará ser executada individualmente em cada conjunto de réplicas. Índices criados implicitamente para restrições (como uma restrição de chave primária) têm suporte.
Não há suporte para alterar ou remover 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.
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ê excluir uma coluna no Publicador e uma restrição dependente for excluída, a replicação tentará excluir a restrição no Assinante. A exclusão no Assinante falhará porque o nome da restrição é diferente. Se a sincronização falhar devido a um problema com o nome da restrição, remova manualmente a restrição no Assinante e execute o Agente de Mesclagem novamente.
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.
Read uncommitted não é um nível de isolamento suportado ao executar 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<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 e não incluir essa coluna em uma publicação existente, desative a replicação das 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 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 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.
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 é removida da tabela de 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 novo snapshot.
A coluna a ser removida não pode ser usada em 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 remover colunas usadas em uma chave primária dos artigos em publicações transacionais, pois elas são usadas pela replicação.
Não é possível remover a coluna rowguid de artigos em publicações de mesclagem nem a coluna mstran_repl_version de artigos em publicações transacionais que oferecem suporte a assinaturas atualizáveis, pois 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. 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 essa remoção for replicada do Publicador para o Assinante. Se a sincronização falhar devido a um índice no Assinante, exclua manualmente o índice e, em seguida, execute novamente o Agente de Mesclagem.
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 executando versões anteriores do SQL Server, mas a instrução DDL deve incluir apenas sintaxe compatível com a versão do Assinante.
Se o Assinante republicar dados, as únicas alterações de esquema aceitas são adicionar e remover uma coluna. Essas alterações devem ser feitas no Publisher usando sp_repladdcolumn (Transact-SQL) e sp_repldropcolumn (Transact-SQL) em vez ALTER TABLE de sintaxe 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 Publicadores que não sejam do 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 a assinaturas com atualização imediata ou com atualização enfileirada, o sistema deverá ser colocado em estado de quiescência antes de fazer alterações no esquema: toda a 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 deverá ser colocado em estado quiescente antes de serem feitas alterações no esquema. Para obter mais informações, confira Como confirmar uma topologia de replicação (Programação Transact-SQL de replicaçã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 por mesclagem
A forma como a replicação de mesclagem trata as alterações de esquema é determinada pelo nível de compatibilidade da publicação e por se o instantâneo está definido para modo nativo (padrão) ou modo 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 se 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. 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 esses 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 for feita uma alteração no esquema de 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 resolução de problemas. Para obter mais informações, consulte sp_markpendingschemachange (Transact-SQL) e sp_enumeratependingschemachanges (Transact-SQL).