Tales from the Machine Room

Primo commento: sono in ferie e non ho più sonno, per cui è giustificato spammare 2 minuti dopo la pubblicazione della storia.

Tornando alla storia, è bello vedere uno che ammette che sbaglia e ci mette una pezza.

Di solito chi più sbaglia, non ha assolutamente comprensione per gli errori (pur se infitamente meno gravi) altrui ed un bel badile gigante per sotterrare i propri. -- Melanippe

Dai la colpa a Bart che ti ha interrotto e fatto perdere il filo di cio che facevi,no?Ricorda , il gusto di lavorare in equipe e' che puoi dare la colpa agli altri!

-- Herr Franz

Il mio personalissimo metodo per cercare di evitare i momenti "Oh Ca$$o" quando lavoro su un db e' quello di fare sempre un backup del singolo DB prima di cominciare a fare qualunque tipo di operazione.

Ovviamente sempre NON include le volte in cui servirebbe (:-P) ed ovviamente ho una quantita' di backup parziali inimmaginabile! -- -Gas-

Quella del "momento "ohca$$o" è un'altra delle perle da incorniciare presenti in questo sito.

E chi dice che non gli è mai successo mente spudoratamente (e non solo in campo informatico)! -- Luca Menegotto

Ma usare le transazioni e quindi fare un bel rollback?

O il DB non le supporta?

Ciao! -- Mauro Viola

> Ma usare le transazioni e quindi fare un bel rollback?

O il DB non le supporta?

Evidentemente no, e la cosa mi lascia decisamente basito.

Da noi si usa Oracle, e il COMMIT e' un comando fondamentale, soprattutto nei casi come quello narrato, dove dopo una update effettuata troppo allegramente, il server risponde col messaggio:

548564 records updated

Mi rendo conto che e' da suicidio lavorare con un DB che non supporta COMMIT e ROLLBACK -- ringo

Mi fa piacere(*) vedere che non sono l'unico ad avere vissuto uno di questi momenti esaltanti.

Da allora UPDATE SET WHERE è sempre preceduto da SELECT COUNT(*) FROM WHERE e lo statement di update è rigorosamente ottenuto dalla modifica della select.

E datemi pure del paranoico.

(*)Ho scherzato. In realtà ovviamente non mi fa piacere. -- Davide

:)

vedo che non sono l'unico a cui capita... a me è capitato di scrivere l'update per intero (inclusa la where), ma siccome non voglio aprire 1000 finestre per gestire le 1000 query con le quali ho a che fare allo stesso tempo, scrivo tutto in una finestra e poi seleziono il testo da eseguire... indovina un po' quale parte mi era rimasta fuori dalla selezione?

Comunque quando si usano database che supportano le transazioni (e ci si ricorda di NON impostare il client in autocommit) c'e' sempre il magico "rollback"

-- Franz

Trattasi di una svista talmente banale e diffusa che alcuni client di database tentano di evitartela: mai sentito parlare di begin/commit/rollback transaction? (ovviamente si, se no vengo li a picchiarti). Non so che database usi tu, ma io a differenza di molti miei colleghi apprezzo la feature di 0r@cle+t0@d, che se non clicchi sul pulsante 'commit' non applica le modifiche: odio l'autocommit, e se posso lo disabilito.

Buon agosto, Big D.! -- leonick

> apprezzo la feature di 0r@cle+t0@d, che se non clicchi sul pulsante 'commit' non applica le modifiche: odio l'autocommit, e se posso lo disabilito.

Se fai TRUNCATE di una tabella non c'è commit e rollback che tenga... ero così stordito che ho letto più volte il nome della tabella e non era quello giusto... meno male che non era ancora in produzione e i dati erano solo fasulli

Ciao, buon agosto a tutti !

P.S.

Ma sono solo io che non vedo i feed RSS aggiornati ? per la cronaca li aggrego con la home page di google... -- Paolo

Un utente "alle prime armi" combina piccoli disastri, non sa quello che ha fatto e non sa correggere gli errori.

Un utente "evoluto" combina piccoli e grandi disastri, sa quasi sempre quello che ha fatto ed è in grado di nascondere i propri errori.

Un sistemista "junior" è in grado di fare molti più disastri, ma poi sa quello che ha fatto, sa come correggere alcuni errori e sa a chi chiedere di correggere gli errori che non sa correggere da solo.

