di Andrea Tassotti
Non me ne vorranno i colleghi di questo blog che per lavoro o diletto praticano il mondo della programmazione Java, ma nello storico contenzioso tra sistemista e programmatore (contenzioso su risorse e sicurezza) si osserva una (dico) “perversa” tendenza tutta (ahimé) dei programmatori Java nel prediligere l’uso di campi LOB di tipo BLOB o CLOB (raramente NCLOB) per risolvere questioni di memorizzazione di informazioni non strettamente primitive, con particolare propensione alla serializzazione di oggetti o immagazzinamento di file di ogni sorta (e orrore, anche xml, trascurando il tipo nativo Oracle) [a difesa dei colleghi del blog…molte volte si ereditano scelte progettuali che sarebbero devastanti da cambiare] in questo tipo di campi, con buona pace o la connivenza [close your eyes] di tanti DBA.
Questi tipi di campi graveranno nella base dati proporzionalmente alla loro dimensione, che è teoricamente molto elevata (8TB), con conseguenze che vedremo e che sono a carico dei DBA.
Ho però sentito DBA legittimare l’uso integrale (integralista) della base dati come unico strumento di memorizzazione per qualsiasi tipo di informazione motivando con la tesi dell’uso di “una soluzione di successo”.
Forse qui dovrei pensare che molti DBA non sono anche sistemisti e che forse ignorano l’esistenza di un qualcosa che si chiama filesystem e che miracolosamente è fatto per memorizzare file e che è in grado finanche di eseguire un backup dei suoi contenuti in varie forme: ma questo è forse il semplice frutto di un altro contenzioso storico, quello tra DBA e sistemista.
Dubito a questo punto che questi DBA abbiano mai amministrato le basi dati di cui promuovono l’universalità d’uso; dubito che potranno essere contenti che in BLOB siano depositati file PDF di un qualche sistema di gestione documentale destinati alla stampa, oppure file audio mp3 di registrazioni telefoniche per un servizio di call center.
Dubito perché le conseguenze nella gestione di basi dati siffatte sono cronaca di molti centri di calcolo: tribolazioni e ore di lavoro straordinario: dei DBA (coinvolgendo spesso sistemisti e specialisti di storage).
La prima importante conseguenza è l’esplosione degli spazi occupati dalla base dati, spesso irragionevolmente rapida. La seconda conseguenza è la difficile manutenzione di questi spazi per la problematicità derivanti dalla costruzione fisica degli stessi.
Oracle ha progettato questi campi per agevolare la gestione di strutture dati complesse e di grandi dimensione; l’esempio in letteratura per questi dati quello multimediale in assenza di contenitori alternativi (quale il file è), ma ovviamente non ci sono vincoli.
Anche il ciclo di vita di questi dati spesso è da considerare nel progettare l’uso dei campi LOB.
I campi BLOB, CLOB e NCLOB sono progettati per gestire il dato con un ciclo di vita ordinario del tutto simile agli altri tipi (con rare eccezioni), contrariamente al tipo LOB BFILE inteso per informazioni a sola lettura, di grandi dimensioni e con storage esterno alla base dati (il famoso file su filesystem) di cui il motore relazionale tiene in tabella un semplice riferimento.
Per i primi tre tipi LOB Oracle prevede un tipo di segmento specifico e ciò consente di distribuire questi dati su tablespace riservati: ma esiste una configurazione (che è default) dello storage per i campi LOB (prevista in realtà per ottimizzare le performance di accesso al dato) che può creare qualche sorpresa: si tratta del parametro IN ROW, che consente di memorizzare un campo LOB inferiore a 4k nel segmento ordinario. Occorre valutare bene la configurazione di questo parametro in ragione dei dati che verranno collocati nel campo LOB, in quanto potrebbe interferire col beneficio derivante dalla costruzione di un tablespace dedicato ai lobsegment (potrebbe non essere utilizzato), facendo crescere la dimensione di riga interferendo sulle performances delle DML anche sulle altre colonne.
Un ulteriore problema nasce invece dallo stesso lobsegment: lo spazio allocato per un segmento, a causa dell’high watermark, non viene rilasciato quando una DML ne riduce l’utilizzo: ne deve seguire una operazione di ALTER TABLE SHRINK, magari consigliata dal Segment Advisor in ragione del tasso di spazio recuperabile.
Ovviamente un campo LOB ha una forte incidenza sul consumo di spazio e una alta volatilità dei suoi dati aumenta il problema. Occorre inoltre ricordare che l’operazione di shrink ordinaria non coinvolge i campi LOB: occorre una specifica istruzione che indichi lo shrink su colonna LOB, oppure applicare la clausola cascade durante una operazione di shrink ordinaria.
L’alta volatilità di un campo LOB creare ulteriori problemi se si considera che un parametro di storage (PCTVERSION) riserva una percentuale dello spazio per mantenere le versioni precedenti dei dati del campo LOB (di norma il 10%).
Tutti questi aspetti rendono l’uso di campi LOB molto disagevole, in special modo se questi campi vengono manipolati dopo la loro creazione.
Se si considera che molto spesso il dato destinato ad un campo LOB è statico e avente come contenitore naturale un file di formato appropriato è conveniente utilizzare, se proprio non se ne può fare a meno, il LOB di tipo BFILE (LOB memorizzato in file esterno) e lasciare al Sistema Operativo l’onere della gestione dello spazio e della sicurezza del dato. Dopotutto Oracle lo implementa per questo scopo: una qualche dignità dovrà pur averla, no?