Come posso sapere se le mie prestazioni di SQL Server DB sono limitate dall'hardware?


8

Test di un'app attualmente sotto carico per singolo utente: poiché i dati del test sono aumentati alle dimensioni di produzione (400k-2M righe per tabella), alcuni sp di SELECT non sono più abbastanza veloci (con dati di test limitati, erano <30ms ciascuno, ora sono 100-200ms, ma ce ne sono diversi, quindi il ritardo sta diventando evidente nell'interfaccia utente).


È quasi garantito che sia codice e design, non hardware ...
gbn

Se le tue query potrebbero sfruttare le funzioni analitiche, sql server 2000 è decisamente limitato dal software.
bernd_k,

Beh, almeno non è interamente hardware - ho messo un'istanza di Express 2008 fianco a fianco sulla macchina di prova. 2000 volte sono ancora nello stesso intervallo, i tempi del 2008 sono tutti <20 ms. I camerieri non sembrano chiarire la differenza. Dopo aver cancellato le statistiche e su un test app identico, 2000 ha avuto PAGEIOLATCH_SH tempo di attesa di 2,48 secondi, in media 4 ms. Il 2008 aveva 2,14 secondi, in media 2 ms. Il che è meglio, ma non spiega il miglioramento di 10 volte nei tempi di risposta effettivi: è solo nei miglioramenti del motore generico dal 2000 al 2008 che non si riflettono nelle statistiche?
Pastymage,

Risposte:


8

È possibile utilizzare DBCC SQLPERF("waitstats"). Ciò restituirà i tempi di attesa di quali attività erano in attesa sul server SQL. Spiegazioni dettagliate di ciascun contatore sono disponibili online. È possibile utilizzare queste informazioni per scoprire i colli di bottiglia.

Inoltre, attiva le statistiche del client nell'analizzatore di query per visualizzare i tempi di attesa sul lato client.

Presumo che l'hardware non sia cambiato dal test iniziale, quindi poiché sono costanti, non ne dubiterei.


Ho raccolto un paio di domande per ordinare e filtrare le informazioni rilevanti da waitstats, e non mi ha detto molto (vedi il mio commento sull'articolo originale).
Pastymage,

@Pastymage prova anche a eseguire sp_updatestats nel tuo database SQL 2000. Provano di nuovo la query e vedono se ci sono miglioramenti delle prestazioni.
StanleyJohns,

No, esattamente lo stesso. Idem per l'aggiornamento di DBCC.
Pastymage,

2

Pensieri:

  • l'hardware non è quasi mai un problema: design e codice scadenti
  • testare sempre con quantità e qualità dei dati di quasi produzione

Alcune soluzioni:

Esegui l'indice DMV mancante per vedere, beh, gli indici mancanti:

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 le query DMV più costose

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

Altrimenti, questa domanda SO ha buoni consigli da me e da altri tipi SQL ad alta rep: https://stackoverflow.com/q/4118156/27535 (non copierò / incollerò tutte e 3 le risposte longish)


Quei DMV sono fantastici per il 2005+ ma non funzionano nel 2000.
SqlSandwiches,

@SqlSandwiches: oops, l'ho perso.
gbn,

Ho provato questo nell'istanza Express del 2008 che ho impostato - dm_exec_query_stats non sembra essere presente?
Pastymage,

1

Registra le risorse di sistema o osserva il task manager per vedere quante risorse di sistema sono utilizzate dai processi.


1

Una cosa interessante da considerare è la versione di MSSQL 2000 in esecuzione

Esistono quattro versioni dei file binari

  1. Esprimere
  2. Standard
  3. Professionale
  4. impresa

Ognuna di queste versioni ha limiti in termini di RAM e CPU.

Vale la pena esplorare la possibilità che la quantità di dati attualmente memorizzati abbia semplicemente superato le capacità della versione di MSSQL 2000 a causa di query che richiedono più RAM per soddisfare query / sottoquery o un utilizzo inadeguato della CPU. Potrebbe essere necessario aggiornare la versione binaria alla versione Entrprise di MSSQL 2000 (probabilmente una panoramica della vecchia versione di MSSQL) o la migliore versione che il budget può permettersi.

Potresti persino voler uscire da MSSQL 2000 poiché il 2008 è l'ultimo e ha il supporto attuale disponibile. Ancora una volta, questo potrebbe essere un problema di bilancio. Se stai già utilizzando Enterprise o il tuo budget non può consentire alcun aggiornamento importante, ora puoi esplorare DB Statistics o DB Design.

Disclaimer: non sono un DBA di SQL Server


L'aggiornamento al 2008 sembra essere una soluzione rapida, perché anche il 2008 Express con i suoi limiti di RAM da 1 CPU da 1 GB ha risolto completamente il problema. Tuttavia, vorrei capire perché / come ...
Pastymage,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.