Glücksspiel Systemstatistiken

Glücksspiel Systemstatistiken Das Märchen vom "typischen Workload" DOAG Konferenz, Nürnberg 2012 Thorsten W. Grebe Grebe@twg-it.de

Agenda 1. Einführung 2. Ermitteln von Workload-Statistiken 3. Einfluss der Messintervall-Länge 4. Ungültige Systemstatistiken 5. Mehrere Sätze von Systemstatistiken? 6. Schlussfolgerungen

Agenda 1. Einführung 2. Ermitteln von Workload-Statistiken 3. Einfluss der Messintervall-Länge 4. Ungültige Systemstatistiken 5. Mehrere Sätze von Systemstatistiken? 6. Schlussfolgerungen

1. Einführung Steckbrief System Statistiken Kennwerte für I/O-Potential und CPU-Taktung Eingeführt mit 9i, erweitert in 10g um NoWorkload-Statistiken Basis für die Kostenberechnung des Cost-Based Optimizers Sollen das Verwenden von optimizer_index_cost_adj und optimizer_index_caching ablösen unterschieden wird zwischen: - Default-No-Workload-Statistiken, - No-Workload und besser als Defaultwerte - Workload-Statistiken empfohlen von Oracle werden gemessen mit dbms_stats.gather_system_stats die Kennwerte werden in der Tabelle SYS.AUX_STATS$ gespeichert Historische Werte in WRI$_OPTSTAT_AUX_HISTORY (nicht manuell gesetzte alte Werte) Änderungen an Systemstatistiken gelten sofort, aber nicht für Statements, die bereits im Shared Pool liegen.

1. Einführung Was sind Systemstatistiken? SQL> select * from sys.aux_stats$ ; SNAME PNAME PVAL1 PVAL2 Kommentar ------------- --------- ----- ---------------- ---------------------------------- SYSSTATS_INFO STATUS COMPLETED oder: MANUAL-, AUTOGATHERING SYSSTATS_INFO DSTART 08-29-2012 18:47 Messung-Startzeit SYSSTATS_INFO DSTOP 08-29-2012 18:47 Messung-Ende,bei NoWorkload=DSTART SYSSTATS_INFO FLAGS 1 0=gelöscht, 1=gesetzt SYSSTATS_MAIN CPUSPEEDNW 1386 NoWorkload: Mio Ops/Sek pro CPU SYSSTATS_MAIN IOSEEKTIM 10 NoWorkload: Zugriffszeit in ms SYSSTATS_MAIN IOTFRSPEED 4096 NoWorkload: Durchsatz in KB/sec SYSSTATS_MAIN SREADTIM Zugriffszeit in ms für Einzelblock SYSSTATS_MAIN MREADTIM Zugriffszeit in ms für Multiblock SYSSTATS_MAIN CPUSPEED Workload: Mio Ops/Sek pro CPU SYSSTATS_MAIN MBRC Durschn. Zahl Blöcke bei FTS, FFS SYSSTATS_MAIN MAXTHR Max Durchsatz in Byte/sec (PX-Proz.) SYSSTATS_MAIN SLAVETHR Durschn. Durchsatz in B/s (PX-Proz.) Workload-Statistiken Default: alle Werte leer Messen: dbms_stats.gather_system_stats('start') ('stop') oder: gather_system_stats('interval',10) NoWorkload-Statistiken Default: nur CPUSPEEDNW gemessen dbms_stats.delete_system_stats Messen: dbms_stats.gather_system_stats

1. Einführung Warum Systemstatistiken messen? Warum NoWorkload-Statistiken messen statt Defaults nehmen? Damit der Optimizer nicht mit 10ms Latenz und 4 MB/s Durchsatz rechnet db_block_size sreadtim = ioseektim + ------------- iotfrspeed db_block_size * mbrc mreadtim = ioseektim + -------------------- iotfrspeed Lewis 2006, Cost-Based Oracle Fundamentals S. 20 Beispielrechnung mit ioseektim = 10, iotfrspeed = 4 MB/s bei 8KB Blockgröße, mbrc = 8: sreadtim = 12 ms Verhältnis 26/12 = 2,2 mreadtim = 26 ms Beispielrechnung mit ioseektim = 5, iotfrspeed = 40 MB/s bei 8KB Blockgröße, mbrc = 8: sreadtim = 5,2 ms Verhältnis 6,6/5,2 = 1,3 mreadtim = 6,6 ms Falle bei NoWorkload-Statistiken : alter system set db_file_multiblock_read_count=128; Beispielrechnung mit ioseektim = 5, iotfrspeed = 40 MB/s bei 8KB Blockgröße, mbrc = 128: sreadtim = 5,2 ms Verhältnis 30,6/5,2 = 5,9 mreadtim = 30,6 ms auch wenn 128 Default ist!

