Comments are added when and more important if I have the time to review them and after removing Spam, Crap, Phishing and the like. So don't hold your breath. And if your comment doesn't appear, is probably becuase it wasn't worth it.
41 messages this document does not accept new posts
buon lunedì By Melanippe posted 03/08/2009 08:06
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
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
Beh.... By Herr Franz posted 03/08/2009 08:34
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
-- Herr Franz
Strategie anti "momenti oh ca$$o" By Gas posted 03/08/2009 08:46
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-
Ovviamente sempre NON include le volte in cui servirebbe (:-P) ed ovviamente ho una quantita' di backup parziali inimmaginabile! -- -Gas-
Grazie, Davide! By Luca Menegotto posted 03/08/2009 08:56
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
E chi dice che non gli è mai successo mente spudoratamente (e non solo in campo informatico)! -- Luca Menegotto
ehm.... By Mauro Viola posted 03/08/2009 09:08
Ma usare le transazioni e quindi fare un bel rollback?
O il DB non le supporta?
Ciao! -- Mauro Viola
O il DB non le supporta?
Ciao! -- Mauro Viola
@ Mauro Viola By ringo posted 03/08/2009 10:42
> 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
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
Attimi di terrore By Davide posted 03/08/2009 09:14
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
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
commit e rollback By Franz posted 03/08/2009 09:21
:)
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
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
E' un momento 'OhCa$$o' molto comune... By leonick posted 03/08/2009 09:50
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
Buon agosto, Big D.!
--
leonick
@ leonick By Paolo posted 03/08/2009 12:27
> 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
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
Differenze tra utenti e sistemisti. By SIGLAZY posted 03/08/2009 10:01
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 "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
@ SIGLAZY By Kurgan posted 03/08/2009 11:37
> 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
[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
distrazioni By Eugenio Dorigati posted 03/08/2009 10:19
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"
@ Eugenio Dorigati By Kurgan posted 03/08/2009 11:40
> 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
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
@ Kurgan By Simone posted 03/08/2009 12:02
>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
Purtroppo capita più volte al giorno, i sysadmin dovrebbero girare armati e licenza di lartare -- - Simone
Alt! By Herr Franz posted 03/08/2009 10:45
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
Gravissimo!!! -- Herr Franz
capita a tutti By argaar posted 03/08/2009 10:50
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...
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...
Differenza CL/sysadmin By BudSpencer posted 03/08/2009 11:07
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
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
per tutti "Commit" e "Transazioni" By Davide Bianchi posted 03/08/2009 11:17
Ragassuoli, questo e' il foxxuto "cluster-che-non-e-un-cluster" di database contro cui ho lottato per mesi, che pensate??
--
Davide Bianchi
@ Davide Bianchi By Michele Montanari posted 03/08/2009 12:06
> 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
Che il bullshit level sia paurosamente vicino al "I'm Gonna kill someone who's not a Sysadmin".... -- Michele Montanari
@ Davide Bianchi By Enrico 'Henryx' Bianchi posted 08/08/2009 13:46
> 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
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
Succede spesso ancha a me... By Alberto posted 03/08/2009 11:46
Di dimenticare il where quando lancio un update.... sia lodato san Backup!
--
Alberto
Il backup e' buono... By Daniele posted 03/08/2009 13:47
il backup e' mio amico...
il backup mi fa dormire sogni tranquilli!!!
;-) -- Daniele
il backup mi fa dormire sogni tranquilli!!!
;-) -- Daniele
Succede a tutti By Flaz posted 03/08/2009 14:08
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
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
Un'altra frase storica By BigFab posted 03/08/2009 15:34
> 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...
Da stampare a caratteri cubitali ed appenderla sopra il proprio monitor, a perenne monito e ricordo!
Saluti. -- E sono il cinquecentesimo...
Si vede che... By Alex ARNZ posted 03/08/2009 16:30
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
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
@ Alex ARNZ By Kurgan posted 03/08/2009 19:37
> 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
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
@ Alex ARNZ By Anonymous coward posted 04/09/2009 14:32
> 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
> 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
in ogni caso By Anonymous coward posted 03/08/2009 16:49
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
Ci scusiamo per l'interruzione By Luca BG posted 03/08/2009 18:08
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
Ed ovviamente, riesco lo stesso ad avere i miei bei momentini "OhCa$$o". Ma per lo meno faccio del mio meglio... -- Luca BG
quanti bei ricordi... By WM posted 03/08/2009 23:39
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
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
Fatto la stessa cosa By Cymon posted 04/08/2009 00:00
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
LIMITati... By St0rM posted 04/08/2009 00:38
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
Che coincidenza... By frakka posted 04/08/2009 03:11
... 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
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
codus interruptus By z f k posted 04/08/2009 09:45
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
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
Identico... By Joe posted 04/08/2009 17:56
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
@ Joe By Davide Bianchi posted 04/08/2009 18:33
> Da allora quando scrivo una query di update..
Il senno di poi e' sempre una scienza esatta.
-- Davide Bianchi
Il senno di poi e' sempre una scienza esatta.
-- Davide Bianchi
oh perdindirindina!!! By Matteo Jurman posted 06/08/2009 16:58
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
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
Meno male che non sono l'unico :D By Motosauro posted 07/08/2009 23:41
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
Buone ferie a tutti -- Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer
Beh,.... By Herr Franz posted 08/08/2009 07:51
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
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
Terrore dall'update profondo... By UsarePiediSePiediMeglioDITesta posted 16/09/2009 00:25
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
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