Un sistemista "senior" fa pochissimi disastri, ma quando li fa sono grossi; sa come correggere gli errori e sa che, se non è in grado di correggerli, nessuno al mondo saprà farlo e così dovrà imparare/inventare un altro "trucco da sistemista senior". -- SIGLAZY

> Un utente "alle prime armi" combina piccoli disastri, non sa quello che ha fatto e non sa correggere gli errori.

[eccetera]

Questa definizione dei vari livelli di capacita` tecnica la trovo molto bella, me la salvo da qualche parte. -- Il massimo danno con il minimo sforzo

Penso che molte delle volte che si commettono errori (se non sei un homo brain-less) sono dovuti a qualcuno/qualcosa che ti disturba. -- "Unix IS user friendly. It's just selective about who its friend are"

> Penso che molte delle volte che si commettono errori (se non sei un homo brain-less) sono dovuti a qualcuno/qualcosa che ti disturba.

Concordo. E tipicamente quando sei li` che ti stai scervellando e rileggi 10 volte quello che hai scritto prima di dare ENTER, arriva il CL di turno e vedendo che non stai scrivendo, ma solo guardando il monitor, inizia: "scusa, visto che sei li` che non fai niente, io ho bisogno di yadda yadda yadda..." e ti rompe la concentrazione. Dopo che gli hai spaccato in testa la crimpatrice per gli RJ45, ti serve una mezz'ora per ricordarti dove eri arrivato.

E la produttivita` si inabissa.

-- Il massimo danno con il minimo sforzo

>arriva il CL di turno e vedendo che non stai scrivendo, ma solo guardando il >monitor, inizia: "scusa, visto che sei li` che non fai niente, io ho bisogno di >yadda yadda yadda..." e ti rompe la concentrazione.

Purtroppo capita più volte al giorno, i sysadmin dovrebbero girare armati e licenza di lartare -- - Simone

Un momento!Fermi tutti!Stavo rileggendomi le storie passate....non hai ancora pubblicato la foto del pinguino ninja di cui alla 4ta storia del 2008!!!!

Gravissimo!!! -- Herr Franz

il mio ultimo momento 'OhCa$$o' risale a 5 giorni fa...stavo lavorando sul mio ubuntu (per fortuna sul portatile quindi l'avevo a portata di mano) quando decido che il mio utente deve far parte del gruppo www-data

apro la shell, e dò "sudo usermod -G www-data davide"

ora, chi sa, ubuntu non ha l'account root abilitato, e (e questo ve lo dico io) il file dei "sudoers" è settato per dare quel privilegio non al singolo utente ma ai membri del gruppo admin.

mettere il relazione la notizia appena appresa, il comando dato e il concetto di reboot.

fatto? bene, ho dovuto prendere un cd di ubuntu 5, modificare il file /etc/sudoers includendo il mio utente, rebootare da hard-disk ed aspettare lunedi per arrivare in ufficio, installare in VM ubuntu e vedere che diavolo di gruppi sono assegnati di default ad un utente creato in fase di installazione.

(se ve lo state chiedendo, è capace che ci sia un metodo più semplice per sapere i gruppi...ma io non lo so) -- Noi esploriamo...e ci chiamate criminali...

Parole sante!

Aggiungerei anzi che

a) tipicamente il sysadmin si rende conto di avere appena avuto un momento "ohca$$o", mentre il CL no, continua a sbattere contro il "non funziona" come una mosca sul vetro

b) tipicamente il sysadmin è in grado di recuperare in autonomia dal proprio momento "ohca$$o", mentre il CL sbianca, bestemmia e si fionda a chiedere aiuto urgentissimo ad altri

c) la precedente è ovviamente l'ipotesi ottimistica, dato che tipicamente il CL dopo il proprio momento "ohca$$o" s-e-n-e-s-b-a-t-t-e e tenta di insabbiare il caso, riversando la colpa su altri.

Bud

-- BudSpencer

Ragassuoli, questo e' il foxxuto "cluster-che-non-e-un-cluster" di database contro cui ho lottato per mesi, che pensate?? -- Davide Bianchi

> Ragassuoli, questo e' il foxxuto "cluster-che-non-e-un-cluster" di database contro cui ho lottato per mesi, che pensate??

Che il bullshit level sia paurosamente vicino al "I'm Gonna kill someone who's not a Sysadmin".... -- Michele Montanari

> Ragassuoli, questo e' il foxxuto "cluster-che-non-e-un-cluster" di database contro cui ho lottato per mesi, che pensate??

