Performance Tuning e Deframmentazione

giovedì 9 agosto 2007 alle 09:48 | Pubblicato su Performance Tuning | 18 commenti

Della serie “non si può mai dire” la mia ultima esperienza “scioccante” è stata la risoluzione di un problema di prestazioni sull’esecuzione di una procedura batch sul database di un nostro cliente. La risoluzione si è avuta dopo l’operazione di “export/import” di alcune tabelle interessate dall’elaborazione della procedura.

Spiego la storia dall’inizio. Presso un nostro cliente viene eseguita due o tre volta all’anno una procedura di aggiornamento delle anagrafiche che parte da un file di dati esterno (un file Access). L’esecuzione di questa procedura ha subito col passare del tempo tempo un degrado delle prestazioni che erano diventate inaccettabili (impiegava oltre 24 ore). Io (con una po’ di disappunto, ma neanche tanto) non sono mai stato coinvolto nell’analisi di questo problema di prestazioni, so che si è prima cercato di modificare la procedura (procedura Java esterna), poi di cancellare un po’ di dati obsoleti. Ad un certo punto sono piovute dal programmatore che ha sviluppato e aggiornato la procedure due proposte per la risoluzione del problema: un potenziamento dell’hardware o un “rebuild” di alcune tabelle e indici.

La mia formazione, la mia stima per asktom.oracle.com e tutta letteratura sul “performance tuning” di Oracle (che non risalga al paleolitico) mi hanno fatto un po’ rivoltare lo stomaco all’udire tali proposte. Il pensiero, formato dalla sintesi di tutto quanto ho letto al riguardo e delle mie esperienze, è che tali rimedi nella maggior parte sono solo palliativi che a lungo termine non risolvono i problemi. Ciò che qualunque esperto, a partire da Thomas Kyte, passando per Jonathan Lewis, per Connor McDonald, Cary Millsap, Mogens Nørgaard (per citare quelli più famosi) dice sempre è che la maggior parte dei problemi di prestazioni deriva da un cattivo progetto iniziale. Questo vale sicuramente per i grossi progetti, forse però per quelli meno grossi vi sono delle eccezioni. In un’ottica di medio termine si può risolvere problemi di prestazioni con rimedi che sulla carta sono solo palliativi.

Quindi vi è stata una prima riunione in cui si è stabilito di proporre al cliente un’aggiornamento dell’architettura, passando da un database singola istanza ad un cluster a due nodi (questo anche per poter gestire la mole di dati aumentata di molto). Nel frattempo però i mesi sono passati, la proposta e rimasta ferma e si è passati a prendere in esame la seconda alternativa: la deframmentazione delle tabelle e degli indici. Per quanto riguarda gli indici mi sono fatto forte delle discussioni di Tom (ad esempio si veda qui: asktom.oracle.com ) ed ho cercato di spiegare che a breve termine la situazione poteva ritornare come prima (senza contare che in caso di update di colonne indicizzate Oracle deve fare un lavoro extra per mantenere bilanciati gli alberi su cui si basano gli indici). Per quanto riguarda le tabelle sarei stato quasi pronto a scommettere che l’operazione sarebbe stata ininfluente, ma essendo io una persona aperta ho valutato che l’unico modo per smentire o conferamare l’utilità dell’operazione era provare. Un caso simile, in cui il cliente ci ha imposto di provare tale operazione, aveva mostrato l’inutilità dell’operazione.

Allora ho fatto un primo test, in effetti, dovuto al fatto che una parte dei dati era stata cancellata l’operazione riduceva di circa il 40% l’occupazione di spazio delle tabelle. Con un conto ingenuo mi aspettavo al massimo un raddoppio della velocità. Invece gia un full scan sulle tabelle impiegava un terzo del tempo. In effetti, quello che accade su un sistema sotto un elevato carico è difficile da analizzare.

Ho quindi proceduto ad eseguire l’operazione nella giornata prestabilita (concordata con il cliente per poter lavorare a sistema fermo). Per non dar luogo a recriminazioni ho provveduto a reimportare le tabelle segnalate su una tablespace separata (tabelle da una parte indici da un’altra come sui vecchi manuali in base ai quali a quanto pare non esisteva la tecnologia RAID). Cosa, sempre sulla carta, poco rilevante, trattandosi di Tablespace Locally Managed con datafile su RAID 5 (HIIIII!!! baarf).