1. Einführung Warum Systemstatistiken messen? Warum Workload-Statistiken messen statt NoWorkload-Statistiken? Damit der Optimizer sreadtim, mreadtim und mbrc nicht ableitet, sondern reale, gemessene Werte verwendet. Workload-Statistiken machen immun gegen Veränderungen von db_file_multiblock_read_count. Bei gemessenen, gültigen Workload-Statistiken verwendet der Optimizer andere Formeln für die Kostenberechnung.

1. Einführung Was sind Systemstatistiken? Beispiel 11.2.0.3 auf Windows

1. Einführung Was sind Systemstatistiken? Beispiel 11.2.0.3 auf Windows Default NoWorkload-Statistiken

1. Einführung Was sind Systemstatistiken? Beispiel 11.2.0.3 auf Windows No-Workload- Statistiken

1. Einführung Was sind Systemstatistiken? Beispiel 11.2.0.3 auf Windows No-Workload- Statistiken 4096 = Misslungene NoWorkload-Messung. Kein Erfolg, aber auch kein Schaden. Erwarten sollte man IOSEEKTIM << 10 IOTFRSPEED >> 20000

1. Einführung Was sind Systemstatistiken? Beispiel 11.2.0.3 auf Windows Workload-Stats

1. Einführung Was sind Systemstatistiken? Beispiel 11.2.0.3 auf Windows Workload-Stats

1. Einführung Was sind Systemstatistiken? Beispiel 11.2.0.3 auf Windows Fantasie-Workload Workload-Stats

1. Einführung Was sind Systemstatistiken? Beispiel 11.2.0.3 auf Windows Workload-Stats Workload-Statistiken sind gesetzt NoWorkload-Statistiken werden jetzt ignoriert

1. Einführung Was sind Systemstatistiken? Beispiel 11.2.0.3 auf Windows

Agenda 1. Einführung 2. Ermitteln von Workload-Statistiken 3. Einfluss der Messintervall-Länge 4. Ungültige Systemstatistiken 5. Mehrere Sätze von Systemstatistiken? 6. Schlussfolgerungen

2. Ermitteln von Workload-Statistiken Oracle-Anleitungen Aus dem 11gR2 Upgrade Best Practices Guide, Folie 54: Anleitung aus 11gR2 Upgrade Companion, Seite 30, Post-Upgrade Tasks: 11gR2 PL/SQL Packages and Types Reference Kapitel 138 (DBMS_STATS) 9 stündige Messintervalle 2 unterschiedliche Workload-Datensätze (Tag, Nacht) Alle Anleitungen gehen von Einmalmessungen aus. Oracle empfiehlt ein mehrstündiges Messintervall. Das Ergebnis wird sofort wirksam in aux_stats$ eingetragen.

2. Ermitteln von Workload-Statistiken Beispiel-Messung nach Oracle-Anleitung 8-stündige Messintervalle Dienstag Mittwoch Donnerstag DSTART 30.10.2012 03:43 31.10.2012 03:46 01.11.2012 03:49 über Nacht DSTOP 30.10.2012 11:43 31.10.2012 11:46 01.11.2012 11:49 SREADTIM 0,24 0,38 0,49 MREADTIM 0,56 0,41 0,40 CPUSPEED 1465 1332 1254 MBRC 7 5 6 MAXTHR 411.243.520 383.084.544 460.174.336 SLAVETHR 21.296.128 19.535.872 19.300.352 Verhältnis mread/sread: 0,56/0,24 = 2,3 0,41/0,38=1,1 0,40/0,49=0,8 (in den beiden 8h Intervallen tagsüber und abends blieb MBRC in dieser Datenbank leer) Bei Einzelmessungen über mehrere Stunden kann die Datenqualität nicht beurteilt werden. Sind sreadtim / mreadtim unter 0,5ms realistisch? War der Workload typisch? Was wurde gemessen? Wie stark würden Werte an anderen Tagen schwanken? Die Qualität des Messergebnisses ist nicht nachvollziehbar.

