Como Resolver o Erro “Subscription Status Could Not Be Changed” na Replicação Transacional do SQL Server
Tempo de leitura: 3 minutosOlá pessoal,
Espero que estejam todos bem! 😊
No post de hoje vou compartilhar com vocês um caso interessante que aconteceu comigo na replicação de um cliente. Me deparei com um erro bem chato na replicação transacional do SQL Server: “The subscription status of the object could not be changed”.
Esse erro aparecia independentemente da operação que eu tentava fazer no ambiente, seja adicionar um novo subscriber, remover um subscriber, incluir ou remover artigos…
Enfim, a replicação ficou praticamente somente leitura. Uma situação bem complicada!
Imaginem o cenário: você tem um ambiente com várias publicações e algumas assinaturas rodando em produção de um volume de dados bem alto. Refazer toda a replicação do zero seria um trabalho gigantesco e custoso demais.
Tentei usar tanto o SSMS quanto procedures do sistema como “sp_dropsubscription”, para tentar contornar o problema, mas sem sucesso. O erro persistia:
Msg 14068, Level 16, State 1, Procedure sp_MSrepl_changesubstatus, Line 1386
The subscription status of the object could not be changed.
Até mesmo o Replication Monitor estava falhando para reinicializar as Subscriptions, e o Snapshot Agent ficava falhando sem dar informações úteis sobre o problema.
A situação estava complicada…
Mas a gente não desiste, não é mesmo?
Primeiro passo foi investigar se haviam “artigos órfãos” na replicação. Para isso, rodei o seguinte script no banco Publisher:
|
1 2 3 4 |
USE [SeuBancoDeDados] GO SELECT object_name(objid), name, artid FROM dbo.sysschemaarticles |
Sucesso!! Encontrei um artigo (objeto) que existia como objeto replicado (no meu caso era uma UDF (User-Defined-Function), mas que já havia sido removido do banco de dados.
Mas como eu sei que o registro está orfão?
Quando o objid retornar NULL, é bem provável que esse registro seja orfão, pois significa que ele não esteja associado a um objeto.
Importante: Não adianta simplesmente recriar o objeto dropado, pois ele terá um object_id diferente e não resolverá o problema.
O próximo passo foi fazer a limpeza desses registros órfãos. É necessário remover os registros de quatro tabelas:
- “syssubscriptions” e sysschemaarticles no banco “publisher”
- “MSsubscriptions” e “MSArticles” no banco “distribution”
No meu caso, identifiquei que o “artid = 2” era o candidato para remoção.
ATENÇÃO: Antes de fazer qualquer delete em produção, crie um backup dos registros numa tabela temporária.
|
1 2 3 4 5 6 7 8 |
-- No banco publisher USE [SeuBancoDeDados] GO DELETE FROM syssubscriptions WHERE artid = 2 DELETE FROM sysschemaarticles WHERE artid = 2 |
|
1 2 3 4 5 6 |
-- No banco distribution DELETE FROM distribution.dbo.MSsubscriptions WHERE article_id = 2 DELETE FROM distribution.dbo.MSArticles WHERE article_id = 2 |
Sucesso!!! Após remover o artigo órfão da replicação, consegui voltar a fazer todas as operações normalmente, adicionar subscribers, incluir novos artigos, enfim, tudo voltou ao normal!
Considerações Importantes
- Muito cuidado, este procedimento envolve alterações diretas nas tabelas de sistema da replicação. Sempre teste em ambiente de homologação primeiro!
- Faça sempre um backup dos registros antes de deletar qualquer coisa, acredite, isto pode te salvar e já me salvou muito.
- Se for fazer em produção, agende uma janela de manutenção e tenha um plano de rollback preparado, tenha em mente que se algo der errado, você terá tempo para resolver.
Dicas Adicionais
1. Monitore regularmente sua replicação para evitar que objetos órfãos se acumulem.
2. Documente todos os objetos que fazem parte da replicação.
3. Teste sempre em homologação antes de aplicar em produção.
Se vocês já passaram por situações similares ou têm outras dicas sobre replicação transacional, compartilhem nos comentários! A troca de experiências é fundamental para o crescimento de todos nós.
É isso pessoal! Espero que essa dica possa ajudar vocês caso se deparem com esse erro chato na replicação.
Se gostaram do post, deixem um comentário! Feedbacks são sempre bem-vindos!
Um grande abraço a todos, até a próxima!
Gustavo Larocca
Consultor SQL Server
