Comment savoir si les performances de ma base de données SQL Server sont limitées au matériel?

Test d'une application actuellement sous charge mono-utilisateur - comme les données de test ont augmenté pour atteindre les tailles de production (400k-2M lignes par table), certains SELECT sp ne sont plus assez rapides (avec des données de test limitées, auparavant <30 ms chacune, maintenant c'est 100-200 ms, mais il y en a plusieurs, donc le retard devient apparent dans l'interface utilisateur).

Vous pouvez utiliser DBCC SQLPERF("waitstats"). Cela renverra les temps d'attente des tâches sur lesquelles votre serveur SQL attendait. Des explications détaillées de chaque compteur sont disponibles en ligne. Vous pouvez utiliser ces informations pour découvrir vos goulots d'étranglement.

Activez également les statistiques du client dans l'analyseur de requêtes pour voir les temps d'attente côté client.

Je suppose que votre matériel n'a pas changé depuis votre test initial, donc comme ils sont constants, je n'en doute pas.

Pensées:

• le matériel n'est presque jamais un problème: c'est une conception et un code médiocres
• testez toujours avec une qualité et une quantité de données proches de la production

Quelques solutions:

Exécutez l'index manquant DMV pour voir, enfin, les index manquants:

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

... et les requêtes DMV les plus chères

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

Sinon, cette question SO contient de bons conseils de ma part et d'autres types de représentants SQL élevés: https://stackoverflow.com/q/4118156/27535 (je ne copierai / collerai pas les 3 réponses longues)

Connectez-vous aux ressources système ou consultez le gestionnaire de tâches pour voir combien de ressources système sont utilisées par les processus.

Une chose intéressante à considérer est la version de MSSQL 2000 exécutée

Il existe quatre versions des binaires

1. Express
2. la norme
3. Professionnel
4. Entreprise

Chacune de ces versions a des limites en termes de RAM et de CPU.

Il convient d'explorer la possibilité que la quantité de données actuellement stockées ait simplement dépassé les capacités de la version de MSSQL 2000 en raison de requêtes nécessitant plus de RAM pour répondre aux requêtes / sous-requêtes ou à une utilisation insuffisante du processeur. Vous devrez peut-être mettre à niveau la version binaire vers la version MSSQL 2000 Entrprise (probablement une longue vue en raison de l'âge de votre version de MSSQL) ou la meilleure version que votre budget peut vous permettre.

Vous voudrez peut-être même sortir de MSSQL 2000 car 2008 est la dernière version et dispose d'un support actuel. Encore une fois, cela pourrait être un problème budgétaire. Si vous utilisez déjà Enterprise ou si votre budget ne permet aucune mise à niveau majeure, vous pouvez maintenant explorer les statistiques ou la conception de DB.

Avertissement: je ne suis pas un DBA SQL Server