Las consultas tardan más tiempo en ejecutarse cuando el tamaño de la caché TokenAndPermUserStore aumenta en SQL Server 2005

Nº de error: 429501 (SQLBUDT)
Nº de error: 429501 (SQL BU seguimiento de defectos)BUG #: 64830 (Mantenimiento de contenido)

Síntomas

En Microsoft SQL Server 2005, puede experimentar los síntomas siguientes:
  • Las consultas que suelen ejecutan con mayor rapidez tardan más tiempo en terminar de ejecutarse.
  • Utilización de la CPU para el proceso de SQL Server es más de lo habitual.
  • Cuando experimenta un rendimiento reducido cuando se ejecuta una consulta ad hoc, ver la consulta en la vista de administración dinámica sys.dm_exec_requests o sys.dm_os_waiting_tasks . Sin embargo, la consulta no parece estar esperando cualquier recurso.
  • El tamaño del almacén de caché TokenAndPermUserStore crece a un ritmo constante.
  • El tamaño del almacén de caché TokenAndPermUserStore está en el orden de varios cientos megabytes (MB).
  • En algunos casos, la ejecución del comando DBCC FREEPROCCACHE proporciona un alivio temporal.
Para supervisar el tamaño de la caché TokenAndPermUserStore, puede utilizar una consulta similar al siguiente:
SELECT SUM(single_pages_kb + multi_pages_kb) AS    "CurrentSizeOfTokenCache(kb)" 
FROM sys.dm_os_memory_clerks
WHERE name = 'TokenAndPermUserStore'

Causa

El almacén de caché TokenAndPermUserStore mantiene los tipos de token de seguridad siguiente:
  • LoginToken
  • TokenPerm
  • UserToken
  • SecContextToken
  • TokenAccessResult.
Diferentes clases de entradas de TokenAccessResult también están presentes. Este problema se produce porque muchas entradas de TokenAccessResult que tienen una clase de 65535 están presentes.


En una instancia de SQL Server que tiene una alta tasa de ejecución de consulta dinámica aleatoria, observará muchas entradas de TokenAccessResult que tienen una clase de 65535 en la vista sys.dm_os_memory_cache_entries . Las entradas de TokenAccessResult que tienen una clase de 65535 representan entradas de caché especial. Estas entradas de caché se utilizan para comprobaciones de permiso acumulado para las consultas. Por ejemplo, puede ejecutar la siguiente consulta:
select * from t1 join t2 join t3
En este caso, SQL Server calcula una comprobación de permiso acumulado para esta consulta. Esta comprobación determina si un usuario tiene select en t1, t2, t3. Estos resultados de la comprobación de permiso acumulado se incrustan en una entrada de TokenAccessResult y se insertan en el almacén de caché TokenAndPermUserStore con un identificador de 65535. Si el mismo usuario vuelve a utilizar o ejecuta esta consulta varias veces, SQL Server reutiliza la entrada de caché TokenAccessResult una vez.

Cuando este almacén de caché crece, aumenta el tiempo para buscar entradas existentes para volver a utilizar. Acceso a esta caché se controla para que sólo un subproceso puede realizar la búsqueda. Este comportamiento eventualmente causas rendimiento de las consultas para reducir y más uso de la CPU se produce.

Solución

Información del Service pack

Para resolver este problema, obtenga el service pack más reciente para SQL Server 2005. Para obtener más información, haga clic en el siguiente número de artículo para verlo en Microsoft Knowledge Base:
913089 cómo obtener el service pack más reciente para SQL Server 2005
Para resolver este problema, SQL Server 2005 Service Pack 2 cambia el comportamiento de almacenamiento en caché de los símbolos (tokens) de permisos. De forma predeterminada, sólo se almacena la entrada de caché de seguridad TokenAccessResult para consultas ad hoc cuando se vuelve a ejecutar una consulta ad hoc específica.

Solución alternativa

Para evitar este problema, utilice uno o varios de los métodos siguientes:
  • Explícitamente parametrizar consultas ad hoc.

    Notas:
    • Este método permite reutilizar eficazmente las consultas ad hoc y sus planes.
    • Cuando se utiliza este método, no es necesario crear una entrada de TokenAccessResult cada vez que ejecuta la consulta ad hoc junto con distintos parámetros.
    • Con este método, el tamaño de la caché TokenAndPermUserStore permanece por debajo de los límites razonables.
  • Ajustar consultas ad hoc en procedimientos almacenados y utilizar procedimientos almacenados en lugar de ejecutar directamente consultas ad hoc.


    Notas:
    • Se almacenan en caché los planes de ejecución de las instrucciones que se encuentran en el procedimiento almacenado.
    • La entrada TokenAccessResult para cada instrucción está asociada con la entrada de plan de ejecución.
    • Mientras el plan de ejecución para este almacenado procedimiento permanece en la caché, cada ejecución del procedimiento almacenado eficazmente reutiliza las entradas de TokenAccessResult. Por lo tanto, no es necesario que crear nuevas entradas de TokenAccessResult.
  • Habilitar la opción de base de datos FORCE_PARAMETERIZATION.

    Notas:
    • Este método permite reutilizar eficazmente las consultas ad hoc y sus planes.
    • Cuando se utiliza este método, no es necesario crear una entrada de TokenAccessResult cada vez que ejecuta la consulta ad hoc junto con distintos parámetros.
    • Con este método, el tamaño de la caché TokenAndPermUserStore permanece por debajo de los límites razonables.
  • Agregar el inicio de sesión que ejecuta variados consultas ad hoc como un miembro del grupo de servidor sysadmin.

    Notas:
    • Entradas de TokenAccessResult sólo se crean para una consulta ad hoc cuando la consulta se ejecuta mediante un inicio de sesión no es miembro del grupo de servidor sysadmin.
    • Ya no se crean las entradas de TokenAccessResult, este comportamiento impide que el tamaño de la caché TokenAndPermUserStore a un tamaño manejable.
  • Vacíe las entradas de la caché TokenAndPermUserStore.

    Notas:
    • Para ello, ejecute el siguiente comando:
      DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')
    • Idealmente, intente ver el umbral del tamaño de caché TokenAndPermUserStore cuando empiezan a aparecer problemas.
    • Puede crear un trabajo programado del agente de SQL Server que realiza las siguientes acciones:
      • Compruebe el tamaño de la caché TokenAndPermUserStore. Para ello, ejecute el siguiente comando:
        SELECT SUM(single_pages_kb + multi_pages_kb) AS    "CurrentSizeOfTokenCache(kb)" 
        FROM sys.dm_os_memory_clerks
        WHERE name = 'TokenAndPermUserStore'
      • Si el tamaño de caché es mayor que el umbral que ha observado, ejecute el siguiente comando:
        DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

Referencias

Para obtener más información, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:

CORREGIR 933564 : se produce un aumento gradual en el consumo de memoria para la caché de USERSTORE_TOKENPERM en SQL Server 2005

959823 cómo personalizar la cuota para el almacén de caché TokenAndPermUserStore en SQL Server 2005 Service Pack 3

Propiedades

Id. de artículo: 927396 - Última revisión: 14 ene. 2017 - Revisión: 1

Comentarios