Como posso saber se o desempenho do meu banco de dados do SQL Server é limitado por hardware?

Testando um aplicativo atualmente sob carga de usuário único - como os dados de teste aumentaram para tamanhos de produção (400k-2M linhas por tabela), alguns sps SELECT não são mais rápidos o suficiente (com dados de teste limitados, costumava ser <30ms cada, agora são 100-200 ms, mas existem vários, então o atraso está se tornando aparente na interface do usuário).

Você pode usar DBCC SQLPERF("waitstats"). Isso retornará os tempos de espera de quais tarefas o servidor SQL estava aguardando. Explicações detalhadas de cada contador podem ser encontradas online. Você pode usar essas informações para descobrir seus gargalos.

Além disso, ative as estatísticas do cliente no analisador de consultas para ver os tempos de espera no lado do cliente.

Estou assumindo que o seu hardware não mudou desde o seu teste inicial; portanto, como são constantes, não duvido deles.

Pensamentos:

• o hardware quase nunca é um problema: é um design e código ruins
• sempre teste com qualidade e quantidade de dados de quase produção

Algumas soluções:

Execute o DMV de índice ausente para ver, bem, índices ausentes:

SELECT 
  migs.avg_total_user_cost * (migs.avg_user_impact / 100.0) * (migs.user_seeks + migs.user_scans) AS improvement_measure, 
  'CREATE INDEX [missing_index_' + CONVERT (varchar, mig.index_group_handle) + '_' + CONVERT (varchar, mid.index_handle) 
  + '_' + LEFT (PARSENAME(mid.statement, 1), 32) + ']'
  + ' ON ' + mid.statement 
  + ' (' + ISNULL (mid.equality_columns,'') 
    + CASE WHEN mid.equality_columns IS NOT NULL AND mid.inequality_columns IS NOT NULL THEN ',' ELSE '' END 
    + ISNULL (mid.inequality_columns, '')
  + ')' 
  + ISNULL (' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement, 
  migs.*, mid.database_id, mid.[object_id]
FROM sys.dm_db_missing_index_groups mig
INNER JOIN sys.dm_db_missing_index_group_stats migs ON migs.group_handle = mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details mid ON mig.index_handle = mid.index_handle
WHERE migs.avg_total_user_cost * (migs.avg_user_impact / 100.0) * (migs.user_seeks + migs.user_scans) > 10
ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC

... e as consultas DMV mais caras

SELECT TOP 20
    qs.sql_handle,
    qs.execution_count,
    qs.total_worker_time AS Total_CPU,
    total_CPU_inSeconds = --Converted from microseconds
    qs.total_worker_time/1000000,
    average_CPU_inSeconds = --Converted from microseconds
    (qs.total_worker_time/1000000) / qs.execution_count,
    qs.total_elapsed_time,
    total_elapsed_time_inSeconds = --Converted from microseconds
    qs.total_elapsed_time/1000000,
    st.text,
    qp.query_plan
FROM
    sys.dm_exec_query_stats AS qs
        CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
        CROSS apply sys.dm_exec_query_plan (qs.plan_handle) AS qp
ORDER BY qs.total_worker_time DESC

Caso contrário, esta pergunta do SO tem boas dicas minhas e de outros tipos de alto rep SQL: https://stackoverflow.com/q/4118156/27535 (não copio / colo todas as três respostas longas)

Registre os recursos do sistema ou consulte o gerenciador de tarefas para ver quantos recursos do sistema são usados ​​pelos processos.

O interessante é que a versão do MSSQL 2000 em execução

Existem quatro versões dos binários

1. Expressar
2. Padrão
3. Profissional
4. Empreendimento

Cada uma dessas versões possui limites em termos de RAM e CPU.

Vale a pena explorar a possibilidade de que a quantidade de dados armazenados atualmente tenha simplesmente superado os recursos da versão do MSSQL 2000 devido a consultas que precisam de mais RAM para atender a consultas / subconsultas ou utilização inadequada da CPU. Você pode precisar atualizar a versão binária para a versão do MSSQL 2000 Entrprise (provavelmente um tiro longo com a idade da sua versão do MSSQL) ou a melhor versão que seu orçamento pode oferecer.

Você pode até querer sair do MSSQL 2000, pois 2008 é o mais recente e possui suporte atual disponível. Novamente, isso pode ser uma questão de orçamento. Se você já está usando o Enterprise ou seu orçamento não pode permitir nenhuma atualização importante, agora você pode explorar o DB Statistics ou o DB Design.

Isenção de responsabilidade: eu não sou um DBA do SQL Server