• Introduzione
• Basic cost arithmetic
• Lezione 2
• Lezione 3
• Lezione 4
• Lezione 5
• Lezione 6
• Lezione 7
• Lezione 8
• Lezione 9

(slide 1.6) A partire da Oracle 9i, l'obiettivo dell'ottimizzatore è stato modificato. E' adesso presente anche "first_rows_N", dove N può essere 1, 10, 100, o 1000. In questo caso l'RDBMS "optimizes with a goal of best response time to return the first n number of rows" (dal manuale 10gR2). Esiste anche un equivalente HINT: "/*+ first_rows(n) */", dove n però può essere un qualunque intero.
La cosa interessante è che per uno statement del tipo:

Oracle 10g si accorege che vogliamo le prime N righe e lo trasforma in:

Questo vuol dire che a seguito di un upgrade del database, il comportamento cambia ottenendo risultati inattesi.

Durante il seminario, Lewis ha precisato più volte che non bisogna più utilizzare come obiettivo "first_rows", che tra l'altro è stato deprecato in 9i, ma quanto piuttosto proprio il "first_rows_N". Il motivo, anche se non detto durante i 2 giorni, lo si può trovare nell'errata corrige al primo capitolo del suo libro.

(slide 1.7) A partire da Oracle 9i, è stato introdotto un nuovo tipo di costo: CPU Costing. Le statistiche possono essere raccolte sempre con il package DBMS_STATS. La procedura è la seguente (come indicato nelle slide):
Di fatto, possiamo dire che le statistiche di sistema, misurano le performance di sistema durante la loro raccolta. Talvota però, queste statistiche possono risultare falsate. Il motivo viene descritto in un articolo scritto da Lewis stesso (di seguito riporto un piccolissimo estratto):

This is a particular problem in a SAN environment, as SANs tend to have very good algorithms for handling high volume reads, using predictive read-ahead methods to pre-load the SAN cache.

Se le statistiche risultano errate, è possibile utilizzare tools esterni. Sul sito www.iozone.org è possibile trovarne uno, oppure utilizzarne uno equivalente della Oracle stessa: Orion.

(slide 1.8)