Spetta ad
Arup Nanda, nel
foreword, presentare questo corposo libro, alla cui realizzazione hanno contribuito ben 16 autori, taluni realizzando un capitolo da soli, alcuni collaborando insieme a formare un testo di 15 capitoli. Gli autori di questa antologia, sono membri del network
OakTable.net e quindi sono riconosciuti esperti delle tecnologie che trattano.
Nanda in 4 pagine fa un piccolo trattato sulla conoscenza e sul cosa significhi essere esperti:
La cosa brutta della conoscenza è che più ne acquisisci, più impari quanto sei ignorante. Dopo aver letto questo libro, ci si renderà conto, di quanto si debba continuare a studiare i vari elementi di
Oracle, per poter dire, un giorno di conoscerlo in maniera sufficiente.
Il
primo capitolo introduce un approccio alla risoluzione dei problemi contro l'improvvisazione, la supposizione (il
guesswork in inglese), descrivendo vari esempi di questa pratica presi da
Oracle-l e dall'
Oracle Technology Network. Vengono spiegate le cause sottostanti alla pratica di implementazione di soluzioni improvvisate e basate su supposizioni, che sono da una parte la pigrizia e dall'altra la pressione dovuta ai tempi ristretti. Vengono proposti dall'autore una serie di tasselli utili a formare un approccio scientifico alla individuazione e risoluzione dei problemi; inoltre sono forniti una serie di esempi reali di errate valutazioni dovute alla mancanza di analisi. Viene poi presentato brevemente, il sito
BAAG Party - Battle Against Any Guess fondato dall'autore del capitolo,
Alex Gorbachev, per combattere l'approccio basato sulle supposizioni.
Jeremiah Wilton, autore del
secondo capitolo, si occupa del
cloud computing, dandone una definizione ben precisa ed esaminando velocemente le varie proposte commerciali di alcune aziende su questa tematica. Poi l'autore si sofferma ad approfondire la soluzione di
Amazon,
Elastic Compute Cloud o EC2, fornita tramite la piattaforma
Amazon Web Services (AWS), che è l'unica a fornire servizi su database
Oracle in
cloud computing. Si definiranno le caratteristiche di questa soluzione in remoto, che permette di richiedere istanze di database di dimensioni Enterprise e di esternalizzare alcune delle attività di gestione, come l'installazione, il backup, il controllo dello spazio fisico del server. E' possibile utilizzare delle macchine virtuali già esistenti, le
AMI (Amazon Machine Image), o costituirne di nuove con una particolare versione di sistema operativo o distribuzione
Linux. Sono brevemente presentati gli strumenti per utilizzare
EC2, dalle console web, alla linea di comando o alle librerie utilizzabili da
Java,
Perl e
Ruby, con un esempio di inizializzazione di un'istanza da linea di comando. Si prosegue analizzando le possibilità di memorizzazione permanente dei dati dell'istanza, in particolare con l'utilizzo dell'
EBS (Elastic Block Storage), di cui vengono valutate le performance e fornito un esempio di configurazione. Si conclude il capitolo con una discussione degli approcci alla persistenza e della gestione dei backup, anche con
OSB Cloud Module di
Oracle.
In questo
terzo capitolo, gli autori
Connie Green,
Graham Wood e
Uri Shaft, propongono una linea guida per la gestione delle performance. Un primo accenno storico al passaggio, in
Oracle, dalle viste di performance
counter-based a viste
time-based e alla relativa analisi condotta rispetto al tempo. Si ricorda, poi, come sia necessario, già in fase di design, pensare alle performance. Dopo tutta una serie di suggerimenti da adottare nelle varie fasi del processo di sviluppo e gestione di un applicativo, si passa a illustrare i vari passi della metodologia proposta per quello che viene chiamato
Reactive Tuning. Si inizia con la definizione del problema, che non è un'attività da sottovalutare, dato che spesso non viene individuato correttamente e la criticità riguarda in realtà un effetto secondario del problema reale. Vengono quindi illustrate una serie di aree oggetto di analisi, su cui insistere, per raccogliere dati sul problema o per avere una fotografia della situazione. Una volta abbozzata la definizione del problema, occorre che questa sia concordata con tutti gli attori coinvolti. Il secondo passo consiste nell'esame dei dati di performance, da analizzare con i vari report di
ASH, il tool
AWR e
ADDM, senza entrare in dettaglio. Il terzo passo consiste nel formulare una ipotesi di quale sia il problema e alcune possibilità di risoluzione. L'ultimo passo indicato riguarda l'implementazione della soluzione e il controllo di quest'ultima. Perciò si esaminano in dettaglio i tool da utilizzare per questa verifica: si passa dall'impiego e interpretazione dei risultati di
ADDM, all'esame dei report di
ASH, si prosegue esaminando i report prodotti da
AWR, arrivando al dettaglio dei vari elementi,
elapsed time,
top event,
load profile,
osstat. Un paragrafo chiarisce il significato degli elementi di alcune statistiche, e il capitolo si conclude con alcune note sull'
ottimizzatore.
Il DBA come designer è il tema del
quarto capitolo e in esso, l'autrice
Melanie Caffrey, ribadisce l'importanza della partecipazione dei DBA alle fasi di design, di nuove applicazioni o procedure. Si consiglia un atteggiamento proattivo da parte del DBA, perché possa inserirsi in questa fase di progettazione, e sia periodicamente interpellato in ogni fase del ciclo di vita; in più si suggerisce anche di provare a partecipare a
reviewing di code, in modo da acquisire conoscenza sull'applicazione e instaurare una proficua collaborazione con il team di sviluppo. Segue una sessione teorica sulle metodologie di design: la classica
Big Design Up Front (BDUF) e la nuova
Agile Software Development, delle quali si esaminano velocemente i pro e i contro. Si passa a una panoramica, più pratica, inerente al design fisico del database; non mancano le considerazioni sulla scelta dei tipi di dato, la dimensione dei
VARCHAR2, l'uso dei
CHAR, la corretta definizione dei campi identificativi; si prosegue con esempi sulle performance a seconda delle scelte di storage, quindi sulla possibilità di utilizzo dei cluster
B*tree, degli
Index-Organized Table (IOT) e delle Global Temporary Table (GTT); e sulle scelte di indicizzazione, con la dovuta considerazione degli FBI (Function-based Index) e dei
domain index, oltre che dei normali
B*Tree e bitmap. Nella parte finale, insieme ad altre considerazioni sul design, viene sottolineata l'importanza di promuovere l'utilizzo delle feature che
Oracle mette a disposizione, così com'è importante familiarizzare con la relativa documentazione disponibile, e sforzarsi di conoscere e testare le caratteristiche nuove o poco conosciute.
Il
quinto capitolo redatto da
Niall Litchfield, si concentra curiosamente sulla gestione di un server
Oracle su piattaforma Windows, configurazione generalmente anomala, come dice lo stesso autore. Vengono comunque presentati una serie di elementi che possono, in ogni caso, tornare utili, come le utility,
Oracle Administration Assistant, e il
Process Explorer (procexp.exe), che è un tool da utilizzare in generale per monitorare i processi Windows. Dopo l'utilizzo di alcune viste di
Oracle, come la
v$process,
v$session e la
v$sqlarea, si passa a esaminare in dettaglio la gerarchia nel registry di Windows dei servizi
Oracle, e alcune possibilità di manipolazione. L'ultima parte del capitolo invece si occupa dello scripting, quindi di WSH e WMI.
Il
sesto capitolo rappresenta un piccolo compendio sulla gestione quotidiana delle performance. Dopo un richiamo alla responsabilizzazione sulle performance del codice e delle query che si scrivono giornalmente, si fa una rapida carrellata sugli elementi che permettono di definire e misurare le performance:
EXPLAIN PLAN,
DBMS_XPLAN, Tracing SQL. Segue poi una serie di esempi pratici, che illustrano alcuni dei problemi di performance che si possono riscontrare, con la relativa spiegazione della modalità per individuarli e quindi risolverli. Si illustra un esempio di mancanza di un indice; un problema di dati con valori non uniformemente distribuiti da risolvere con la corretta computazione delle statistiche e la creazione di un istogramma; una casistica in cui occorre definire diversamente l'istruzione SQL; infine un caso di
overhead inutile dovuto al cambiamento di contesto legato all'utilizzo di una funzione PL/SQL.
Nel
settimo capitolo,
Joze Senegacnik presenterà la modalità per supportare il
CBO (Cost-Based Oprimizer) nella preparazione di piani di esecuzione ottimali in presenza di funzioni PL/SQL nelle condizioni di una query. Viene inizialmente proposta una veloce rivisitazione teorica sul processo di ottimizzazione: la fase di parsing, la preparazione del piano di esecuzione, il computo degli elementi base per il lavoro del
CBO: selettività, cardinalità e costo. Nella seconda parte del capitolo viene affrontato il tema dell'
extensible optimizer, che permette di utilizzare il
CBO anche per funzioni definite dall'utente. L'esempio completo presentato, come viene indicato, va ben oltre la normale complessità in cui si incorre normalmente, ma può essere utile per capire, in profondità, il funzionamento del
CBO esteso. Viene quindi proposta una nuova funzione utente e definito un nuovo
TYPE, che servirà da contenitore ed elemento di calcolo delle performance, in quanto associato alla funzione.Gli esempi successivi mostrano come il
CBO invoca la selettività e la funzione di costo dal
TYPE e come il
CBO reagisca a diversi valori di questi; si mostra come più semplicemente è possibile definire una selettività e un costo di default, senza
TYPE, per i casi meno complessi e più frequenti.
Nell'
ottavo capitolo, che rappresenta, come numero di pagine, quasi un quarto del libro,
Charles Hooper e
Randolf Geist iniziano un percorso di due capitoli sulla presentazione e il corretto utilizzo delle innumerevoli opzioni per l'ottimizzazione delle performance messe a disposizione in
Oracle. Dopo aver sconsigliato il cambio di parametri
Oracle, che spesso si effettua quasi a caso, inizia una lunga dissertazione sul
Buffer Cache Hit Ratio (BCHR), con tutta una serie di esempi tesi a indicare che non sempre è utile focalizzarsi su questa misura e sulla sua ottimizzazione. Successivamente viene avviata una valutazione dei monitoraggi da effettuare per una prima analisi della causa di problemi di performance, utilizzando le viste messe a disposizione da
Oracle: dal delta sulle statistiche di sistema e di sessione, ai relativi eventi di attesa, il monitoraggio dell'attività sui file, la verifica dell'uso dei tempi di utilizzo della CPU. Tutto questo con esempi di query sulle viste e spiegazioni su alcuni risultati. Si passa poi a proporre come effettuare un campionamento delle statistiche con minimo
overhead, per poter individuare problemi di performance prima che vengano segnalati dagli utenti, costruendosi delle tabelle globali temporanee e uno script per alimentarle. Il paragrafo successivo propone una serie di query sulle tabelle temporanee, come indicatori di alcuni eventuali problemi. Gli autori propongono qui uno script per creare
STATSPACK a un intervallo stabilito e i relativi report; proseguono soffermandosi sulle viste con statistiche sugli
statement SQL con uno script di cattura che utilizza tabelle globali temporanee; ancora viste per monitorare i piani di esecuzione per
statement SQL e i parametri di ottimizzazione che determinato i piani. Il corposo paragrafo che segue si occupa dell'utilizzo del trace 10053 relativo all'
ottimizzatore, e dell'analisi approfondita delle varie sezioni del
trace file, come l'esposizione delle variabile
bind, i parametri di ottimizzazione effettivamente usati, le trasformazioni di SQL, le statistiche sia dell'oggetto che di sistema, il
dynamic sampling, i piani di esecuzione e la forma trasformata degli
hint. La successiva analisi riguarda invece il contenuto dell'
extended trace file 10046, che fornisce informazioni di performance specifiche di una sessione. In questa occasione sono presentate le diverse modalità per attivare questo trace e un esempio di produzione e analisi del
trace file; sono anche illustrate diverse modalità per poter produrre dei
trace file su sessioni diverse dalla corrente, tramite
SQL*Plus ORADEBUG, quindi per processi in
lock, o per applicazioni con codice
Java; viene anche analizzato come produrre
dump della memoria,
PGA, UGA e condivisa, e anche lo stack di processi. Dopo un paragrafo sull'
Automated Database Diagnostic Monitor (ADDM), si accenna all'analisi dei pacchetti di rete, utilizzando tra l'altro
Wireshark, la generazione e l'esame del trace lato client. Questo capitolo va sicuramente segnalato, non solo per l'innumerevole quantità di informazioni che contiene, ma anche per la nutrita serie di documenti
MetaLink e le decine di articoli di siti e blog di esperti suggeriti come approfondimento. Nel sommario finale si trova un elenco dei quasi 30 script presentati.
Dopo aver fornito le innumerevoli opzioni di ottimizzazione, i due autori proseguono nel
nono capitolo proponendo alcune linee guida per la scelta, a seconda della problematica verificatasi, del metodo di risoluzione più opportuno. Inizialmente è presentato un
Decision Tree, che tiene conto del soggetto che ha rilevato il problema di performance: utente finale singolo, utenti di un dipartimento, o problematica generalizzata; quando temporalmente si verifica il problema; e lo scope del problema: solo una funzionalità, tutta un'applicazione, un server, ecc. Si propone quale strategia adottare in ognuno dei casi e si procede poi a illustrare approfonditamente alcuni esempi di analisi e risoluzione di tipiche problematiche di performance, da quella verificatasi dopo un aggiornamento di release di
Oracle a quella dopo l'aggiornamento del sistema ERP, utilizzando i metodi illustrati nel precedente capitolo. L'ultima parte del capitolo considera alcune delle più comuni tipologie di problematiche e la metodologia sistematica per affrontarle e risolverle: cominciando dalla casistica piuttosto comune del riscontro di una o più query SQL, che risultano poco efficienti, si continua con la problematica di un eccessivo tempo di
parsing, per passare a tempi eccessivi in esecuzione o
fetching, e concludere con l'abuso dello
shared pool. Si analizza in dettaglio come raccogliere dati aggiuntivi e quali azioni da intraprendere per migliorare la situazione.
Il
decimo capitolo è deputato, dall'autore
Tim Gorman, ad approfondimenti sulla gestione di un
VLDB (Very Large Database). Dopo una definizione pratica di cosa sia un
VLDB, si esamina come gestire il partizionamento di una grande mole di dati, e come utilizzare l'
EXCHANGE PARTITION: vengono esaminati alcuni scenari di esempio, come processi di aggiornamento di centinaia di milioni di righe, o la loro selezione, e alcune tecniche per avere efficienza e scalabilità, come il
direct-path insert, e il
partition pruning. Un'analisi sull'
Information Life Cycle Management (ILM) consente di capire se i dati hanno un ciclo di vita compatibile, di organizzare la partizione in diversi
tablespace e minimizzare il peso delle normali operazioni anche per grossi database. Infine vengono presi in considerazione alcuni parametri e componenti da settare correttamente, come
DB_BLOCK_SIZE,
Hierarchical Storage Management (HSM),
READ_ONLY_OPEN_DELAYED.
Le statistiche, con alcuni dei problemi riscontrabili e le strategie per risolverli, sono l'argomento in cui nell'
undicesimo capitolo si cimenta
Jonathan Lewis, autore del fondamentale testo
Cost-Based Oracle Fundamentals.
Lewis illustra una serie di casi d'esempio in cui vi è un'errata valutazione della cardinalità e l'ottimizzatore utilizza alcuni valori di default; un caso di navigazione ordinata nelle partizioni e poi altri esempi di problemi di deficitaria valutazione della cardinalità o selettività, e alcune proposte di risoluzione utilizzando il
dynamic sampling (introdotto con
Oracle 9i) e le statistiche estese (introdotte con la 11g). Gli esempi sono molto chiari e dettagliati e questo capitolo può essere utilizzato come guida di riferimento per tutta una serie di problematiche.
Nel
dodicesimo capitolo l'autore
Riyaj Shamsudeen fa un'approfondita analisi del macro problema del
latch contention. Dopo una sezione di definizione di cosa è un
latch e di come viene utilizzato in
Oracle, delle varie tipologie vengono discussi un paio di algoritmi simili a quelli usati dall'engine
Oracle per acquisire i
latch. Si prosegue illustrando una serie di passi per l'identificazione di problematiche di
latch contention. Seguono poi una serie di esempi delle problematiche più comuni con le cause che le producono e le possibili soluzioni. Infine si propongono casi di
Cache Buffers Chains Latch Contention,
Shared Pool Latch Contention,
Library Cache Latch Contention e
Enqueue Hash Chains Latch Contention.
Robyn Sands nel
tredicesimo capitolo introduce quella che può essere definita una robusta teoria della misura delle performance, utilizzando la
metodologia Taguchi. Dopo aver proposto un'analogia con la misura dei risultati in borsa, e aver definito gli elementi base della misurazione di performance in un database — il tempo di risposta, il
throughput, e sopratutto le attese degli utenti — si passa alla presentazione di un caso pratico, concernente un datawarehouse, per il quale sono state evidenziate problematiche, partendo dall'analisi di dati statistici sui tempi di risposta, come media, mediana, deviazione standard, varianza e
variance-to-mean ratio (VMR) o indice di dispersione. Viene poi proposta una sessione teorica con tanto di formule, sulle distribuzioni di Gauss e Poisson, e la loro applicazione alle distribuzioni dei tempi di risposta, con l'analisi della varianza e dell'indice di dispersione. Infine viene proposto un altro esempio, che prevede l'utilizzo dell'
Instrumentation Library for Oracle (ILO), e tutti i concetti illustrati precedentemente sull'analisi statistica dei tempi.
L'argomento del
quattordicesimo capitolo, illustrato da
Pete Finnigan, è la sicurezza utente dei database
Oracle. L'autore propone un piano di azione per ridurre la cosidetta
attack surface, partendo dal censimento degli utenti, sia quelli di default
Oracle, sia quelli creati dall'utilizzatore e dalla analisi della loro utilità. A corredo della trattazione, vi è una serie di utili pratiche, query e script, per il censimento degli utenti e dei ruoli, con l'obiettivo di eliminare quelli che non sono necessari. Si prosegue con un check sulla robustezza delle password degli utenti, utilizzando un password cracker in PL/SQL proposto dall'autore e poi, dopo una rapida carrellata sui programmi di password cracker che si trovano in Rete, viene proposto un esempio di utilizzo di
woraauthbf. Si continua con il censimento dei ruoli e dei privilegi, anche in questo caso per una possibile riduzione, per finire poi con uno sguardo a cosa voglia dire introdurre un processo di gestione delle password. Da rilevare che in questo capitolo l'autore ha inserito una domanda sul calcolo del numero totale di password, la cui risposta è nel paragrafo finale.
Il
quindicesimo capitolo, l'ultimo del libro, sempre di
Pete Finnigan, si focalizza sul mettere in sicurezza i dati. Procedendo con un esempio, si localizzano i dati da proteggere, e si analizzano gli utenti e gli oggetti che vi hanno accesso, andando a esplorare tutta la gerarchia di oggetti e le catene formate dalla concessione delle GRANT. Si prosegue nella ricerca dei possibili accessi ai dati che si vogliono proteggere andando a esplorare il file system, alla ricerca di eventuali file che li contengono, così come all'interno della SGA. L'ultima verifica che viene proposta è quella dell'eventuale presenza di copie dei dati da proteggere.
I testi composti da contributi di diversi autori rischiano spesso di essere dispersivi, introdurre argomenti poco correlati tra loro e usare livelli di dettaglio non uniformi, finendo per generare solo confusione. Non è però il caso di questo testo, che senza dubbio è rivolto ad un pubblico di lettori che siano DBA e anche piuttosto esperti, i quali però troveranno un libro da consultare in diverse occasioni. Come anche indicato nell'Apress roadmap sulla quarta di copertina, prima di accedere a questo testo occorrerebbe aver letto almeno
Beginning Oracle Database 11g Administration e
Expert Oracle Database 11g Administration.