Comment puis-je déterminer de manière fiable si une instance SQL Server donnée dispose du droit «Verrouiller les pages en mémoire»?

Le droit "Verrouiller les pages en mémoire" peut être accordé au compte de service utilisé par SQL Server. Cela permet à SQL Server d'empêcher la mémoire d'être paginée sur le disque.

J'ai remarqué que plusieurs de nos machines SQL Server n'ont pas la stratégie locale configurée pour autoriser ce droit pour le compte de service utilisé par SQL Server. Étant donné que nous avons un grand nombre de serveurs, il sera au mieux fastidieux de vérifier chacun d'eux manuellement à l'aide de la console de gestion "Local System Policy".

Existe-t-il une requête T-SQL, une procédure stockée étendue ou une autre méthode que je peux utiliser pour déterminer si le serveur en question a le droit ou non?

Je ne voudrais pas l' utiliser EXEC xp_readerrorlog 0, 1, 'lock memory privilege was not granted';car il repose sur la vérification du journal des erreurs SQL Server actuel; et ce journal d'erreurs peut ne pas contenir l'entrée appropriée en supposant que le journal a été remplacé depuis le dernier redémarrage du serveur. Je me rends compte que je pouvais vérifier les journaux plus anciens en modifiant le premier paramètre de 0à 1, etc., mais nous ne conservons que 10 journaux d'erreurs, et cela peut ne pas être suffisant. Je veux un moyen sûr de confirmer le paramètre.

Si xp_cmdshellest une option, voici un script utilisant whoami:

DECLARE @LockPagesInMemory VARCHAR(255);
SET @LockPagesInMemory = 'UNKNOWN';
DECLARE @Res TABLE
(
    [output] NVARCHAR(255) NULL
);

IF (SELECT value_in_use
    FROM sys.configurations c
    WHERE c.name = 'xp_cmdshell'
    ) = 1
BEGIN
    INSERT INTO @Res
    EXEC xp_cmdshell 'WHOAMI /PRIV';

    IF EXISTS (SELECT *
        FROM @Res 
        WHERE [output] LIKE 'SeLockMemoryPrivilege%'
        )
        SET @LockPagesInMemory = 'ENABLED';
    ELSE
        SET @LockPagesInMemory = 'DISABLED';
END

SELECT LockPagesInMemoryEnabled = @LockPagesInMemory;

whoami.exea la possibilité de signaler tous les droits détenus par le responsable du compte whoami. Ceci, combiné avec le, xp_cmdshellfournit un moyen fiable de déterminer si l'instance de SQL Server a le droit nécessaire pour verrouiller les pages en mémoire.

Si xp_cmdshelln'est pas activé, ce code revient UNKNOWN. En supposant qu'il xp_cmdshell est activé et que la droite est activée pour le compte SQL Server, il revient ENABLED, sinon il revient DISABLED.

Il existe également d'autres méthodes. Vous pouvez peut-être utiliser deux DMV. Veuillez noter que les deux ne fonctionneront que pour SQL Server 2008 et versions ultérieures.

Une valeur non nulle pour locked_page_allocations_kbvous indiquerait que le compte SQL Server possède des privilèges de pages verrouillées en mémoire.

select osn.node_id, 
osn.memory_node_id, 
osn.node_state_desc, 
omn.locked_page_allocations_kb
from sys.dm_os_memory_nodes omn
inner join sys.dm_os_nodes osn on (omn.memory_node_id = osn.memory_node_id)
where osn.node_state_desc <> 'ONLINE DAC'

...et:

select
(physical_memory_in_use_kb/1024)Memory_usedby_Sqlserver_MB,
(locked_page_allocations_kb/1024 )Locked_pages_used_Sqlserver_MB,
(total_virtual_address_space_kb/1024 )Total_VAS_in_MB,
process_physical_memory_low,
process_virtual_memory_low
from sys.dm_os_process_memory

