Storie dalla Sala Macchine


Home Page | Commenti | Articoli | Faq | Documenti | Ricerca | Archivio | Storie dalla Sala Macchine | Contribuire | Imposta lingua:en it | Login/Register


Rollback

I databases sono cose fantastiche. Consentono di organizzare i dati in entita' gestibili (chiamate 'records') ordinandoli, aggiungendoli, modificandoli eccetera ecceterandoli. Come tutte le cose belle ed utili pero', i database richiedono di essere usati in modo appropriato.

Se si cerca di usare un... qualsiasi cosa in effetti, in modo inappropriato non si otterra' il risultato desiderato ma si complichera' inutilmente la vita di tutti i coinvolti, in primis del SysAdmin che vi bestemmiera' dietro.

E' quello che ho pensato oggi, quando mi e' piovuta nella casella di posta una mail che parla di "rilascio" dell'applicazioen tal-de-tali nell'ambiente di test.

Il 'rilascio' consiste piu' o meno nella solita roba: copia di file .war, modifica di configurazioni ed una paccata di script .sql per aggiornare il database.

Uno in particolare di questi script ha attirato la mia attenzione:

delete from tabella1 where campo=valore;
delete from tabella2 where campo=valore;
delete from tabella3 where campo=valore;
delete from tabella4 where campo=valore;
delete from tabella5 where campo=valore;

Un rapido (si fa per dire) controllo mi ha detto che tabella1 contiene 18 milioni di records (diciottomilioni) di cui 17.9 milioni corrispondono a quella clausola 'where'... taccio sulle altre tabelle il cui contenuto e' simile.

Immediatamente e' partita una mia mail che diceva piu' o meno "ma se dobbiamo rimuovere il 99% dei records di una tabella, non facciamo prima a fare una copia dei dati che NON DEVONO essere rimossi, truncate della tabella e poi fare un restore dei dati salvati prima?"

Il programmatroto in oggetto ha blaterato di 'coerenza dei dati' ed altre cose varie, il discorso era abbastanza vacuo e lacunoso ed a me ha dato la netta impressione di qualcuno che non sa che differenza operativa ci sia tra una TRUNCATE ed una DELETE. Soprattutto quando ci sono di mezzo 18 milioni e passa di records ed un database con le transazioni.

L'ho detto che era venerdi' pomeriggio alle 16.30? Se non l'ho detto era sufficientemente sottinteso?

Comunque sia, io ho lanciato (in screen) lo script. Dopo un paio d'ore, comunicato a chi di dovere che lo script stava ancora girando ed io non avevo la piu' pallida idea di quanto ci avrebbe messo, me ne sono andato a casa. Durante il fine-settimana ho dato un'occhiata di tanto in tanto a come stavano andando le cose. Lo script era sempre fermo al suo 'delete'.

79 ore dopo, lunedi', mi arriva la telefonata del 'responsabile it' (CL) della situazione.

CL - Noi avevamo richiesto un rilascio venerdi' scorso. Non abbiamo piu' saputo nulla.
IO - Il vostro rilascio richiedeva l'esecuzione di una serie di script di aggiornamento del database, uno di questi sta ancora girando. Avevo fatto presente venerdi' che lo script era fatto in modo... diciamo sub-ottimale... ed avrebbe richiesto del tempo per essere eseguito.
CL - Ma e' da venerdi' che noi non possiamo fare niente!
IO - Non e' che io possa farci molto: il database non lo posso di certo velocizzare.

Dopo un po' di geremiadi il CL decide di riportare il problema al suo programmatroto. Il quale finisce con il mandare una mail (in CC a me) che dice piu' o meno che la cosa migliore da fare e' di rifare lo script in modo "ottimizzato". Come ottimizzazione lui suggerisce di... copiare i records da non cancellare in una tabella temporanea, eseguire una 'truncate' della tabelle e... insomma la stessa identica cosa che io avevo suggerito a lui prima di eseguire questa query.

Ovviamente, quello che il programmatroto non ha preso in considerazione e' che interrompere adesso la query vuole dire eseguire un rollback dell'intera operazione, rollback che, probabilmente, ci mettera' lo stesso identico tempo che ci ha messo fino ad ora.

