Solucionar problemas de erros de falta de memória com Azure SQL Database e Fabric SQL Database

Applies to:Azure SQL Database SQL database in Fabric

Você poderá ver mensagens de erro quando o mecanismo do banco de dados SQL não tiver alocado memória suficiente para executar a consulta. Isso pode ser causado por vários motivos, incluindo os limites do objetivo de serviço selecionado, as demandas agregadas de memória da carga de trabalho e as demandas de memória pela consulta.

Para obter mais informações sobre o limite de recursos de memória para Azure SQL Database, consulte Resource management in Azure SQL Database. O Banco de Dados SQL do Fabric compartilha muitos recursos com Azure SQL Database, para obter mais informações sobre monitoramento de desempenho, consulte Fabric SQL Database performance monitoring.

Para saber mais sobre como solucionar problemas de memória em SQL Server, consulte MSSQLSERVER_701.

Experimente as seguintes vias de investigação em resposta a:

Código de erro 701 com a mensagem "Não há memória suficiente do sistema no pool de recursos '%ls' para executar a consulta".
Código de erro 802 com a mensagem "Não há memória suficiente disponível no pool de buffers".

Exibir eventos de memória insuficiente

Se você encontrar erros de memória insuficiente, revise sys.dm_os_out_of_memory_events. Essa visualização inclui informações sobre a causa prevista de falta de memória, determinada por um algoritmo heurístico e é fornecida com um nível finito de confiança.

SELECT * FROM sys.dm_os_out_of_memory_events ORDER BY event_time DESC;

Investigar alocação de memória

Se os erros de memória insuficiente persistirem em Azure SQL Database, considere, pelo menos, aumentar temporariamente o objetivo de nível de serviço do banco de dados no portal Azure.

Se os erros de memória insuficiente persistirem, use as consultas a seguir para procurar concessões de memória de consulta excepcionalmente altas que possam estar contribuindo para a condição de memória insuficiente. Execute as consultas de exemplo a seguir no banco de dados que experimentaram o erro (não no banco de dados master do servidor lógico Azure SQL).

Usar as consultas de gerenciamento dinâmico para ver eventos de falta de memória

O sys.dm_os_out_of_memory_events permite visibilidade dos eventos e das causas de eventos fora da memória (OOM) em Azure SQL Database. O evento summarized_oom_snapshot estendido é parte da sessão de evento system_health existente para simplificar a detecção. Para obter mais informações, consulte sys.dm_os_out_of_memory_events e o Blog: Uma nova maneira de solucionar erros de memória no mecanismo de banco de dados.

Usar DMVs para exibir os administradores de memória

Comece com uma ampla investigação, caso o erro de memória tenha ocorrido recentemente, e o exame da alocação de memória aos administradores de memória. Gerentes de memória são internos ao mecanismo de banco de dados do Azure SQL Database. Os principais gestores de memória em termos de páginas alocadas podem fornecer informações sobre qual tipo de consulta ou recurso do SQL Server está consumindo mais memória.

SELECT [type], [name], pages_kb, virtual_memory_committed_kb
FROM sys.dm_os_memory_clerks
WHERE memory_node_id <> 64 -- ignore Dedicated Admin Connection (DAC) node
ORDER BY pages_kb DESC;
GO
SELECT [type], [name], pages_kb, virtual_memory_committed_kb
FROM sys.dm_os_memory_clerks
WHERE memory_node_id <> 64 -- ignore Dedicated Admin Connection (DAC) node
ORDER BY virtual_memory_committed_kb DESC;

Alguns gerentes de memória comuns, como MEMORYCLERK_SQLQERESERVATIONS, são melhor resolvidos pela identificação de consultas com grandes alocações de memória e pela melhoria do desempenho por meio de melhor indexação e ajuste dos índices.
Embora OBJECTSTORE_LOCK_MANAGER não esteja relacionado a concessões de memória, espera-se que seja um número alto quando as consultas declaram muitos bloqueios, por exemplo, devido ao escalonamento de bloqueio desabilitado ou a transações muito grandes.
Espera-se que alguns responsáveis tenham a maior utilização: MEMORYCLERK_SQLBUFFERPOOL é quase sempre o principal responsável, enquanto CACHESTORE_COLUMNSTOREOBJECTPOOL tem alta utilização quando os índices columnstore são usados. É esperada a mais alta utilização por esses escriturários.

