Quali sono i 3 principali problemi di prestazioni che riscontri con i tuoi server SQL?

Sono uno studente della Fontys University di Eindhoven e attualmente sto conducendo una serie di interviste per aiutare con lo sviluppo di uno strumento SQL Server e vorrei ricevere feedback dagli esperti del settore.

Una delle mie domande è:

Quali sono i 3 principali problemi di prestazioni che riscontri con le tue istanze di SQL Server e come li identifichi?

In particolare sono interessato agli script e agli strumenti utilizzati per misurare questo.

Fuori dalla cima della mia testa - primi 3 problemi di query:

• Conversioni implicite
• Strategie di indicizzazione errate (troppe o non sufficienti o del tipo sbagliato)
• Utilizzando SELECT * invece di nominare solo i campi necessari

C'è molto di più in merito a problemi di configurazione a livello di server, problemi di schema del database, problemi hardware, ecc. Ho scritto uno script per analizzare rapidamente i server alla ricerca di questo tipo di problemi:

http://www.brentozar.com/blitz/

• Design / query / indicizzazione scadenti
• Non è consentito acquistare hardware corretto
• Braindead ORMs (alias "SQL is dead")

Non tra i primi 3, ma ho pensato di menzionare cose non ancora menzionate:

1. SQL ha messo su macchine virtuali senza dettagli / trasparenza forniti al DBA. Il server host modificherà in modo dinamico le impostazioni dei computer guest causando un calo delle prestazioni e lasciando il DBA senza indizi. Funzionalità come hypertreading, teaming di rete e ballooning della memoria rendono i contatori delle prestazioni un obiettivo mobile da monitorare.Tools: sysmon/perfmon, DMVs, maintaining a history of performance counters in tables.
2. Allo stesso modo, nessuna trasparenza / verificabilità sulle impostazioni SAN fornite al DBA. Ho avuto LUN con diverse preferenze di cache di lettura / scrittura impostate ma ho detto che erano tutte uguali.Tools: IO DMVs, SQLIO.
3. Architettura DB errata: come dimensionamento e posizionamento dei dati e dei file di registro e tempdb. Uso improprio del parallelismo. Creazione di più filegroup sugli stessi dischi fisici.Tools: experience.

Un altro strumento che sto verificando ora è Project Lucy . Sembra pulito.

• privo di indici adeguati
• uso di con nolock nel codice di produzione da parte di qualcuno per cercare di risolvere problemi di prestazioni. Soprattutto se il codice modifica i dati nelle tabelle
• applicazione selezionando più dati del necessario in più volte di quanto sia necessario. Ex ha un binario restituito ogni volta anche se vuoi solo i dati di testo della stessa tabella.

Query che si ridimensionano male (ottieni tutti gli ordini per X anni per tutti i clienti ecc. Inclusi tutti gli ordini inclusi dati sommati e altri dati medi calcolati male)

Basta interrogare tutto in una volta.

Tabelle che contengono campi varchar / text 'descrittivi' che devono essere cercati attraverso ogni query.

• Manutenzione impropria, vale a dire nessuna reorgs di indice, statistiche, nessun backup del registro
• Indici mancanti
• Query scritte male

• Cattivo database e progettazione dell'applicazione
• scarso utilizzo dei vantaggi della piattaforma (gli sviluppatori desideravano avere un codice di accesso al database integrato nella piattaforma. Nessun SP, nessuna funzione ecc.)
• cattiva indicizzazione, ovviamente.

• query ad hoc sui dati di prod - sì, gli sviluppatori ritengono che sia necessario e alcuni potrebbero persino avere accesso :-)
• progettazione errata di un'app che utilizza il database, ad esempio: troppi dati aggiunti e mai rimossi anche se non sono più necessari (il che porta a problemi di prestazioni perché i backup diventano grandi, le attività di manutenzione richiedono più tempo ... ecc)
• tutti i file di database sullo stesso raid o peggio, sulla stessa unità (ad esempio: dbs di sistema, tempdb, dbs utente tutti insieme sulla stessa unità / raid)

• Cattiva progettazione del database
• Scarsa strategia di indicizzazione (inclusi troppi indici, indici mancanti e mancanza di manutenzione degli indici)
• Scarse decisioni sull'architettura hardware

L'indicizzazione è fondamentale per le prestazioni, ma ho scoperto che la maggior parte dei DBA lo sa, e quindi tende ad essere una delle prime cose che viene risolta tramite l'ottimizzazione delle query. Le aree che spesso non sono ben indirizzate:

1. Troppi viaggi di andata e ritorno per DB. Chattiness è uno dei principali problemi di prestazioni che vedo.
2. Ottenere i limiti di transazione giusti. La transazione di ogni INSERT / UPDATE / DELETE può essere un killer ad alte prestazioni.
3. Mancata ottimizzazione del lato hardware; in particolare, inserendo il registro DB su un volume diverso dai dati DB.

Se potessi aggiungere un quarto elemento all'elenco, sarebbe un uso eccessivo e inappropriato di trigger e / o cursori. Non sembra succedere troppo in questi giorni, ma quando lo fa, è doloroso dal punto di vista delle prestazioni.