¿Cómo puedo determinar de manera confiable si una instancia determinada de SQL Server tiene el derecho "Bloquear páginas en la memoria"?

El derecho "Bloquear páginas en memoria" se puede otorgar a la cuenta de servicio utilizada por SQL Server. Esto permite que SQL Server evite que la memoria se pagine al disco.

He notado que varias de nuestras máquinas de SQL Server no tienen la política local configurada para permitir este derecho para la cuenta de servicio utilizada por SQL Server. Como tenemos una gran cantidad de servidores, será, en el mejor de los casos, tedioso verificar manualmente cada uno de ellos utilizando la consola de administración "Política del sistema local".

¿Existe una consulta T-SQL, un procedimiento almacenado extendido o algún otro método que pueda usar para determinar si el servidor en cuestión tiene el derecho o no?

Me gustaría no usarlo, EXEC xp_readerrorlog 0, 1, 'lock memory privilege was not granted';ya que depende de verificar el registro de errores actual de SQL Server; y ese registro de error puede no contener la entrada relevante, suponiendo que el registro se haya reiniciado desde la última vez que se reinició el servidor. Me doy cuenta de que podría verificar los registros antiguos modificando el primer parámetro de 0a 1, etc., sin embargo, solo conservamos 10 registros de errores, y eso puede no ser suficiente. Quiero una forma segura de confirmar la configuración.

Si xp_cmdshelles una opción, aquí hay un script que utiliza 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.exetiene la capacidad de informar todos los derechos que posee la cuenta en ejecución whoami. Esto, combinado con el xp_cmdshellproporciona una forma confiable de determinar si la instancia de SQL Server tiene el derecho necesario para bloquear páginas en la memoria.

Si xp_cmdshellno está habilitado, este código vuelve UNKNOWN. Suponiendo que xp_cmdshell está habilitado y el derecho está habilitado para la cuenta de SQL Server, regresa ENABLED, de lo contrario, regresa DISABLED.

Hay otros métodos también. Quizás pueda usar dos DMV. Tenga en cuenta que ambos solo funcionarán para SQL Server 2008 y versiones posteriores.

Un valor distinto de cero locked_page_allocations_kble indicaría que la cuenta de SQL Server tiene páginas bloqueadas en privilegios de memoria.

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'

...y:

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 columna Locked_pages_allocation_KBmuestra un valor distinto de cero, también la cuenta de servicio de SQL Server tiene páginas bloqueadas en privilegios de memoria.

...y:

La sección "Administrador de memoria" de la DBCC MEMORYSTATUSsalida mostrará un valor distinto de cero para el "AWE asignado" o si la cuenta de servicio de SQL Server tiene páginas bloqueadas en el privilegio de memoria.

NOTA:

Si la cuenta de servicio de SQL Server se ejecuta con la cuenta del Sistema local (NT Authority \ System), de forma predeterminada, SQL Server tendrá páginas bloqueadas en el privilegio de memoria.

Actualizar:

Antes de SQL Server 2012 para Standard Edition, debemos habilitar el indicador de seguimiento t -845 para aprovechar LPIM. Incluso si está ejecutando SQL Server con una cuenta con privilegio LPIM, el servidor SQL no usaría la ventaja LPIM a menos que el indicador de rastreo esté habilitado.

A partir de 2012 no necesitamos habilitar la marca de seguimiento en la edición estándar para aprovechar LPIM.

Microsoft facilita esto en las versiones más nuevas del producto si lo que realmente quiere saber es si SQL Server se está ejecutando con un modelo de memoria que aprovecha LPIM (en lugar de tener el permiso correcto). Esta información está en sys.dm_os_sys_info según su versión de SQL Server. La mejora se anunció en una publicación de blog :

Con SQL Server 2016 SP1 y SQL Server 2012 SP4, hay dos nuevas columnas, viz sql_memory_model y sql_memory_model_desc, agregadas a sys.dm_os_sys_info, que se pueden usar para identificar si los permisos de Bloquear páginas en memoria (LPIM) se asignan a la cuenta de servicio de SQL Server.

Una cosa importante a tener en cuenta es que las nuevas columnas informan el modelo de memoria sql en uso desde el inicio de la instancia de SQL Server, que es la información deseada. No hay comprobaciones realizadas a nivel del sistema operativo para los permisos LPIM para la cuenta de servicio sql. Si durante el inicio de SQL Server, el privilegio LPIM está presente en el token de proceso de la cuenta de servicio del servidor SQL, SQL Server usa páginas bloqueadas (no paginables) para asignar memoria sql. Además, si está ejecutando la edición Enterprise de SQL Server con privilegios LPIM asignados a la cuenta de servicio sql y la marca de seguimiento 834 activada, SQL Server usa páginas grandes para asignar memoria sql.

Para verificar si el privilegio Bloquear páginas en memoria está vigente para una instancia determinada de SQL Server, puede consultar sql_memory_model en sys.dm_os_sys_info y buscar valores mayores que 1.

Si faltan permisos LPIM en el token de proceso de la cuenta de servicio, se utiliza el modelo de memoria convencional y DMV informa de lo mismo (sql_memory_model = 1). Si ahora, el privilegio de bloqueo de páginas en memoria se asigna al servidor SQL pero el servicio SQL no se reinicia, el DMV continuará informando el modelo de memoria convencional, ya que ese es el modelo de memoria vigente desde el inicio. Después de reiniciar, SQL Server usa páginas bloqueadas en el modelo de memoria y sql_memory_model y sql_memory_model_desc informan lo mismo en sys.dm_os_sys_info.

Si ejecuto la siguiente consulta en uno de mis servidores:

SELECT sql_memory_model, sql_memory_model_desc
FROM sys.dm_os_sys_info;

El modelo de memoria actualmente en uso es CONVENTIONAL, lo que significa que LPIM no se otorgó en el momento del inicio del servidor. Sin embargo, sería posible otorgar LPIM pero no reiniciar el servicio SQL Server, por lo que este DMV puede no ser útil para usted dependiendo de la naturaleza exacta de su pregunta.