Contadores de desempenho do SQL Server

Question

Eu tenho uma instância do SQL Server 2005 que está passando por alguns tempos lentos. Este link mostra os detalhes do perfmon. Como não analiso esse tipo de dados diariamente, fiquei me perguntando se há alguns problemas reais com o sistema de E / S.

O servidor está usando uma SAN e os arquivos DB e os arquivos Tempdb estão na mesma unidade (E :). Não é a melhor arquitetura, mas não tenho controle sobre o servidor. O servidor é usado para executar relatórios usando o Cognos, portanto, é principalmente um banco de dados somente leitura.

Obrigado

Aqui está um código divertido que precisa ser corrigido.

select "tempSalesRpt_SubRgnDist"."Region" AS "Region",
   min("tempSalesRpt_SubRgnDist"."RegionName") AS "Region_Text"
from "SalesReporting"."dbo"."tempSalesRpt_SubRgnDist" "tempSalesRpt_SubRgnDist",
        (select "SecurityMaster"."Userid" AS "Userid", "SecurityMaster"."SoldTo" AS "SoldTo"
        from "SalesReporting"."dbo"."SecurityMaster" "SecurityMaster" 
        where "SecurityMaster"."Userid" = lower ('USTGACA')) "SecurityMaster4" 
where NOT "SecurityMaster4"."Userid" is null 
    and "tempSalesRpt_SubRgnDist"."SoldTo" ="SecurityMaster4"."SoldTo" 
    group by "tempSalesRpt_SubRgnDist"."Region" 
    order by 1 asc , 2 asc

A tabela securitymaster é acessada em todas as consultas e essa é a tabela que aumentou recentemente.

Eu diria que esse código não tem código sargable, mas o plano de execução mostra que pesquisas de índice são usadas e pesquisas de chaves.

Eu vejo que alguns novos índices podem ajudar, mas precisam cavar mais.

    

Answer 1

Com base nos dados fornecidos, você tem algo acontecendo. Suas filas de disco são segundos por leitura e segundos por contadores de gravação são muito maiores do que você deseja. Agora, a pegadinha aqui é que isso não significa que é um problema de disco, apenas que os discos estão sendo atingidos. Você poderia ter um problema de indexação ou um problema de estatísticas, o que está fazendo com que o SQL Server atinja os discos com mais força do que o necessário.

Comece examinando os índices no banco de dados e veja se é necessário criar novos índices. Isso aumentará o tamanho do seu banco de dados, mas você verá uma redução no tráfego para o disco e uma diminuição no tempo de execução da consulta.

Você pode começar examinando os planos de execução de suas consultas de longa duração, que lhe dirão onde você precisa adicionar índices.

    

Answer 2

Além da resposta do Denny, você tem cerca de 5 GB de memória livre na sua caixa - você configurou a memória do SQL corretamente?

Se você tiver um sistema de 32 bits, poderá endereçar mais memória ativando o AWE:

link

O SQL usará essa memória extra para armazenar em cache mais tabelas / índices do banco de dados (supondo que seu banco de dados seja maior que sua memória livre).