Come dicevo: se non si capisce come usare uno strumento si puo' stare certi che lo si usera' molto, ma molto male.

Davide
19/12/2011 08:00

Precedente Successivo

I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.

24 messaggi this document does not accept new posts

Anonymous coward

Di Anonymous coward postato il 19/12/2011 08:46

L'importante e' avere SEMPRE TUTTO scritto via mail, con i vari "ma siete sicuri?" ed i relativi "si, siamo sicuri, fate come diciamo noi perche' noi siamo quelli che pagano, in modo tale da pararsi il sedere quando vengono con "ma qui non funziona un caiser" potendo cosi rispondere "noi ve lo avevamo detto, voi avete insistito".

Non so voi, ma io mi sono stufato di lavorare nel reparto "sistemiamo per un pugno di lenticchie i casini stellari che avete creato con la vostra incompentenza/iniettitudine/sordita'_agli_avvertimenti/mancanza_di_pianificazione/etcetc"

-- Anonymous coward

Luca Bertoncello

Di Luca Bertoncello postato il 19/12/2011 08:49

Anche questa e' "magia nera"... :\)
Che dire invece di quelli che "inseriscono tutto nel DB senza controlli, che tanto quelli li faccio con PHP"?
Quanti ne conosco, di quelli... E quante volte mi capita di vedere records n-plicati nel DB... -- Luca Bertoncello

Zomas

Di Zomas postato il 19/12/2011 09:06

Più o meno come mi accadde in una precedente azienda: solo che, a differenza tua, me ne usci con un "come ti avevo detto di procedere io..."

...



Ti ho detto che ho cambiato lavoro?...

-- Zomas

Anonymous Comrade

Di Anonymous Comrade postato il 19/12/2011 09:06

Let it roll, baby, roll

Let it roll, baby, roll

Let it roll, baby, roll

Let it roll, all night long

[The BackDoors: Datawarehouse Blues]

-- Anonymous Comrade

Carlo

Di Carlo postato il 19/12/2011 09:17

Pensa positivo: magari ha imparato la lezione e la prossima volta non lo fa piu'..........indecision

-- --
Carlo

ringo

Di ringo postato il 19/12/2011 09:33

Vogliamo parlare del comando PREPARE da inserire prima di una query parametrica che deve essere ripetuta decinaia di migliaia di volte?

 

Cos'è? Mi dice il programmatroto?

Lasciamo perdere, rispondo io.

 

L'ho detto che la query °parametrica° era una cosa del tipo

q="UPDATE CAMPO SET VALORE=" + valore + " WHERE ID=" + id

sql.execute q;

o era sottinteso?

 

-- ringo

leonick

Di leonick postato il 19/12/2011 10:14

Ma è straordinario: un programmatroto TI HA CAPITO, decidendo di seguire il tuo consiglio! surprise

Mi aspettavo che si lamentasse che il db server è lento... bisogna festeggiare: forse l'umanità ha ancora qualche speranza di sopravvivenza, dopotuttowink

-- leonick

Anonymous coward

Di Anonymous coward postato il 19/12/2011 11:20

> L'ho detto che era venerdi' pomeriggio alle 16.30?

> Dopo un paio d'ore,

>79 ore dopo, lunedi', mi arriva la telefonata del 'responsabile it' (CL) della situazione.

La Terra ha giorni di circa 24 ore. Ora, 3 giorni sono 72 ore, per cui se lo script e' partito alle 16.30 di venerdi e' la telefonata arriva 79 ore dopo, ci troviamo alle 16.30+(79-72) = 23.30 di lunedi' sera, se poi contiamo pure il Dopo un paio d'ore  arriviamo alle 1.30 del martedi.

Se i numeri ed i conti sono giusti, allora capisco perche' al lavoro sei sull'incazzato stabile.

-- Anonymous coward

Lucazeo

Di Lucazeo postato il 19/12/2011 11:22

Il problema del progammatore è fondamentalmente il seguente: non potrebbe fare una truncate su una tabella che viene referenziata da una chiave esterna (questo è vero per SQL server, non so se era il caso).