Si la colonne Locked_pages_allocation_KBaffiche une valeur non nulle, le compte de service SQL Server dispose également du privilège Pages verrouillées en mémoire.

...et:

La section «Gestionnaire de mémoire» de la DBCC MEMORYSTATUSsortie affichera une valeur différente de zéro pour «AWE alloué» ou si le compte de service SQL Server dispose de privilèges de pages verrouillées en mémoire.

REMARQUE:

Si le compte de service SQL Server s'exécute avec le compte Système local (NT Authority \ System), par défaut, SQL Server aura le privilège Pages verrouillées en mémoire.

Mise à jour:

Avant SQL Server 2012 pour Standard Edition, nous devons activer l'indicateur de trace t -845 pour tirer parti de LPIM. Même si vous exécutez SQL Server avec un compte disposant de privilèges LPIM, SQL Server n'utilisera pas réellement l'avantage LPIM à moins que l'indicateur de trace ne soit activé.

À partir de 2012, nous n'avons plus besoin d'activer l'indicateur de trace dans l'édition standard pour profiter du LPIM.

Microsoft facilite cela dans les versions plus récentes du produit si ce que vous voulez vraiment savoir, c'est si SQL Server s'exécute avec un modèle de mémoire qui tire parti de LPIM (au lieu d'avoir la bonne autorisation). Ces informations se trouvent dans sys.dm_os_sys_info selon votre version de SQL Server. Cette amélioration a été annoncée dans un article de blog :

Avec SQL Server 2016 SP1 et SQL Server 2012 SP4, il y a deux nouvelles colonnes, sql_memory_model et sql_memory_model_desc ajoutées à sys.dm_os_sys_info, qui peuvent être utilisées pour identifier si des autorisations de verrouillage des pages en mémoire (LPIM) sont attribuées au compte de service SQL Server.

Une chose importante à savoir est que les nouvelles colonnes indiquent le modèle de mémoire sql utilisé depuis le démarrage de l'instance SQL Server, qui est l'information souhaitée. Aucune vérification n'est effectuée au niveau du système d'exploitation pour les autorisations LPIM pour le compte de service SQL. Si, au démarrage de SQL Server, le privilège LPIM est présent dans le jeton de processus de compte de service SQL Server, SQL Server utilise des pages verrouillées (non paginables) pour allouer la mémoire SQL. En outre, si vous exécutez l'édition Enterprise de SQL Server avec des privilèges LPIM attribués au compte de service SQL et que l'indicateur de trace 834 est activé, SQL Server utilise de grandes pages pour allouer la mémoire SQL.

Pour vérifier si le privilège de verrouillage des pages en mémoire est en vigueur pour une instance SQL Server donnée, vous pouvez interroger sql_memory_model dans sys.dm_os_sys_info et rechercher des valeurs supérieures à 1.

Si les autorisations LPIM sont manquantes dans le jeton de processus de compte de service, le modèle de mémoire conventionnel est utilisé et le même est signalé par DMV (sql_memory_model = 1). Si maintenant, le privilège de verrouillage des pages en mémoire est attribué au serveur SQL mais que le service SQL n'est pas redémarré, DMV continuera de signaler le modèle de mémoire conventionnel car il s'agit du modèle de mémoire en vigueur depuis le démarrage. Après le redémarrage, SQL Server utilise des pages verrouillées dans le modèle de mémoire et la même chose est signalée par sql_memory_model et sql_memory_model_desc dans sys.dm_os_sys_info.

Si j'exécute la requête suivante sur l'un de mes serveurs:

SELECT sql_memory_model, sql_memory_model_desc
FROM sys.dm_os_sys_info;

Le modèle de mémoire actuellement utilisé est CONVENTIONAL, ce qui signifie que LPIM n'a pas été accordé au moment du démarrage du serveur. Cependant, il serait possible d'accorder LPIM mais pas de redémarrer le service SQL Server, donc ce DMV peut ne pas vous être utile selon la nature exacte de votre question.