Come posso ridurre al minimo il rischio di modificare accidentalmente il database errato?

Ho appena imparato che la disconnessione da un server in Esplora oggetti non ti impedisce in seguito di eseguire finestre di query già aperte su quel server.

La mia situazione è questa: ho un'istanza di SSMS che utilizzo per connettermi al nostro server di sviluppo / gestione temporanea e al nostro server di produzione. Ho dovuto eliminare un sacco di dati su dev, quindi ho pensato che avrei dovuto chiudere la mia connessione alla produzione, ma non ho prestato attenzione alla finestra della query che stavo usando. (Fortunatamente abbiamo avuto un backup di solo poche ore.)

Non sono la prima persona a distruggere i dati di produzione e non sarò l'ultimo, ne sono sicuro. Quindi sto cercando liste di controllo, migliori pratiche, ecc. Che ti aiutino a minimizzare il rischio di eseguire query sul database sbagliato. Ti è mai successo prima e come hai adattato il tuo flusso di lavoro per cercare di evitarlo?

Una cosa che mi piace fare in SSMS è utilizzare i colori personalizzati durante la connessione al database. Quindi scegli un bel rosso brillante per i database Live e un delicato blu o verde per i sistemi di sviluppo o test. Prima usavo SSMS integrato, ma in questi giorni preferisco la codifica a colori del componente aggiuntivo SSMS Tools.

O come questo per gli strumenti SSMS (un componente aggiuntivo davvero carino, e trovo il colore migliore quando è in alto, piuttosto che in basso come quello incorporato)

A seconda di chi chiedi, richiederà un po 'più di lavoro, ma ho preso l'abitudine di usare sempre l'istruzione seguente per tutte le finestre di query di produzione o pre-produzione, e per tutti UPDATE, DELETEe le INSERTdichiarazioni in tutti gli ambienti.

BEGIN TRAN
-- END OF QUERY WINDOWS
ROLLBACK TRAN
PRINT 'Transaction rolled back.'

Se vedo questo, saprò immediatamente, "Spiacenti, la finestra della query era ancora connessa" o "Oh merda, ho fatto automaticamente qualcosa che non avrei dovuto" - e sì, puoi chiudere il database in Esplora oggetti, ma un la finestra della query può ancora essere connessa. Nella mia mente, tutte le query di produzione dovrebbero essere evidenziate ed eseguite BEGIN TRAN; un F5 accidentale su tutto, dovrebbe riportare tutto indietro, no COMMIT. Ciò che fa è forzare l'utente ad essere consapevole delle proprie azioni; simile a scattare una foto di ogni pasto che mangi ti aiuterà a perdere peso perché devi fermarti e pensare a quello che stai facendo.

Ci vuole più tempo per fare? Sì. Ferma il 100% degli errori. Sì, perché nulla commette mai, a meno che non forzassi manualmente il COMMITpost, digitandolo, che la natura stessa mi ha costretto a considerare COMMIT.

Crea un secondo account utente per le modifiche di produzione e revoca l'accesso al tuo account attualmente. Quando vuoi fare cose in produzione puoi eseguire ssms come secondo utente.

EDIT: questo sarebbe utile solo nel caso di accessi al dominio. Se avessi due account di dominio separati, verrai costretto ad avere istanze separate di SSMS per DEV e PROD. Se non stai utilizzando account di dominio, questo suggerimento non ti aiuterebbe molto.

Inoltre, se si utilizzano account di dominio separati, è possibile regolare le impostazioni del colore SSMS per utente, magari con uno sfondo rosso brillante per l'account che si collega a PROD.

Ecco un buon white paper che mi è venuto in mente: http://download.microsoft.com/download/D/2/D/D2D931E9-B6B5-4E3B-B0AF-22C749F9BB7E/SQL_Server_Separation_of_Duties_White_Paper_Jul2011.docx

Discute cose come non dare al tuo account di accesso giornaliero pieno accesso SA.

Dai un'occhiata al mio componente aggiuntivo: SSMSBoost. Ha esattamente quello che ti serve. Ho migliorato la funzionalità di colorazione della barra di stato di SSMS in modo che segua il database corrente e cambi il colore. Inoltre è possibile aggiungere la descrizione comandi mobile "avviso DB importante":

Maggiori informazioni su questa funzione qui: http://www.ssmsboost.com/Features/ssms-add-in-preferred-connections

