Wenn man das Statspack auf einem RAC benutzen will, kann es laut Jonathan Lewis dazu kommen, dass sich die einzelnen Instanzen beim Zugriff auf die DB gegenseitig locken.
"Now there’s no reason why Statspack should
lock up a RAC cluster – in principle. But this was an 8-node cluster and
if you set up the automatic job to take snapshots by running the
default spauto.sql script all eight nodes
could start running every hour on the hour – so they would all be
fighting constantly for every block of every table and index in the Statspack
schema. (I’m exaggerating for effect, of course, but not by much). You
might not notice the global cache contention in a 2-node cluster but
eight nodes could, indeed, “lock up the system” at this point."
Sein Artikel bezieht sich zwar auf die 10g, aber es sieht so aus, als könnte es dieses Risiko in der 11g und höher weiterhin geben.
Auch ist RAC mit 2 Nodes wohl nicht gefährdet. Ich habe trotzdem ein wenig weiter gegraben. Hier http://www.oracle-class.com/?p=2384 ist ein guter Artikel, in dem beschrieben wird, wie man das Statspack auf einem 4-Node-RAC ausführen lässt. Die Anleitung bezieht sich ebenfalls auf Jonathan Lewis und nutzt sehr anschaulich DBMS_SCHEDULER und Services um die einzelnen Nodes gezielt anzusprechen.
Die Skripte lassen sich - geringfügig angepasst - so nutzen.
Posts mit dem Label Performance werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Performance werden angezeigt. Alle Posts anzeigen
Dienstag, 8. Juli 2014
Freitag, 6. Juni 2014
Die In-Memory-Option - Oracles Antwort auf HANA
Vor 1,5 Jahren habe ich mich das erste mal mit dem Phänomen HANA beschäftigt. Seitdem ist eine Menge passiert und Oracle hat reagiert.
Am vergangenen Dienstag war ich auf der DOAG 2014 Datenbank in Düsseldorf und kam wieder einmal mit dem Thema in Berührung. Günter Stürner (Oracle) hielt dort die Keynote.
Der Focus seiner Rede lag auf der kommenden In-Memory-Option („Turbo Boost für die Datenbank“) der Datenbank und der Abgrenzung zur HANA.
Ein paar Sachen haben mich an meinen Text erinnert. Zeit sich den alten Kram wieder anzusehen… ich kann behaupten, dass ich gar nicht einmal falsch lag. :)
Vieles, was zwischen SAP und Oracle zum Thema In-Memory ausgetauscht wurde und wird, ist natürlich reines Marketing. SAP will seine eigene DB verkaufen und Oracle seine Marktführerschaft ausbauen bzw. nicht verlieren.
Die Existenz von HANA ist dabei meiner Meinung nach an sich keine Gefahr für Oracle. HANA steht vielmehr für die Gefahr, dass Oracle aus Kundensicht die Fähigkeit verlieren könnte, die wichtigen technischen Trends zu setzen und als Saurier dasteht.
Oracle versucht den In-Memory-Hype einerseits etwas abzuschwächen, indem sie darauf aufmerksam machen, dass dieses Thema nichts Neues ist. Andererseits wollen sie auf der Welle mitreiten. (Man ist SAP für die Marketingvorarbeit zu Thema In-Memory dankbar.)
Dabei wird dann noch klar gestellt, dass es weniger um In-Memory geht, sondern vielmehr und die Frage „Arbeitet die Datenbank der Zukunft zeilen- oder spaltenorientiert?“. (columnar)
Diese Frage hat Oracle für sich etwa so beantwortet:
Je nach Anwendungsfall ist die eine oder die andere Technologie sinnvoller. Oracle bietet beides in einem Produkt an. Auf dem Storage liegen die Daten zeilenorientiert und im Hauptspeicher werden sie auf Wunsch spaltenorientiert verarbeitet.
(So würde ich das zusammenfassen und ich kann nicht sagen, dass ich diesen Ansatz schlecht fände.)
Ganz nebenbei wuchert Oracle mit dem Pfund, eine ausgereifte, skalierbare Enterpriselösung (Backup, RAC, DataGuard, Vault…) anbieten zu können: SAP müsse schließlich erst noch aus HANA eine Enterpriselösung machen.
In der Keynote hat Günter Stürner dargestellt, wie einfach die Lösung implementiert ist. Ein einfaches „ALTER TABLE <tablename> INMEMORY;“ lädt die Tabelle „columnar“ in den Hauptspeicher. Der Zugriff soll sich bis um den Faktor 100 beschleunigen. Das soll auch mit Tablespaces, Partitionen und sogar der ganzen Datenbank funktionieren – falls die DB dort hineinpasst.
Ich denke, dass man sich um Oracle keine Sorgen machen muss. Am 11.06.2014 soll die In-Memory-Option für die 12c vorgestellt werden. (Am 17.06.2014 kann man sich das live in Frankfurt ansehen.) Wenn es tatsächlich so ist, dass die Option für die Applikation transparent nutzbar ist, kann Oracle sich zurücklehnen und sagen:
"Hey, SAP hat nur HANA, wir haben HANA on board - und wir lassen uns das ebenfalls sehr gut bezahlen." ;)
Ich freu mich schon darauf „ALTER DATABASE INMEMORY;“ testen zu können. Eine DB, die in den Hauptspeicher passt und mit einem suboptimalen Datenmodell glänzt, habe ich für den Performancetest. :)
Am vergangenen Dienstag war ich auf der DOAG 2014 Datenbank in Düsseldorf und kam wieder einmal mit dem Thema in Berührung. Günter Stürner (Oracle) hielt dort die Keynote.
Der Focus seiner Rede lag auf der kommenden In-Memory-Option („Turbo Boost für die Datenbank“) der Datenbank und der Abgrenzung zur HANA.
Ein paar Sachen haben mich an meinen Text erinnert. Zeit sich den alten Kram wieder anzusehen… ich kann behaupten, dass ich gar nicht einmal falsch lag. :)
Vieles, was zwischen SAP und Oracle zum Thema In-Memory ausgetauscht wurde und wird, ist natürlich reines Marketing. SAP will seine eigene DB verkaufen und Oracle seine Marktführerschaft ausbauen bzw. nicht verlieren.
Die Existenz von HANA ist dabei meiner Meinung nach an sich keine Gefahr für Oracle. HANA steht vielmehr für die Gefahr, dass Oracle aus Kundensicht die Fähigkeit verlieren könnte, die wichtigen technischen Trends zu setzen und als Saurier dasteht.
Oracle versucht den In-Memory-Hype einerseits etwas abzuschwächen, indem sie darauf aufmerksam machen, dass dieses Thema nichts Neues ist. Andererseits wollen sie auf der Welle mitreiten. (Man ist SAP für die Marketingvorarbeit zu Thema In-Memory dankbar.)
Dabei wird dann noch klar gestellt, dass es weniger um In-Memory geht, sondern vielmehr und die Frage „Arbeitet die Datenbank der Zukunft zeilen- oder spaltenorientiert?“. (columnar)
Diese Frage hat Oracle für sich etwa so beantwortet:
Je nach Anwendungsfall ist die eine oder die andere Technologie sinnvoller. Oracle bietet beides in einem Produkt an. Auf dem Storage liegen die Daten zeilenorientiert und im Hauptspeicher werden sie auf Wunsch spaltenorientiert verarbeitet.
(So würde ich das zusammenfassen und ich kann nicht sagen, dass ich diesen Ansatz schlecht fände.)
Ganz nebenbei wuchert Oracle mit dem Pfund, eine ausgereifte, skalierbare Enterpriselösung (Backup, RAC, DataGuard, Vault…) anbieten zu können: SAP müsse schließlich erst noch aus HANA eine Enterpriselösung machen.
In der Keynote hat Günter Stürner dargestellt, wie einfach die Lösung implementiert ist. Ein einfaches „ALTER TABLE <tablename> INMEMORY;“ lädt die Tabelle „columnar“ in den Hauptspeicher. Der Zugriff soll sich bis um den Faktor 100 beschleunigen. Das soll auch mit Tablespaces, Partitionen und sogar der ganzen Datenbank funktionieren – falls die DB dort hineinpasst.
Ich denke, dass man sich um Oracle keine Sorgen machen muss. Am 11.06.2014 soll die In-Memory-Option für die 12c vorgestellt werden. (Am 17.06.2014 kann man sich das live in Frankfurt ansehen.) Wenn es tatsächlich so ist, dass die Option für die Applikation transparent nutzbar ist, kann Oracle sich zurücklehnen und sagen:
"Hey, SAP hat nur HANA, wir haben HANA on board - und wir lassen uns das ebenfalls sehr gut bezahlen." ;)
Ich freu mich schon darauf „ALTER DATABASE INMEMORY;“ testen zu können. Eine DB, die in den Hauptspeicher passt und mit einem suboptimalen Datenmodell glänzt, habe ich für den Performancetest. :)
Freitag, 19. April 2013
Systemstatistiken
In der 01/2013 der DOAG News ist ein sehr empfehlenswerter Artikel von Thorsten W. Grebe über die Oracle Systemstatistiken zu finden: “Glücksspiel Systemstatistiken - Das Märchen vom typischen Workload“ (S.52) Auf www.twg-it.de ist dazu sein Vortrag auf der DOAG-Konferenz zu finden.
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:
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:
Workloadstatistiken lassen sich natürlich auch manuell einstellen (dbms_stats.set_systems_stats(...)) oder auf Default zurücksetzen (dbms_stats.delete_system_stats()):
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.
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.
Abonnieren
Posts (Atom)