Estou apenas começando a aprender sobre o uso de memória no SQL Server. Ao usar a consulta na resposta à pergunta SQL Server 2008 R2 "Ghost Memory"? , descobri que um único banco de dados está ocupando a maior parte do espaço no conjunto de buffers. Olhando mais adiante, usando sys.allocation_units
e sys.indexes
, confirmei que isso provavelmente é causado pelo uso intenso de índices no banco de dados. A maioria dos índices são agrupados.
Outro desenvolvedor de banco de dados acredita que estamos tendo problemas de memória no servidor - que as consultas estão começando a ficar longas porque não há memória disponível.
Minha pergunta aqui é - o uso desses índices e sua existência no buffer pool tiram a memória disponível para outros processos?
Sim, as páginas de dados de um índice usado que são armazenadas em cache no buffer pool ocuparão espaço no cache de dados . Mas não deixe que isso o afaste do uso de índices (em primeiro lugar, um índice clusterizado são os dados reais da tabela, portanto, lembre-se disso também). O uso de índices (devidamente projetados e implementados, é claro) é uma coisa boa.
Seus problemas de memória provavelmente não são de ter índices em suas tabelas . Mergulhe nos problemas de memória, quais são exatamente os problemas? Você está tendo uma baixa expectativa de vida da página ? Como sua memória está configurada no servidor? A memória máxima do servidor está muito baixa, restringindo o tamanho do buffer pool?
Para obter um detalhamento das páginas de índice em seu cache de dados, você pode executar a consulta abaixo:
Para obter essas estatísticas por banco de dados:
Os índices consomem espaço do buffer pool, sim. Esta é mais uma razão pela qual você deve tomar cuidado com sua estratégia de indexação e minimizar duplicatas.
Lembre-se de que um índice clusterizado é a tabela . A única sobrecarga que existe para um índice clusterizado além daquela para um heap (que geralmente é indesejável) é para as páginas de índice não folha e a inclusão da chave de cluster em todos os índices não clusterizados para essa tabela. É por isso que as chaves de cluster estreitas são preferidas.
Os artigos de Kimberley Tripp sobre escolhas de chaves agrupadas são uma excelente referência para isso.