2. Ermitteln von Workload-Statistiken Messreihen aufzeichnen Zuverlässige, nachvollziehbaren Systemstatistiken lassen sich über das Aufzeichnen von Messreihen ermitteln. 1. Statistik-Sammeltabelle erstellen 2. Scheduler-Job einrichten, der 10-Minuten Intervalle aufzeichnet 3. Daten graphisch aufbereiten 4. Workload-Statistikwerte auf Plausibilität prüfen und in aux_stats$ eintragen

2. Ermitteln von Workload-Statistiken Messreihen aufzeichnen Schritt1: Erzeugen der Statistik-Sammeltabelle: SQL> begin dbms_stats.create_stat_table( ownname => 'SYSTEM', stattab => 'SYSTEM_STATS_TWG' ); end; /

2. Ermitteln von Workload-Statistiken Messreihen aufzeichnen Schritt 2a: Scheduler-Job einrichten : begin dbms_scheduler.create_job( job_name => 'twg_sys_stats', job_type => 'plsql_block', job_action => 'declare l_start varchar2(14); l_label varchar2(30); begin select to_char(sysdate, ''yyyymmddhh24mi'') into l_start from dual; l_label := ''Workload_'' SYS_CONTEXT(''userenv'', ''instance_name'') ''_'' l_start; dbms_stats.gather_system_stats( gathering_mode => ''INTERVAL'', interval => 10, statid => l_label, stattab => ''SYSTEM_STATS_TWG'', statown => ''SYSTEM''); end;', start_date => sysdate, end_date => sysdate+35, repeat_interval => 'FREQ=MINUTELY;INTERVAL=11', enabled => true, comments => 'Workload Systemstatistiken, DOAG 2012'); END; /

2. Ermitteln von Workload-Statistiken Messreihen aufzeichnen SQL> select job_name, run_count as cnt, failure_count as fail, last_start_date from dba_scheduler_jobs where job_name = 'TWG_SYS_STATS' or job_name like 'ST$%'; JOB_NAME CNT FAIL LAST_START_DATE ------------- --- ---- ------------------------------- TWG_SYS_STATS 1 0 30.09.12 11:44:43,012000 +02:00 ST$637 0 0 SQL> select statid, c1 as status, c2 as startzeit, c4 as messart from system.system_stats_twg order by statid; Schritt 2b: Scheduler-Job kontrollieren STATID STATUS STARTZEIT MESSART -------------------------- ------------- ---------------- --------- WORKLOAD_ORCL_201209301144 COMPLETED 09-30-2012 11:44 CPU_SERIO WORKLOAD_ORCL_201209301144 PARIO WORKLOAD_ORCL_201209301155 AUTOGATHERING 09-30-2012 11:55 CPU_SERIO WORKLOAD_ORCL_201209301155 PARIO

2. Ermitteln von Workload-Statistiken Messreihen aufzeichnen Schritt 3a: Daten graphisch aufbereiten - Spaltenkorrelation SQL>desc SYSTEM_STATS_TWG DBMS_STATS.CREATE_STAT_TABLE(...) Name Typ -------- ------------- STATID VARCHAR2(30) SQL>desc aux_stats$ Welche Spalten TYPE CHAR(1) Name Typ gehören VERSION NUMBER ------- ------------- FLAGS NUMBER zusammen? SNAME VARCHAR2(30) C1 VARCHAR2(30) PNAME VARCHAR2(30) C2 VARCHAR2(30) C3 VARCHAR2(30) PVAL1 NUMBER set_system_stats C4 VARCHAR2(30) PVAL2 VARCHAR2(255) import_system_stats C5 VARCHAR2(30) N1 NUMBER N2 NUMBER N3 NUMBER MOS 1074354.6 DBMS_STATS.CREATE_STAT_TABLE: What Do N4 Table Columns NUMBER Mean? N5 NUMBER "The columns and types that compose this table are not relevant N6 as it NUMBER should be accessed solely through the procedures in this package N7 (dbms_stats)." NUMBER N8 NUMBER create_stat_table erzeugt eine generische Tabelle. N9 NUMBER N10 NUMBER Das Mapping zwischen aux_stats$ und der Sammeltabelle N11 NUMBER ist nicht dokumentiert. N12 NUMBER Oracle stellt die Methoden set_system_stats und D1 DATE R1 RAW(32) import_system_stats für den Übertrag von einzelnen R2 RAW(32) Datensätzen bereit. CH1 VARCHAR2(1000) CL1 CLOB

