私はその問題の回避策に来ました。なぜそれが機能するのかわかりませんが、それ以下になることはありません。 :)それは間違いなくセキュリティについてです。
DOMAIN \ Userなどのドメインユーザーに代わってSQLエージェントが実行されていることを調査しました 。サーバーに対する管理者権限の完全なセット（「sysadmin」サーバーの役割など）があります。 SQLServer自体は同じユーザーの下で実行されています。
sp_send_dbmailへの呼び出しを含むジョブのステップ 同じDOMAIN\ Userの下で実行されます 。
また、 sp_send_dbmailのクエリ部分を実行するときにそれをトレースしました exec xp_logininfo'DOMAIN \ User'を実行しようとします そのユーザーに問題がないかどうかをActiveDirectoryと照合します。そして驚き：何かが間違いなくOKではありません。このチェックは次のようになります：
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.
つまり、ある程度の確率で、そのユーザーのパスワードの有効期限が切れているか、ユーザーがロックされているか、またはその人にとって他の不快なことを意味する可能性があります。
エージェントのユーザーを変更するのは危険だと判断しました。そのため、「sysadmin」サーバーの役割は同じですがSQL認証を持ち、このADチェック手順を省略した「sa」に代わってメールを送信することになりました。
管理者のふりをして、実際の管理者に危険なコードを実行するように依頼する1人のユーザーのようです:)
したがって、このジョブの最後のコードは最初で唯一のステップは次のようになります。
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