Come rispondere al motivo per cui improvvisamente abbiamo bisogno di indici o query deve essere cambiata

Sono un DBA junior con 3 anni di esperienza. Il nostro compito è mettere a punto le query o avvisare gli sviluppatori che un determinato codice deve essere riscritto o che sono necessari indici.

Una semplice domanda che il team di sviluppo pone frequentemente è: "Ieri ha funzionato bene, cosa è cambiato improvvisamente?" e ci verrà chiesto di controllare il lato dell'infrastruttura. La prima reazione a qualsiasi problema sembra sempre essere quella di dare la massima colpa all'infrastruttura, che è sempre la prima cosa da convalidare.

Come dovremmo rispondere alle domande "cosa è cambiato" dal team di sviluppo? Avete mai affrontato la stessa situazione? In tal caso, condividi la tua esperienza.

Come rispondere a ciò che ha cambiato la domanda da parte di dev?

Questa è una domanda molto comune non solo con DEV, ma si applica a tutti i team IT e aziendali.

Che cosa è cambiato? ==> è possibile rispondere con fatti e cifre.

I fatti si riferiscono ad esempio

• aumentare la quantità di utenti che accedono al database?
• Qualche cambiamento nel parametro di configurazione del server?
• Manutenzione database: aggiornamento statistiche, reorg / ricostruzione degli indici non eseguiti? Per questo motivo i piani vengono generati in modo errato!
• La quantità di dati è aumentata?
• Sono state apportate modifiche sul lato della rete, il sistema operativo è stato patchato e / o è stato distribuito un nuovo service pack o CU per il server sql - senza eseguire un test di regressione completo del ciclo aziendale dell'applicazione ?
• La SAN sottostante è diventata improvvisamente lenta?

Le figure possono essere derivate se si hanno dati da mostrare. Per esempio :

• Basilea il tuo server è fondamentale in questa situazione. Questo allevierà il gioco della colpa poiché puoi supportare i fatti con cifre solide.
• Inizia a raccogliere dati utilizzando DMV o sp_whoisactive su una tabella, in modo che i dati vengano persistiti dopo il riavvio di un server sql.

(devi allenarti in base al tuo ambiente e alle tue esigenze, a quanto spesso raccogliere i dati / quali dati raccogliere e quanto sarà il periodo di conservazione) o (puoi investire in un software di terze parti come sqlsentry o il responsabile diagnostico di idera che farà il lavoro sopra per te) .

Bene, potresti avere un piano diverso perché:

• il piano avrebbe potuto essere espulso dalla cache a causa di:
  • un riavvio del servizio
  • svuotamento manuale della cache del piano
  • riavvio o failover del servizio
  • una modifica involontaria, ad esempio alcune sp_configuremodifiche possono svuotare la cache
  • alcune modifiche a oggetti, indici, statistiche o altre dipendenze sottostanti hanno innescato una ricompilazione
• potresti semplicemente ricevere un piano diverso rispetto agli altri utenti o invocazioni precedenti perché:
  • il testo della query potrebbe non essere identico (questo include la distinzione tra maiuscole e minuscole e spazi bianchi, non importa colonne diverse, criteri di join, filtri, ecc.)
  • la query potrebbe essere eseguita da diversi utenti con opzioni set diverse (o diversi schemi predefiniti, se qualsiasi oggetto nel piano non ha un nome completo, incluso lo schema )
• la query e il piano potrebbero essere gli stessi, ma potresti ottenere prestazioni diverse perché:
  • il piano è stato memorizzato nella cache utilizzando parametri diversi e tale piano non è ottimale per l'attuale set di parametri (questo è comunemente chiamato "sniffing dei parametri")
  • la quantità di dati basata sui parametri o semplicemente a causa della modifica dei dati nel frattempo è significativamente diversa
  • i dati sono cambiati abbastanza da alterare il modo più efficiente di accedere ai dati, ma non abbastanza per innescare aggiornamenti o ricompilazioni di statistiche (ricerca di un problema chiave crescente e algoritmo di auto-statistiche)
  • i dati sono stati sfrattati dal pool di buffer e ora devono essere letti dal disco
  • vi è una maggiore concorrenza, blocco o altri sforzi sulle risorse necessarie per soddisfare la query

Ne passo molti di questi in modo più dettagliato qui:

• Piani multipli per una query "identica"

Se questi sono in esecuzione su ambienti diversi, allora ho un'intera serie di cose da controllare qui:

• Piani diversi per server "identici"

Inoltre, è importante tenere presente che la creazione di un indice o la modifica della query potrebbe non essere il motivo diretto per cui una query improvvisamente si comporta meglio - a volte è solo perché tali modifiche hanno effettivamente generato un nuovo piano e / o invalidato quello già esistente .

Come al solito Aaron Bertrand e Kin hanno fornito risposte eccellenti. Tuttavia entrambe le risposte contengono un thread comune. Se analizzi una delle risposte vedrai che il motivo per cui XYZ non funziona come ha funzionato ieri non è dovuto a qualcosa che X ha fatto. Il motivo per cui le cose sono cambiate è perché il database ha deciso di fare le cose in modo diverso a causa di motivi XYZ.

Un database è un'entità vivente che respira . I database prenderanno le decisioni e cambieranno idea a causa di una combinazione di ipotesi, statistiche e altri strumenti euristici. Ciò è notevolmente diverso dalla maggior parte della programmazione a livello di applicazione (l'apprendimento automatico è un'eccezione notevole).

_{Userò alcuni riferimenti militari perché non riesco a pensare a qualcosa di meglio in questo momento. Una metafora più generale sarebbe apprezzata (nessun gioco di parole inteso).}

Nella maggior parte delle applicazioni il programmatore funge da istruttore di trapani. Dicono al computer esattamente cosa fare, in quale ordine e talvolta per quanto tempo. Programmare un database è più come agire come un comandante. Dici quello che vuoi che faccia ad alto livello e offri qualche guida dove necessario. Il database si impegna a trovare il modo migliore per eseguire il piano basato sull'intelligence attuale come gli ufficiali junior e gli ufficiali non commissionati.

Rendendo chiara questa distinzione nelle menti degli altri programmatori, si spera che inizieranno a vedere che non hai poteri dittorici come fanno sul loro ambiente. Stai guidando il database verso la soluzione e occasionalmente il database va fuori strada per ragioni buone o cattive. Ricorda loro che alla fine non importa il motivo per cui * il database è andato fuori strada, ma cosa possiamo fare per riportarlo indietro.

_{* Riconosco "perché" è molto prezioso per la prevenzione, l'apprendimento, ecc., Ma sembra che l'OP stia affrontando la resistenza di persone che non stanno cercando di conoscere o aiutare il problema.}