In questi casi si fa comunque una truncate, facendo prima un DROP dei vincoli e ricreandoli dopo, ma questo significa mettersi a fare le cose con cognizione :-\)

Sono commosso che abbia utilizzato delle chiavi esterne (se è vero che lo ha fatto), spesso il db viene utilizzato.. quasi come un file di testo.

-- Lucazeo

lufo88

Di lufo88 postato il 19/12/2011 11:47

Dopo aver fatto uno stage presso $azienda_italiana dove ho sviluppato un'interfaccia per ricavare i risultati degli explain su tre DB diversi, ho capito anch'io che i DB sono maltrattati. Per capirsi la prima query che ho testato era una frase SQL lunga circa 40 righe, con almeno 4 subquery, senza contare i LEFT OUTER JOIN utilizzati come se non esistesse altro. Il piano di esecuzione era composto da circa 70 operazioni di cui la maggior parte erano scan su tabelle di circa 30.000 record senza alcuna indice! Inutile dire che il DB di produzione conteneva minimo un milione di record per tabella. Poi si lamentano che il server e' lento!

-- lufo88

Anonymous coward

Di Anonymous coward postato il 19/12/2011 12:54

Beh, se hanno fatto le cose 'più o meno' come andavano fatte, i record cancellati andavano COMUNQUE cancellati, quindi puoi killare lo script senza problemi e passare il nuovo script 'giusto', no?

O, come è probabile parlando di programmatroti, gli altri script lavoravano sulle stesse tabelle e sugli altri valori? =p

-- Anonymous coward

Anonymous coward

Di Anonymous coward postato il 19/12/2011 12:56

"Il programmatroto in oggetto ha blaterato di 'coerenza dei dati' ed altre cose varie," sì, perché probabilmente per eseguire la truncate deve disabilitare un po' di constraint e poi riabilitarli, senza contare il dover creare le tabelle temporanee e poi eliminarle... e questo richiede più lavoro. Tanto lui l'ha provato sulla sua tabella di test con 6 record e lì funziona benissimo.

Ed in genere in situazioni di questo tipo la lotta fra la pigrizia del programmatore e quella del sistemista o DBA (si incontra anche questa "ah, ma questo aggiornamento richiede la patch xyz? Non l'abbiamo installata" "Ma era la Critiical Patch Update di gennaio!" "eh sì, ma noi non le installiamo, la rana, la fava, ecc. ecc.")

-- Anonymous coward

Il codardo senza nome

Di Il codardo senza nome postato il 19/12/2011 13:10

Certo è come quando il vicino di casa prende un martello demolitore elettrico formato godzilla e si mette a staccare piastrelle del pavimento. Martella per 3 gg di fila dalle ore 8.00 alle ore 19.00 e ad un certo punto incontra casualemente un tubo dell'acqua condominale.. non esiste un roll-back in quel caso vero ? .. sgrunt :\(

-- Il codardo senza nome

Anonymous coward

Di Anonymous coward postato il 19/12/2011 13:28

Proceduralmente fantastico!

-- Anonymous coward

Anonymous Swiss Coward

Di Anonymous Swiss Coward postato il 19/12/2011 14:14

Il problema è che i programmatori ormai vedono i database come una commodity qualunque. Se uno si mette oggi a sbirciare le query che girano in server di produzione c'è da spaventarsi, spesso si trovano stored procedure e query varie che nemmeno usano le variabili bind. :/

Tanto ci pensano i core e le san con fibra...

-- Anonymous Swiss Coward

Macpi100

Di Macpi100 postato il 19/12/2011 15:32

Beh, se vuoi i miei 2 cent, una volta mi è stato chiesto se non fosse possibile utilizzare una TRUNCATE [..] WHERE.. 

lascio a te ogni commento..

-- Macpi100

Guido

Di Guido postato il 19/12/2011 21:37

Davide, grazie che ci sei te che ci fai sorridere perchè è periodaccio per chi cerca lavoro...

salut ;\)

-- Guido

Anonymous coward

Di Anonymous coward postato il 20/12/2011 12:50