Para saber mais sobre tipos de administrador de memória, confira sys.dm_os_memory_clerks.

Usar DMVs para investigar consultas ativas

Na maioria dos casos, a consulta com falha não é a causa do erro.

A consulta de exemplo a seguir para Azure SQL Database retorna informações importantes sobre transações que estão atualmente mantendo ou aguardando concessões de memória. Buscar as principais consultas identificadas para exame e ajuste de desempenho e avaliar se elas estão sendo executadas conforme o esperado. Considere o momento de consultas de relatório com uso intensivo de memória ou operações de manutenção.

--Active requests with memory grants
SELECT
--Session data 
  s.[session_id], s.open_transaction_count
--Memory usage
, r.granted_query_memory, mg.grant_time, mg.requested_memory_kb, mg.granted_memory_kb
, mg.required_memory_kb, mg.used_memory_kb, mg.max_used_memory_kb     
--Query 
, query_text = t.text, input_buffer = ib.event_info, query_plan_xml = qp.query_plan
, request_row_count = r.row_count, session_row_count = s.row_count
--Session history and status
, s.last_request_start_time, s.last_request_end_time, s.reads, s.writes, s.logical_reads
, session_status = s.[status], request_status = r.status
--Session connection information
, s.host_name, s.program_name, s.login_name, s.client_interface_name, s.is_user_process
FROM sys.dm_exec_sessions s 
LEFT OUTER JOIN sys.dm_exec_requests AS r 
    ON r.[session_id] = s.[session_id]
LEFT OUTER JOIN sys.dm_exec_query_memory_grants AS mg 
    ON mg.[session_id] = s.[session_id]
OUTER APPLY sys.dm_exec_sql_text (r.[sql_handle]) AS t
OUTER APPLY sys.dm_exec_input_buffer(s.[session_id], NULL) AS ib 
OUTER APPLY sys.dm_exec_query_plan (r.[plan_handle]) AS qp 
WHERE mg.granted_memory_kb > 0
ORDER BY mg.granted_memory_kb desc, mg.requested_memory_kb desc;

Você pode optar por usar a instrução KILL para interromper uma consulta em execução no momento que possua ou esteja aguardando uma grande alocação de memória. Use essa instrução com cuidado, especialmente quando processos críticos estiverem em execução. Para obter mais informações, consulte KILL (Transact-SQL).

Usar Query Store para investigar o uso de memória de consulta anterior

Embora a consulta de exemplo anterior relata apenas os resultados da consulta dinâmica, a consulta a seguir usa o Query Store para retornar informações sobre a execução de consulta passada. Isso pode ser útil na investigação de um erro de falta de memória ocorrido no passado.

A consulta de exemplo a seguir do Azure SQL Database retorna informações importantes sobre execuções de consulta registradas pelo Query Store. Buscar as principais consultas identificadas para exame e ajuste de desempenho e avaliar se elas estão sendo executadas conforme o esperado. Observe o filtro de tempo em qsp.last_execution_time para restringir os resultados a um histórico recente. Você pode ajustar a cláusula TOP para produzir mais ou menos resultados, dependendo do seu ambiente.

SELECT TOP 10 PERCENT --limit results
  a.plan_id, query_id, plan_group_id, query_sql_text
