Cost-based Oracle cap. 2: le statistiche di sistema

Sto leggendo il libro "Cost-based Oracle" di Jonathan Lewis.
Pensavo di dedicare un post ad ogni capitolo, ma non riesco a riportare tutte le cose interessanti che leggo; più realisticamente proverò a commentare i passi più importanti.

Oggi vi volevo parlare delle statistiche di sistema Oracle 10g. Non intendo le statistiche sugli oggetti di SYS e compari, e nemmeno le statistiche sulle fixed tables, ma su un gruppo di misure che l'optimizer può utilizzare per il suo lavoro.
Tra queste sono comprese la velocità della CPU, il tempo di lettura a singoli blocchi, il tempo di lettura multiblocco.
I valori ricavati dalle misure vengono inseriti nella tabella SYS.AUX_STATS$, che tra l'altro non ha sinonimi.

La tabella SYS.AUX_STATS$ si presenta più o meno così, dopo la creazione di un database:

SQL> select SNAME, PNAME, PVAL1 from sys.aux_stats$ where SNAME = 'SYSSTATS_MAIN';

SNAME                          PNAME                               PVAL1
------------------------------ ------------------------------ ----------
SYSSTATS_MAIN                  CPUSPEEDNW                     1116.77078
SYSSTATS_MAIN                  IOSEEKTIM                              10
SYSSTATS_MAIN                  IOTFRSPEED                           4096
SYSSTATS_MAIN                  SREADTIM
SYSSTATS_MAIN                  MREADTIM
SYSSTATS_MAIN                  CPUSPEED
SYSSTATS_MAIN                  MBRC
SYSSTATS_MAIN                  MAXTHR
SYSSTATS_MAIN                  SLAVETHR

9 rows selected.

Si può notare come i valori di *READTIM e MAXTHR, tra i più interessanti, non siano valorizzati; inoltre i valori di IOSEEKTIM e IOTFRSPEED sono sempre uguali, anche per altri database non RAC.

Questa tabella viene popolata dalla procedura DBMS_STATS.GATHER_SYSTEM_STATS(). Può lavorare in due gathering_mode: NOWORKLOAD e a intervalli.
Nel primo caso la procedura misura le performance di I/O del sistema, determinando i valori di cpuspeednw, ioseektim, iotfrspeed.
Nel secondo caso si può far partire la misura con START e fermarla con STOP, scegliendo così un periodo di carico di lavoro tipico, altrimenti è possibile specificare INTERVAL con l'intervallo, misurato in minuti, trascorso il quale la misura viene terminata.

Alla fine delle misure l'aspetto potrebbe essere più o meno questo:

SQL> select SNAME, PNAME, PVAL1 from sys.aux_stats$ where SNAME = 'SYSSTATS_MAIN';

SNAME                          PNAME                               PVAL1
------------------------------ ------------------------------ ----------
SYSSTATS_MAIN                  CPUSPEEDNW                       1606.781
SYSSTATS_MAIN                  IOSEEKTIM                           7.469
SYSSTATS_MAIN                  IOTFRSPEED                      52290.723
SYSSTATS_MAIN                  SREADTIM                            5.912
SYSSTATS_MAIN                  MREADTIM                            2.651
SYSSTATS_MAIN                  CPUSPEED                             1614
SYSSTATS_MAIN                  MBRC                                   10
SYSSTATS_MAIN                  MAXTHR                             105472
SYSSTATS_MAIN                  SLAVETHR

9 rows selected.

A che cosa serve tutto ciò? Le statistiche di sistema vengono utilizzate dal cost-based optimizer per determinare il miglior piano di esecuzione basandosi anche sul costo della CPU e della modalità di I/O (signolo blocco o multiblocco).

Manca ancora il costo di lettura dalla cache, ovvero la stima del costo basata sulla probabilità che un determinato blocco si ritrovi già in cache; ciò dipende soprattutto dalle statistiche derivabili da V$SEGSTAT, che misura l'attività relativa ai segmenti (dati e indici scritti su disco). Dovrò fare delle prove su 11g per vedere se ciò è stato implementato.