我们的一个用户的名称已合法更改，因此我们更改了他们的 Active Directory 用户名以匹配 - 从域\旧名称到域\新名称。但是，当此用户在存储过程中调用 suser_sname() 时，它返回旧名称，而不是新名称。
谷歌搜索让我找到了KB 946358，这表明他们的名字被缓存在服务器上并且没有更新，大概是因为 suser_name() 正在调用 LsaLookupSids。但是，该文章中的解决方法涉及重新启动服务器，即使是这样，我仍然想了解问题所在。
如果我将上下文更改为他们的上下文，则会返回正确的名称：
EXECUTE AS LOGIN = 'domain\newname'
GO
SELECT suser_name() --returns 'domain\newname'
...我会假设这也会调用 LsaLookupSids，因此会返回不正确的名称。我似乎不太了解这里的工作机制。
一些可能重要的观察结果：
此用户在服务器上没有显式登录。但他们是这样做的 AD 组的成员。更改后的名称 (domain\newname) 出现在结果集中exec xp_logininfo 'domain\ADGroupName', 'members'；域\旧名称没有。
用户从存储过程中调用 suser_name()，从 Access 2003 MDB 中的直通查询调用。
过去我们更改了大量用户的帐户名称，但仅在上周才发现此问题（上周进行了两次更改，似乎都出现了此问题）。
服务器在 Windows 2008 R2 数据中心版上运行 Sql Server 2008 SP3 x64。
这是怎么回事？作为 DBA，我可以做什么或者我可以在哪里解决这个问题？
大约每周一次，我必须解决 SQL Server 2005 数据库上的阻塞链，这是由 Access 2003 前端的长期读取锁引起的。每当用户打开某个表单时就会解除锁定，并在用户完成滚动表单或关闭表单后解除锁定。由于我们的许多用户打开此表单作为参考，因此这些锁会保留一段时间。对该表的任何更新都会导致阻塞，突然间没有人可以从该表中进行选择，因为他们都在等待第一个锁。这对我们来说是一个很大的问题，因为许多应用程序都依赖于这些数据。我知道这种锁定行为是 Access 如何处理链接表的一部分。
我一直在通过 Activity Monitor 解决这个问题，只要我发现它，就会杀死任何一个是 Head Blocker 的 SELECT 进程。这是一个问题，不仅因为我手动完成它需要时间，还因为它是被动的。当我听说它时，它已经成为很多人的问题。
我想知道是否有一种自动方法来检查这些持久的阻塞链，并通过电子邮件发送或自动解决问题。逻辑看起来很简单（“如果任何与此 SELECT 查询匹配的进程阻塞了超过一分钟，请通知我/杀死它”）但我不知道如何使用 SQL Server 实现这一点。
对于它的价值，我认为正确的解决方案是修复或重写应用程序。然而，由于部门政治，这不是未来几个月的选择，所以我正在寻找一个权宜之计。
我有一个很小但很重要的 MS SQL Server 2000 数据库，我想将它复制到开发盒中。我知道通常的方法是制作完整备份文件的副本，然后将该备份恢复到开发盒上。
这里的扭曲是我最近继承了这个数据库，它的备份由第三方工具 (Groundworks) 管理。据我所知，我无权访问备份文件本身，只能访问似乎没有公开它们的 Groundworks 界面。数据库具有完整、差异和事务日志备份，因此我不能仅从 Management Studio 自己进行备份，因为我知道在下一次完整计划备份之前我会使备份链无效。
如果这是 SQL Server 2005，我会使用仅复制备份来解决这个问题，但 SQL Server 2000 中似乎没有该功能。
有没有我缺少的方法？Groundworks 手册似乎没有涵盖这种情况，而且我在网上也没有运气，但我对 DBA 工作还很陌生，并且感觉我忽略了一些东西。
将 MS SQL Server 实例升级到更高的服务包时，是否有任何特定的陷阱/标准注意事项？除了确保有系统和用户数据库的当前备份之外，还有什么特别的吗？
我是在问这个问题，因为我认为无论版本或情况如何，答案都是相似的。但是，如果我弄错了并且细节确实很重要，那么提示我问题的情况是将 SQL Server 2008 从 SP2 升级到 SP3，在带有故障转移群集的 Windows Server 2008 上运行。