Tales from the Machine Room


Home Page | Comments | Articles | Faq | Documents | Search | Archive | Tales from the Machine Room | Contribute | Login/Register

Rollback en

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

Previous Next

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.

24 messages this document does not accept new posts
Anonymous coward By Anonymous coward - posted 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 By Luca Bertoncello - posted 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 By Zomas - posted 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 By Anonymous Comrade - posted 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 By Carlo - posted 19/12/2011 09:17

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

--
--
Carlo


ringo By ringo - posted 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 By leonick - posted 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 By Anonymous coward - posted 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 By Lucazeo - posted 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 By lufo88 - posted 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 By Anonymous coward - posted 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 By Anonymous coward - posted 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 By Il codardo senza nome - posted 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 By Anonymous coward - posted 19/12/2011 13:28

Proceduralmente fantastico!

--
Anonymous coward


Anonymous Swiss Coward By Anonymous Swiss Coward - posted 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 By Macpi100 - posted 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 By Guido - posted 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 By Anonymous coward - posted 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 By Anonymous coward - posted 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 By Massimiliano - posted 20/12/2011 18:29

Queste storie mi fanno sempre piegare in due dalle risate.

Grande, auguri di buon Natale Big D.

--
Massimiliano


Alberto By Alberto - posted 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 By Anonymous coward - posted 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 By Anonymous coward - posted 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 By Rolando Francini - posted 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 messages this document does not accept new posts

Previous Next


This site is made by me with blood, sweat and gunpowder, if you want to republish or redistribute any part of it, please drop me (or the author of the article if is not me) a mail.


This site was composed with VIM, now is composed with VIM and the (in)famous CMS FdT.

This site isn't optimized for vision with any specific browser, nor it requires special fonts or resolution.
You're free to see it as you wish.

Web Interoperability Pleadge Support This Project
Powered By Gojira