Completata l’operazione il programmatore ha svolto un suo test ed ha comunicato che la procedura, su un blocco dati di campione è passata da 10 minuti a 2 minuti, quindi un quinto. Ovviamente sono rimasto sbalordito, ma rimango sempre perplesso e aspetto lungo il fiume la prossima esecuzione completa della procedura. Nel frattempo metto nel mio sacco questa esperienza.

18 commenti »

RSS feed for comments on this post. TrackBack URI

  1. Ciao, guarda anch’io ho avuto la stessa sorpresa.
    Sembrano dei palliativi e sicuramente potrebbero esserlo ma sta di fatto che qualche volta i “vecchi” metodi funzionano in barba ai vari guru che rinnegano questa procedura. Ogni database è fine a stesso e ciò che potrebbe non funzionare su alcuni potrebbero funzionare su tanti.
    Complimenti per il blog…
    Ciao
    Alberto Frosi

  2. senza un test case riproducibile la cosa rimane un pò fine a se stessa, di fatto bisognerebbe vedere ed analizzare diverse cose quali ad esmpio le statistiche (non so perchè ma mi suona come di un problema di errato clustering factor)ed i piani di esecuzione

    Alessandro

  3. In effetti è vero che senza un test case la cosa rimane fine a se stessa però c’è anche da dire che non sempre è possibile farlo quindi il dubbio è sempre in agguato. Sicuramente i piani hanno inciso ma come si potrebbe fare in questo caso in termini di tempo a risolvere questo problema? Sicuramente fare la prova + banale che era proprio questa.
    Alberto Frosi

  4. scusami ma non mi trovi d’accordo, personalmente salvo sempre le statistiche prima di riprenderne di nuove in modo che, se c’è qualcosa che non va in questo senso, per mantenere la user satisfaction ci rimetto le vecchie in maniera tale da darmi un po di tempo per le analisi da mettere in campo

    Alessandro

  5. La “vera” verità è che a chi comanda (almeno qui da me) interessano i risultati a breve termine. Quindi il fatto che con questa manovra il problema sia al momento “risolto” per loro è sufficente. Per quanto mi riguarda non sono soddisfatto perchè a me piace andare a fondo sui problemi, capirne le cause e porre rimedi definitivi. Non mi piace la filosofia che vige su Windows: “riavvia e vedi se funziona”, però spesso funziona e per molti è sufficente.
    Il caso che ho descritto è un po’ complicato, in realtà sulle nostre installazioni di Oracle 9i l’applicazione lavora con l’ottimizzatore RULE, in sostanza non calcoliamo le statistiche. Quindi è possibile che vi fosse un problema con il clustering factor, ma questo non incide sulle scelte dell’ottimizzatore (che non conosce quale sia il clustering factor) ma sulle prestazioni per via del maggior lavoro sui dischi. Per quanto riguarda il test case questo dovrebbe essere proprio la procedura lanciata dallo sviluppatore. Il problema è che per avere tutti i dati avrei anche dovuto aver a disposizione alcuni snapshot catturati con statspack durante l’esecuzione della procedura, prima e dopo la “deframmentazione”. Purtroppo non sono stato coinvolto prima nel problema e non mi è stato permesso di fare tale raccolta dati. Sicuramente i report di Statspack ci avrebbero dato un sacco di informazioni interessanti.

  6. è vermente raro che un indice b*tree abbia necessità di una rebuild e nel clustering_factor spesso molti pensano che sia una statistica riferita all’indice ma in realtà ti dice quanto i dati della tabella sono ordinati rispetto all’indice, cioè in parole povere con un clustering_factor errato è la tabella che andrebbe ricostruita e riordinata e non l’indice, in questo caso l’indice lo ricrei solo perchè con la rebuild della tabella viene posto ad uno stato unusable ma ciò non cambia la sostanza delle cose però anche perchè ti accorgerai che la situazione presto o tardi si riverificherà nuovamente (da qui la definizione di palliativo perchè in sostanza non stai andando al nocciolo della questione ma ci stai girando attorno);

    Alessandro

  7. Alessandro,
    trovo molto saggia la tua regola di salvare le statistiche. Personalmente trovo che gestire e mantenere un database con ottimizzatore in modalità COST sia una cosa molto difficile, personalmente mi ha dato molti grattacapi.

  8. Ciao Cristian,
    pensa però se avessi a che fare con tabelle ed indici di dimensioni notevolissime su db 24/7 allora in quei casi non basta una soluzione ma deve anche essere possibilmente la migliore possibile;
    ok col RULE la cosa è diversa perchè devi vedere la situazione in funzione delle famose golden rules dell’RBO che sono circa una ventina e alcune ti assicuro davvero bizzarre😉 , e li le cose andrebbero analizzate in maniera un pò differente anche se i piani comunque rivestono una grande importanza

    Alessandro

  9. Alessandro,
    confesso che in realtà io avrei preferito essere coinvolto maggiormente nell’analisi della procedura. Rimango convinto anche io che si tratti di un palliativo ma vale sempre la regola: “risultati a breve termine” quindi è probabile che passino altri due anni prima che il problema si ripresenti, allora ci si sarà dimenticati e si parlerà di sostituire l’hardware. Tutto ciò è frustrante per la mia volontà di sviscerare e risolvere i problemi ma è la triste realtà.

  10. Guarda sul CBO non credere, effettivamente finchè non lo padroneggi (per quanto possibile ovviamente) hai la senzazione che la cosa sia più difficile (e ti assicuro che chi + chi meno ci siamo passati tutti) ma dopo ti accorgerai che è esattamente il contrario, hai molte + opportunità da mettere in campo

    dimenticavo, in generale se proprio vuoi ti consiglio una coalesce dell’indice piuttosto che una rebuild, meno dispendiosa in termini di utilizzo di risorse e meno invasiva😉

    Alessandro

  11. Ciao anch’io penso che salvarsi le statistiche sia una operazione molto saggia , anch’io non condivido la tecnica tipo Windows “spegni e riaccendi” e tutto va bene però bisogna anche condividere i risultati che l’azienda vuole ottenere e quindi meno tempo di risoluzione = + benefici.
    Andava fatta un’analisi più approfondita ma è andata così. Il CBO va padroneggiato a dovere altrimenti si rischiano di fare dei casini…però piano piano si cerca di apprendere il + possibile.
    Alberto Frosi

  12. vi consiglio un documento, se già non lo avete, sugli indici B*TREE che è vermente ben fatto, corretto serio corredato di test case riproducibili, da leggere sino in fondo

    http://www.miracleas.dk/images/upload/Docs/Richard%20Foote.pdf

    Alessandro

  13. Grazie Alessandro,
    un documento interssante, in realtà lo avevo nel mio catalogo ma non lo avevo mai letto con attenzione, ora lo leggerò bene. Bellissima la sezione “Expert” quotes regarding Indexes con in prima posizione l’ormai mitico Don Burleson, che a quanto pare per il bene di tutta la comunità Oracle pare abbia oscurato il suo sito… forse è partito per la crocera🙂 o forse ha capito il messaggio di Doug Burns

  14. già, anche io ho avuto modo di dibattere con lui diverse volte…

    E’ possibile che la lettura di quel documento sia in qualche modo illuminante su l problema che hai avuto

  15. Grazie Alessandro, anch’io lo avevo nei già nei miei documenti ma per carenza di tempo non l’ho mai letto bene, comincerò ora. Scusate ma il mitico Don oltre a litigare via blog e non solo con tutti che professione svolge veramente ;-)?
    Alberto Frosi

  16. si occupa anche di una particolare razza di cavalli nani, almeno così si desume da alcune foto (della serie datti all’ippica😉 )

    Alessandro

  17. Alberto, ma non ci siamo già incontrati su oracleportal.it ? Il mio nick è Alasondro su oracleportal

  18. Ciao Alessandro, si ci siamo già incontrati su oracleportal.it, il mio nick è Abe.


Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Crea un sito o un blog gratuitamente presso WordPress.com.
Entries e commenti feeds.

%d blogger cliccano Mi Piace per questo: