Introdução às tabelas Memory-Optimized

Aplica-se a:SQL ServerBase de Dados SQL do AzureInstância Gerida SQL do Azure

As tabelas com otimização de memória são criadas usando CREATE TABLE (Transact-SQL).

As tabelas com otimização de memória são totalmente duráveis por padrão e, como as transações em tabelas baseadas em disco (tradicionais), as transações em tabelas com otimização de memória são totalmente atômicas, consistentes, isoladas e duráveis (ACID). Tabelas com otimização de memória e procedimentos armazenados compilados nativamente suportam apenas um subconjunto de recursos Transact-SQL.

A partir do SQL Server 2016 e no Banco de Dados SQL do Azure, não há limitações para agrupamentos ou páginas de código específicas para In-Memory OLTP.

O armazenamento primário para tabelas com otimização de memória é a memória principal. As linhas da tabela são lidas e gravadas na memória. Uma segunda cópia dos dados da tabela é mantida no disco, mas apenas para fins de durabilidade. Consulte Criando e gerenciando armazenamento para objetos Memory-Optimized para obter mais informações sobre tabelas duráveis. Os dados em tabelas com otimização de memória só são lidos do disco durante a recuperação do banco de dados (por exemplo, após a reinicialização do servidor).

Para ganhos de desempenho ainda maiores, In-Memory OLTP suporta tabelas duráveis com durabilidade de transação adiada. As transações duráveis atrasadas são salvas no disco logo após a confirmação da transação e o controle é devolvido ao cliente. Em troca do aumento do desempenho, as transações confirmadas que não são persistidas no disco são perdidas em uma falha ou failover do servidor.

Além das tabelas padrão com otimização de memória durável, o SQL Server também oferece suporte a tabelas com otimização de memória não durável, que não são registradas e seus dados não são persistidos no disco. Isso significa que as transações nessas tabelas não exigem nenhuma E/S de disco, mas os dados são perdidos se houver uma falha ou failover do servidor.

In-Memory OLTP é integrado ao SQL Server para fornecer uma experiência perfeita em todas as áreas, como desenvolvimento, implantação, capacidade de gerenciamento e suporte. Um banco de dados pode conter objetos na memória e baseados em disco.

As linhas em tabelas com otimização de memória são versionadas. Isso significa que cada linha da tabela tem potencialmente várias versões. Todas as versões de linha são mantidas na mesma estrutura de dados da tabela. O controle de versão de linha é usado para permitir leituras e gravações simultâneas na mesma linha. Para obter mais informações sobre leituras e gravações simultâneas na mesma linha, consulte Transações com tabelas Memory-Optimized.

A figura a seguir ilustra o multiversionamento. A figura mostra uma tabela com três linhas e cada linha tem versões diferentes.

A tabela tem três linhas: r1, r2 e r3. R1 tem três versões, R2 tem duas versões, e R3 tem quatro versões. Versões diferentes da mesma linha não ocupam necessariamente locais de memória consecutivos. As diferentes versões de linha podem ser dispersas pela estrutura de dados da tabela.

A estrutura de dados da tabela com otimização de memória pode ser vista como uma coleção de versões de linha. As linhas em tabelas baseadas em disco são organizadas em páginas e extensões, e linhas individuais são endereçadas usando número de página e deslocamento de página. Em tabelas otimizadas para memória, as versões de linha são abordadas usando ponteiros de memória de 8 bytes.

Os dados em tabelas com otimização de memória são acessados de duas maneiras:

• Através de procedimentos armazenados compilados nativamente.

• Por meio de Transact-SQL interpretado, fora de um procedimento armazenado compilado nativamente. Essas Transact-SQL instruções podem estar dentro de procedimentos armazenados interpretados ou podem ser instruções Transact-SQL ad hoc.

Acessando dados em tabelas Memory-Optimized

As tabelas com otimização de memória podem ser acessadas de forma mais eficiente a partir de procedimentos armazenados compilados nativamente (Procedimentos armazenados compilados nativamente). Tabelas com otimização de memória também podem ser acessadas com o Transact-SQL interpretado (tradicional). Interpretado Transact-SQL refere-se ao acesso a tabelas com otimização de memória sem um procedimento armazenado compilado nativamente. Alguns exemplos de acesso Transact-SQL interpretado incluem o acesso a uma tabela otimizada para memória a partir de um gatilho DML, de um lote ad hoc Transact-SQL, de uma exibição e de uma função com valor de tabela.

