Partilhar via

Guia de arquitetura de gerenciamento de memória

Aplica-se a:SQL ServerBanco de Dados SQL do AzureInstância Gerenciada SQL do Azure do Azure Synapse AnalyticsAnalytics Platform System (PDW)

Gerenciador de memória virtual do Windows

As regiões confirmadas do espaço de endereço são mapeadas para a memória física disponível pelo Gerenciador de Memória Virtual do Windows (VMM).

Para obter mais informações sobre a quantidade de memória física suportada por diferentes sistemas operacionais, consulte a documentação do Windows sobre limites de memória para versões do Windows.

Os sistemas de memória virtual permitem o comprometimento excessivo da memória física, de modo que a proporção de memória virtual/física pode exceder 1:1. Como resultado, programas maiores podem ser executados em computadores com várias configurações de memória física. No entanto, usar significativamente mais memória virtual do que os conjuntos de trabalho médios combinados de todos os processos pode causar baixo desempenho.

Arquitetura de memória do SQL Server

O SQL Server adquire e libera memória dinamicamente conforme necessário. Normalmente, um administrador não precisa especificar quanta memória deve ser alocada para o SQL Server, embora a opção ainda exista e seja necessária em alguns ambientes.

Um dos principais objetivos de design de todos os softwares de banco de dados é minimizar a E/S de disco porque as leituras e gravações de disco estão entre as operações que consomem mais recursos. O SQL Server cria um pool de buffers na memória para armazenar páginas lidas do banco de dados. Grande parte do código no SQL Server é dedicada a minimizar o número de leituras e gravações físicas entre o disco e o pool de buffers. O SQL Server tenta alcançar um equilíbrio entre dois objetivos:

  • Evite que o pool de buffers se torne tão grande que todo o sistema esteja com pouca memória.
  • Minimize a E/S física para os arquivos de banco de dados maximizando o tamanho do pool de buffers.

Em um sistema muito carregado, algumas consultas grandes que exigem uma grande quantidade de memória para serem executadas não conseguem obter a quantidade mínima de memória solicitada e recebem um erro de tempo limite enquanto aguardam recursos de memória. Para resolver isso, aumente a opção de espera de consulta. Para uma consulta paralela, considere reduzir o grau máximo do valor de paralelismo .

Em um sistema muito carregado sob pressão de memória, consultas com junção de mesclagem, ordenação e bitmap no plano de consulta podem descartar o bitmap quando as consultas não obtêm a quantidade mínima de memória necessária para o bitmap. Isso pode afetar o desempenho da consulta e, se o processo de classificação não couber na memória, pode aumentar o uso de tabelas de trabalho no tempdb banco de dados, fazendo com que tempdb cresça. Para resolver esse problema, adicione memória física ou ajuste as consultas para usar um plano de consulta diferente e mais rápido.

Memória convencional e virtual

Todas as edições do SQL Server oferecem suporte à memória convencional na plataforma de 64 bits. O processo SQL Server pode aceder ao espaço de endereçamento virtual até ao máximo do sistema operativo na arquitetura x64.

Observação

A partir do SQL Server 2025 (17.x), a edição SQL Server Standard suporta até 256 GB. No SQL Server 2022 (16.x) e versões anteriores, a edição SQL Server Standard suporta até 128 GB.

Com a arquitetura IA64, o limite era de 7 TB (IA64 sem suporte no SQL Server 2012 (11.x) e versões posteriores).

Para mais informações, consulte Limites de Memória para Windows.

Memória AWE (Address Windows Extensions)

Usando AWE ( Address Windowing Extensions ) e o privilégio LPIM (Bloquear páginas na memória ) exigido pelo AWE, você pode manter a maior parte da memória de processo do SQL Server bloqueada na RAM física em condições de pouca memória virtual. Isso acontece em alocações AWE de 32 bits e 64 bits. O bloqueio de memória ocorre porque a memória AWE não passa pelo Gerenciador de memória virtual no Windows, que controla a paginação da memória. A API de alocação de memória AWE requer o privilégio Bloquear páginas na memória (SeLockMemoryPrivilege); consulte AllocateUserPhysicalPages notes. Portanto, o principal benefício de usar a API AWE é manter a maior parte da memória residente na RAM se houver pressão de memória no sistema. Para obter informações sobre como permitir que o SQL Server use o AWE, consulte Habilitar a opção Bloquear páginas na memória (Windows).

Se o LPIM for concedido, é altamente recomendável que você defina max server memory (MB) para um valor específico, em vez de deixar o padrão de 2.147.483.647 megabytes (MB). Para obter mais informações, consulte Opções de configuração de memória do servidor: definir opções manualmente e Bloquear páginas na memória (LPIM).

