错误 #: 429501 (SQLBUDT)

症状

在 Microsoft SQL Server 2005 中,您可能会遇到下列症状︰

  • 通常运行得更快的查询需要很长的时间才能完成运行。

  • SQL Server 进程的 CPU 使用率是比平常多。

  • 当您遇到性能降低运行 ad hoc 查询时,您查看从sys.dm_exec_requests或sys.dm_os_waiting_tasks动态管理视图的查询。但是,查询不会等待任何资源。

  • TokenAndPermUserStore 高速缓存存储区的大小会以稳定的速率增加。

  • TokenAndPermUserStore 高速缓存存储区的大小是按几百兆字节 (MB)。

  • 在某些情况下,执行 DBCC FREEPROCCACHE 命令提供了临时的止裂槽。

若要监视 TokenAndPermUserStore 缓存的大小,可以使用类似下面的查询︰

SELECT SUM(single_pages_kb + multi_pages_kb) AS 
"CurrentSizeOfTokenCache(kb)"
FROM sys.dm_os_memory_clerks
WHERE name = 'TokenAndPermUserStore'

原因

TokenAndPermUserStore 高速缓存存储区保持以下的安全令牌类型︰

  • LoginToken

  • TokenPerm

  • UserToken

  • SecContextToken

  • TokenAccessResult。

不同等级的 TokenAccessResult 条目也是存在的。这一特定问题出现的原因有 65535 的一个类的多个 TokenAccessResult 项都存在。


具有较高的随机动态查询执行率的 SQL Server 的实例,您注意到大量的sys.dm_os_memory_cache_entries视图中,有一类的 65535 的 TokenAccessResult 条目。有 65535 的类的 TokenAccessResult 条目表示特殊的缓存项。这些缓存条目用于查询的累积权限检查。例如,您可以运行以下查询︰

select * 
from t1 join t2 join t3

在这种情况下,SQL Server 计算此查询的累积权限检查。这一检查将确定用户是否具有在 t1、 t2、 t3 的选择。这些累积的权限检查结果嵌入到 TokenAccessResult 项,插入到具有 ID 65535 的 TokenAndPermUserStore 高速缓存存储区。如果同一个用户重复使用或多次执行此查询时,SQL Server 会重用 TokenAccessResult 缓存项一次。

当此缓存存储增长时,搜索现有条目重复使用时间增长。此缓存的访问控制,以便只有一个线程可以执行搜索。这种现象最终导致查询性能下降,并出现更多的 CPU 利用率。

解决方案

Service Pack 信息

若要解决此问题,请获取最新的 service pack,SQL Server 2005。有关详细信息,请单击下面的文章编号,以查看 Microsoft 知识库中相应的文章:

913089如何获取最新的 service pack,SQL Server 2005
若要解决此问题,SQL 服务器 2005 Service Pack 2 更改权限标记的缓存行为。默认情况下,ad hoc 查询 TokenAccessResult 安全缓存条目只缓存时再次执行特定的 ad hoc 查询。

解决方法

若要变通解决此问题,请使用一个或多个下列方法︰

  • 显式 ad hoc 查询参数化。

    备注:

    • 此方法可以有效地重复使用 ad hoc 查询和他们的计划。

    • 当您使用此方法时,您不需要创建每次运行 ad hoc 查询以及不同参数的 TokenAccessResult 条目。

    • 使用此方法,TokenAndPermUserStore 缓存的大小保持在合理限制下。

  • 在存储过程中的特殊查询并使用存储的过程而不是直接执行特殊查询。


    备注:

    • 为存储过程中的语句缓存执行计划。

    • 每个语句的 TokenAccessResult 项是与执行计划项相关联。

    • 只要这样的执行计划在缓存中存储过程保持,每次执行存储过程的有效重用的 TokenAccessResult 条目。因此,您不需要创建新的 TokenAccessResult 条目。

  • 启用 FORCE_PARAMETERIZATION 数据库选项。

    备注:

    • 此方法可以有效地重复使用 ad hoc 查询和他们的计划。

    • 当您使用此方法时,您不需要创建每次运行 ad hoc 查询以及不同参数的 TokenAccessResult 条目。

    • 使用此方法,TokenAndPermUserStore 缓存的大小保持在合理限制下。

  • 添加执行登录不同 ad hoc 查询作为系统管理员服务器组的成员。

    备注:

    • TokenAccessResult 条目仅创建 ad hoc 查询时查询执行的不是系统管理员服务器组的成员登录。

    • 因为不会创建的 TokenAccessResult 项,此行为将使 TokenAndPermUserStore 高速缓存大小为可管理的大小。

  • 刷新从 TokenAndPermUserStore 高速缓存条目。

    备注:

    • 若要执行此操作,请运行以下命令︰

      DBCC FREESYSTEMCACHE (TokenAndPermUserStore)

    • 理想情况下,尝试观看的 TokenAndPermUserStore 高速缓存大小的阈值,当问题开始出现。

    • 您可以创建计划的 SQL Server 代理作业,执行以下操作︰

      • 检查 TokenAndPermUserStore 高速缓存的大小。若要执行此操作,请运行以下命令︰

        SELECT SUM(single_pages_kb + multi_pages_kb) AS 
        "CurrentSizeOfTokenCache(kb)"
        FROM sys.dm_os_memory_clerks
        WHERE name = 'TokenAndPermUserStore'
      • 如果您观察到的阈值大于高速缓存的大小,请运行以下命令︰

        DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

参考资料

有关详细信息,请单击下面的文章编号,以查看 Microsoft 知识库中相应的文章:

933564解决︰ 在 SQL Server 2005 中发生的 USERSTORE_TOKENPERM 高速缓存存储区的内存消耗的逐渐增加

959823如何自定义 SQL 服务器 2005 Service Pack 3 中的 TokenAndPermUserStore 高速缓存存储的配额

Need more help?

Expand your skills
Explore Training
Get new features first
Join Microsoft Insiders

Was this information helpful?

How satisfied are you with the translation quality?
What affected your experience?

Thank you for your feedback!

×