2. Ermitteln von Workload-Statistiken Messreihen aufzeichnen Schritt 3a: Daten graphisch aufbereiten - Spaltenkorrelation Spalte Erläuterung. STATID TYPE Titel der Messung eindeutig, mit Buchstaben beginnend, kein Leerzeichen Immer "S" (für Systemstatistik) VERSION "6" = 11.2; "5" = 11.1; "4" = 10.2, 9.2 FLAGS immer "1" C1 AUX_STATS$.STATUS für C4=CPU_SERIO: COMPLETED MANUALGATHERING AUTOGATHERING für C4=PARIO: NULL C2 C3 C4 C5 N1 N2 AUX_STATS$.DSTART für C4=CPU_SERIO: Startzeit der Messung für C4=PARIO: NULL AUX_STATS$.DSTOP für C4=CPU_SERIO: Endezeit der Messung für C4=PARIO: NULL Art des Datensatzes, kein Feld in AUX_STATS$ C4= CPU_SERIO (Messungen, die auf CPU und serielles IO-bezogen sind) C4= PARIO (Messungen, die auf paralleles IO-bezogen sind) immer leer AUX_STATS$.SREADTIM bzw. AUX_STATS$.MAXTHR für C4=CPU_SERIO: single block readtime in ms (= SREADTIM) für C4=PARIO: maxthr in Bytes/Sekunde (= MAXTHR) AUX_STATS$.MREADTIM bzw. AUX_STATS$.SLAVETHR für C4=CPU_SERIO: single block readtime in ms (= MREADTIM) für C4=PARIO: slavethr in Bytes/Sekunde (= SLAVETHR)

2. Ermitteln von Workload-Statistiken Messreihen aufzeichnen Schritt 3a: Daten graphisch aufbereiten - Spaltenkorrelation Spalte Erläuterung.... N3 N4 N5 N6 N7 N8 AUX_STATS$.CPUSPEED für C4=CPU_SERIO: Millionen Oracle-Operationen/Sekunde AUX_STATS$.SBLKRDS (bei SNAME=SYSSTATS_TEMP) für C4=CPU_SERIO: Zwischensumme Single Block Reads (aus x$kcfio.kcfiosbr) AUX_STATS$.SBLKRDTIM (bei SNAME=SYSSTATS_TEMP) für C4=CPU_SERIO: Zwischensumme Single Block Read Time (x$kcfio.kcfiosbt) AUX_STATS$.MBLKRDS (bei SNAME=SYSSTATS_TEMP) für C4=CPU_SERIO: Zwischensumme Multi Block Reads (aus x$kcfio.kcfiombr) AUX_STATS$.MBLKRDTIM (bei SNAME=SYSSTATS_TEMP) für C4=CPU_SERIO: Zwischensumme Multi Block Read Time (x$kcfio.mblkrdtim) AUX_STATS$.CPUCYCLES (bei SNAME=SYSSTATS_TEMP) für C4=CPU_SERIO: Zwischenstand Summe CPU-Operationen N9 AUX_STATS$.CPUTIM (bei SNAME=SYSSTATS_TEMP) für C4=CPU_SERIO: Zwischenstand Summe CPU-Zeit N10 N11 N12 Spaltenbedeutung konnte nicht geklärt werden für C4=CPU_SERIO: fast immer 0 (gelegentlich 4-5 stellige Zahlenwerte) AUX_STATS$.MBRC für C4=CPU_SERIO: Multi Block Read Count AUX_STATS$.MBRTOTAL (bei SNAME=SYSSTATS_TEMP) für C4=CPU_SERIO: Zwischenstand Summe MBRTOTAL D1, R1, R2, CH1, CL1 immer leer, spielen scheinbar keine Rolle bei Systemstatistiken