Se o LPIM não estiver habilitado, o SQL Server alternará para o uso de memória convencional e em casos de esgotamento da memória do sistema operacional, e o erro de MSSQLSERVER_17890 poderá ser relatado no log de erros. O erro é semelhante ao seguinte exemplo:

A significant part of SQL Server process memory has been paged out. This may result in a performance degradation. Duration: #### seconds. Working set (KB): ####, committed (KB): ####, memory utilization: ##%.

Alterações no gerenciamento de memória a partir do SQL Server 2012

Em versões mais antigas do SQL Server, a alocação de memória era feita usando cinco mecanismos diferentes:

  • Single-Page Alocador (SPA), incluindo apenas alocações de memória menores ou iguais a 8 KB no processo SQL Server. As max server memory (MB) opções e min server memory (MB) configuração determinaram os limites de memória física que o SPA consumiu. O Buffer Pool era simultaneamente o mecanismo para SPA e o maior consumidor de alocações de página única.

  • Multi-Page Allocator (MPA), para alocações de memória que solicitam mais de 8 KB.

  • Alocador CLR, incluindo os heaps SQL CLR e suas alocações globais que são criadas durante a inicialização do CLR.

  • Alocações de memória para pilhas de threads no processo do SQL Server.

  • Alocações diretas do Windows (DWA), para solicitações de alocação de memória feitas diretamente no Windows. Isso inclui o uso de heap do Windows e alocações virtuais diretas feitas por módulos carregados no processo do SQL Server. Exemplos de tais solicitações de alocação de memória incluem alocações de DLLs de procedimento armazenado estendido, objetos que são criados usando procedimentos de automação (sp_OA chamadas) e alocações de provedores de servidor vinculados.

A partir do SQL Server 2012 (11.x), as alocações de Single-Page, as alocações de várias páginas e as alocações CLR são todas consolidadas em um alocador de páginas de "qualquer tamanho" e incluídas nos limites de memória controlados pelas max server memory (MB) opções de configuração e min server memory (MB) configuração. Essa alteração forneceu uma capacidade de dimensionamento mais precisa para todos os requisitos de memória que passam pelo gerenciador de memória do SQL Server.

Importante

Analise cuidadosamente suas configurações atuais max server memory (MB) e min server memory (MB) posteriores após a atualização para o SQL Server 2012 (11.x) e versões posteriores. Isso ocorre porque, a partir do SQL Server 2012 (11.x), essas configurações agora incluem e contabilizam mais alocações de memória em comparação com versões anteriores. Essas alterações se aplicam às versões de 32 bits e 64 bits do SQL Server 2012 (11.x) e do SQL Server 2014 (12.x) e às versões de 64 bits do SQL Server 2016 (13.x) e versões posteriores.

A tabela a seguir indica se um tipo específico de alocação de memória é controlado pelas max server memory (MB) opções e min server memory (MB) configuração:

Tipo de alocação de memória SQL Server 2005 (9.x), SQL Server 2008 (10.0.x) e SQL Server 2008 R2 (10.50.x) Começando com o SQL Server 2012 (11.x)
Alocações de página única Sim Sim, consolidado em alocações de páginas de qualquer tamanho
Alocações de várias páginas Não Sim, consolidado em alocações de páginas de qualquer tamanho
Dotações CLR Não Sim
Memória das pilhas de execução Não Não
Alocações diretas de recursos do Windows Não Não

SQL Server pode atribuir memória além do limite máximo de memória definido para o servidor

A partir do SQL Server 2012 (11.x), o max server memory (MB) SQL Server pode alocar mais memória do que o valor especificado na configuração. Esse comportamento pode ocorrer quando o valor de memória total do servidor (KB) já atingiu a configuração de memória do servidor de destino (KB), conforme especificado pelo max server memory (MB). Se não houver memória livre contígua suficiente para atender à demanda de solicitações de memória de várias páginas (mais de 8 KB) devido à fragmentação da memória, o SQL Server poderá executar um comprometimento excessivo em vez de rejeitar a solicitação de memória.

Assim que essa alocação é executada, a tarefa em segundo plano do Monitor de Recursos começa a sinalizar todos os consumidores de memória para liberar a memória alocada e tenta trazer o valor Total de Memória do Servidor (KB) abaixo da especificação de Memória do Servidor de Destino (KB). Portanto, o uso de memória do SQL Server pode exceder brevemente a max server memory (MB) configuração. Nessa situação, a leitura do contador de desempenho Total Server Memory (KB) excede as configurações e max server memory (MB)Target Server Memory (KB).

Esse comportamento normalmente é observado durante as seguintes operações:

  • Grandes consultas de índice columnstore
  • Modo de lote grande em consultas rowstore
  • Reconstruções de índices Columnstore, que usam grandes volumes de memória para executar operações de Hash e de Ordenação
  • Operações de backup que exigem buffers de memória grandes
  • Operações de rastreamento que precisam armazenar grandes parâmetros de entrada
  • Solicitações de concessão de memória grande

