sdcharle's questions

Temos uma publicação de mesclagem que estava funcionando bem há muito tempo (anos). Recentemente, um artigo foi adicionado, fomos informados de que o instantâneo estava desatualizado, então o regeneramos. Em seguida, recebemos mensagens de erro durante a inicialização e encontramos este problema nos logs de erros detalhados:

Msg 1934, Nível 16, Estado 1, Procedimento DDLTrigger_Index, Linha 19 INSERT falhou porque as seguintes opções SET têm configurações incorretas: 'ANSI_PADDING'. Verifique se as opções SET estão corretas para uso com exibições indexadas e/ou índices em colunas computadas e/ou notificações de consulta e/ou métodos de tipo de dados xml.

...avanço rápido para agora. Em experimentos, descobrimos que sim, é possível criar uma publicação mesclada no editor e se inscrever em nosso servidor de assinantes, mas apenas se estiver usando um banco de dados diferente. Passei por isso apenas para descartar permissões / etc e para determinar se era realmente o banco de dados do assinante que era o problema.

Portanto, parecia lógico remover a replicação do banco de dados afetado na esperança de limpar qualquer confusão de metadados enterrada:

sp_removedbreplication @dbname = 'sickDB' @type = 'all'

Até agora tudo bem. No entanto, agora recebo exatamente o mesmo erro, mas muito mais cedo no processo. Especificamente, ao executar:

/****** Begin: Script to be run at Subscriber ******/
use [sickDB]
exec sp_addmergepullsubscription 
@publisher = N'publisher',
 @publication = N'publication', 
 @publisher_db = N'goodDB',
  @subscriber_type = N'Local',
   @subscription_priority = 0,
    @description = N'hope this works', @sync_type = N'Automatic'

(acima editado ligeiramente).

Existe algum problema remanescente à espreita nos metadados? A teoria original sobre o material ANSI_PADDING era de fato algumas tabelas no banco de dados do assinante com colunas computadas, portanto, que pareciam relacionadas. No entanto, algumas mudanças nas configurações ANSI_PADDING (e pesquisas no Google) não levaram a uma resposta conclusiva.

Muito obrigado pela leitura e deixe-me saber de qualquer outra informação que eu possa fornecer que possa ajudar.

Ah, sim, editor e assinante são SQL Server 2005.

Estou configurando a comunicação do Service Broker entre 2 servidores, A e B, vamos chamá-los. Usei este artigo como exemplo.

A é SQL 2005, B é SQL 2012. Não funciona e não consegui encontrar um bom motivo para isso. O que posso ver é:

O Profiler na extremidade receptora nem mesmo mostra nenhum evento do Service Broker, indicando que nada está chegando até ele.

Mas usando ssbdiagnose conforme abaixo, ele diz parabéns, você não tem erros:

C:\Users\me>ssbdiagnose -level info -E configuration from service ServerAServiceTest -S ServerA -d MyDB to Service ServerBServiceTest -S ServerB -d MyDB on Contract myContract

Microsoft SQL Server 11.0.2100.60
Service Broker Diagnostic Utility
0 Errors, 0 Warnings

Também na fila de transmissão, a única coisa que vejo que parece particularmente desligada é 'to_broker_instance' é nulo, embora eu tenha especificado explicitamente essa informação ao configurar a rota.

Além disso, nenhum erro está aparecendo emmission_status.

Além disso, os logs de erro do SQL Server não estão esclarecendo nada.

Quanto aos problemas de firewall, bem, esses são servidores de teste não acessíveis de fora, então tentei desligar os firewalls completamente.

Uma coisa que é incômoda, vou pegar isso:

Ocorreu uma exceção ao enfileirar uma mensagem na fila de destino. Erro: 15581 Estado: 7. Crie uma chave mestra no banco de dados ou abra a chave mestra na sessão antes de executar esta operação.

Eu abro a chave e eles vão embora. Mas eu não deveria ter que abrir repetidamente a chave toda vez que quero fazer algo, deveria? Suspeito que isso seja parte do problema, embora, como mencionado, os erros desapareçam.

Desculpe pela pergunta um tanto aberta - até mesmo alguma ajuda para identificar onde obter erros mais informativos ou informações de depuração seria ótima. Este é um território novo para mim.