Perché è male eseguire selezioni da un server prod?

Sembra che questa battaglia abbia avuto luogo innumerevoli volte. Inizia quasi sempre con alcuni programmatori inesperti (solitamente utilizzando Access) che eseguono query direttamente sui database back-end e creano problemi di prestazioni / blocco.

La reazione più comune è che il DBA applichi semplicemente la legge marziale e blocchi tutti dall'accesso diretto al database con le stesse identiche spiegazioni fornite in precedenza. Questo è sfortunato, perché ignora il fatto che le persone che gestiscono quelle query non lo fanno solo per divertimento o per dispetto del DBA, questi professionisti hanno bisogno di accedere ai dati per portare a termine il loro lavoro. Il problema è che gli utenti delle applicazioni e gli analisti di dati back-end sono in lotta per le risorse e devi soddisfare entrambi i gruppi.

Non sto dicendo che non dovresti bloccare il DB, ma solo che il DBA non dovrebbe lasciare sempre che gli utenti della app superino le esigenze degli analisti. Invece, lui / lei dovrebbe lavorare con gli analisti per trovare modi alternativi per soddisfare le loro esigenze di dati senza abbattere il sistema.

Ad esempio:
- È possibile utilizzare uno strumento di report per ridurre al minimo la necessità di query ad-hoc?
- È possibile stabilire una finestra temporale in cui sono consentite query ad hoc per mitigare il danno di una query errata?
- Gli analisti possono ottenere una formazione dal DBA sulle migliori pratiche per evitare le query di uccisione di DB?
- La maggior parte delle piattaforme DB ha un governatore di query che limita il danno che si può fare con le query di lunga durata (sebbene non sia di grande aiuto con i problemi di blocco)
 -È possibile impostare un mirror DB o un data warehouse come alternativa all'interrogazione del sistema live?

TL: DR - Non guardare le persone che uccidono il tuo DB con le loro query ad-hoc come avversari che devono essere fermati, ma come un'altra classe di utenti che devi trovare un modo per soddisfare le loro esigenze aziendali e mitigare il rischio di impatto sulle prestazioni sul / sui sistema / i.

Hanno da qualche altra parte per testare le loro domande, come un duplicato di prod, con gli stessi dati, ma in una regione di test isolata dove possono fare tutto ciò che vogliono? Potrebbero voler testare il loro codice / query sui prod perché non c'è un sostituto adatto. E se c'è un sostituto adatto, puoi cambiare le password per bloccarle? NESSUNO dovrebbe avere accesso al prodotto, eccetto per il personale di supporto prod.

Suppongo che il motivo più semplice sia: "Il server di produzione è un server PRODUCTION, non un server di prova, quindi smetti di testare il tuo lavoro di sviluppo su PROD!"

Penso che il tuo punto di vista sulle query che potrebbero avere un impatto negativo sulle prestazioni di produzione sia buono. Se non rispettano questo (e se non riesci a bloccarlo), allora questo è più un problema di autorità sul luogo di lavoro, e potrebbe valere la pena tenerlo a mente quando è il momento di rinnovare il contratto.

Se questi sono consulenti esterni, non dovresti avere per persuaderli.

Bloccali.

Se, come richiesto da un altro poster, non esiste un altro database di "test" che possono utilizzare, quindi disporre di una configurazione per loro, con i dati resi anonimi, se necessario.

Se hai davvero bisogno di un motivo per una persona non tecnica, digli che non vuoi che una persona non tecnica scriva potenzialmente domande inefficienti che potrebbero compromettere le prestazioni del tuo database e delle applicazioni circostanti.

Se sei una società quotata in borsa (o progetti di essere), è una violazione di Sarbanes- Oxley requisiti (in particolare, sezione 404) per gli sviluppatori di avere accesso diretto ai dati di produzione. Se gli utenti dispongono di accesso sufficiente per eseguire query selezionate, quasi certamente dispongono delle autorizzazioni per manomettere i dati.

Se hai dipendenti incompetenti o consulenti di cui non ci si può fidare a non eseguire un record di milioni di copie, unisciti a prod, quindi licenziateli.