Se você observar esse comportamento com frequência, considere usar o sinalizador de rastreamento 8121 no SQL Server 2019 (15.x) para permitir que o Monitor de Recursos limpe mais rapidamente. A partir do SQL Server 2022 (16.x), essa funcionalidade é habilitada por padrão e o sinalizador de rastreamento não tem efeito.

Alterações no memory_to_reserve a partir do SQL Server 2012

Em versões mais antigas do SQL Server, o gerenciador de memória do SQL Server reservava uma parte do espaço de endereçamento virtual (VAS) do processo para uso pelo Multi-Page Allocator (MPA),CLR Allocator, alocações de memória para pilhas de threads no processo do SQL Server e alocações diretas do Windows (DWA). Essa parte do espaço de endereço virtual também é conhecida como região "Mem-To-Leave" ou "non-Buffer Pool".

O espaço de endereço virtual reservado para essas alocações é determinado pela opção de memory_to_reserve configuração. O valor padrão que o SQL Server usa é 256 MB.

Como o alocador de página "de qualquer tamanho" também lida com alocações maiores que 8 KB, o memory_to_reserve valor não inclui as alocações de várias páginas. Exceto por essa alteração, todo o resto permanece o mesmo com esta opção de configuração.

A tabela a seguir indica se um tipo específico de alocação de memória cai na memory_to_reserve região do espaço de endereço virtual para o processo do SQL Server:

Tipo de alocação de memória SQL Server 2005 (9.x), SQL Server 2008 (10.0.x) e SQL Server 2008 R2 (10.50.x) Começando com o SQL Server 2012 (11.x)
Alocações de página única Não Não, consolidado em alocações de página de qualquer tamanho
Alocações de várias páginas Sim Não, consolidado em alocações de página de qualquer tamanho
Dotações CLR Sim Sim
Memória das pilhas de execução Sim Sim
Alocações diretas de recursos do Windows Sim Sim

Gerenciamento dinâmico de memória

O comportamento padrão de gerenciamento de memória do Mecanismo de Banco de Dados do SQL Server é adquirir a quantidade de memória necessária sem criar uma escassez de memória no sistema. O Mecanismo de Banco de Dados do SQL Server faz isso usando as APIs de Notificação de Memória no Microsoft Windows.

Quando o SQL Server está usando memória dinamicamente, ele consulta o sistema periodicamente para determinar a quantidade de memória livre. Manter essa memória livre evita que o sistema operativo (SO) pagine. Se menos memória estiver livre, o SQL Server libera memória para o sistema operacional. Se houver mais memória livre, o SQL Server poderá alocar mais memória. O SQL Server adiciona memória somente quando sua carga de trabalho requer mais memória; Um servidor em repouso não aumenta o tamanho do seu espaço de endereço virtual. Se você notar que o Gerenciador de Tarefas e o Monitor de Desempenho mostram uma diminuição constante na memória disponível quando o SQL Server está usando o gerenciamento dinâmico de memória, esse é o comportamento padrão e não deve ser percebido como um vazamento de memória.

As opções de configuração de memória do servidor controlam a alocação de memória do SQL Server, a memória de compilação, todos os caches (incluindo o pool de buffers), as concessões de memória de execução de consulta, amemória do gerenciador de bloqueio e a memória CLR1 (essencialmente qualquer funcionário de memória encontrado no sys.dm_os_memory_clerks).

1 A memória CLR é gerenciada em max server memory (MB) alocações a partir do SQL Server 2012 (11.x).

A consulta a seguir retorna informações sobre a memória alocada no momento:

SELECT physical_memory_in_use_kb / 1024 AS sql_physical_memory_in_use_MB,
       large_page_allocations_kb / 1024 AS sql_large_page_allocations_MB,
       locked_page_allocations_kb / 1024 AS sql_locked_page_allocations_MB,
       virtual_address_space_reserved_kb / 1024 AS sql_VAS_reserved_MB,
       virtual_address_space_committed_kb / 1024 AS sql_VAS_committed_MB,
       virtual_address_space_available_kb / 1024 AS sql_VAS_available_MB,
       page_fault_count AS sql_page_fault_count,
       memory_utilization_percentage AS sql_memory_utilization_percentage,
       process_physical_memory_low AS sql_process_physical_memory_low,
       process_virtual_memory_low AS sql_process_virtual_memory_low
FROM sys.dm_os_process_memory;

Tamanhos de pilha

A memória para pilhas de threads 1, CLR 2, arquivos de .dll de procedimento estendido, os provedores OLE DB referenciados por consultas distribuídas, objetos de automação referenciados em instruções Transact-SQL e qualquer memória alocada por uma DLL que não seja do SQL Server, não são controlados pelo max server memory (MB).

