Na documentação , temos um exemplo de como tabelas temporárias podem ser substituídas por tabelas em memória e porque uma tabela com otimização de memória:
- é armazenado apenas na memória e não possui nenhum componente no disco
- não envolve nenhuma atividade de IO
- não envolve utilização ou contenção de tempdb
Eles disseram isso:
A otimização de memória resulta em aumentos de velocidade que geralmente são 10 vezes mais rápidos ou mais.
Gostaria de saber se nosso sistema já está usando ram para banco de dados tempdb, qual dos benefícios ainda se aplica? Eu acho que eles estão testando o temdb no disco rígido ou ssd e duvidam de obter resultados tão bons.
Mais detalhes. Uma das funções de variável de tabela mais usadas no sistema é a que calcula o acesso a uma entidade específica. Em seguida, o resultado é unido a várias tabelas para obter os dados da solicitação. Para otimizar as últimas junções, estou armazenando o resultado desta função em uma tabela temporária e os resultados são bons.
Mas para volumes muito grandes (por exemplo, quando a função retorna 1-2 milhões de entidades) a execução da função em si é lenta (o que é novamente normal, pois estamos inserindo tantas linhas na variável da tabela).
Então, estou pensando em reescrever essa função como procedimento armazenado e inserir as entidades na tabela de memória, esperando que a operação CRUD com a tabela seja 10 times faster or more.
Em um comentário de Ned Otter :
Se sua carga de trabalho atual está ficando lenta devido à contenção de componentes internos, colocar tempdb em um ramdisk não o ajudará. Isso ocorre porque o problema não está relacionado à taxa de transferência de E/S. Confira este post detalhado de Paul Randal sobre o assunto:
O DBA acidental (dia 27 de 30): Solução de problemas: contenção de Tempdb
Ned continua com:
Este é um novo recurso em 2019 projetado para ajudar com esses tipos de problemas de contenção. Você pode ver uma demonstração de como isso ajuda e como ainda não está pronto na visualização atual do SQL Server 2019, no blog de Erik Darling:
SQL Server 2019 na memória tempdb
Você realmente precisa medir se a desaceleração é devido a E/S ou devido à contenção. Use o post de Paul Randal acima para se aprofundar nisso.
Como você atualizou sua pergunta para mencionar que os casos lentos são quando você insere milhões de linhas em uma variável de tabela, vou assumir que a contenção mencionada acima provavelmente não é um problema (a menos que você esteja criando essas variáveis de tabela de muitas conexões diferentes ao mesmo tempo). Nesse caso, a abordagem do ramdisk certamente poderia ajudar.
Em sua última atualização para a pergunta, você disse:
Este é um "problema" bem conhecido com OLTP na memória. Em vez de usar o paralelismo interno, você precisa "fazer o seu próprio" carregando dados nas tabelas na memória de várias conexões.