Doszedłem do obejścia tego problemu. Nie wiem, dlaczego miałoby to działać, ale nie mniej. :) Zdecydowanie chodzi o bezpieczeństwo.
Zbadałem, czy agent SQL działa w imieniu użytkownika domeny, powiedzmy DOMAIN\User .Posiada pełny zestaw uprawnień administratora na serwerze (rola serwera 'sysadmin', itp.). Sam SQL Server działa pod tym samym użytkownikiem.
Krok zadania zawierający wywołanie sp_send_dbmail działa w ramach tej samej DOMENY\Użytkownika .
Prześledziłem również to podczas uruchamiania części zapytania sp_send_dbmail próbuje wykonaćexec xp_logininfo 'DOMAIN\User' aby sprawdzić w Active Directory, czy ten użytkownik jest w porządku. I niespodzianka:zdecydowanie coś jest nie w porządku. Ta kontrola kończy się na:
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.
To z pewnym prawdopodobieństwem może oznaczać, że wszystko, co dotyczy hasła tego użytkownika, wygasło lub użytkownik jest zablokowany, lub inne nieprzyjemne rzeczy dla tego gościa.
Uznałem, że zmiana użytkownika na Agenta jest ryzykowna. Podchodzę więc do wysyłania poczty w imieniu „sa”, która ma tę samą rolę serwera „sysadmin”, ale autoryzację SQL i pomija ten krok sprawdzania AD.
Wygląda na to, że jeden użytkownik udający administratora poprosił prawdziwego administratora o uruchomienie niebezpiecznego kodu :)
Tak więc końcowy kod tego zadania jest pierwszym i jedynym krokiem podobnym do tego:
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