Che l'engine dei database e` MyISAM. Brutta, bruttissima mossa, personalmente farei una conversione massiva delle tabelle in InnoDB (ovviamente prima testo tutto in un ambiente creato appositamente per l'occasione)

Enrico -- Enrico 'Henryx' Bianchi

Di dimenticare il where quando lancio un update.... sia lodato san Backup! -- Alberto

il backup e' mio amico...

il backup mi fa dormire sogni tranquilli!!!

;-) -- Daniele

L'ultimo OhCa$$o capitato a me è stato bannare con iptables il router da cui provenivano tutti i pacchetti nel server in co-location.

Sarebbe bastato un banale riavvio, peccato fossero le 23.00 di venerdì sera. Ergo mx principale di posta down per tutto il weekend! -- http://flaz.biz

> la differenza tra un CL ed un sysadmin e' che il sysadmin e' in grado di recuperare dal proprio momento "ohca$$o".

Da stampare a caratteri cubitali ed appenderla sopra il proprio monitor, a perenne monito e ricordo!

Saluti. -- E sono il cinquecentesimo...

Non lavori in una multinazionale americana.

Nella mia azienda, per un problema simile (cancellazione "accidentale" di un DB), fecero:

1. riunione per capire l'accaduto

2. riunione (con altre persone) per fare uno "studio di fattibilità".

3. riunione (con altre persone ancora) per studiare il piano di ripristino.

4. riunione per capire perché se il DB era stato cancellato, le cose continuavano a funzionare senza problemi.

Il punto 4 rimane ancora molto criptico, (quasi) nessuno riuscì a capire che cosa era successo.

La soluzione la sappiamo solo io ed un collega (quello che cancellò il DB). Quando i capi stavano predisponendo la sala riunioni per il punto UNO, 'erano due persone che anziché perdere tempo, fecero immediatamente un restore del DB.

La cancellazione fu eseguita alle tre del pomeriggio, la riunione UNO fu indetta per le sei (tre ore più tardi). Il nastro del restore finì di girare poco prima delle quattro. La riunione TRE venne indetta per le 10 della mattina seguente. La riunione QUATTRO per le cinque di sera, del giorno dopo.... -- Alex ARNZ

> Non lavori in una multinazionale americana.

Nella mia azienda, per un problema simile (cancellazione "accidentale" di un DB), fecero:

[eccetera]