L'unica spiegazione per usare il delete, potrebbe essere che si voglia essere sicuri che non venga violata qualche constraint. Pero' se ci sono dei constraint, a maggior ragione la delete sara' piu' lenta, visto che per ogni record dovra' controllare che non ci siano constraint coinvolti, in pratica una select ulteriore per ogni contraint coinvolto.

Ma almeno mi aspetto che mettano un bel commit ogni tot record.  Giusto per non intasare il db con un unica transazione da 18 milioni di record.

-- Anonymous coward

Anonymous coward

@ Anonymous coward Di Anonymous coward postato il 22/12/2011 22:16

"L'unica spiegazione per usare il delete, potrebbe essere che si voglia essere sicuri che non venga violata qualche constraint. Pero' se ci sono dei constraint, "

Se crei una tabella temporanea con gli stessi constraint, copi lì i record da non eliminare, svuoti la tabella originale in un colpo solo e poi ricopi i dati (o droppi la tabella e rinomini la temporanea) sei comunque sicuro che non venga violato alcun constraint. In più lo spazio occupato dalla tabella non sembra una forma di gruviera con i record superstiti sparpagliati per tutto lo spazio occupato prima, cosa che può richiedere una riorganizzazione della tabella o le prestazioni possono anche andare a ramengo in caso ti table scan.

"Ma almeno mi aspetto che mettano un bel commit ogni tot record. "

Okkio che se lo fai troppo spesso la lentezza potrebbe pure aumentare, un commit è un commit e richiede un'ulteriore serie di operazioni.

 

-- Anonymous coward

Massimiliano

Di Massimiliano postato il 20/12/2011 18:29

Queste storie mi fanno sempre piegare in due dalle risate.

Grande, auguri di buon Natale Big D.

-- Massimiliano

Alberto

Di Alberto postato il 21/12/2011 01:39

e che chissà che progettone se zappano via il 90% dei dati...

Tienili stretti questi personaggi perché ci rendono la vita allegra.

-- zioniccio

Anonymous coward

@ Alberto Di Anonymous coward postato il 21/12/2011 21:13

 

>e che chissà che progettone se zappano via il 90% dei dati...

 

Non sono tanti...se consideri che i dati inutili o errati ( con  un programmatroto cosi' ) saranno il 100% .

Il bello verra' quando ( dopo il commit ) si accorgeranno che il database non va piu' e vi chiederanno di ripristinarlo tutto da zero ( magari dimenticarndosi di aggiornare qualcosa di strettamente collegato al db e....badabum!)

 

-- Anonymous coward

Anonymous coward

@ Alberto Di Anonymous coward postato il 24/12/2011 16:43

un numero simile di dati penso sia un'importazione da fonte esterna. Il beota che ha fatto, ne ha reimportarti un po per i suoi test e poi ha detto "per far prima" questi li ho gia' non li riprendo........

e che chissà che progettone se zappano via il 90% dei dati...

Tienili stretti questi personaggi perché ci rendono la vita allegra.

 

-- Anonymous coward

Rolando Francini

Di Rolando Francini postato il 24/12/2011 11:06

Faccio parte dei lettori "passivi", rompo il silenzio per augurare a Davide e a tutti i frequentatori, un felice Natale!

-- -liftman-

24 messaggi this document does not accept new posts

Precedente Successivo


Il presente sito e' frutto del sudore della mia fronte (e delle mie dita), se siete interessati a ripubblicare uno degli articoli, documenti o qualunque altra cosa presente in questo sito per cortesia datemene comunicazione (o all'autore dell'articolo se non sono io), cosi' il giorno che faccio delle aggiunte potro' avvisarvi e magari mandarvi il testo aggiornato.


Questo sito era composto con VIM, ora e' composto con VIM ed il famosissimo CMS FdT.

Questo sito non e' ottimizzato per la visione con nessun browser particolare, ne' richiede l'uso di font particolari o risoluzioni speciali. Siete liberi di vederlo come vi pare e piace, o come disse qualcuno: "Finalmente uno dei POCHI siti che ancora funzionano con IE5 dentro Windows 3.1".

Web Interoperability Pleadge Support This Project
Powered By Gojira