FTS Kosten mit WORKLOAD statistics in 11.2

Zur Berechnung der Kosten eines FTS bei Verwendung von Workload-Statistiken hatte ich vor einigen Monaten schon mal einen Test gemacht, aber dabei vermutlich die Rolle des CPU-Elements nicht berücksichtigt. Daher das Ganze noch einmal...

FTS bei WORKLOAD system statistics

Der Tests basiert auf der gleichen Grundlage wie die beiden letzten Tests (also letztlich auf den Definitionen des cbo-Buchs von Jonathan Lewis). Zunächst setze ich die Systemstatistiken - den CPUSPEEDNW-Wert allerdings auf einen extrem hohen Wert, um den CPU-Anteil des costings wieder auszuschalten.

begin
   dbms_stats.set_system_stats('CPUSPEED', 1000000);
   dbms_stats.set_system_stats('SREADTIM', 5.0);
   dbms_stats.set_system_stats('MREADTIM', 30.0);
   dbms_stats.set_system_stats('MBRC', 12);
end;
/

PNAME                               PVAL1
------------------------------ ----------
CPUSPEEDNW                        1000000
IOSEEKTIM                              10
IOTFRSPEED                           4096
SREADTIM                                5
MREADTIM                               30
CPUSPEED                          1000000
MBRC                                   12

Nach Jonathan Lewis errechnen sich die Kosten in diesem Fall als:

• (Anzahl_Blocks / MBRC) * (MREADTIM/SREADTIM)

Also:

• 10000/12 * 30/5 = 5000

Tatsächlich ergibt sich (wieder mit dem Beispiel aus dem ersten Teil der Mini-Serie):

select /*+ cpu_costing */ max(val)
  from t1;

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |     4 |  5000   (0)| 00:00:26 |
|   1 |  SORT AGGREGATE    |      |     1 |     4 |            |          |
|   2 |   TABLE ACCESS FULL| T1   | 10000 | 40000 |  5000   (0)| 00:00:26 |
---------------------------------------------------------------------------

Das Ergebnis entspricht also exakt der Erwartung. Jetzt noch einmal der Test mit veränderter MBRC-Angabe, der mir im Januar Kopfzerbrechen bereitete:

dbms_stats.set_system_stats('MBRC', 16);

Die Formel ergibt nun:

• 10000/16 * 30/5 = 3750

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |     4 |  3750   (0)| 00:00:19 |
|   1 |  SORT AGGREGATE    |      |     1 |     4 |            |          |
|   2 |   TABLE ACCESS FULL| T1   | 10000 | 40000 |  3750   (0)| 00:00:19 |
---------------------------------------------------------------------------

Also erneut eine exakte Übereinstimmung. Die Abweichung im Januar ergab sich offenbar daraus, dass ich damals bei den Blocks auch die oberhalb der HWM mitgerechnet hatte. Nun, immerhin lässt sich das aufklären.