Alterando o proprietário do banco de dados no SQL Server 2008; Problemas de CLR dependendo do método usado?

Question

Anexei um banco de dados e tentei alterar o proprietário para um login válido.

Eu usei a declaração: ALTER AUTHORIZATION ON database :: my_db_name TO "sa". As propriedades do banco de dados mostraram que o novo proprietário era 'sa', no entanto, eu ainda estava recebendo erros de permissão para assemblies CLR irrestritos (0x80FC80F1, 0x8013150A), algo sobre problemas de confiança de assembly.

Resolvi o problema usando a instrução: EXEC sp_changedbowner 'sa'; para alterar o proprietário do banco de dados.

Minha pergunta é qual é a diferença entre esses dois métodos de alterar o proprietário do banco de dados. Eles são equivalentes? Parece claro para mim que sp_changedbowner está fazendo algo mais / correto que a declaração de alteração de autorização não está fazendo.

Caso você esteja interessado ... antes de consertar as coisas com sp_changedbowner, tentei:

• definindo a propriedade confiável do banco de dados como ON; na verdade, fiz isso algumas vezes; Eu sei que é um requisito para executar assemblies CLR personalizados sem restrições e não assinados
• alterando o proprietário de cada assembly do CLR para dbo, já que o proprietário estava em branco, mas aparentemente o dbo já era o proprietário e está sempre em branco no SSMS.
• alterando o proprietário de cada assembly do CLR para outra coisa, mas isso não funciona, porque os assemblies com assemblies dependentes parecem sempre precisar do mesmo proprietário; mas é impossível alterar o proprietário simultaneamente em ambos com a interface fornecida.
• chamando GRANT UNSAFE ASSEMBLY para [sa]; aparentemente você não pode conceder permissões para essa conta interna, junto com algumas outras; eles já têm permissão
• chamando GRANT UNSAFE ASSEMBLY para [NT AUTHORITY \ NETWORK SERVICE] (os métodos de chamada de conta nos assemblies); sem erros, mas não parece ter conseguido nada (talvez tenha alterado o número do erro? mas a mensagem nunca mudou).
• ... e provavelmente algumas outras coisas que não consigo lembrar.

Answer 1

Na sua lista, não vejo a configuração do banco de dados como confiável, então presumo que você tenha esquecido este passo:

ALTER DATABASE my_db_name SET TRUSTWORTHY ON;

Mas talvez não ...

Verificando com este artigo: link , parece que eles realmente sugerem o uso de sp_changedbowner em vez de ALTER AUTHORIZATION. Mas o fato é que faz exatamente a mesma coisa (sp_changedbowner chama ALTER AUTHORIZATION sob as cobertas). A diferença é que também remove "aliases" para o usuário do dbo (de qualquer forma, a funcionalidade reprovada), além de forçar um ponto de verificação do banco de dados. Essa última peça pode ser a que você está procurando.

    

Answer 2

Acredito que ALTER_AUTHORIZATION e sp_changedbowner podem alterar a propriedade do objeto de banco de dados. A diferença entre os comandos, é claro, é que ALTER_AUTHORIZATION pode mudar outras coisas (como a propriedade de tabelas), enquanto sp_changedbowner é apenas para mudar o dono do banco de dados.

O comportamento que você indicou parece muito estranho, no entanto. Você pode replicá-lo?