In uno dei miei lavori abbiamo sviluppato uno strumento per questo scopo.

Se volevi eseguire una dichiarazione su PROD, ti costringeva a scrivere:

run_sql servername PROD <file_with_sqlstatements>.sql

Scriverebbe i risultati in un file di registro e aggiungerebbe l'esecuzione in un registro nel nostro database di gestione. È stato molto utile, ad esempio, quando volevamo capire chi era l'ultima persona a cambiare un determinato tavolo.

In SSMS, quando si hanno server registrati, è possibile applicare un determinato colore a una connessione, in modo che ad esempio tutte le connessioni PROD abbiano un colore rosso nella parte inferiore. Ma è meglio evitare di usare gli strumenti della GUI su un server di produzione, se possibile.

Solo altri due consigli, dal momento che non vedo già nulla di simile qui:

1. Nel mio flusso di lavoro lavoro spesso con più istruzioni in una sola finestra e sono abbastanza abituato a selezionare-testo-quindi-eseguire il flusso. Ma ho sempre paura di premere accidentalmente F5 quando non viene selezionato alcun testo ed eseguire di conseguenza tutte le istruzioni in una finestra. Quindi ogni volta che apro una nuova finestra, comincio con la digitazione di qualunque immondizia che SQL rifiuterà di compilare. Ciò rende effettivamente non eseguibile l'intero batch. (Avvertenza! Se si utilizzano più lotti separati con, GOè necessario immondizia per lotto.)

2. Quando si effettuano modifiche ai dati sul server di produzione (o ogni volta che ho bisogno di estrema cura), le transazioni implicite sono molto utili ( SET IMPLICIT_TRANSACTIONS ONo si modifica un'opzione in SSMS in modo che l'opzione sia efficace per ogni nuova finestra). In questo modo ogni estratto conto che non è in transazione - avvia una nuova transazione. Mi impegno solo se mi assicuro due volte di aver fatto ciò che intendevo.

Prova a utilizzare un utente Windows separato, che è l' unico a cui è configurato il database di produzione. Imposta l'intero tema di colore di questo utente su rosso. Con una rapida commutazione dell'utente questo non dovrebbe essere un problema.

Non utilizzare mai le credenziali di produzione in un account che si trova su una macchina di sviluppo. Una breve telefonata o una domanda da collega e in seguito cancellerai felicemente tutto per il tuo nuovo test ...

Un'altra opzione (stessa idea) è l'utilizzo di un desktop remoto o di una macchina virtuale con un tema diverso.

Un altro modo piuttosto semplice per impedire l'esecuzione di tutto nella finestra della query quando si preme F5 sarebbe quello di circondare tutto il contenuto con / * e * / rendendo così l'intera cosa un commento.

Puoi comunque eseguire le istruzioni che desideri evidenziandole e premendo F5 nel solito modo, anche se sono racchiuse in un commento.

Nota: se si sceglie questo metodo, non si sarà in grado di beneficiare dell'evidenziazione della sintassi o del completamento automatico, ma se non si utilizzano queste funzionalità così tanto, potrebbe valerne la pena sacrificarle per assicurarsi che sia impossibile danneggiare al 100% il database con un F5 accidentale.

Modifica: inoltre non sarai in grado di usare / * * / ovunque all'interno della finestra della query, altrimenti inavvertitamente toglierai il commento al codice successivo. È necessario attenersi alla notazione invece.

In accordo con il commento di Swasheck sulla domanda originale, che ne dici di eseguire ...

seleziona @@ nomeserver + '\' + @@ nome servizio

... prima di eseguire qualsiasi DML, o anche guardare la barra di stato per vedere a quale istanza sei connesso, o persino eseguire tutto il DML in una transazione in modo da poter eseguire il rollback se ti rendi conto di aver fatto un errore? Molti ottimi suggerimenti qui, ma fondamentalmente, quando si tratta di DML potenzialmente distruttivo, i trucchi ti porteranno solo così lontano. Controllo sempre, ricontrollo e ricontrollo. E se ho a che fare con una piccola quantità di dati, potrei anche SELEZIONARE IN una nuova tabella prima del DML, eseguire il mio DML, fare alcuni confronti per accertarmi che le cose funzionino correttamente, quindi eliminare la tabella "backup". Lavora in modo più intelligente, non più difficile.