Como posso determinar com segurança se uma determinada instância do SQL Server tem o direito "Bloquear páginas na memória"?

O direito "Bloquear páginas na memória" pode ser concedido à conta de serviço usada pelo SQL Server. Isso permite que o SQL Server impeça que a memória seja paginada em disco.

Notei que várias de nossas máquinas SQL Server não possuem a diretiva local configurada para permitir esse direito para a conta de serviço usada pelo SQL Server. Como temos um grande número de servidores, será tedioso, na melhor das hipóteses, verificar manualmente cada um deles usando o console de gerenciamento "Diretiva do sistema local".

Existe uma consulta T-SQL, procedimento armazenado estendido ou algum outro método que eu possa usar para determinar se o servidor em questão tem o direito ou não?

Eu gostaria de não usar, EXEC xp_readerrorlog 0, 1, 'lock memory privilege was not granted';pois ele depende da verificação do log de erros atual do SQL Server; e esse log de erros pode não conter a entrada relevante, supondo que o log tenha sido rolado desde que o servidor foi reiniciado pela última vez. Sei que poderia verificar logs mais antigos modificando o primeiro parâmetro de 0para 1etc, no entanto, mantemos apenas 10 logs de erros e isso pode não ser suficiente. Quero uma maneira segura de confirmar a configuração.

Se xp_cmdshellfor uma opção, aqui está um script usando 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.exetem a capacidade de relatar todos os direitos detidos pela conta em execução whoami. Isso, combinado com o, xp_cmdshellfornece uma maneira confiável de determinar se a instância do SQL Server tem o direito necessário para bloquear páginas na memória.

Se xp_cmdshellnão estiver ativado, esse código retornará UNKNOWN. Assumindo que xp_cmdshell está habilitado, e o direito está habilitado para a conta do SQL Server, ele retorna ENABLED; caso contrário, ele retorna DISABLED.

Existem outros métodos também. Talvez você possa usar dois DMVs. Observe que ambos funcionarão apenas para o SQL Server 2008 e superior.

Um valor diferente de zero locked_page_allocations_kbindica que a conta do SQL Server possui privilégios de páginas bloqueadas na memória.

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'

...e:

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

Se a coluna Locked_pages_allocation_KBmostrar um valor diferente de zero, também a conta de serviço do SQL Server terá privilégios de páginas bloqueadas na memória.

...e:

A seção "Gerenciador de memória" da DBCC MEMORYSTATUSsaída mostrará um valor diferente de zero para o "AWE alocado" ou se a conta de serviço do SQL Server tiver privilégio de páginas bloqueadas no memória.

NOTA:

Se a conta de serviço do SQL Server estiver em execução com a conta Sistema Local (NT Authority \ System), por padrão, o SQL Server terá páginas bloqueadas no privilégio de memória.

Atualizar:

Antes do SQL Server 2012 para Standard Edition, precisamos ativar o sinalizador de rastreamento t -845 para aproveitar o LPIM. Mesmo se você estiver executando o SQL Server com uma conta com privilégio LPIM, o SQL Server não usaria realmente a vantagem LPIM, a menos que o sinalizador de rastreamento esteja ativado.

A partir de 2012, não precisamos ativar o sinalizador de rastreamento na edição padrão para aproveitar a vantagem do LPIM.

A Microsoft facilita isso nas versões mais recentes do produto, se o que você realmente deseja saber é se o SQL Server está sendo executado com um modelo de memória que tira proveito do LPIM (em vez de ter a permissão correta). Essas informações estão em sys.dm_os_sys_info, dependendo da sua versão do SQL Server. O aprimoramento foi anunciado em uma postagem no blog :

Com o SQL Server 2016 SP1 e o SQL Server 2012 SP4, há duas novas colunas: sql_memory_model e sql_memory_model_desc adicionadas ao sys.dm_os_sys_info, que podem ser usadas para identificar se as permissões LPIM (Lock Pages in Memory) estão atribuídas à conta de serviço do SQL Server.

Um aspecto importante a ser observado é que as novas colunas relatam o modelo de memória sql em uso desde a inicialização da instância do SQL Server, que é a informação desejada. Não há verificações executadas no nível do sistema operacional para permissões de LPIM para a conta de serviço sql. Se durante a inicialização do SQL Server, o privilégio LPIM estiver presente no token de processo da conta de serviço do SQL Server, o SQL Server usará páginas bloqueadas (não pagináveis) para alocar memória sql. Além disso, se você estiver executando a edição Enterprise do SQL Server com privilégios LPIM atribuídos à conta de serviço sql e o sinalizador de rastreamento 834 ativado, o SQL Server usará páginas grandes para alocar memória sql.

Para verificar se o privilégio Bloquear páginas na memória está em vigor para uma determinada instância do SQL Server, você pode consultar sql_memory_model em sys.dm_os_sys_info e procurar valores maiores que 1.

Se as permissões LPIM estiverem ausentes no token do processo da conta de serviço, o modelo de memória convencional será usado e o mesmo será relatado pela DMV (sql_memory_model = 1). Se agora, o privilégio de bloqueio de páginas na memória for atribuído ao servidor SQL, mas o serviço SQL não for reiniciado, o DMV continuará relatando o modelo de memória convencional, já que esse é o modelo de memória em vigor desde a inicialização. Após a reinicialização, o SQL Server usa páginas bloqueadas no modelo de memória e o mesmo é relatado pelo sql_memory_model e sql_memory_model_desc em sys.dm_os_sys_info.

Se eu executar a seguinte consulta em um dos meus servidores:

SELECT sql_memory_model, sql_memory_model_desc
FROM sys.dm_os_sys_info;

O modelo de memória atualmente em uso é o CONVENTIONALque significa que o LPIM não foi concedido no momento da inicialização do servidor. No entanto, seria possível conceder LPIM, mas não reiniciar o serviço SQL Server, portanto, essa DMV pode não ser útil para você, dependendo da natureza exata da sua pergunta.