Temos um robusto servidor Windows 2008 x64 (CPU 4 x 4 core, 32 GB 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 é muito aleatório de E / S para que as probabilidades sejam muito baixas queixam-se da lentidão inicial). Os discos são rápidos o suficiente (local SAS 15K), mas eu acho que o aplicativo é um pouco desajeitado (é uma solução COTS), então eu estou querendo saber se há uma maneira de "forçar" um banco de dados na memória no SQL Server 2005 (2008 não é suportado pelo fornecedor, por isso não devemos atualizar para isso ainda) para ajudar a evitar os blues iniciais de preenchimento de cache?
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 esse método (e modificar o script para interrogar os índices e escrever as cláusulas WHERE apropriadas para armazenar em cache é o complexo ferver-oceano).
Não, não há como forçar um banco de dados no cache, infelizmente. 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 baixa, como dizer reconstruir o índice se ele estiver 1% fragmentado, como este:
Isso levará mais tempo e envolverá mais gravações no disco, mas terá o efeito colateral de desfragmentar seus índices e atualizar as estatísticas, o que é uma boa ideia, de qualquer maneira.
Ok - Eu não posso comentar sobre a resposta do Brent (ainda, como eu não tenho representantes suficientes) - mas se você estiver indo para a rota de desfragmentação, não necessariamente reconstruir o índice - como isso vai construir novos índices, possivelmente aumentando o banco de dados se não houver espaço livre suficiente, e garantindo que o próximo backup de log tenha pelo menos o tamanho de seus índices e seu log também tenha 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 de folha na memória e só operará no fragmentado. Páginas. Os níveis que não são folha devem entrar rapidamente após algumas consultas e (dependendo do fan-out) devem ser muito menos dados do que o nível da folha.
Por que os objetos de banco de dados são liberados do cache? Você está reiniciando os serviços SQL ou removendo o banco de dados / online? Ou eles estão sendo empurrados para fora do cache de outros bancos de dados?
Atenciosamente,
SCM.
Se o banco de dados for pequeno, considere colocá-lo no SSD?
Eu tive alguns cenários que estavam atualizando as estatísticas com o FULLSCAN nas tabelas de chaves, forçando os dados para o cache e tornando meus DMLs subsequentes em torno dessas tabelas muito mais rápido. E isso não foi resultado de estatísticas desatualizadas, pois não resultou em mudanças nos planos de execução.
Por que você não instala uma segunda instância do SQL Server com apenas esse banco de dados e defina a 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.
Eu usaria o profiler para verificar seu sql. Compare as leituras 'lógicas' às leituras 'físicas'. O SQL Server é inteligente e usará a RAM necessária para os resultados mais eficientes.
Verifique também se os seus autostats estão atualizados.
Sem mais ideia do tipo de consulta e dos tamanhos das tabelas do banco de dados, isso parece um pouco estranho.