it-swarm-pt.tech

SQL Server - Forçar banco de dados na memória?

Temos um servidor Windows 2008 x64 robusto (CPU de 4 x 4 núcleos, 32 GB de RAM) executando SQL Server 2005 de 64 bits. Temos um banco de dados pequeno (6 GB), mas muito importante, que é um pouco lento para acessar até que as páginas sejam armazenadas em cache na memória (o uso é muito I/O aleatório, então as chances são muito baixas de que uma determinada página esteja na memória e os usuários finais reclamar da lentidão inicial). Os discos são rápidos o suficiente (SAS local de 15K), mas acho que o aplicativo foi escrito de maneira um tanto desajeitada (é uma solução COTS), então estou me perguntando se há uma maneira de "forçar" um banco de dados na memória no SQL Server 2005 (2008 não é compatível pelo fornecedor, então não devemos atualizar para isso ainda) para ajudar a evitar os blues de preenchimento de cache inicial

Meu método atual é executar um SELECT * de cada tabela em um script para obter páginas de dados na memória, mas alguns objetos (índices, pesquisa de texto completo, etc.) não são armazenados em cache por este método (e modificando o script para interrogar índices e escrever cláusulas WHERE apropriadas para armazenar em cache o complexo boil-the-ocean).

14
Matt Rogish

Não, não há uma maneira de forçar um banco de dados no cache, infelizmente. Seu método de força bruta é provavelmente o mais direto. Você pode conseguir chegar mais perto usando scripts de desfragmentação de índice com uma configuração de limite muito baixa, como dizer reconstruir o índice se estiver 1% fragmentado, assim:

http://sqlserverpedia.com/wiki/Index_Maintenance

Vai demorar mais e envolver mais gravações no disco, mas terá o efeito colateral de desfragmentar seus índices e atualizar estatísticas, o que é uma boa ideia de qualquer maneira.

15
Brent Ozar

Ok - não posso comentar a resposta de Brent (ainda, porque não tenho representantes suficientes) - mas se você estiver indo para a rota de desfragmentação, não necessariamente reconstrua o índice - pois isso criará novos índices, possivelmente aumentando o banco de dados se não houver espaço livre suficiente e garantindo que seu próximo backup de log seja pelo menos do tamanho de seus índices e seu log possa ter uma tonelada de registros de log também (dependendo do modelo de recuperação). Se você vai fazer a rota de desfragmentação, faça um ALTER INDEX ... REORGANIZE, que não requer nenhum espaço livre (bem, uma página de 8k), mas irá ler o nível folha na memória e operar apenas no fragmentado Páginas. Os níveis não-folha devem chegar rapidamente após algumas consultas e (dependendo do fan-out) deve haver muito menos dados do que o nível folha.

9
Paul Randal

Eu tive alguns cenários em que a atualização de estatísticas com FULLSCAN em tabelas-chave forçou os dados em cache e tornou meus DMLs subsequentes em torno dessas tabelas muito mais rápidos. E este não foi o resultado de estatísticas desatualizadas, pois não resultou em alterações nos planos de execução.

1
user172049

Por que os objetos de banco de dados são eliminados do cache em primeiro lugar? Você está reiniciando os serviços SQL ou desligando/online o banco de dados? Ou eles estão sendo eliminados pelo cache de outros bancos de dados?

Saudações,

SCM.

1
SuperCoolMoss

Se o banco de dados for tão pequeno, considere colocá-lo em SSD?

1
Roger Lipscombe

Por que você não instala um segunda instância do SQL Server apenas com esse banco de dados e define o memória mínima para essa instância como 6 GB?

Isso garantirá que seus outros bancos de dados nunca roubem memória de seu banco de dados "pequeno, mas muito importante".

Isso também significa que você pode colocar a outra instância offline e seu pequeno banco de dados permanecerá na memória.

0
Portman

Eu usaria o profiler para verificar seu sql. Compare leituras 'lógicas' com leituras 'físicas'. O servidor SQL é inteligente e usará o RAM necessário para obter os resultados mais eficientes.

Verifique também se suas estatísticas automáticas estão atualizadas.

Sem mais ideia do tipo de consulta e dos tamanhos da tabela de banco de dados, parece um pouco estranho.

0
Guy