¿Cómo puedo saber si el rendimiento de mi DB de SQL Server está limitado por hardware?

Prueba de una aplicación actualmente bajo carga de un solo usuario: a medida que los datos de prueba aumentaron a tamaños de producción (400k-2M filas por tabla), algunos SP SELECT ya no son lo suficientemente rápidos (con datos de prueba limitados, solían ser <30ms cada uno, ahora son 100-200 ms, pero hay varios, por lo que el retraso se está haciendo evidente en la interfaz de usuario).

Puedes usar DBCC SQLPERF("waitstats"). Esto devolverá los tiempos de espera de las tareas que estaba esperando su servidor SQL. Las explicaciones detalladas de cada contador se pueden encontrar en línea. Puede usar esta información para descubrir sus cuellos de botella.

Además, active las estadísticas del cliente en el analizador de consultas para ver los tiempos de espera en el lado del cliente.

Supongo que su hardware no ha cambiado desde su prueba inicial, por lo que, dado que son constantes, no dudaría de ellos.

Pensamientos:

• el hardware casi nunca es un problema: su diseño y código son deficientes
• siempre pruebe con datos de calidad y cantidad cercanos a la producción

Algunas soluciones:

Ejecute el índice DMV faltante para ver, bueno, índices faltantes:

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

... y las consultas DMV más 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

De lo contrario, esta pregunta SO tiene buenos consejos de mí y otros tipos de alta repetición de SQL: https://stackoverflow.com/q/4118156/27535 (no copiaré / pegaré las 3 respuestas largas)

Registre los recursos del sistema o mire el administrador de tareas para ver cuántos recursos del sistema utilizan los procesos.

Lo interesante que debe considerarse es la versión de MSSQL 2000 en ejecución

Hay cuatro versiones de los binarios.

1. Rápido
2. Estándar
3. Profesional
4. Empresa

Cada una de esas versiones tiene límites en términos de RAM y CPU.

Vale la pena explorar la posibilidad de que la cantidad de datos actualmente almacenados simplemente haya superado las capacidades de la versión de MSSQL 2000 debido a que las consultas necesitan más RAM para cumplir consultas / subconsultas o la utilización inadecuada de la CPU. Es posible que necesite actualizar la versión binaria a la versión MSSQL 2000 Entrprise (probablemente una posibilidad remota de la antigüedad de su versión de MSSQL) o la mejor versión que su presupuesto puede pagar.

Es posible que incluso desee salir de MSSQL 2000, ya que 2008 es la última versión y tiene soporte actual disponible. Nuevamente, esto podría ser un problema presupuestario. Si ya está utilizando Enterprise, o su presupuesto no puede permitir ninguna actualización importante, ahora puede explorar las Estadísticas de DB o el Diseño de DB.

Descargo de responsabilidad: no soy un DBA de SQL Server