SQL Server - Forçar DB na memória?

Temos um servidor robusto Windows 2008 x64 (CPU de 4 x 4 núcleos, 32 GB de RAM) executando o 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 é de E / S aleatória, portanto 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 é um tanto desajeitado (é uma solução COTS), por isso estou pensando se há uma maneira de "forçar" um banco de dados em memória no SQL Server 2005 (não há suporte para 2008 pelo fornecedor, portanto, não devemos atualizar para isso ainda) para ajudar a evitar os blues iniciais de preenchimento de cache?

Meu método atual é que eu execute 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 esse método (e modificando o script para interrogar índices e escrever cláusulas WHERE apropriadas para armazenar em cache é o complexo boil-the-ocean).

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

http://sqlserverpedia.com/wiki/Index_Maintenance

Levará mais tempo 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.

Ok - não posso comentar a resposta de Brent (ainda, como não tenho representantes suficientes) - mas se você seguir 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 tenha pelo menos o tamanho de seus índices e que seu log também poderá ter uma tonelada de registros de log (dependendo do modelo de recuperação). Se você for fazer a rota de desfragmentação, faça um ALTER INDEX ... REORGANIZE, que não requer espaço livre (bem, uma página de 8k), mas lerá o nível da folha na memória e funcionará apenas no fragmentado Páginas. Os níveis não foliares devem aparecer rapidamente após algumas consultas e (dependendo da dispersão) devem ter muito menos dados que o nível foliar.

Por que os objetos de banco de dados são liberados do cache em primeiro lugar? Você está reiniciando os serviços SQL ou desativando / on-line o banco de dados? Ou eles estão sendo enviados pelo cache de outros bancos de dados?

Saudações,

SCM.

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

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

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

Isso garantirá que seus outros bancos de dados nunca roubem memória do 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.

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

Verifique também se seus autostats estão atualizados.

Sem mais idéia do tipo de consulta e do tamanho da tabela db, parece um pouco estranho.