MITICO! Se non era per voi, restavano senza database per un paio di giorni prima di arrivare finalmente a deliberare che (guarda un po`) occorreva ricaricarlo dal backup.

-- Il massimo danno con il minimo sforzo

> Non lavori in una multinazionale americana.

> Nella mia azienda, per un problema simile (cancellazione "accidentale" di un DB), fecero:

> 1. riunione per capire l'accaduto

> 2. riunione (con altre persone) per fare uno "studio di fattibilità".

> 3. riunione (con altre persone ancora) per studiare il piano di ripristino.

> 4. riunione per capire perché se il DB era stato cancellato, le cose continuavano a funzionare senza problemi.

>

> Il punto 4 rimane ancora molto criptico, (quasi) nessuno riuscì a capire che cosa era successo.

> La soluzione la sappiamo solo io ed un collega (quello che cancellò il DB). Quando i capi stavano predisponendo la sala riunioni per il punto UNO, 'erano due persone che anziché perdere tempo, fecero immediatamente un restore del DB.

>

> La cancellazione fu eseguita alle tre del pomeriggio, la riunione UNO fu indetta per le sei (tre ore più tardi). Il nastro del restore finì di girare poco prima delle quattro. La riunione TRE venne indetta per le 10 della mattina seguente. La riunione QUATTRO per le cinque di sera, del giorno dopo....

>

>

E poi si accorsero che il DB era quello che gestiva le prenotazioni della sala riunioni ? -- Anonymous coward

non e' un po' troppo "easy" lanciare script sulla prod senza testarli? qui ($NoiSalviamoTanteVite) funziona che chi lancia lo script e chi lo scrive sono due persone diverse, il primo non ha la responsabilita' di cio' che lo script fa, il secondo non ha accesso alla prod e deve fornire un comando non una lista di istruzioni. -- Anonymous coward

Certo che essere interrotti mentre si fa qualcosa di delicato è il miglior generatore di momenti "OhCa$$o". Ecco perché in questi casi telefono, cellulofono, email e chat restano in naftalina, e se posso maltratto anche chi si fa vedere di persona. E qualche volta decido di fare i lavori più delicati da casa per evitare il più possibile interruzioni.

Ed ovviamente, riesco lo stesso ad avere i miei bei momentini "OhCa$$o". Ma per lo meno faccio del mio meglio... -- Luca BG

ne sono passati di anni da quando ho smanettato l' ultima volta su un DBR...

quello che ricordo era che con il programma da mettere a punto erano parecchi gli interventi da fare sul server 0r@cl3 di prova per liberare i vari lock lasciati da una query che poi era stata interrotta da un baco

comunque grazie per la "risata" (eh si, quando ho letto che mancava il where... )

WM -- WM

Assolutamente la medesima proprio proprio. Fortunatamente erano solo 15 righe perché non potevo accedere a backup. Così mi sono dovuto mettere a riscriverle a mano... e visto che con la mia mossa avevo mandato in corto il sistema di notifiche di un applicativo mentre con una mano facevo update selvagge con l'altra spiegavo al telefono che "Devo controllare il problema, magari dipende da Outlook, sai, è probabile che l'applicativo abbia bisogno di una sistematina blah blah blah yaddayaddayadaa" -- Cymon

E questo e' il motivo per cui, per non sapere ne leggere ne scrivere ho iniziato a scrivere le query con LIMIT 1, poi HOME, e scrivo la query... Poi semmai levo il limit. -- St0rM

... Ho avuto un momento 'OhCa$$o' proprio stanotte quando, rincoglionito dal sonno, ho eliminato un vhd da 80Gb che conteneva il server di un cliente. Ok che il server non è più in produzione ma mi aspettavo una telefonata per le 08.00 di mattina in cui mi chiedevano di recuperare quell'importantissimo dato che non avevano esportato...

Mandato una mail alle 04.00 di mattina (capito perchè avevo sonno??) all'impiegata che si occupa di ruotare i supporti di backup e recuperato il file appena sveglio.

E nessuno si è accorto di nulla, per fortuna. -- frakka

Io se sto scrivendo qualcosa quando mi arrivano con "scusa hai un momento" et similia, faccio scattare l'automatismo "alzalamano'aspettaunmomento'", concludo quello che sto facendo, salvo e alzo lo sguardo sul/la questuante.

Ovvio che poi per rimettermi in carreggiata devo ricostruire che cattso stavo facendo e perche' cattso lo stavo facendo (lo sapete meglio di me come funziona), ma almeno non ho "parentesi aperte".

Ora che ci penso fa un po' adventure games ^_^;

CYA -- z f k

Mi e' successa ESATTAMENTE la stessa cosa in passato. Da allora quando scrivo una query di update o delete scrivo sempre prima la where condition, poi cosa aggiornare e solo dopo il semicolon. In modo da evitare altri momenti tipo quello! -- Joe

> Da allora quando scrivo una query di update..

Il senno di poi e' sempre una scienza esatta.

-- Davide Bianchi

appena successo...

cioe', successo ad aprile, ma me ne sono accorto or ora ravanando tra le varie risorse...

risolto senza che nessuno se ne accorgesse...

e non fatemi la menata uh, son passati 4 mesi senza che nessuno se ne accorgesse, ma perche' non hai lasciato come stava? il punto e' che io, come credo la maggior parte di tutti quelli che leggono queste storie, se finisco nel momento OhCa$$o, devo sistemare a prescindere...

comunque, e' proprio vero, la differenza tra un CL ed un sysadmin e' che il sysadmin e' in grado di recuperare dal proprio momento "ohca$$o".

--

---

BabboMatteo

Dall'unica volta che mi è successo su un db in produzione adesso scrivo prima il where, poi la parte di update/delete

Buone ferie a tutti -- Those who do not understand Unix are condemned to reinvent it, poorly.

-- Henry Spencer

Anche un CL sa come recuperare i dati di un momento del "oh,ca$$o".

Chiama il sysadmin e poi gli lascia fare il sacro bkup temepestandolo di "+ in fretta!+ in fretta!"(e nega di essere stato lui a causare il casino)! -- Herr Franz

E' solo questione di tempo... Dopo 100000 query di update la 100001 è Quella Devastante Senza Rimedio Alcuno. Come stare sulla faglia di S.Andreas.

Pertanto, da noi in $tantofiniamoallaneurolostesso.com, vige la regola della doppia chiave per armare i missili : uno scrive la query, l'altro la guarda, il primo preme il tasto NOreturn. E per ora ce la siamo cavata, anche se ogni volta sono sudori gelidi...

Ciao a tutti !

-- UsarePiediSePiediMeglioDITesta