在只读Always On可用性组副本上使用sp_setapprole时遇快照隔离错误

咱先理清楚你遇到的问题核心：你在Always On的只读副本数据库里执行应用角色的切换操作（sp_setapprole和sp_unsetapprole）时碰了壁，而且错误信息让你摸不着头脑。先看你贴的代码，最后sp_unsetapprole里的变量写成了@coo...，这大概率是输入时的笔误，但这不是核心问题——真正的拦路虎是只读副本的特性限制。

为什么只读副本上用不了应用角色？ #

Always On的只读副本是严格只读模式，而sp_setapprole这个操作本质上会触发隐式事务，还需要对系统表做写入操作（比如记录会话的角色切换状态）。但只读副本完全不允许任何写入操作，哪怕是系统级的变更，这就直接导致操作失败了。

你大概率会遇到的错误（及解读） #

常见的错误信息类似这样：

Msg 3906, Level 16, State 1, Procedure sp_setapprole, Line 62
Failed to update database "YourDB" because the database is read-only.

或者是和事务相关的报错，本质都是只读副本的只读属性直接阻止了应用角色切换所需的系统操作。

可行的解决方案 #

针对这个场景，给你几个实用的处理思路：

1. 换主副本执行角色切换（但有局限性） #

应用角色的切换必须在主副本或者配置为可读可写的副本上完成。如果你的应用需要访问只读副本的数据，流程得这么调整：

• 先让应用连接主副本，执行sp_setapprole获取cookie
• 但注意：cookie是和当前会话绑定的，跨副本的会话不共享，所以你没法拿着主副本的cookie去只读副本用。这就意味着这个方案只能是应用先在主副本完成角色切换，再切换连接到只读副本——但这样的流程对应用来说不太友好，所以更推荐第二个方案。

2. 用权限匹配的数据库用户替代应用角色 #

既然只读副本上跑不了应用角色，咱就换个思路：直接创建一个和TestRole权限完全一致的数据库用户，让应用用这个用户直接连接只读副本。步骤很简单：

• 在主副本上创建用户（比如TestAppUser）
• 把TestRole的所有权限都授予这个用户
• 因为Always On会自动同步主副本的用户和权限到只读副本，所以不需要额外操作
• 应用直接用TestAppUser连接只读副本，跳过sp_setapprole的操作，直接就能访问对应权限的数据

3. 先修正代码里的小笔误（如果是实际问题的话） #

你贴的sp_unsetapprole代码里变量名写成了@coo...，实际应该是@cookie，如果这是你真实代码里的错误，也会导致语法报错，但这只是小问题，核心还是只读副本的限制。

总结 #

Always On只读副本的只读特性直接锁死了sp_setapprole这类需要写入系统表的操作，所以最稳妥的办法就是用权限匹配的数据库用户替代应用角色来访问只读副本。如果必须用应用角色，那只能调整应用流程，在主副本完成角色切换后再处理数据，但这种方式的局限性比较大。

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