1 Consulte Configuração do servidor: max worker threads, para obter informações sobre os threads de trabalho padrão calculados para um determinado número de CPUs afinizadas no host atual. Os tamanhos de pilha do SQL Server são os seguintes:

Arquitetura do SQL Server Arquitetura do SO Tamanho da pilha
x86 (32 bits) x86 (32 bits) 512 KB
x86 (32 bits) x64 (64 bits) 768 KB
x64 (64 bits) x64 (64 bits) 2.048 KB
IA64 (Itânio) IA64 (Itânio) 4.096 KB

2 A memória CLR é gerenciada em max server memory (MB) alocações a partir do SQL Server 2012 (11.x).

O SQL Server usa a API QueryMemoryResourceNotification de notificação de memória para determinar quando o gerenciador de memória do SQL Server pode alocar memória e liberar memória.

Quando o SQL Server é iniciado, ele calcula o tamanho do espaço de endereço virtual para o pool de buffers com base em vários parâmetros, como quantidade de memória física no sistema, número de threads de servidor e vários parâmetros de inicialização. O SQL Server reserva a quantidade computada de seu espaço de endereço virtual de processo para o pool de buffers, mas adquire (confirma) apenas a quantidade necessária de memória física para a carga atual.

Em seguida, a instância continua a adquirir memória conforme necessário para suportar a carga de trabalho. À medida que mais usuários se conectam e executam consultas, o SQL Server adquire mais memória física sob demanda. Uma instância do SQL Server continua a adquirir memória física até atingir seu max server memory (MB) destino de alocação ou o sistema operacional indicar que não há mais excesso de memória livre, ele libera memória quando é mais do que a configuração de memória mínima do servidor e o sistema operacional indica que há falta de memória livre.

À medida que outros aplicativos são iniciados em um computador que executa uma instância do SQL Server, eles consomem memória e a quantidade de memória física livre cai abaixo do destino do SQL Server. A instância do SQL Server ajusta seu consumo de memória. Se outro aplicativo for interrompido e mais memória ficar disponível, a instância do SQL Server aumentará o tamanho de sua alocação de memória. O SQL Server pode liberar e adquirir vários megabytes de memória a cada segundo, permitindo que ele se ajuste rapidamente às alterações de alocação de memória.

Efeitos da memória mínima e máxima do servidor

As opções de configuração min server memory e max server memory estabelecem limites superiores e inferiores para a quantidade de memória usada pelo pool de buffers e outros caches do Mecanismo de Banco de Dados. O pool de buffers não adquire imediatamente a quantidade de memória especificada em min server memory. O pool de buffers começa apenas com a memória necessária para inicializar. À medida que a carga de trabalho do Mecanismo de Banco de Dados do SQL Server aumenta, ela continua adquirindo a memória necessária para dar suporte à carga de trabalho. O pool de buffers não libera nenhuma memória adquirida até atingir a quantidade especificada em min server memory. Uma vez que a memória mínima do servidor é atingida, o pool de buffers usa o algoritmo padrão para adquirir e liberar memória conforme necessário. A única diferença é que o pool de buffers nunca deixa cair sua alocação de memória abaixo do nível especificado em min server memory e nunca adquire mais memória do que o nível especificado em max server memory (MB).

Observação

O SQL Server como um processo adquire mais memória do que o especificado pela max server memory (MB) opção. Os componentes internos e externos podem alocar memória fora do pool de buffers, que consome memória adicional, mas a memória alocada para o pool de buffers geralmente ainda representa a maior parte da memória consumida pelo SQL Server.

A quantidade de memória adquirida pelo Mecanismo de Banco de Dados do SQL Server depende inteiramente da carga de trabalho colocada na instância. Uma instância do SQL Server que não está processando muitas solicitações pode nunca atingir o valor especificado pelo min server memory (MB).

Se o mesmo valor for especificado para min server memory e max server memory (MB), assim que a memória alocada para o Mecanismo de Banco de Dados do SQL Server atingir esse valor, o Mecanismo de Banco de Dados do SQL Server interromperá dinamicamente a liberação e a aquisição de memória para o pool de buffers.

Se uma instância do SQL Server estiver sendo executada em um computador onde outros aplicativos são frequentemente interrompidos ou iniciados, a alocação e a desalocação de memória pela instância do SQL Server podem diminuir os tempos de inicialização de outros aplicativos. Além disso, se o SQL Server for um dos vários aplicativos de servidor em execução em um único computador, os administradores de sistema deverão controlar a quantidade de memória alocada para o SQL Server. Nesses casos, você pode usar a memória mínima do servidor e max server memory (MB) as opções para controlar a quantidade de memória que o SQL Server pode usar. As min server memory (MB) opções e max server memory (MB) são especificadas em megabytes. Para obter mais informações, incluindo recomendações sobre como definir essas configurações de memória, consulte Opções de configuração de memória do servidor.

Memória usada pelas especificações de objetos do SQL Server

A lista a seguir descreve a quantidade aproximada de memória usada por diferentes objetos no SQL Server. Os valores listados são estimativas e podem variar dependendo do ambiente e de como os objetos são criados:

  • Bloqueio (como mantido pelo Gestor de Bloqueios): 64 bytes + 32 bytes por proprietário
  • Conexão de usuário: Aproximadamente (3 * network_packet_size + 94 KB)

O tamanho do pacote de rede é o tamanho dos pacotes TDS (fluxo de dados tabulares) usados para se comunicar entre aplicativos e o Mecanismo de Banco de Dados. O tamanho de pacote padrão é de 4 KB e é controlado pela opção de configuração de tamanho de pacote de rede.

Quando vários conjuntos de resultados ativos (MARS) estão habilitados, a conexão do usuário é aproximadamente (3 + 3 * num_logical_connections) * network_packet_size + 94 KB.

Efeitos da memória mínima por consulta

A min memory per query opção de configuração estabelece a quantidade mínima de memória (em kilobytes) que será alocada para a execução de uma consulta. Isso também é conhecido como concessão mínima de memória. Todas as consultas devem aguardar até que a memória mínima solicitada possa ser protegida, antes que a execução possa ser iniciada ou até que o valor especificado na opção de configuração do servidor de espera de consulta seja excedido. O tipo de espera acumulado neste cenário é RESOURCE_SEMAPHORE.

Importante

Não defina a opção de configuração do min memory per query servidor muito alta, especialmente em sistemas muito ocupados, porque isso pode levar a:

  • Aumento da concorrência por recursos de memória.
  • Diminuição da simultaneidade aumentando a quantidade de memória para cada consulta, mesmo que a memória necessária em tempo de execução seja menor que essa configuração.

Para obter recomendações sobre como usar essa configuração, consulte Configuração do servidor: memória mínima por consulta.

Considerações sobre concessão de memória

Para execução no modo de linha, a concessão de memória inicial não pode ser excedida sob nenhuma condição. Se for necessária mais memória do que a concessão inicial para executar operações de hash ou classificação , as operações serão derramadas para o disco. Uma operação de hash que transborda é suportada por um Workfile no tempdb, enquanto uma operação de ordenamento que transborda é suportada por um Worktable.

Um derramamento que ocorre durante uma operação de classificação é conhecido como uma classe de evento de avisos de classificação. Os avisos de ordenação indicam que as operações de ordenação não têm espaço suficiente na memória. Isso não inclui operações de classificação que envolvam a criação de índices, apenas operações de ordenação numa consulta (como uma cláusula ORDER BY usada numa instrução SELECT).

Um derramamento que ocorre durante uma operação de hash é referido como uma Classe de Evento de Aviso de Hash. Estes ocorrem quando uma recursão de hash ou cessação de hashing (resgate de hash) ocorreu durante uma operação de hash.

  • A recursão de hash ocorre quando a entrada de compilação não cabe na memória disponível, resultando na divisão da entrada em várias partições que são processadas separadamente. Se alguma dessas partições ainda não caber na memória disponível, ela é dividida em subpartições, que também são processadas separadamente. Esse processo de divisão continua até que cada partição se encaixe na memória disponível ou até que o nível máximo de recursão seja atingido.
  • O resgate de hash ocorre quando uma operação de hashing atinge seu nível máximo de recursão e muda para um plano alternativo para processar os dados particionados restantes. Esses eventos podem causar um desempenho reduzido no servidor.

Para execução em modo de lote, a concessão de memória inicial pode aumentar dinamicamente até um determinado limite interno por padrão. Esse mecanismo de concessão de memória dinâmica foi projetado para permitir a execução residente na memória de operações de hash ou classificação em execução no modo de lote. Se essas operações ainda não cabem na memória, as operações são derramadas para o disco.

Para obter mais informações sobre modos de execução, consulte o Guia de arquitetura de processamento de consultas.

Gerenciamento de buffer

O objetivo principal de um banco de dados do SQL Server é armazenar e recuperar dados, portanto, a E/S de disco intensiva é uma característica central do Mecanismo de Banco de Dados. E como as operações de E/S de disco podem consumir muitos recursos e levar um tempo relativamente longo para serem concluídas, o SQL Server se concentra em tornar a E/S altamente eficiente. O gerenciamento de buffer é um componente fundamental para alcançar essa eficiência. O componente de gerenciamento de buffer consiste em dois mecanismos: o gerenciador de buffer para acessar e atualizar páginas de banco de dados e o cache de buffer (também chamado de pool de buffers), para reduzir a E/S do arquivo de banco de dados.

Para obter uma explicação detalhada da E/S de disco no SQL Server, consulte Fundamentos de E/S do SQL Server.

Como funciona o gerenciamento de buffer

Um buffer é uma página de 8 KB na memória, o mesmo tamanho de uma página de dados ou índice. Assim, o cache do buffer é dividido em páginas de 8 KB. O gerenciador de buffer gerencia as funções para ler dados ou páginas de índice dos arquivos de disco do banco de dados no cache do buffer e gravar páginas modificadas de volta ao disco. Uma página permanece no cache do buffer até que o gerenciador do buffer precise da área do buffer para ler mais dados. Os dados são gravados de volta no disco somente se forem modificados. Os dados no cache do buffer podem ser modificados várias vezes antes de serem gravados de volta no disco. Para obter mais informações, consulte Ler páginas de dados no Mecanismo de Banco de Dados e Escrever páginas no Mecanismo de Banco de Dados.

Quando o SQL Server é iniciado, ele calcula o tamanho do espaço de endereço virtual para o cache de buffer com base em vários parâmetros, como a quantidade de memória física no sistema, o número configurado de threads máximos de servidor e vários parâmetros de inicialização. O SQL Server reserva essa quantidade computada de seu espaço de endereço virtual de processo (chamado de destino de memória) para o cache de buffer, mas adquire (confirma) apenas a quantidade necessária de memória física para a carga atual. Você pode consultar as committed_target_kb colunas e committed_kb na exibição de catálogo sys.dm_os_sys_info para retornar o número de páginas reservadas como destino de memória e o número de páginas confirmadas atualmente no cache de buffer, respectivamente.

O intervalo entre a inicialização do SQL Server e quando o cache de buffer obtém seu destino de memória é chamado de ramp-up. Durante esse tempo, as solicitações de leitura preenchem os buffers conforme necessário. Por exemplo, uma única solicitação de leitura de página de 8 KB preenche uma única página de buffer. Isso significa que o aumento depende do número e do tipo de solicitações do cliente. A aceleração do ramp-up é conseguida transformando solicitações de leitura de página única em solicitações alinhadas de oito páginas (formando uma extensão). Isso permite que o processo de aumento de capacidade termine muito mais rapidamente, especialmente em máquinas que possuam grande quantidade de memória. Para obter mais informações sobre páginas e extensões, consulte Guia de arquitetura de páginas e extensões.

Como o gerenciador de buffer usa a maior parte da memória no processo do SQL Server, ele coopera com o gerenciador de memória para permitir que outros componentes usem seus buffers. O gerenciador de buffer interage principalmente com os seguintes componentes:

  • Gestor de Recursos para controlar o uso geral de memória e, em plataformas de 32 bits, para controlar o uso de espaço de endereçamento.
  • Gerenciador de Banco de Dados e o Sistema Operacional SQL Server (SQLOS) para operações de E/S de arquivos de baixo nível.
  • Log Manager para registo antecipado de logs.

Funcionalidades suportadas

O gerenciador de buffer suporta os seguintes recursos:

  • O gerenciador de buffer reconhece acesso não uniforme à memória (NUMA). As páginas de cache de buffer são distribuídas entre nós de hardware NUMA, o que permite que um thread aceda a uma página de buffer alocada no nó NUMA local em vez de memória estrangeira.

  • O gerenciador de buffer suporta Hot Add Memory, que permite aos usuários adicionar memória física sem reiniciar o servidor.

  • O gerenciador de buffer suporta páginas grandes em plataformas de 64 bits. O tamanho da página é específico para a versão do Windows.

    Observação

    Antes do SQL Server 2012 (11.x), habilitar páginas grandes no SQL Server exigia o sinalizador de rastreamento 834.

  • O gestor de buffer fornece diagnósticos adicionais que são expostos através de visões de gestão dinâmica. Você pode usar esses modos de exibição para monitorar vários recursos do sistema operacional específicos do SQL Server. Por exemplo, você pode usar a exibição sys.dm_os_buffer_descriptors para monitorar as páginas no cache do buffer.

Deteção de pressão da memória

A pressão da memória é uma condição resultante da falta de memória e pode resultar em:

  • E/S extras (como thread de fundo do escritor preguiçoso muito ativo)
  • Maior taxa de recompilação
  • Consultas de execução prolongada (caso existam esperas por concessão de memória)
  • Ciclos extras da CPU

Esta situação pode ser desencadeada por causas externas ou internas. As causas externas incluem:

  • A memória física disponível (RAM) é baixa. Isso faz com que o sistema corte conjuntos de trabalho de processos em execução no momento, o que pode resultar em lentidão geral. O SQL Server pode reduzir o objetivo de confirmação do pool de buffers e começar a reduzir caches internos com mais frequência.
  • A memória geral disponível do sistema (que inclui o arquivo de página do sistema) é baixa. Isso pode fazer com que o sistema falhe nas alocações de memória, pois não é possível paginar a memória alocada no momento.

