Requêtes de prennent plus de temps pour terminer l’exécution lorsque la taille de la mémoire cache TokenAndPermUserStore grandit dans SQL Server 2005

N° de bogue : 429501 (SQLBUDT)

Symptômes

Dans Microsoft SQL Server 2005, vous pouvez rencontrer les problèmes suivants :

  • Les requêtes qui s’exécutent généralement plus rapidement prennent plus de temps pour terminer l’exécution.

  • Utilisation de l’UC pour le processus SQL Server est plus que d’habitude.

  • Lorsque vous rencontrez une baisse des performances lorsque vous exécutez une requête ad hoc, vous permet d’afficher la requête à partir de la vue de gestion dynamique association ou sys.dm_os_waiting_tasks . Toutefois, la requête ne semble pas être en attente d’une ressource.

  • La taille de la banque de cache TokenAndPermUserStore augmente à une vitesse constante.

  • La taille de la banque de cache TokenAndPermUserStore est dans l’ordre de plusieurs centaines mégaoctets (Mo).

  • Dans certains cas, l’exécution de la commande DBCC FREEPROCCACHE permet temporaire.

Pour contrôler la taille de la mémoire cache TokenAndPermUserStore, vous pouvez utiliser une requête semblable à la suivante :

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

Cause

La banque de cache TokenAndPermUserStore gère les types de jetons de sécurité suivant montre :

  • LoginToken

  • TokenPerm

  • UserToken

  • SecContextToken

  • TokenAccessResult.

Différentes classes d’entrées de TokenAccessResult sont également présents. Ce problème se produit parce que le nombre d’entrées TokenAccessResult ayant une classe de 65 535 est présent.


Sur une instance de SQL Server qui a un taux élevé d’exécution de requêtes de dynamique aléatoire, vous remarquez beaucoup d’entrées TokenAccessResult ayant une classe de 65 535 dans la vue sys.dm_os_memory_cache_entries . Les entrées TokenAccessResult ayant une classe de 65 535 représentent des entrées de cache spécial. Ces entrées du cache sont utilisées pour les vérifications d’autorisations cumulatives pour les requêtes. Par exemple, vous pouvez exécuter la requête suivante :

select * 
from t1 join t2 join t3

Dans ce cas, SQL Server calcule une vérification d’autorisation cumulé pour cette requête. Cette vérification détermine si un utilisateur a sélectionner t1, t2, t3. Ces résultats de la vérification des autorisations cumulatives sont intégrées dans une entrée TokenAccessResult et sont insérés dans la banque de cache TokenAndPermUserStore avec un ID de 65 535. Si le même utilisateur réutilise ou exécute cette requête plusieurs fois, SQL Server réutilise l’entrée de cache TokenAccessResult une seule fois.

Lorsque ce stockage en cache augmente, le temps de rechercher les entrées existantes de réutiliser augmente. L’accès à ce cache est contrôlé afin que seul un thread peut effectuer la recherche. Ce comportement finalement causes requête baisse des performances, et plus l’utilisation du processeur se produit.

Résolution

Informations sur le service pack

Pour résoudre ce problème, procurez-vous le dernier service pack pour SQL Server 2005. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :

913089 comment obtenir le dernier service pack pour SQL Server 2005
Pour résoudre ce problème, SQL Server 2005 Service Pack 2 modifie le comportement de mise en cache des jetons Permission. Par défaut, l’entrée de cache de sécurité TokenAccessResult pour les requêtes ad hoc est uniquement mis en cache lorsqu’une requête ad hoc spécifique est exécutée à nouveau.

Solution de contournement

Pour contourner ce problème, appliquez une ou plusieurs des méthodes suivantes :

  • Paramétrer explicitement les requêtes ad hoc.

    Remarques

    • Cette méthode vous permet de réutiliser efficacement des requêtes ad hoc et leurs plans.

    • Lorsque vous utilisez cette méthode, vous n’êtes pas obligé de créer une entrée TokenAccessResult chaque fois que vous exécutez la requête ad hoc avec des paramètres différents.

    • Avec cette méthode, la taille de la mémoire cache TokenAndPermUserStore reste dans des limites raisonnables.

  • Encapsuler les requêtes ad hoc dans des procédures stockées et utiliser des procédures stockées au lieu d’exécuter directement des requêtes ad hoc.


    Remarques

    • Les plans d’exécution sont mis en cache pour les instructions qui se trouvent dans la procédure stockée.

    • L’entrée TokenAccessResult pour chaque instruction est associée à l’entrée du plan d’exécution.

    • Tant que le plan d’exécution pour ce stockées procédure reste dans le cache, chaque exécution de la procédure stockée réutilise efficacement les entrées TokenAccessResult. Par conséquent, il est inutile de créer de nouvelles entrées de TokenAccessResult.

  • Activer l’option de base de données FORCE_PARAMETERIZATION.

    Remarques

    • Cette méthode vous permet de réutiliser efficacement des requêtes ad hoc et leurs plans.

    • Lorsque vous utilisez cette méthode, vous n’êtes pas obligé de créer une entrée TokenAccessResult chaque fois que vous exécutez la requête ad hoc avec des paramètres différents.

    • Avec cette méthode, la taille de la mémoire cache TokenAndPermUserStore reste dans des limites raisonnables.

  • Ajouter la connexion qui exécute diverses requêtes ad hoc en tant que membre du groupe de serveur sysadmin.

    Remarques

    • Les entrées TokenAccessResult ne sont créées que pour une requête ad hoc, lorsque la requête est exécutée par une connexion qui n’est pas un membre du groupe de serveur sysadmin.

    • Étant donné que les entrées TokenAccessResult ne sont pas créées, ce comportement conserve la taille du cache TokenAndPermUserStore à une taille gérable.

  • Vider les entrées du cache TokenAndPermUserStore.

    Remarques

    • Pour ce faire, exécutez la commande suivante :

      DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

    • Dans l’idéal, essayez de regarder le seuil de la taille du cache TokenAndPermUserStore lorsque les problèmes commencent à apparaître.

    • Vous pouvez créer une tâche planifiée de l’Agent de SQL Server qui exécute les actions suivantes :

      • Vérifiez la taille de la taille du cache TokenAndPermUserStore. Pour ce faire, exécutez la commande suivante :

        SELECT SUM(single_pages_kb + multi_pages_kb) AS 
        "CurrentSizeOfTokenCache(kb)"
        FROM sys.dm_os_memory_clerks
        WHERE name = 'TokenAndPermUserStore'
      • Si la taille du cache est plus grande que le seuil que vous avez observé, exécutez la commande suivante :

        DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

Références

Pour plus d’informations, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft :

933564 correctif : une augmentation progressive de la consommation de mémoire pour l’entrée de cache USERSTORE_TOKENPERM se produit dans SQL Server 2005

959823 comment personnaliser le quota pour la banque de cache TokenAndPermUserStore dans SQL Server 2005 Service Pack 3

Besoin d’aide ?

Développez vos compétences
Découvrez des formations
Accédez aux nouvelles fonctionnalités en avant-première
Rejoindre Microsoft Insider

Ces informations vous ont-elles été utiles ?

Dans quelle mesure êtes-vous satisfait(e) de la qualité de la traduction ?

Qu’est-ce qui a affecté votre expérience ?

Avez-vous d’autres commentaires ? (Facultatif)

Nous vous remercions pour vos commentaires.

×