我们有许多弹性代理服务器，其作业针对弹性池。对于已存在一段时间的所有数据库，作业仍能成功完成，但对于设置并添加到池中的新数据库，我们会收到以下身份验证错误。
适用于现有数据库的 Azure 弹性代理作业对于新创建的数据库来说会失败
服务器主体“ac1971e9-381b-449b-9e1a-9cc276fc2985@b5313c9d-fb0d-47af-bc87-7c050bffbdc3”无法访问数据库。
作业配置为使用从实例级登录映射的数据库级用户帐户连接到数据库。我已经检查了与受影响的数据库关联的用户的分配权限，它们都配置正确（与作业成功完成的其他数据库完全一致）。这可能是 Azure 的后端问题（由于某种原因）仅影响添加到弹性作业目标组的新创建的数据库吗？
我还应该提到，我已经测试了使用弹性作业用户（从登录映射）登录到作业失败的数据库（使用 SQL 身份验证）并且可以成功完成此操作，因此这似乎更像是代理的问题服务器登录目标数据库。
我已检查逻辑实例级别登录名和映射的目标数据库用户的 SID 是否相同。
我已经检查了用户的数据库级别权限。它有足够的权限（db_owner）。
我尝试重新映射登录名和用户。
作业的目标组是弹性池，因此新数据库（作业失败的数据库）已被添加为目标组成员，因为将其添加到与目标组关联的弹性池（不是单独添加）。这就是我们将所有新数据库纳入弹性作业目标范围的方式。
我现在解决了这个问题。用户分配的托管标识与弹性作业代理相关联，尽管尚未设置任何作业来使用它（目标服务器/数据库的所有作业仍使用从登录映射的数据库用户）。将用户分配的托管标识关联到弹性代理服务器之前存在的所有数据库不受影响，但在此之后创建的数据库作业将失败，并显示“服务器主体”ac1971e9-381b-449b-9e1a-9cc276fc2985@b5313c9d- fb0d-47af-bc87-7c050bffbdc3”无法访问数据库”。取消用户分配的托管标识与弹性代理服务器的关联解决了该问题。