Qualche buon motivo per...

...lavorare il meno possibile in ambiente di produzione.

Se è vero che il miglior amico del DBA è il SQL Profiler, è anche vero che il DBA è costretto ad essere un buon amico del Management Studio, ...e come tale a conviverci nel migliore dei modi, sfruttandone le buone abitudini ed evitando come la peste quelle cattive. In particolare, in ambiente di produzione sono quest'ultime che mi interessano maggiormente.

E' risaputo che è buona abitudine NON modificare la struttura di tabelle usando il designer grafico poiché il comportamento del Management Studio è abbastanza radicale, tant'è che di default da qualche tempo è configurato per impedirlo a meno che proprio non ci si voglia fare male modificando l'opzione "Prevent saving changes that require table re-creation".

Tra le buone abitudini invece ci sono le combinazioni di tasti che velocizzano sensibilmente l'attività dei virtuosi del T-SQL. Per esempio, c'è una combinazione di tasti che probabilmente digito un centinaio di volte al giorno: CTRL+R. Per chi non la conoscesse, serve a far comparire/scomparire la finestra di risultati.

Lunedì scorso, per la prima volta in vita mia ho sbagliato la combinazione CRTL+R e mi è scappato l'indice sinistro sul tasto "E". Ne è uscito fuori un fantastico CTRL+E che mi ha eseguito lo script sul database ...di sviluppo (menomale!!!).Sempre lunedì mattina - ..che fantastica giornata il lunedì .. :) - un collega sviluppatore incappa in una di quelle svista che ti può valere la "testa": il Management Studio è aperto e nell'object explorer è connesso un istanza di SQL di Sviluppo, ma c'è anche una finestra di query aperta e connessa, ma al server di produzione! Peccato che lo sviluppatore crede che se nella barra di sx ha un nome di server, tutte le finestre di query aperte sono relative a quel server. Non è la prima volta che mi capita di assistere a questo fraintendimento.

Morale della favola, sarebbe bello poter disabilitare il CTRL+E dal Management Studio per evitare spiacevoli inconvenienti, ma visto che non si può (o almeno così credo), non resta che impedire al team di sviluppo la connessione al server di produzione (con la forza ovviamente, … non credo ci siano altri metodi con gli sviluppatori più incalliti.. e questo lo so bene perché anch’io in un certo qual modo ne faccio parte). Quando dico impedire, parlo semplicemente di subnet separate, opportune credenziali di accesso di sistema e di SQL Server. Dalla mia piccola esperienza questo è lo standard di fatto nelle grandi realtà, ma nelle piccole/medie è assoluta utopia nonostante gli altissimi rischi a cui si può andare incontro per banali distrazioni.

Come tutti i dba posso dire che “ne ho visto cose che voi umani …”, ed è pure inutile fingere di non esserne mai stati gli artefici, e poichè “errare è umano ma perseverare è diabolico “, da diverso tempo uso in produzione (previo test in ambiente diverso) un pattern di esecuzione query di UPDATE/DELETE a prova di “suicidio”:

BEGIN TRAN

  SELECT <righe interessate dall’update/delete>           
  SELECT @@ rowcount;           
 
  UPDATE/DELETE <righe interessate>           
  SELECT @@rowcount;            

  SELECT <righe interessate dall’update/delete>           
  SELECT @@ rowcount;

ROLLBACK TRAN

In tal modo, posso vedere coi miei occhi le modifiche che mi appresto ad apportare e verificare che le righe interessate siano effettivamente quelle attese confrontando i valori restituiti dai @@rowcount. Quindi se tutto quadra,  la ripeto sostituendo la ROLLBACK con la COMMIT.
E' un mondo difficile quello dei dati!