Tutti coloro che come sviluppatori hanno lavorato con Oracle, si sono imbattuti in un DBA piú
o me meno "particolare", dove per particolare intedo uno di quei DBA che volendosi dimostrare all'altezza delle
aspettative, in realtá risulta poco preparato, cadendo talvolta nel ridicolo.
Partendo da questo presupposto, immaginiamo allora, proprio in qulità di utenti di database, di doverci misurare con un
tale amministratore. Tale gioco di fantasia è pensato soprattutto per far capire quale possa essere il giusto
modo di procedere nell'eventualità di dover affrontare un problema più o meno grave.
Ovviamente quello che descrivo è il mio punto di vista.
Prima di iniziare, vorrei fare una piccola precisazione. Io stessto sono stato DBA per alcuni anni, poi una scelta personale,
mi ha condotto nel modo dello sviluppo. Tale scelta è stata dettata da un mio cruccio. Sono sempre stato
convinto infatti che un bravo DBA, debba conoscere bene le problematiche di sviluppo. Cosí implementando piccoli programmi,
ho acquisito un punto di vista che prima mi era del tutto estraneo.
Insomma, sto conoscendo il nemico dall'interno :)
Per capire allora con che tipo di DBA dobbiamo misurarci, facciamo un paoio di esempi introduttivi. Supponiamo
che in qualità di utente BEA Weblogic, in presenza di connessioni verso il databae, riscontriamo dei problemi di lentezza
nella esecuzione dei workflow. Bene. Il nostro DBA, con una semplice SELECT sulla V$SESSION ci dice che va tutto
bene perché non ha riscontrato nulla di interessante. ;)
Immaginiamo poi di avere un problema con una "stored procedure" schedulata, che fallisce ogni volta che proviamo ad eseguirla: e
purtroppo non riusciamo da soli a capirne il motivo. Cerchiamo così un aiuto chiedendogliene il motivo. Ora, se un job
fallisce, Oracle lo segnala nell'alert.log (non potrebbe fare altrimenti: visto che il job gira in modo non
interattivo, ci deve essere un punto in cui l'RDBMS segnala un'eventuale problema e l'unico posto è porprio l'alert.log).
Il nostro DBA, deve quindi aprire il log, torovare l'orario (che gli abbiamo fornito) in cui è fallita la procedura
e leggerci l'errore. La sua risposta invece è che dobbiamo modificare la "stored proced" in modo da controllare
meglio l'insieme dei dati su cui lavoriamo. Di per sè, una tale risposta è giusta se data in un contesto
diverso da quello in cui ci troviamo. Fondamentalmente la sua risposta ha messo in risalto le seguenti cose:
- Non ha guardato l'alert.log (chisá perché)
- Non ha ascoltato la nostra richiesta di aiuto (ma che ci vuole poi?)
- Non si è interessato del nostro problema (e questo è l'aspetto piú grave)
Di seguito immaginerò allora le (dis)avventure, del nostro amico DBA.
Documentum
SMON