As causas internas incluem:

  • Respondendo à pressão de memória externa, quando o Mecanismo de Banco de Dados do SQL Server define limites de uso de memória mais baixos.
  • As configurações de memória foram reduzidas manualmente reduzindo a configuração de memória máxima do servidor .
  • Alterações na distribuição de memória de componentes internos entre os vários caches.

O Mecanismo de Banco de Dados do SQL Server implementa uma estrutura dedicada a detetar e manipular a pressão da memória, como parte de seu gerenciamento dinâmico de memória. Essa estrutura inclui a tarefa em segundo plano chamada Monitor de Recursos. A tarefa Monitor de Recursos monitora o estado dos indicadores de memória externa e interna. Uma vez que um desses indicadores muda de status, ele calcula a notificação correspondente e a transmite. Essas notificações são mensagens internas de cada um dos componentes do mecanismo e armazenadas em buffers de anel.

Dois buffers de anel contêm informações relevantes para o gerenciamento dinâmico de memória:

  • O buffer de anel do Monitor de Recursos, que rastreia a atividade do Monitor de Recursos como se a pressão da memória estivesse sinalizada ou não. Este buffer de anel tem informações de status dependendo da condição atual de RESOURCE_MEMPHYSICAL_HIGH, RESOURCE_MEMPHYSICAL_LOW, RESOURCE_MEMPHYSICAL_STEADY, ou RESOURCE_MEMVIRTUAL_LOW.

  • O buffer de anel do Agente de Memória, que contém registros de notificações de memória para cada pool de recursos do Administrador de Recursos. À medida que a pressão interna da memória é detetada, a notificação de pouca memória é ativada para componentes que alocam memória, para acionar ações destinadas a equilibrar a memória entre caches.

Os corretores de memória monitoram o consumo de demanda de memória por cada componente e, em seguida, com base nas informações coletadas, calcula e o valor ideal de memória para cada um desses componentes. Há um conjunto de corretores para cada pool de recursos do Administrador de Recursos. Essas informações são então transmitidas para cada um dos componentes, que aumentam ou diminuem seu uso conforme necessário.

Para obter mais informações sobre agentes de memória, consulte sys.dm_os_memory_brokers.

Deteção de erros

As páginas de banco de dados podem usar um dos dois mecanismos opcionais que ajudam a garantir a integridade da página, desde o momento em que ela é gravada no disco até ser lida novamente: proteção de página rasgada e proteção de soma de verificação. Esses mecanismos permitem um método independente de verificar a correção não apenas do armazenamento de dados, mas de componentes de hardware, como controladores, drivers, cabos e até mesmo do sistema operacional. A proteção é adicionada à página imediatamente antes de gravá-la no disco e verificada depois de lida do disco.

O SQL Server tenta novamente qualquer leitura que falhe com uma soma de verificação, página rasgada ou outro erro de E/S quatro vezes. Se a leitura for bem-sucedida em qualquer uma das tentativas de repetição, uma mensagem será gravada no log de erros e o comando que disparou a leitura continuará. Se as tentativas de repetição falharem, o comando falhará com o erro MSSQLSERVER_824 .

O tipo de proteção de página usado é um atributo do banco de dados que contém a página. A proteção de soma de verificação é a proteção padrão para bancos de dados criados no SQL Server 2005 (9.x) e versões posteriores. O mecanismo de proteção de página é especificado no momento da criação do banco de dados e pode ser alterado usando ALTER DATABASE SET. Você pode determinar a atual configuração de proteção de página consultando a page_verify_option coluna na exibição de catálogo sys.databases ou a IsTornPageDetectionEnabled propriedade da função DATABASEPROPERTYEX.

Observação

Se a configuração de proteção de página for alterada, a nova configuração não afetará imediatamente todo o banco de dados. Em vez disso, as páginas adotam o nível de proteção atual do banco de dados sempre que são escritas em seguida. Isto significa que a base de dados pode ser composta por páginas com diferentes tipos de proteção.

Proteção contra rasgos de página

A proteção de página rasgada, introduzida no SQL Server 2000 (8.x), é principalmente uma maneira de detetar corrupções de página devido a falhas de energia. Por exemplo, uma falha de energia inesperada pode deixar apenas parte de uma página gravada no disco. Quando a proteção de página rasgada é usada, é aplicado um padrão de assinatura de 2 bits específico para cada setor de 512 bytes na página do banco de dados de 8 kilobytes (KB) e é armazenado no cabeçalho da página do banco de dados quando a página é gravada no disco.

Quando a página é lida do disco, os bits rasgados armazenados no cabeçalho da página são comparados com as informações reais do setor da página. O padrão de assinatura alterna entre binário 01 e 10 a cada gravação, por isso é sempre possível saber quando apenas uma parte dos setores chegou ao disco: se um bit está no estado errado quando a página é lida posteriormente, a página foi escrita incorretamente e uma página rasgada é detetada. A deteção de páginas rasgadas usa recursos mínimos; no entanto, ele não deteta todos os erros causados por falhas de hardware de disco. Para obter informações sobre como definir a deteção de página rasgada, consulte ALTER DATABASE SET Options.

