Las consultas tardan más en terminar la ejecución cuando el tamaño de la caché TokenAndPermUserStore aumenta en SQL Server 2005

Seleccione idioma Seleccione idioma
Id. de artículo: 927396 - Ver los productos a los que se aplica este artículo
Nº de error: 429501 (SQLBUDT)
Expandir todo | Contraer todo

En esta página

Síntomas

En Microsoft SQL Server 2005, puede experimentar los síntomas siguientes:
  • Consultas que normalmente se ejecutan más rápido tardan más tiempo para finalizar la ejecución.
  • Utilización de CPU para el proceso de SQL Server es más habitual.
  • Cuando experimenta una reducción del rendimiento al ejecutar una consulta ad hoc, ver la consulta desde 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 a cualquier recurso.
  • El tamaño del almacén de caché TokenAndPermUserStore crece a un ritmo.
  • El tamaño del almacén de caché TokenAndPermUserStore es en el orden de varios cientos megabytes (MB).
  • En algunos casos, la ejecución del comando DBCC FREEPROCCACHE proporciona 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 específico se produce porque muchas entradas TokenAccessResult que tienen una clase de 65535 están presentes.

En una instancia de SQL Server que tiene una tasa alta de ejecución de consultas dinámicas aleatorio, observa mucha entradas 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, se 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 comprobación de permiso acumulado están incrustados en una entrada 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 se aumenta este almacén de caché, aumenta el tiempo para buscar las entradas existentes para volver a utilizar. El acceso a esta caché se controla para que sólo un subproceso puede realizar la búsqueda. Este comportamiento finalmente causas consulta rendimiento disminuya y se produce más la CPU.

Solución

Información de 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 número de artículo siguiente para verlo en Microsoft Knowledge Base:
913089Có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 almacenamiento en caché de los símbolos de permisos. De forma predeterminada, la entrada de caché de seguridad TokenAccessResult para consultas ad hoc se almacena en sólo caché cuando se vuelve a ejecuta una consulta ad hoc específica.

Solución

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 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 TokenAndPermUserStore caché permanece en unos 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 para las instrucciones que están 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 crear TokenAccessResult nueva entradas.
  • 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 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 TokenAndPermUserStore caché permanece en unos límites razonables.
  • Agregar el inicio de sesión que se ejecuta variados consultas ad hoc como un miembro del grupo de servidor sysadmin.

    notas
    • TokenAccessResult entradas se crean sólo para una consulta ad hoc cuando se ejecuta la consulta un inicio de sesión no es un miembro del grupo de servidor sysadmin.
    • Dado que no se crean las entradas de TokenAccessResult, este comportamiento mantiene el tamaño de la caché TokenAndPermUserStore a un tamaño manejable.
  • Entradas de la caché TokenAndPermUserStore de vaciado.

    notas
    • Para ello, ejecute el comando siguiente:
      DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')
    • Idealmente, intente inspeccionar el umbral del tamaño de caché TokenAndPermUserStore cuando empiezan a aparecer problemas.
    • Puede crear un trabajo programado de SQL Server Agent realiza las acciones siguientes:
      • Compruebe el tamaño del tamaño de 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 observado, ejecute el comando siguiente:
        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:
933564REVISIÓN: Se produce un aumento gradual en el consumo de memoria para el almacenamiento en caché de USERSTORE_TOKENPERM en SQL Server 2005
959823Có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: martes, 28 de julio de 2009 - Versión: 4.0
La información de este artículo se refiere a:
  • 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
Palabras clave: 
kbmt kbtshoot kbinfo kbsql2005tsql kbprb KB927396 KbMtes
Traducción automática
IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.
Haga clic aquí para ver el artículo original (en inglés): 927396

Enviar comentarios

 

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