L'evoluzione

Un articolo molto interessante su OakTable descrive come Oracle si sia evoluto a partire dalla sua prima versione (V2.3).

Il sottoscritto ha visto tuttavia solo le ultime modifiche e devo dire che se guardo indietro, la vecchia 8.1.5 mi sembra davvero un dinosauro. Lavoro ancora con la 8i (aggiornata a 8.1.7.4) e sento la mancaza di molte delle caratteristiche presenti in 9i come le EXTERNAL TABLES.

Anche se ormai sono diversi anni che non lavoro più come DBA, ho seguito la crescita del db sempre dal punto di vista dell'amministratore, ed effettivamente i cambiamenti sono stati sostanziali. L'idea che mi sono fatto è che così come la 8i ha rappresentato un salto generazionale rispetto ad oracle 7.3 ed 8, la 10g lo è stato per 8i e 9i.

Studiando quali sono state le modifiche introdotte con l'ultima release del db mi sono reso conto come il tema "Performance & Tuning" abbia subito un radicale e profondo cambiamento: a partire da 10g credo si possa dire che sia cambiata la filosofia di approccio.

Tutto è cominciato da YAPP
il documento scritto da Anjo Kolk, che di fatto fornisce uno strumento su come affrontare i problemi di performance. Diventa allora famosa l'espressione

Response Time = Service Time + Wait Time

in cui l'obiettivo è cercare di ridurre il tempo di risposta. (Su tale tema, Cary Millsap e Jeff Holt hanno scritto un libro davvero bello). Con 8i, Oracle introduce statspack, che con l'aiuto del sito di Kolk, diventa uno strumento davvero utile per individuare i problemi di performance. Con 9i, Oracle subisce una spinta in avanti non indifferente. Dapprima viene introdotto il timing in microsecondi e riportato il timing in V$SQL e poi, in 9iR2, statspack si modifica riportando la statistica "CPU Time" e la dicitura "Top Wait Events" diventa "Top Timed Events", ad indicare come sempre più l'obbiettivo di analisi sia orientato nel cercare di ridurre il tempo di risposta.

E poi arriva Oracle 10g. Viene introdotto AWR che di fatto è uno statspack direttamente dentro il kernel dell'rdbms. C'è ASH, che permette di capire per sommi capi, i potenziali problemi. Ma soprattutto conosciamo ADDM, l'inteliggenza che ci aiuta a capire dove sono i problemi nel db. Sostanzialmente adesso se vogliamo sapere dove il db langue, basta tirare giù un report di ADDM per capire dove dobbiamo indirizzare i nostri sforzi. Ma non solo. ADDM suggerise anche che fare.

WOW.