Proteção de checksum

A proteção de soma de verificação, introduzida no SQL Server 2005 (9.x), fornece uma verificação mais forte da integridade dos dados. Uma soma de verificação é calculada para os dados em cada página que é gravada e armazenada no cabeçalho da mesma. Sempre que uma página com uma soma de verificação armazenada é lida do disco, o mecanismo de banco de dados recalcula a soma de verificação para os dados na página e gera o erro 824 se a nova soma de verificação for diferente da soma de verificação armazenada. A proteção de checksum pode detetar mais erros do que a proteção de página rasgada, uma vez que é afetada por cada byte da página; no entanto, consome recursos de forma moderada.

Quando a soma de verificação está ativada, erros causados por falhas de energia e hardware ou firmware defeituoso podem ser detetados sempre que o gerenciador de buffer lê uma página do disco. Para obter informações sobre como definir a soma de verificação, consulte ALTER DATABASE SET Options.

Importante

Quando um banco de dados de usuário ou sistema é atualizado para o SQL Server 2005 (9.x) ou posterior, o valor PAGE_VERIFY (NONE ou TORN_PAGE_DETECTION) é mantido. Recomendamos vivamente que se use CHECKSUM. TORN_PAGE_DETECTION pode usar menos recursos, mas fornece um subconjunto mínimo da CHECKSUM proteção.

Compreender o acesso não uniforme à memória

O SQL Server reconhece acesso não uniforme à memória (NUMA) e tem um bom desempenho em hardware NUMA sem configuração especial. À medida que a velocidade do clock e o número de processadores aumentam, torna-se cada vez mais difícil reduzir a latência de memória necessária para usar esse poder de processamento extra. Para contornar isso, os fornecedores de hardware fornecem grandes caches L3, mas essa é apenas uma solução limitada. A arquitetura NUMA fornece uma solução escalável para esse problema.

O SQL Server foi projetado para aproveitar os computadores baseados em NUMA sem exigir alterações no aplicativo. Para obter mais informações, consulte Soft-NUMA (SQL Server).

Partição dinâmica de objetos de memória

Os alocadores de heap, conhecidos como objetos de memória no SQL Server, permitem ao motor da base de dados alocar memória do heap. Estes podem ser rastreados usando a sys.dm_os_memory_objects DMV.

CMemThread é um tipo de objeto de memória thread-safe que permite alocações de memória simultânea de vários threads. Para o rastreamento correto, os objetos CMemThread dependem de construções de sincronização (um mutex) para garantir que apenas uma única thread esteja a atualizar partes críticas da informação de cada vez.

Observação

O CMemThread tipo de objeto é utilizado em toda a base de código do motor de base de dados para diversas alocações diferentes, podendo ser particionado globalmente, por nó ou por CPU.

No entanto, o uso de mutexes pode levar à contenção se muitos threads estiverem alocando do mesmo objeto de memória de forma altamente simultânea. Portanto, o SQL Server tem o conceito de objetos de memória particionados (PMO) e cada partição é representada por um único CMemThread objeto. O particionamento de um objeto de memória é definido estaticamente e não pode ser alterado após a criação. Como os padrões de alocação de memória variam amplamente com base em aspetos como hardware e uso de memória, é impossível criar o padrão de particionamento perfeito antecipadamente.

Na maioria dos casos, o uso de uma única partição é suficiente, mas em alguns cenários isso pode levar à contenção, que pode ser evitada apenas com um objeto de memória altamente particionado. Não é desejável particionar cada objeto de memória, pois mais partições podem resultar em outras ineficiências e aumentar a fragmentação da memória.

Observação

Antes do SQL Server 2016 (13.x), o sinalizador de rastreamento 8048 podia ser usado para forçar um PMO baseado em nó a se tornar um PMO baseado em CPU. A partir do SQL Server 2014 (12.x) SP2 e do SQL Server 2016 (13.x), esse comportamento é dinâmico e controlado pelo mecanismo.

A partir do SQL Server 2014 (12.x) SP2 e do SQL Server 2016 (13.x), o Mecanismo de Banco de Dados pode detetar dinamicamente contenção em um objeto específico CMemThread e promover o objeto para uma implementação por nó ou por CPU. Uma vez promovido, o PMO permanece promovido até que o processo do SQL Server seja reiniciado. CMemThread a contenção pode ser detetada pela presença de altas CMEMTHREAD esperas na sys.dm_os_wait_stats DMV, e observando as colunas sys.dm_os_memory_objects, contention_factor, partition_type, exclusive_allocations_count, e waiting_tasks_count.

Conteúdo relacionado

  • Last updated on