2. Ermitteln von Workload-Statistiken Messreihen aufzeichnen Schritt 3b: Daten graphisch aufbereiten - Spaltenkorrelation Daten extrahieren: SQL> select statid, c2 as Beginn, c3 as Ende, n1 as sreadtim, n2 as mreadtim, n3 as cpuspeed, n11 as mbrc from system_stats_twg where statid like '%_ORCL%' and C4 = 'CPU_SERIO' and C1 = 'COMPLETED' order by STATID ; SQL> select statid, n1 as maxthr, n2 as slavethr from system_stats_twg where statid like '%_ORCL%' and c4 = 'PARIO' order by STATID ;

2. Ermitteln von Workload-Statistiken mreadtim vs. sreadtim mreadtim <= 1,2*sreadtim sind invalide (MOS 153761.1), heute aber häufig die Regel 8h-Messintervalle Dieser "typische Workload" erlaubt nicht die gleichzeitige Messung von sreadtim und mreadtim. Artefakt- Mittelwerte über 10 Min-Intervalle von 1-3 µs.

2. Ermitteln von Workload-Statistiken with aggr as ( select avg(n1) as avg_all 10ms, stddev(n1) as std_all from system.system_stats_twg where c4 = 'CPU_SERIO' and statid like 'WL_10_ORCL%' and n1 > 0,1 and n1 <= 10,0 ) Ausreißer select 'SREADTIM' as Statistik, round(min(n1),2) as min, round(max(n1),2) as max, round(avg(n1),2) as avg, round(stddev(n1),2) as stddev, round((stddev(n1)/avg(n1)*100),0) "% STDV", count(*) as "gült.mess." from system.system_stats_twg where c4 = 'CPU_SERIO' and statid like 'WL_10_ORCL%' and n1 > (select avg_all - std_all from aggr) and n1 < (select avg_all + std_all from aggr); Berechnen von sreadtim STATISTK MIN MAX AVG STDDEV % STDV gült.mess. -------- ---- ---- ---- ------ ------ ---------- SREADTIM 0,57 4,05 2,25 0,9 40 529 Mittelwert aus allen sreadtim innerhalb einer Standardabweichung sreadtim=2,25 ± 0,04

2. Ermitteln von Workload-Statistiken Werte aktivieren Schritt 4: Workload-Statistikwerte festlegen und in aux_stats$ eintragen SQL> begin dbms_stats.set_system_stats(pname=> 'SREADTIM', pvalue=> 2.25); dbms_stats.set_system_stats(pname=> 'MREADTIM', pvalue=> 2.7); dbms_stats.set_system_stats(pname=> 'CPUSPEED', pvalue=> 1400); dbms_stats.set_system_stats(pname=> 'MBRC', pvalue=> 10); dbms_stats.set_system_stats(pname=> 'MAXTHR', pvalue=> 2500000000); dbms_stats.set_system_stats(pname=> 'SLAVETHR', pvalue=> 15000000 ); end; / SQL> select pname, pval1 from sys.aux_stats$ where pval1 is not null; PNAME PVAL1 --------------- --------------... SREADTIM 2.25 MREADTIM 2.70 CPUSPEED 1400.00 MBRC 10.00 MAXTHR 2500000000.00 SLAVETHR 15000000.00 Plausibilitätsregeln beachten: 1. sreadtim < 10ms 2. mreadtim > sreadtim 3. cpuspeed nahe erwarteter Prozessortaktung 4. mbrc nicht unter 3, nicht über 30 5. slavethr 1-2 Größenordnungen unter maxthr

Agenda 1. Einführung 2. Ermitteln von Workload-Statistiken 3. Einfluss der Messintervall-Länge 4. Ungültige Systemstatistiken 5. Mehrere Sätze von Systemstatistiken? 6. Schlussfolgerungen

