Eu vim para contornar esse problema. Não sei por que isso funcionaria, mas nunca menos. :) É definitivamente sobre segurança.
Investiguei se o SQL Agent está sendo executado em nome do usuário do domínio, digamos DOMAIN\User .Tem um conjunto completo de direitos de administrador no servidor (função de servidor 'sysadmin', etc). O próprio SQL Server está sendo executado nesse mesmo usuário.
A etapa do job que contém a chamada para sp_send_dbmail é executado no mesmo DOMÍNIO\Usuário .
Também rastreei isso ao executar a parte de consulta de sp_send_dbmail ele tenta executarexec xp_logininfo 'DOMAIN\User' para verificar no Active Directory se esse usuário está OK. E surpresa:algo definitivamente não está bem. Esta verificação termina com:
Msg 15404, Level 16, State 19, Server SQLC002INS02\SQLC002INS02, Line 1
Could not obtain information about Windows NT group/user 'DOMAIN\User.', error code 0x2.
Isso, com alguma probabilidade, pode significar que qualquer coisa sobre a senha desse usuário expirou ou o usuário está bloqueado ou qualquer outra coisa não agradável para esse cara.
Eu decidi que é arriscado mudar de usuário para agente. Então, chego a enviar e-mails em nome de 'sa', que tem a mesma função de servidor 'sysadmin', mas autorização SQL e omite essa etapa de verificação do AD.
Parece que um usuário que finge ser administrador para pedir ao administrador real para executar um código perigoso para ele :)
Portanto, o código final deste trabalho é o primeiro e o único passo semelhante a este:
execute as login = 'sa'
exec msdb.dbo.sp_send_dbmail
@profile_name = 'profile_name',
@recipients = '[email protected]',
@body = 'body',
@subject = 'subj',
--Parameters that refers to attached file
@attach_query_result_as_file = 1,
@query_result_header = 0,
@query_result_no_padding = 1,
@query = 'select 1',
@query_attachment_filename = 'test.csv'
revert