A tabela a seguir resume o acesso Transact-SQL nativo e interpretado para vários objetos.

Característica	Acesso usando um procedimento armazenado compilado nativamente	Acesso Transact-SQL interpretado	Acesso CLR
Tabela com otimização de memória	Sim	Sim	N.o1
Tipo de tabela com otimização de memória	Sim	Sim	Não
Procedimento armazenado compilado nativamente	Agora há suporte para aninhamento de procedimentos armazenados compilados nativamente. Você pode usar a sintaxe EXECUTE dentro dos procedimentos armazenados, desde que o procedimento referenciado também seja compilado nativamente.	Sim	Não*

^1ºNão é possível acessar uma tabela com otimização de memória ou um procedimento armazenado compilado nativamente a partir da conexão de contexto (a conexão do SQL Server ao executar um módulo CLR). No entanto, você pode criar e abrir outra conexão a partir da qual você pode acessar tabelas com otimização de memória e procedimentos armazenados compilados nativamente.

Dados confidenciais em tabelas com otimização de memória podem ser protegidos usando Always Encrypted. Aplicam-se as seguintes limitações:

• Ao usar Always Encrypted com enclaves seguros, não é suportado o uso de chaves compatíveis com enclave para colunas em tabelas otimizadas para memória. Isso significa que a criptografia no local não pode ser usada e a criptografia inicial é efetuada no cliente.
• Always Encrypted não é suportado para nenhuma coluna em uma tabela com otimização de memória quando a tabela é referenciada em um módulo compilado nativamente.

Desempenho e escalabilidade

Os seguintes fatores afetam os ganhos de desempenho que podem ser alcançados com In-Memory OLTP:

Comunicação: Um aplicativo que usa muitas chamadas curtas de procedimento armazenado pode ter um ganho de desempenho menor em comparação com um aplicativo com menos chamadas e mais funcionalidade implementada em cada procedimento armazenado.

ExecuçãoTransact-SQL: In-Memory OLTP alcança o melhor desempenho ao usar procedimentos armazenados compilados nativamente em vez de procedimentos armazenados interpretados ou execução de consulta. Pode haver um benefício em acessar tabelas otimizadas para memória a partir desses procedimentos armazenados.

Varrimento de intervalo vs pesquisa de ponto: Os índices não agrupados otimizados para memória suportam varrimentos de intervalo e varrimentos ordenados. Para pesquisas pontuais, os índices hash otimizados para memória têm melhor desempenho do que os índices não clusterizados otimizados para memória. Os índices não clusterizados otimizados para memória têm melhor desempenho do que os índices baseados em disco.

• A partir do SQL Server 2016, o plano de consulta para uma tabela com otimização de memória pode verificar a tabela em paralelo. Isso melhora o desempenho das consultas analíticas.
  • Os índices de hash também se tornaram digitalizáveis em paralelo no SQL Server 2016.
  • Os índices não clusterizados também se tornaram digitalizáveis em paralelo no SQL Server 2016.

Operações de índice: As operações de índice não são registradas e existem apenas na memória.

Simultaneidade: Os aplicativos cujo desempenho é afetado pela simultaneidade a nível do motor de execução, como contenção de travas ou bloqueio, melhoram significativamente quando os aplicativos são movidos para In-Memory OLTP.

A tabela a seguir lista os problemas de desempenho e escalabilidade comumente encontrados em bancos de dados relacionais e como In-Memory OLTP pode melhorar o desempenho.

