Assunzione di uno specialista OLTP SqlServer, quale esperienza o requisiti devo cercare? [chiuso]

Question

Sto riscontrando problemi di prestazioni Db con un progetto OTLP a cui sto lavorando. Un altro sviluppatore e io abbiamo raggiunto la fine delle nostre conoscenze sulle prestazioni accumulate e cerchiamo un individuo che si unisca al team per aiutarci ad accelerare la nostra applicazione.

Per alcuni retroscena abbiamo apportato modifiche allo schema per denormalizzare parti dei dati, ottimizzato ogni query, eseguito più consulenti di ottimizzazione del database per ottenere i nostri indici giusti, ottimizzato le opzioni del server di MSSql.

Non abbiamo bisogno che qualcuno entri e ci dica che i join possono essere lenti e che cos'è il deadlock, abbiamo bisogno di qualcuno che sappia cosa fare dopo aver esaurito tutti i passaggi sopra elencati.

Qualcuno ha qualche consiglio o esperienza nell'assumere DBA OLTP da condividere? Che tipo di domande possiamo porre al DBA durante il processo di intervista?

È una situazione strana in cui ci troviamo, sappiamo che abbiamo bisogno di qualcuno che sappia più della squadra attuale, ma non sappiamo quali domande porre perché non sappiamo quali saranno i prossimi passi. Ha senso?

Answer 1

Ok, questo mi dice qualcosa:

  

Per alcuni retroscena abbiamo apportato modifiche allo schema per denormalizzare parti dei dati, ottimizzato ogni query, eseguito più consulenti di ottimizzazione del database per ottenere i nostri indici giusti, ottimizzato le opzioni del server di MSSql.

Hai già abbinato o superato ciò che il 90% delle persone che si definiscono DBA saranno in grado di fare.

Il problema è che molti DBA non sono in realtà programmatori, sono più dal lato dell'amministrazione del sistema. Hai bisogno di un programmatore DBA che non sia solo bravo in TSQL, ma che conosca anche i tuoi altri linguaggi di programmazione.

Trascorro una parte significativa del mio tempo in problemi di ottimizzazione del database come questo, e la soluzione spesso comporta riprogettazioni significative dal front-end allo schema del database. Non puoi risolvere questi problemi da solo e senza il controllo completo (e la comprensione totale) dell'intera architettura, non otterrai mai le prestazioni di cui hai bisogno.

Tu potresti essere la persona migliore per il lavoro e potrebbe essere più intelligente per te assumere qualcuno che prenda il lavoro occupato dal piatto in modo da poterti concentrare sui problemi di prestazioni OLTP.

Answer 2

Devi stare molto attento qui, puoi finire per assumere un DBA Guru, fargli migliorare significativamente le prestazioni del database e avere ancora problemi con la tua applicazione che sono radicati nella sua architettura.

Alcune idee:

1. Prendi la query più complessa che hai ottimizzato, consegnala al DBA candidato con QA e falla ottimizzare di nuovo. Chiedi loro di descrivere cosa hanno fatto e come lo hanno fatto.

2. Assicurati che questa persona comprenda l'hardware, quando useresti più filegroup, array di raid, partizionamento dei dati, prestazioni a 64 vs 32 bit ecc ...

3. Cerca qualcuno che abbia anche un background di architettura software.

4. Poni loro alcune domande più difficili sul server SQL, ad es. Cos'è la dichiarazione OVER? Le GUID sono buone chiavi primarie e perché, è preferibile l'identità int?

Answer 3

Risintonizza il tuo DB un po 'prima della tua ottimizzazione e daglielo. Verifica se riescono a ottimizzarlo per ottenere prestazioni migliori o migliori rispetto alle modifiche apportate.

Chiedi perché hanno scelto quella tecnica.

Raccogli i riferimenti e scopri gli ambienti da cui provengono che sono più probabili corrispondere ai tuoi.

Answer 4

Un buon DBA sarà in grado di dirti nell'intervista ad alto livello quali passi intraprenderebbero dopo. Dovresti prestare maggiore attenzione ai processi di pensiero qui, piuttosto che alla soluzione del problema. Quando il DBA ha fornito alcune soluzioni, torna indietro e interrogale e chiedi loro perché il problema dovrebbe essere risolto in quel modo.

Questo metodo distinguerà molto rapidamente gli uomini dai ragazzi, per così dire.

Answer 5

Quanto sei vicino alle massime prestazioni del db? È molto facile creare un problema OLTP irrisolvibile con questa tecnologia. Come ha detto Eric, la riprogettazione totale dell'architettura potrebbe essere in ordine. Più ram, basta aggiungere più ram :)

Answer 6

Certamente senza vedere il database è difficile dire quale potrebbe essere il modo migliore per ottimizzare. Dato ciò che hai fatto, probabilmente dovrai assumere un progettista di database, uno con esperienza nella progettazione e nell'ottimizzazione di database nella gamma di dimensioni che hai. Nel chiedere come avrebbero affrontato il problema, vedere se l'intervistatore avrebbe esaminato le query con scarso rendimento ed eseguito il profiler per vedere cosa stava succedendo e per identificarle. La persona dovrebbe essere in grado di rispondere a domande specifiche sullo sniffing dei parametri e su come evitarlo, quali sono i metodi che possono essere utilizzati per evitare i cursori, perché le statistiche devono essere aggiornate, cosa rende una query noiosa. Ci sono alcune cose comuni che vorrei guardare nell'ottimizzazione delle prestazioni. La rete è al massimo (a volte non è il database), il design generale è mal concepito, stai usando il codice SQl che in generale funziona male? Se tutte le tue ricerche consentono ad esempio un carattere jolly come primo carattere, non è nemmeno possibile farli essere veloci. Se i tuoi join sono su chiavi naturali a più colonne, sono più lenti di quanto dovrebbero essere. Stai memorizzando più di un pezzo di informazione in un campo causando molta manipolazione per recuperare i dati? Stai usando i cursori? Stai usando le funzioni? Stai riutilizzando il codice quando non dovresti esserlo? Restituisci sempre le informazioni minime necessarie? Stai chiudendo le connessioni? Stai ottenendo deadlock? Le righe della tabella sono troppo larghe? Hai troppi record in tabelle particolari (eliminare i vecchi record o metterli in un database di archivio può fare una grande differenza)? Quanto del tuo codice è orientato alle righe e non impostato? Questi sono esempi dei tipi di cose che una persona di database esperta guarderebbe e quindi i tipi di cose di cui dovrebbero parlare nell'intervista.

Alcuni esempi di codici errati (sai cosa hai già ottimizzato) possono darti una buona idea del loro approccio al modo in cui si sintonizzerebbero. Vuoi qualcuno che sia metodico e abbia una conoscenza approfondita di SQL.

Ci sono alcuni buoni libri sull'ottimizzazione delle prestazioni: suggerirei di acquisirli e conoscerli prima di intervistare.