Partilhar via

Planeje sua adoção de In-Memory recursos OLTP no SQL Server

Aplica-se a:SQL ServerBanco de Dados SQL do AzureInstância Gerenciada SQL do Azure

Este artigo descreve as maneiras pelas quais a adoção de recursos na memória no SQL Server afeta outros aspetos do seu sistema comercial.

Observação

Um. Adoção dos recursos OLTP In-Memory

As subseções a seguir discutem os fatores a considerar ao planear adotar e implementar os recursos In-Memory.

A.1 Pré-requisitos

Um pré-requisito para usar os recursos In-Memory pode envolver a edição ou a camada de serviço do produto SQL. Para este e outros pré-requisitos, consulte:

A.2 Prever a quantidade de memória ativa

O seu sistema tem memória ativa suficiente para suportar uma nova tabela otimizada para memória?

Microsoft SQL Server

Uma tabela otimizada para memória que contenha 200 GB de dados requer mais de 200 GB de memória ativa dedicada ao seu suporte. Antes de implementar uma tabela com otimização de memória contendo uma grande quantidade de dados, você deve prever a quantidade de memória ativa adicional que talvez seja necessário adicionar ao computador servidor. Para orientações sobre estimativas, consulte:

Orientações semelhantes estão disponíveis para a Instância Gerenciada SQL do Azure:

Base de Dados SQL do Azure

Para um banco de dados hospedado no serviço de nuvem do Banco de Dados SQL do Azure, a camada de serviço escolhida afeta a quantidade de memória ativa que seu banco de dados pode consumir. Você deve planejar monitorar o uso de memória do seu banco de dados usando um alerta. Para mais informações, consulte:

Variáveis de tabela com otimização de memória

Uma variável de tabela que é declarada como otimizada para memória às vezes é preferível a um #TempTable tradicional que reside no banco de dados tempdb. As variáveis de tabela podem fornecer ganhos de desempenho sem usar quantidades significativas de memória ativa.

A.3 A tabela deve estar offline para ser convertida em memória otimizada

Algumas funcionalidades ALTER TABLE estão disponíveis para tabelas com otimização de memória. Mas você não pode emitir uma instrução ALTER TABLE para converter uma tabela baseada em disco em uma tabela com otimização de memória. Em vez disso, você deve usar um conjunto mais manual de etapas. O que se segue são várias maneiras de converter sua tabela baseada em disco para ser otimizada para memória.

Scripts manuais

Uma maneira de converter sua tabela baseada em disco em uma tabela com otimização de memória é codificar as etapas de Transact-SQL necessárias.

  1. Suspender a atividade do aplicativo.

  2. Faça um backup completo.

  3. Renomeie a tabela baseada em disco.

  4. Emita uma instrução CREATE TABLE para criar sua nova tabela com otimização de memória.

  5. INSERT INTO sua tabela com otimização de memória com um sub-SELECT da tabela baseada em disco.

  6. Elimine a sua tabela baseada em disco.

  7. Faça outro backup completo.

  8. Retomar a atividade do aplicativo.

Consultor de otimização de memória

A ferramenta Memory Optimization Advisor pode gerar um script para ajudar a implementar a conversão de uma tabela baseada em disco para uma tabela com otimização de memória. A ferramenta é instalada como parte do SSDT (SQL Server Data Tools).

Arquivo .dacpac

Você pode atualizar o seu banco de dados no local usando um arquivo .dacpac, gerido pelo SSDT. No SSDT, você pode especificar alterações no esquema codificado no arquivo .dacpac.

Você trabalha com arquivos .dacpac no contexto de um projeto do Visual Studio do tipo Database.

A.4 Orientação para saber se os recursos OLTP do In-Memory são adequados para a sua aplicação

Para obter orientação sobre se In-Memory recursos OLTP podem melhorar o desempenho de seu aplicativo específico, consulte:

B. Recursos não suportados

Os recursos que não são suportados em determinados cenários OLTP In-Memory são descritos em:

As subseções a seguir destacam alguns dos recursos sem suporte mais importantes.

B.1 INSTANTÂNEO de uma base de dados