3. Einfluss der Messintervall-Länge cpuspeed Konturen verschwimmen ab 20minütigen Intervallen Kürzere Messintervalle geben besserer Resultate

3. Einfluss der Messintervall-Länge mbrc Datenbank ORCL1 In dieser Datenbank hat die Intervalllänge kaum einen Effekt auf das Ergebnis. Konsens-Ergebnis: 10 viele NULL-Werte, die NICHT auf den Durchschnitt gerechnet werden

3. Einfluss der Messintervall-Länge mbrc Datenbank ORCL2 Bei mbrc hängt es von dem Workload der Datenbank ab, ob in mreadtim-schwachen Phasen "0" oder "NULL" für mbrc ermittelt wird. NULL-Werte wirken sich nicht auf den Durchschnitt aus. 0 oder nahe 0 Werte haben einen negativen Effekt bei längeren Messintervallen. Nur dort, wo viele Daten entstehen (gestrichelter Kasten), verhält sich die Ermittlung neutral gegenüber der Intervalllänge. viele Werte nahe 0, die auf den Durchschnitt gerechnet werden

3. Einfluss der Messintervall-Länge mreadtim mreadtim Mi 2:00 6:00 5 minütig ORCL1 (links) 4h-Ausschnitt Mittwoch Morgens mreadtim über eine Woche 5 minütig mreadtim Mi 2:00 6:00 10 minütig sehr kleine Werte (nicht NULL) mreadtim Mi 2:00 6:00 20 minütig mreadtim Mi 2:00 6:00 40 minütig ORCL2 (rechts) Wochenausschnitt starke Abhängigkeit von mreadtim zur Intervalllänge; nur dort, wo viele Daten entstehen, hat die Intervalllänge keinen Einfluss; alle anderen Bereiche werden zunehmend gedämpft mreadtim über eine Woche 10 minütig mreadtim über eine Woche 20 minütig mreadtim über eine Woche 40 minütig

Agenda 1. Einführung 2. Ermitteln von Workload-Statistiken 3. Einfluss der Messintervall-Länge 4. Ungültige Systemstatistiken 5. Mehrere Sätze von Systemstatistiken? 6. Schlussfolgerungen

4. Ungültige Systemstatistiken NoWorkload-Statistiken NoWorkload-Statistiken können nicht ungültig werden. Workload-Statistiken Ungültig Workload-Statistiken sind ungültig, wenn einer der vier Werte sreadim oder mreadtim oder cpuspeed oder mbrc fehlt. Sonderfall Bei mreadtim <= sreadtim verwendet der Optimizer die 8i-Formeln für die I/O-Kostenberechnung (MOS 153761.1) Bugs Bug 9842771 in 11.2.0.1 und 11.2.0.2 fügt 3-5 stellige Werte für mreadtim und sreadtim ein

4. Ungültige Systemstatistiken 10053-Optimizer-Trace Was geschieht, wenn nicht alle Workload-Statistiken gesetzt sind? alle Werte gesetzt: cpuspeed oder sreadtim oder mreadtim fehlen: Using WORKLOAD Stats CPUSPEED: 1200 millions instructions/sec SREADTIM: 4.000000 milliseconds MREADTIM: 7.000000 millisecons MBRC: 10 blocks MAXTHR: 100000000 bytes/sec SLAVETHR: 2500000 bytes/sec auch bei invaliden Workload- Statistiken wird ein gesetzter Wert für mbrc berücksichtigt. Using NOWORKLOAD Stats CPUSPEEDNW: 1434 millions instructions/sec (default is 100) IOTFRSPEED: 4096 bytes per millisecond (default is 4096) IOSEEKTIM: 10 milliseconds (default is 10) MBRC: 10 blocks (default is 8) mbrc fehlt oder gar keine Werte: maxthr und slavethr fehlen: Using NOWORKLOAD Stats CPUSPEEDNW: 1434 millions instructions/sec (default is 100) IOTFRSPEED: 4096 bytes per millisecond (default is 4096) IOSEEKTIM: 10 milliseconds (default is 10) MBRC: NO VALUE blocks (default is 8) Using WORKLOAD Stats CPUSPEED: 1200 millions instructions/sec SREADTIM: 4.000000 milliseconds MREADTIM: 7.000000 millisecons MBRC: 10 blocks MAXTHR: -1 bytes/sec SLAVETHR: -1 bytes/sec abgleitet von _db_file_optimizer_read_count solange db_file_multiblock_read_count auf Default oder "0" steht. Fehlende maxthr und slavethr haben keinen Einfluss auf die Gültigkeit von Workload-Statistiken