Questão	In-Memory Impacto OLTP
Desempenho Alto uso de recursos (CPU, E/S, rede ou memória).	CPU (Unidade Central de Processamento) Os procedimentos armazenados compilados nativamente podem reduzir significativamente o uso da CPU porque exigem menos instruções para executar uma instrução Transact-SQL em comparação com os procedimentos armazenados interpretados. In-Memory OLTP pode ajudar a reduzir o investimento em hardware em cargas de trabalho escalonadas, porque um servidor pode potencialmente fornecer a taxa de transferência de vários servidores. E/S Se encontrar um gargalo de I/O do processamento para dados ou páginas de índice, In-Memory OLTP pode reduzir o gargalo. Além disso, o checkpointing dos objetos OLTP de In-Memory é contínuo e não resulta em aumentos súbitos nas operações de E/S. No entanto, se o conjunto de trabalho das tabelas críticas de desempenho não couber na memória, In-Memory OLTP não se aplica porque requer que os dados sejam residentes na memória. Se você encontrar um gargalo de E/S no registo, In-Memory OLTP pode reduzir o gargalo porque faz menos registo. Se uma ou mais tabelas com otimização de memória forem configuradas como tabelas não duráveis, pode eliminar o registo de dados. Memória In-Memory OLTP não oferece nenhum benefício de desempenho. In-Memory OLTP pode colocar pressão extra na memória, pois os objetos precisam ser residentes na memória. Rede In-Memory OLTP não oferece nenhum benefício de desempenho. Os dados precisam ser comunicados da camada de dados para a camada de aplicativo.
Escalabilidade A maioria dos problemas de dimensionamento em aplicativos do SQL Server é causada por problemas de simultaneidade, como contenção em bloqueios, travas e spinlocks.	Contenção de trava Um cenário típico é a contenção na última página de um índice ao inserir linhas simultaneamente em ordem de chave. Como In-Memory OLTP não usa travas ao acessar dados, os problemas de escalabilidade relacionados a contenções de trava são totalmente removidos. Contenção de Spinlock Como In-Memory OLTP não usa travas ao acessar dados, os problemas de escalabilidade relacionados a contenções de spinlock são totalmente removidos. Contenção relacionada ao bloqueio Se seu aplicativo de banco de dados encontrar problemas de bloqueio entre operações de leitura e gravação, In-Memory OLTP removerá os problemas de bloqueio porque usa uma nova forma de controle de simultaneidade otimista para implementar todos os níveis de isolamento de transação. In-Memory OLTP não usa o TempDB para armazenar versões de linha. Se o problema de dimensionamento for causado por conflito entre duas operações de gravação, como duas transações simultâneas tentando atualizar a mesma linha, In-Memory OLTP permitirá que uma transação seja bem-sucedida e causará a falha da outra transação. A transação com falha deve ser reenviada explícita ou implicitamente, tentando novamente a transação. Em ambos os casos, você precisa fazer alterações no aplicativo. Se a sua aplicação tiver conflitos frequentes entre duas operações de escrita, a vantagem do bloqueio otimista será reduzida. O aplicativo não é adequado para In-Memory OLTP. A maioria das aplicações OLTP não tem conflitos de gravação, a menos que o conflito seja o resultado de escalonamento de bloqueios.

Row-Level Segurança em Memory-Optimized Tabelas

SegurançaRow-Level é suportada em tabelas otimizadas para memória. A aplicação de diretivas de segurança Row-Level a tabelas com otimização de memória é essencialmente a mesma que tabelas baseadas em disco, exceto que as funções com valor de tabela embutidas usadas como predicados de segurança devem ser compiladas nativamente (criadas usando a opção WITH NATIVE_COMPILATION). Para obter detalhes, consulte a seção Compatibilidade entre recursos no tópico SegurançaRow-Level .

Várias funções de segurança incorporadas que são essenciais para a segurança em nível de linha estão disponíveis para tabelas com otimização de memória. Para obter detalhes, consulte Funções internas em módulos compilados nativamente.

EXECUTE AS CALLER - Todos os módulos nativos agora suportam e usam EXECUTE AS CALLER por padrão, mesmo que a dica não seja especificada. Isso ocorre porque espera-se que todas as funções de predicado de segurança em nível de linha usem EXECUTE AS CALLER para que a função, e quaisquer funções internas usadas nela, sejam avaliadas no contexto do usuário chamador.
EXECUTE AS CALLER tem um pequeno (aproximadamente 10%) impacto de desempenho causado por verificações de permissão no chamador. Se o módulo especificar EXECUTAR COMO PROPRIETÁRIO ou EXECUTAR COMO SI MESMO explicitamente, essas verificações de permissão e o custo de desempenho associado serão evitados. No entanto, usar qualquer uma dessas opções juntamente com as funções internas mencionadas incorre em um maior impacto de desempenho devido à mudança de contexto necessária.

Cenários

Para obter uma breve discussão dos cenários típicos em que In-Memory OLTP pode melhorar o desempenho, consulte In-Memory OLTP.

Ver também

In-Memory OLTP (otimizaçãoIn-Memory)