Após a primeira vez que qualquer tabela ou módulo otimizado para memória é criado num determinado banco de dados, nenhuma SNAPSHOT do banco de dados pode ser feita. A razão específica é que:

  • O primeiro item otimizado para memória torna impossível descartar o último arquivo do FILEGROUP otimizado para memória; e ainda
  • Nenhum banco de dados que tenha um arquivo em um FILEGROUP otimizado para memória pode suportar um SNAPSHOT.

Normalmente, um SNAPSHOT pode ser útil para iterações de teste rápido.

B.2 Consultas entre bases de dados

As tabelas com otimização de memória não suportam transações de entre bases de dados. Não é possível acessar outro banco de dados da mesma transação ou da mesma consulta que também acessa uma tabela com otimização de memória.

As variáveis de tabela não são transacionais. Portanto, variáveis de tabela otimizadas para memória podem ser usadas em consultas entre bancos de dados.

B.3 Dica de tabela READPAST

Nenhuma consulta pode aplicar a dica de tabela READPAST a qualquer tabela otimizada para memória.

A dica READPAST é útil em cenários em que várias sessões estão acessando e modificando o mesmo pequeno conjunto de linhas, como no processamento de uma fila.

B.4 RowVersion, Sequência

  • Nenhuma coluna pode ser marcada para RowVersion numa tabela otimizada para memória.

  • Uma SEQUENCE não pode ser usada com uma restrição numa tabela com otimização de memória. Por exemplo, não é possível criar uma restrição DEFAULT com uma cláusula NEXT VALUE FOR. SEQUENCEs podem ser usados com instruções INSERT e UPDATE.

C. Manutenção administrativa

Esta seção descreve as diferenças na administração do banco de dados onde tabelas com otimização de memória são usadas.

C.1 Reinicialização da semente de identidade, incremento > 1

DBCC CHECKIDENT, para redefinir uma coluna IDENTITY, não pode ser usado numa tabela otimizada para memória.

O valor de incremento é restrito a exatamente 1 para uma coluna IDENTITY em uma tabela com otimização de memória.

C.2 DBCC CHECKDB não é possível validar tabelas com otimização de memória

O comando DBCC CHECKDB não faz nada quando seu destino é uma tabela com otimização de memória. As etapas a seguir são uma solução alternativa:

  1. Faça backup do log de transações.

  2. Faça backup dos arquivos no FILEGROUP otimizado para memória em um dispositivo nulo. O processo de backup realiza uma validação de checksum.

    Se for encontrada corrupção, prossiga com as próximas etapas.

  3. Copie dados de suas tabelas com otimização de memória para tabelas baseadas em disco, para armazenamento temporário.

  4. Restaure os arquivos do FILEGROUP otimizado para memória.

  5. INSIRA os dados que armazenou temporariamente nas tabelas baseadas em disco para as tabelas com otimização de memória.

  6. SOLTE as tabelas baseadas em disco que armazenavam temporariamente os dados.

D. Desempenho

Esta seção descreve situações em que o excelente desempenho de tabelas com otimização de memória pode ser mantido abaixo do potencial total.

D.1 Considerações sobre o índice

Todos os índices em uma tabela com otimização de memória são criados e gerenciados pelas instruções relacionadas à tabela CREATE TABLE e ALTER TABLE. Não é possível direcionar uma tabela com otimização de memória com uma instrução CREATE INDEX.

O índice não clusterizado tradicional da árvore B geralmente é a escolha sensata e simples quando você implementa pela primeira vez uma tabela otimizada para memória. Mais tarde, depois de ver o desempenho do seu aplicativo, você pode considerar a troca de outro tipo de índice.

Observação

A documentação usa o termo árvore B geralmente em referência a índices. Nos índices de armazenamento em linha, o Mecanismo de Base de Dados implementa uma árvore B+. Isso não se aplica a índices de armazenamento em colunas ou a índices em tabelas com otimização de memória. Para obter mais informações, consulte o SQL Server e o guia de design de arquitetura e design de índice SQL do Azure.

Dois tipos especiais de índices precisam ser discutidos no contexto de uma tabela com otimização de memória: índices de hash e índices Columnstore.

Para obter uma visão geral dos índices em tabelas com otimização de memória, consulte:

Índices de hash

