SQL Server服务与代理账户权限变更后是否需重启服务生效

你遇到的访问报错本质是Windows访问令牌机制导致的：Windows服务启动时会加载当前账户的所有权限、组身份生成静态访问令牌，服务运行过程中给账户新增的权限，不会自动同步到已经启动的进程里。你只重启了SQL Server Agent，仅更新了Agent进程的令牌，SQL Server引擎进程还在使用权限删除后、重新添加前的旧令牌，所以所有走SQL Server引擎执行的共享访问都会报拒绝访问，等维护窗口重启SQL Server服务即可完全恢复。

1. 为何SQL Server Agent作业会与SQL Server服务的运行账户存在关联？ #

SQL Server Agent本质只是个作业调度框架，本身不具备T-SQL执行能力：

• 所有T-SQL类型的作业步骤，Agent只会把SQL文本转发给SQL Server数据库引擎执行，自身不处理任何数据逻辑
• 你调用的xp_cmdshell是SQL Server引擎自带的扩展存储过程，整个执行逻辑都运行在SQL Server服务的进程空间内，哪怕调用入口是Agent作业，实际执行主体还是SQL Server引擎，权限自然受SQL Server服务账户的约束。

2. SQL Server Agent服务账户与SQL Server服务账户之间的关系是什么？ #

两者是完全独立的Windows系统服务，没有强制绑定为同一账户的要求，你当前环境使用相同的domain\sqlservice是手动配置的结果，不是产品默认规则。两者的交互逻辑如下：

• SQL Server Agent需要连接本地SQL Server实例存储作业配置、写入执行日志、提交执行任务，因此Agent服务账户默认需要被授予SQL Server实例的sysadmin角色权限
• 两类服务的权限边界完全独立，各自进程的访问令牌互不影响，各自负责自身承载执行逻辑的权限校验。

3. SQL Server Agent作业访问作业中定义的文件共享时，是否仍然使用该服务账户？ #

没有统一答案，完全取决于作业步骤的类型：

• 如果是T-SQL步骤中通过引擎能力访问共享：包括调用xp_cmdshell、BULK INSERT、OPENROWSET、服务器端执行SSIS包等场景，使用的是SQL Server服务账户的权限上下文
• 如果是CmdExec、PowerShell、复制分发等操作系统层面的作业步骤：默认使用SQL Server Agent服务账户的权限上下文，如果步骤单独配置了代理账户，则使用代理账户的权限。

如果想在重启SQL Server服务前确认判断，可以在现有作业里新增一个独立的CmdExec类型步骤，内容写dir \\fileserver\Path1直接执行。这个步骤走Agent进程上下文，你已经重启过Agent服务，该步骤应该能正常返回路径下的文件列表，即可证明问题确实出在SQL Server引擎进程的令牌未更新。

内容的提问来源于stack exchange，提问作者alwaysLearning