, query_plan = TRY_CAST(query_plan as XML)
, avg_query_max_used_memory
, min_query_max_used_memory
, max_query_max_used_memory
, last_query_max_used_memory 
, last_execution_time  
, query_count_executions
    FROM (
    SELECT 
      qsp.plan_id, qsp.query_id, qsp.plan_group_id, qsp.query_plan, qsqt.query_sql_text
    , last_execution_time = MAX(qsp.last_execution_time)
    , query_count_executions = SUM(qsrs.count_executions) 
    , avg_query_max_used_memory = AVG(qsrs.avg_query_max_used_memory)
    , min_query_max_used_memory = MIN(qsrs.min_query_max_used_memory)
    , max_query_max_used_memory = MAX(qsrs.max_query_max_used_memory)
    , last_query_max_used_memory = MAX(qsrs_latest.last_query_max_used_memory) --only from latest result
    FROM sys.query_store_plan AS qsp 
    INNER JOIN sys.query_store_query AS qsq
        ON qsp.query_id = qsq.query_id
    INNER JOIN sys.query_store_query_text AS qsqt
        ON qsq.query_text_id = qsqt.query_text_id 
    INNER JOIN sys.query_store_runtime_stats AS qsrs
        ON qsp.plan_id = qsrs.plan_id 
    INNER JOIN (SELECT plan_id
            , last_query_max_used_memory 
            , rownum = ROW_NUMBER() OVER (PARTITION BY plan_id ORDER BY last_execution_time DESC)
            FROM sys.query_store_runtime_stats qsrs) AS qsrs_latest
        ON qsrs_latest.plan_id = qsp.plan_id
        AND qsrs_latest.rownum = 1 --use latest last_query_max_used_memory per plan_id
    WHERE DATEADD(hour, -24, sysdatetime()) < qsp.last_execution_time --past 24 hours only
    AND qsrs_latest.last_query_max_used_memory > 0
    GROUP BY qsp.plan_id, qsp.query_id, qsp.plan_group_id, qsp.query_plan, qsqt.query_sql_text
    ) AS a
ORDER BY max_query_max_used_memory DESC, avg_query_max_used_memory DESC;

Eventos estendidos

Além das informações anteriores, pode ser útil capturar um rastreamento das atividades no servidor para investigar detalhadamente um problema de memória insuficiente em Azure SQL Database.

Existem duas maneiras de capturar rastreamentos no SQL Server: Eventos Estendidos (XEvents) e Tracejos do Profiler. No entanto, a tecnologia de rastreamento SQL Server Profiler está obsoleta e não tem suporte para o Azure SQL Database. Extended Events é a tecnologia de rastreamento mais recente que permite mais versatilidade e menos impacto ao sistema observado e sua interface é integrada ao SSMS (SQL Server Management Studio). Para obter mais informações sobre como consultar eventos estendidos no Azure SQL Database, consulte eventos estendidos no Azure SQL Database.

Consulte o documento que explica como usar o Assistente de Nova Sessão de Eventos Estendidos no SSMS. No entanto, para bancos de dados Azure SQL, o SSMS fornece uma subpasta de Eventos Estendidos em cada banco de dados em Object Explorer. Use uma sessão de Eventos Estendidos para capturar esses eventos úteis e identificar as consultas que os geram:

Erros de categoria:
- error_reported
- exchange_spill
- hash_spill_details
Execução da Categoria:
- excessive_non_grant_memory_used
Memória da categoria:
- query_memory_grant_blocking
- query_memory_grant_usage
summarized_oom_snapshot

A captura de blocos de concessão de memória, vazamentos de concessão de memória ou concessões excessivas de memória pode ser um potencial indicativo de que uma consulta está consumindo subitamente mais memória do que antes, e uma explicação potencial para um erro de memória insuficiente em uma carga de trabalho existente. O evento summarized_oom_snapshot estendido é parte da sessão de evento system_health existente para simplificar a detecção. Para obter mais informações, consulte o blog: Uma nova maneira de solucionar erros de memória no mecanismo de banco de dados.

OLTP na memória com falta de memória

Você poderá encontrar Error code 41805: There is insufficient memory in the resource pool '%ls' to run this operation se estiver usando OLTP na memória. Reduza a quantidade de dados em tabelas otimizadas para memória e em parâmetros de tabela otimizados para memória, ou dimensione o banco de dados para um objetivo de serviço mais alto para ter mais memória. Para obter mais informações sobre problemas de memória insuficiente com SQL Server In-Memory OLTP, consulte Resolve problemas de memória insuficiente.

Obter suporte Azure SQL Database

Se erros de memória insuficiente persistirem em Azure SQL Database, registre uma solicitação Azure support selecionando Get Support no site Azure Support.

Comentários

Esta página foi útil?

Last updated on 2026-03-11