Hr. Grebe stellt in dem DOAG-News-Artikel sehr gut dar, dass es nicht so einfach ist, an verlässliche Systemstatistiken zu kommen, wie Oracle es in seiner Doku unterstellt.
Hier sieht man die Defaultwerte einer unberührten DB:
SQL> set wrap off; SQL> col sname format a20; SQL> col pname format a20; SQL> col pval2 format a20; SQL> select * from aux_stats$; SNAME PNAME PVAL1 PVAL2 -------------------- -------------------- ---------- -------------------- SYSSTATS_INFO STATUS COMPLETED SYSSTATS_INFO DSTART 11-03-2011 06:38 SYSSTATS_INFO DSTOP 11-03-2011 06:38 SYSSTATS_INFO FLAGS 1 SYSSTATS_MAIN CPUSPEEDNW 1720,20725 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 13 Zeilen ausgewählt. Abgelaufen: 00:00:00.01 SQL>Die No-Workloadwerte sind IOSEEKTIM und IOTFRSPEED.
Die Workloadstatistiken waren mir schon lange suspekt. Weil ich mir bisher nie sicher war, wann und wie lang ich die Workloadstatistiken aufzeichnen soll, habe ich es lieber ganz sein lassen. Und das ist bis auf weiteres auch in Ordnung. Für gute Workloadstatistiken muss mehr Aufwand betrieben werden, als Oracle Glauben machen will.
Und hier gilt diesmal im Gegensatz zu den Objektstatistiken: Lieber Defaultstatistiken als schlechte Statistiken.
Wobei: Für die No-Workloadstatistiken gilt das nicht ganz, bzw. ist hier zumindest der Aufwand nicht so hoch, wie für die Generierung plausibler Workloadstatistiken.
Die No-Workload-Statistiken kann man ruhig generieren, wenn man auch tatsächlich prüft, ob die Werte sinnvoll sind. Wird der DB-Server gerade stark beansprucht, während die No-Workloadwerte generiert werden, können auch diese Statistiken verfälscht werden.
No-Workloadstatistiken generiert man mit dem Package DBMS_STATS:
SQL> exec DBMS_STATS.GATHER_SYSTEM_STATS(); PL/SQL-Prozedur erfolgreich abgeschlossen. Abgelaufen: 00:00:08.95 SQL> select * from aux_stats$; SNAME PNAME PVAL1 PVAL2 -------------------- -------------------- ---------- -------------------- SYSSTATS_INFO STATUS COMPLETED SYSSTATS_INFO DSTART 04-19-2013 07:32 SYSSTATS_INFO DSTOP 04-19-2013 07:32 SYSSTATS_INFO FLAGS 1 SYSSTATS_MAIN CPUSPEEDNW 1460 SYSSTATS_MAIN IOSEEKTIM 7 SYSSTATS_MAIN IOTFRSPEED 28796 SYSSTATS_MAIN SREADTIM SYSSTATS_MAIN MREADTIM SYSSTATS_MAIN CPUSPEED SYSSTATS_MAIN MBRC SYSSTATS_MAIN MAXTHR SYSSTATS_MAIN SLAVETHR 13 Zeilen ausgewählt. Abgelaufen: 00:00:00.00 SQL>
Workloadstatistiken lassen sich natürlich auch manuell einstellen (dbms_stats.set_systems_stats(...)) oder auf Default zurücksetzen (dbms_stats.delete_system_stats()):
SQL> exec DBMS_STATS.DELETE_SYSTEM_STATS (); PL/SQL-Prozedur erfolgreich abgeschlossen. Abgelaufen: 00:00:00.01 SQL> select * from aux_stats$; SNAME PNAME PVAL1 PVAL2 -------------------- -------------------- ---------- -------------------- SYSSTATS_INFO STATUS COMPLETED SYSSTATS_INFO DSTART 04-19-2013 07:38 SYSSTATS_INFO DSTOP 04-19-2013 07:38 SYSSTATS_INFO FLAGS 0 SYSSTATS_MAIN CPUSPEEDNW 1460 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 13 Zeilen ausgewählt. Abgelaufen: 00:00:00.00 SQL>
Beruhigend: Erst wenn man tatsächlich Performanceprobleme und die Systemstatistiken als Ursache identifiziert hat, muss man sich eingehend mit dem Thema befassen.
Bis dahin gilt weiter: Ursache Nr.1 für Performanceprobleme in der Anwendung ist schlechtes SQL.
sehr interessante Präsentation - Danke für den Hinweis. Randolf Geist hat vor ein paar Jahren zum Thema eine Artikelserie geschrieben (Teil 1: http://oracle-randolf.blogspot.de/2009/04/understanding-different-modes-of-system.html), die recht detailliert auf die Folgen für's Costing eingeht.
AntwortenLöschen