Запросы занять больше времени для завершения работы при расширении размер кэша TokenAndPermUserStore в SQL Server 2005

Переводы статьи Переводы статьи
Код статьи: 927396 - Vizualiza?i produsele pentru care se aplic? acest articol.
Ошибка #: 429501 (SQLBUDT)
Развернуть все | Свернуть все

В этой статье

Проблема

В Microsoft SQL Server 2005 могут возникнуть следующие проблемы:
  • Запросы, которые обычно выполняются быстрее занять больше времени для завершения работы.
  • Загрузка центрального Процессора для процесса SQL Server — это больше, чем обычно.
  • Когда вы снижение производительности при выполнении нерегламентированных запросов, просмотре запроса изsys.dm_exec_requests-или-sys.dm_os_waiting_tasksдинамическое административное представление. Тем не менее запрос не ожидается какой-либо ресурс.
  • Размер хранилища кэша TokenAndPermUserStore растет с постоянной скоростью.
  • Размер хранилища кэша TokenAndPermUserStore — в порядке следования несколько сотен мегабайт (МБ).
  • В некоторых случаях выполнение команды DBCC FREEPROCCACHE предоставляет временное рельефа.
Для наблюдения за размером кэша TokenAndPermUserStore, можно использовать запрос, подобное приведенному ниже:
SELECT SUM(single_pages_kb + multi_pages_kb) AS 
   "CurrentSizeOfTokenCache(kb)" 
   FROM sys.dm_os_memory_clerks 
   WHERE name = 'TokenAndPermUserStore'

Причина

Хранилища кэша TokenAndPermUserStore поддерживает типы маркеров безопасности folllowing:
  • LoginToken
  • TokenPerm
  • UserToken
  • SecContextToken
  • TokenAccessResult.
Также имеются различные классы TokenAccessResult операции. Данная проблема возникает, если имеются несколько TokenAccessResult операции, которые имеют класс 65535.

On an instance of SQL Server that has a high rate of random dynamic query execution, you notice lots of TokenAccessResult entries that have a class of 65535 in thesys.dm_os_memory_cache_entriesПредставление:. TokenAccessResult entries that have a class of 65535 represent special cache entries. These cache entries are used for cumulative permission checks for queries. For example, you may run the following query:
select * 
from t1 join t2 join t3
In this case, SQL Server computes a cumulative permission check for this query. This check determines whether a user has select on t1, t2, t3. These cumulative permission check results are embedded into a TokenAccessResult entry and are inserted into the TokenAndPermUserStore cache store with an ID of 65535. If the same user reuses or executes this query multiple times, SQL Server reuses the TokenAccessResult cache entry one time.

When this cache store grows, the time to search for existing entries to reuse increases. Access to this cache is controlled so that only one thread can perform the search. This behavior eventually causes query performance to decrease, and more CPU utilization occurs.

Решение

Сведения о пакете обновления

To resolve this problem, obtain the latest service pack for SQL Server 2005. Для получения дополнительных сведений обратитесь к следующей статье Базы Знаний Майкрософт::
913089How to obtain the latest service pack for SQL Server 2005
To resolve this problem, SQL Server 2005 Service Pack 2 changes the caching behavior of the Permission tokens. By default, the TokenAccessResult security cache entry for ad hoc queries is only cached when a specific ad hoc query is executed again.

Временное решение

To work around this problem, use one or more of the following methods:
  • Explicitly parameterize ad hoc queries.

    Примечания
    • This method lets you effectively reuse ad hoc queries and their plans.
    • When you use this method, you do not have to create a TokenAccessResult entry every time that you run the ad hoc query together with different parameters.
    • With this method, the size of the TokenAndPermUserStore cache remains under reasonable limits.
  • Wrap ad hoc queries within stored procedures, and use stored procedures instead of directly executing ad hoc queries.

    Примечания
    • Execution plans are cached for the statements that are in the stored procedure.
    • The TokenAccessResult entry for each statement is associated with the execution plan entry.
    • As long as the execution plan for this stored procedure remains in the cache, every execution of the stored procedure effectively reuses the TokenAccessResult entries. Therefore, you do not have to create new TokenAccessResult entries.
  • Enable the FORCE_PARAMETERIZATION database option.

    Примечания
    • This method lets you effectively reuse ad hoc queries and their plans.
    • When you use this method, you do not have to create a TokenAccessResult entry every time that you run the ad hoc query together with different parameters.
    • With this method, the size of the TokenAndPermUserStore cache remains under reasonable limits.
  • Add the login that executes varied ad hoc queries as a member of the sysadmin server group.

    Примечания
    • TokenAccessResult entries are only created for an ad hoc query when the query is executed by a login that is not a member of the sysadmin server group.
    • Because the TokenAccessResult entries are not created, this behavior keeps the TokenAndPermUserStore cache size to a manageable size.
  • Flush entries from the TokenAndPermUserStore cache.

    Примечания
    • Для этого выполните следующую команду:
      DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')
    • Ideally, try to watch the threshold of the TokenAndPermUserStore cache size when problems start to appear.
    • You can create a scheduled SQL Server Agent job that performs the following actions:
      • Check the size of the TokenAndPermUserStore cache size. Для этого выполните следующую команду:
        SELECT SUM(single_pages_kb + multi_pages_kb) AS 
           "CurrentSizeOfTokenCache(kb)" 
           FROM sys.dm_os_memory_clerks 
           WHERE name = 'TokenAndPermUserStore'
      • If the cache size is bigger than the threshold that you observed, run the following command:
        DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

Ссылки

Дополнительные сведения см. в следующих статьях базы знаний Майкрософт::
933564Исправление: Постепенное увеличение потребления памяти для хранения кэша USERSTORE_TOKENPERM происходит в SQL Server 2005
959823Настройка квот для хранилища кэша TokenAndPermUserStore в SQL Server 2005 с пакетом обновления 3

Свойства

Код статьи: 927396 - Последний отзыв: 27 ноября 2010 г. - Revision: 2.0
Информация в данной статье относится к следующим продуктам.
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Enterprise Edition for Itanium Based Systems
  • Microsoft SQL Server 2005 Enterprise X64 Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Standard X64 Edition
Ключевые слова: 
kbtshoot kbinfo kbsql2005tsql kbprb kbmt KB927396 KbMtru
Переведено с помощью машинного перевода
ВНИМАНИЕ! Перевод данной статьи был выполнен не человеком, а с помощью программы машинного перевода, разработанной корпорацией Майкрософт. Корпорация Майкрософт предлагает вам статьи, переведенные как людьми, так и средствами машинного перевода, чтобы у вас была возможность ознакомиться со статьями базы знаний KB на родном языке. Однако машинный перевод не всегда идеален. Он может содержать смысловые, синтаксические и грамматические ошибки, подобно тому как иностранец делает ошибки, пытаясь говорить на вашем языке. Корпорация Майкрософт не несет ответственности за неточности, ошибки и возможный ущерб, причиненный в результате неправильного перевода или его использования. Корпорация Майкрософт также часто обновляет средства машинного перевода.
Эта статья на английском языке:927396

Отправить отзыв

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com