Agenda 1. Einführung 2. Ermitteln von Workload-Statistiken 3. Einfluss der Messintervall-Länge 4. Ungültige Systemstatistiken 5. Mehrere Sätze von Systemstatistiken? 6. Schlussfolgerungen

5. Mehrere Sätze von Systemstatistiken? Tom Kyte 2003, Effective Oracle by Design, Oracle Press (S. 311f) Noch sehr enthusiastisch, sieht OPTIMIZER_INDEX_CACHING/COST_ADJ abgelöst. Futhermore you will most likely want to have several sets of system statistics gathered on your system, each representing different load profiles it may be necessary to flush the shared pool Jonathan Lewis 2007, System Stats Strategy, http://jonathanlewis.wordpress.com/ This different times of day approach is in principle correct - and an approach that I originally thought to be quite reasonable. There is a problem, however, with caching mechanisms and bad code. You can get into a feedback loop where bad code is protected by (say) a filesystem cache which makes multiblock reads appear to be very fast.... This is why I now lean towards simply setting some times that reflect the actual disk speeds when tested in the absence of Oracle. Christian Antognini 2008, Trouble Shooting Oracle Performance, Apress (S. 116f) It must be said, however, that I have never come across a case that required more than one set of workload statistics. - Was ist bei spontanen Abfragen oder Berichten: Statistiken austauschen und Shared Pool leeren? - Niedrige Werte können bedeuten, dass nichts gemessen wurde, hohe Werte können bedeuten, dass ein System überlastet ist, in beiden Fällen wäre das Anpassen der Workload-Statistiken eine unangemessene Reaktion. Heutiger Konsens: In der Regel sind mehrere Sätze von Systemstatistiken nicht sinnvoll.

Agenda 1. Einführung 2. Ermitteln von Workload-Statistiken 3. Einfluss der Messintervall-Länge 4. Ungültige Systemstatistiken 5. Mehrere Sätze von Systemstatistiken? 6. Schlussfolgerungen

6. Schlussfolgerungen Das Ermitteln von nachvollziehbaren Systemstatistiken ist aufwändig Einzelmessungen erlauben keine Aussage zur Datenqualität. Mehrstündige Messintervalle sind nicht sinnvoll. Gute Intervalllängen sind 5-10 Minuten und sollten über mindestens einen Wochenzyklus laufen. Eine sinnvolle Alternative ist es, CPU- und I/O-Kennzahlen unabhängig von Oracle zu ermitteln. Systemstatistiken müssen auf Plausibilität evaluiert werden, bevor sie in die Tabelle aux_stats$ eingetragen werden. Vier Werte müssen gesetzt sein (nur maxthr, slavethr dürfen fehlen). Wer sollte Workload-Statistiken ermitteln? DBAs, denen keine Beschwerden zur Performance bekannt sind: NEIN. DBAs, die nach Oracle-Anleitung vorgehen und einmalig messen: NEIN. DBAs, die Init-Parameter zur Performancesteigerung ändern (besonders optimizer_index_cost_adj und db_file_multiblock_read_count): JA. Für die meisten Statements wird das Setzen von Workload-Statistiken keine Konsequenzen für Ausführungspläne haben. Es ist in der Regel nicht sinnvoll mehrere Sätze von Systemstatistiken zu ermitteln. Offene Fragen: - Warum gibt es keinen Advisor? - Warum setzt Oracle keine zeitgemäßen Defaultwerte? - Warum gibt es im Enterprise Manager keinen Zugriff auf Systemstatistiken?

Glücksspiel Systemstatistiken Das Märchen vom "typischen Workload" DOAG Konferenz, Nürnberg 2012 Thorsten W. Grebe Grebe@twg-it.de