Sqlserver
 sql >> Base de Dados >  >> RDS >> Sqlserver

Limites de memória no SQL Server 2016 SP1


Algumas semanas atrás, fiz um grande negócio sobre o SQL Server 2016 Service Pack 1. Muitos recursos anteriormente reservados para o Enterprise Edition foram liberados para edições inferiores, e fiquei em êxtase ao saber dessas alterações.

No entanto, estou vendo algumas pessoas que estão, digamos, um pouco menos animadas do que eu.

É importante ter em mente que as alterações aqui não foram feitas para fornecer paridade completa de recursos em todas as edições; eles tinham o propósito específico de criar uma área de superfície de programação mais consistente. Agora, os clientes podem usar recursos como OLTP In-Memory, Columnstore e compactação sem se preocupar com a(s) edição(ões) de destino – apenas com o quão bem eles serão dimensionados. Vários recursos de segurança que realmente não parecem ter nada a ver com a edição também são abertos. O que eu menos entendia era Always Encrypted; Eu não conseguia entender por que apenas os clientes Enterprise precisavam proteger coisas como dados de cartão de crédito. A Criptografia de Dados Transparente ainda é somente Enterprise, em versões anteriores ao SQL Server 2019, porque esse não é realmente um recurso de programação (está ativado ou não).

Então, o que realmente há para os clientes da Edição completa?


Acho que o maior problema que a maioria das pessoas tem é que a memória máxima na Standard Edition ainda é limitada a 128 GB. Eles olham para isso e dizem:"Puxa, obrigado por todos os recursos, mas o limite de memória significa que não posso usá-los".

No entanto, as mudanças na área de superfície trazem oportunidades de melhoria de desempenho, mesmo que essa não fosse sua intenção original (ou mesmo que fosse – eu não estava em nenhuma dessas reuniões). Vamos dar uma olhada mais de perto em uma pequena seção das letras miúdas (dos documentos oficiais):

Limites de memória para Enterprise/Standard no SQL Server 2016 SP1

O leitor astuto notará que a redação do limite do buffer pool mudou, de:
Memória:memória máxima utilizada por instância
Para:
Memória:tamanho máximo do buffer pool por instância
Esta é uma descrição melhor do que realmente acontece na Standard Edition:um limite de 128 GB apenas para o pool de buffers e outras reservas de memória podem ser superiores a isso (pense em pools como o cache do plano). Assim, com efeito, um servidor Standard Edition poderia usar 128 GB de buffer pool, então a memória máxima do servidor poderia ser maior e suportar mais memória usada para outras reservas. Da mesma forma, o Express Edition agora está devidamente documentado para usar 1,4 GB para o pool de buffers.

Você também pode notar algumas palavras muito específicas nessa coluna mais à esquerda (por exemplo, "por instância" e "por banco de dados") para os recursos que estão sendo expostos na Edição Standard pela primeira vez. Para ser mais específico:
  • A instância está limitada a 128 GB de memória para o pool de buffers .
  • A instância pode ter um adicional 32 GB alocados para objetos Columnstore, além do limite do buffer pool.
  • Cada banco de dados de usuário na instância pode ter um adicional 32 GB alocados para tabelas com otimização de memória, além do limite do buffer pool.

E para ser claro:Esses limites de memória para ColumnStore e OLTP In-Memory NÃO são subtraídos do limite do buffer pool , desde que o servidor tenha mais de 128 GB de memória disponível. Se o servidor tiver menos de 128 GB, você verá essas tecnologias competirem com a memória do buffer pool e, na verdade, serão limitadas a uma % da memória máxima do servidor. Mais detalhes estão disponíveis neste post de Parikshit Savjani da Microsoft.

Não tenho hardware à mão para testar a extensão disso, mas se você tivesse uma máquina com 256 GB ou 512 GB de memória, teoricamente poderia usar tudo com uma única instância do Standard Edition, se pudesse - por exemplo - espalhar seu In -Dados de memória em bancos de dados em <=blocos de 32 GB, para um total de 128 GB + (32 GB * (# de bancos de dados)). Se você quiser usar ColumnStore em vez de In-Memory, poderá distribuir seus dados em várias instâncias, fornecendo (128 GB + 32 GB) * (nº de instâncias). E você pode combinar essas estratégias para ((128 GB + 32 GB ColumnStore) * (nº de instâncias)) + (32 GB na memória * (nº de bancos de dados * nº de instâncias)).
Se dividir seus dados dessa maneira é prático para seu aplicativo, não tenho certeza; Estou apenas sugerindo que é possível. Alguns de vocês podem já estar fazendo algumas dessas coisas para obter um melhor uso do Standard Edition em servidores com mais de 128 GB de memória.

Com o ColumnStore especificamente, além de poder usar 32 GB além do pool de buffers, lembre-se de que a compactação que você pode obter aqui significa que muitas vezes você pode caber muito mais nesse limite de 32 GB do que com os mesmos dados no tradicional loja de linha. E se você não puder usar o ColumnStore por qualquer motivo (ou ainda não caber em 32 GB), agora você pode implementar a compactação tradicional de página ou linha – isso pode não permitir que você ajuste todo o banco de dados no pool de buffer de 128 GB, mas ele pode permitir que mais dados estejam na memória a qualquer momento.

Coisas semelhantes são possíveis no Express (em uma escala menor), onde você pode ter 1,4 GB para o pool de buffers, mas um adicional de ~ 352 MB por instância para ColumnStore e ~ 352 MB por banco de dados para OLTP na memória.

Mas a Enterprise Edition ainda tem muitas vantagens


Existem muitos outros diferenciais para manter o interesse no Enterprise Edition, além de limites de memória ilimitados em todos os aspectos – de reconstruções online e varreduras de carrossel a grupos de disponibilidade completos e todos os direitos de virtualização que você pode ter. Até os índices ColumnStore têm aprimoramentos de desempenho bem definidos reservados para a Enterprise Edition.

Então, só porque existem algumas técnicas que permitirão que você tire mais proveito da Standard Edition, isso não significa que ela será magicamente dimensionada para atender às suas necessidades de desempenho. Como meus outros posts sobre "fazer com orçamento limitado" (por exemplo, particionamento e secundários legíveis), você certamente pode gastar tempo e esforço juntando uma solução, mas isso só o levará até certo ponto. O objetivo deste post foi simplesmente demonstrar que você pode ir mais longe com o Standard Edition em 2016 SP1 do que jamais poderia antes.