Os índices de hash podem ser o formato mais rápido para acessar uma linha específica pelo seu valor exato de chave primária usando o operador '='.

  • Operadores inexatos como '!=', '>', ou 'BETWEEN' prejudicariam o desempenho se usados com um índice de hash.

  • Um índice de hash pode não ser a melhor escolha se a taxa de duplicação do valor de chave se tornar muito alta.

  • Evite subestimar quantos buckets seu índice de hash podem precisar, para evitar longas cadeias dentro de buckets individuais. Para mais informações, consulte:

Índices columnstore não clusterizados

As tabelas otimizadas para memória oferecem alta taxa de transferência de dados transacionais comerciais típicos, no paradigma que chamamos de processamento de transações on-line ou OLTP. Os índices Columnstore oferecem alta taxa de transferência de agregações e processamento semelhante que chamamos de Analytics. Em anos passados, a melhor abordagem disponível para satisfazer as necessidades do OLTP e do Analytics era ter tabelas separadas com grande movimentação de dados e com algum grau de duplicação de dados. Hoje, uma solução híbrida mais simples está disponível: ter um índice de armazenamento em colunas numa tabela otimizada para memória.

  • Uma de índice columnstore pode ser criada numa tabela baseada em disco, mesmo como o índice clusterizado. Mas em uma tabela com otimização de memória, um índice columnstore não pode ser agrupado.

  • As colunas LOB ou fora da linha para uma tabela com otimização de memória impedem a criação de um índice columnstore na tabela.

  • Nenhuma instrução ALTER TABLE pode ser executada em uma tabela com otimização de memória enquanto existir um índice columnstore na tabela.

    • A partir de agosto de 2016, a Microsoft tem planos de curto prazo para melhorar o desempenho da recriação do índice columnstore.

D.2 LOB e colunas fora da linha

Objetos grandes (LOBs) são colunas de tipos como varchar(max). Ter algumas colunas LOB em uma tabela otimizada para memória provavelmente não prejudica o desempenho o suficiente para ser importante. Mas evite ter mais colunas LOB do que seus dados precisam. O mesmo conselho se aplica às colunas fora de linha. Não defina uma coluna como nvarchar(3072) se varchar(512) for suficiente.

Mais informações sobre LOB e colunas fora da linha estão disponíveis em:

E. Limitações de procs nativos

Não há suporte para elementos específicos de Transact-SQL em módulos T-SQL compilados nativamente, incluindo procedimentos armazenados. Para obter detalhes sobre quais recursos são suportados, consulte:

Para obter considerações ao migrar um módulo Transact-SQL que usa recursos sem suporte para ser compilado nativamente, consulte:

Além das limitações em certos elementos do Transact-SQL, também há limitações nos operadores de consulta suportados em módulos T-SQL compilados nativamente. Devido a essas limitações, os procedimentos armazenados compilados nativamente não são adequados para consultas analíticas que processam grandes conjuntos de dados.

Sem processamento paralelo em um proc nativo

O processamento paralelo não pode fazer parte de nenhum plano de consulta para um proc nativo. Os procs nativos são sempre single-threaded.

Tipos de junção

Tanto as junções de hash quanto as uniões de mesclagem não podem fazer parte de nenhum plano de consulta para um proc nativo. As junções de loop aninhadas são usadas.

Sem agregação de hash

Quando o plano de consulta para um proc nativo requer uma fase de agregação, somente a agregação de fluxo está disponível. A agregação de hash não é suportada em um plano de consulta para um proc nativo.

  • A agregação de hash é melhor quando os dados de um grande número de linhas devem ser agregados.

F. Design do aplicativo: Transações e lógica de repetição

Uma transação envolvendo uma tabela com otimização de memória pode se tornar dependente de outra transação que envolva a mesma tabela. Se a contagem de transações dependentes atingir o máximo permitido, todas as transações dependentes falharão.

No SQL Server 2016:

  • O máximo permitido é de oito transações dependentes. Oito é também o limite de transações do qual qualquer transação pode ser dependente.
  • O número do erro é 41839. (No SQL Server 2014, o número do erro é 41301.)

Você pode tornar seus scripts de Transact-SQL mais robustos contra um possível erro de transação ao adicionar lógica de repetição aos seus scripts. É mais provável que a lógica de repetição ajude quando as chamadas UPDATE e DELETE são frequentes ou se a tabela com otimização de memória é referenciada por uma chave estrangeira em outra tabela. Para mais informações, consulte:

Conteúdo relacionado

  • Last updated on