Patch sets provide bug fixes only; they do not include new functionality and they do not require certification on the target system.

Wie in diesem Blogeintrag zu sehen ist, gibt es weitere neue Funktionen, worüber sich die "Performance Junkies" freuen werden

Download: www.trivadis.com -> Know-how-Center -> Publikationen
Oder direkt hier.

Diese Aussage stimmt so inzwischen nicht mehr.

Mein Kollege Chris war gestern ganz erstaunt, dass Oracle 9.2.0.8 im Execution-Plan folgendes ausgab:

------------------------------------------------------------
| Id | Operation                | Name | Pstart  | Pstop   |
------------------------------------------------------------
|  0 | SELECT STATEMENT         |      |         |         |
|  1 | PARTITION RANGE ITERATOR |      | KEY(MC) | KEY(MC) |
|* 2 | TABLE ACCESS FULL        | T    | KEY(MC) | KEY(MC) |
------------------------------------------------------------
 

KEY(MC) heisst aber "Multi-column partition pruning"!

Ich habe dies dann in einer 9.2.0.7 Datenbank ausgetestet - dort funktioniert es nicht...
Nach diversen Tests in unterschiedlichen Oracle-Versionen hat Chris dann folgendes festgestellt:
Oracle hat einen Backport dieses Features auf 9.2.0.8 und 10.1.0.5 vorgenommen. In allen älteren 10.1 und 9.2-Versionen funktioniert es nicht.

Was heisst das nun - oder ?
- Ein wichtiges Feature wurde in noch häufig benutzte Versionen eingebaut.
- Hoffentlich wurde das in den doch sehr komplexen Optimizer auch richtig implementiert...

Das in meinem letzten Blog-Eintrag beschriebene Database Replay kann einiges nicht:

• Nur einzelne Statements analysieren
• Statements, die auf eine bestimmte Tabelle zugreifen, analysieren
• Zusätzliche (nicht aufgezeichnete) Statements analysieren
• Auf Detailebene Statistiken und Ausführungspläne analysieren

Genau diese Punkte sind die Stärken des SQL Performance Analyzer (SPA).

Ein kleines Beispiel: Ich habe den TPC-H-Benchmark von Hammerora laufen lassen, danach optimizer_index_cost_adj von 100 auf 10 gesetzt, die gleichen Statements nochmals laufen lassen und die Resultate verglichen:

Cool

Aber wie immer - Es ist noch nicht 100% perfekt:
Ich würde mir wünschen, dass die Performanceauswirkungen einer Migration vorhergesehen werden können. Nun kann ich zwar mit Oracle 10g ein SQL Tuningset erzeugen, dies in 11g importieren und dort analysieren. Leider werden nur die Statements, nicht aber die Statistiken und Ausführungspläne übernommen. D.h., die Statements werden mit 11g neu ausgeführt - und können auch nur mit 11g verglichen werden.
Zwar kann ich z.B. den Optimizer von 10g (und auch früher) simulieren - aber es ist doch nicht das gleiche.
Also - das wäre noch mein Wunsch: Die Statistikdaten von 10g mit übernehmen und auch mit vergleichen. Dies würde das sehr gute Tool nochmals aufwerten.

OK - starten wir mit Database Replay. Ein guter Einstieg dazu ist der Artikel von Arup Nanda. Empfehlen würde ich aber, nicht alles per Enterprise Manager zu "klicken", sondern sich etwas mit dem PL/SQL-API zu beschäftigen. Dies ist nicht so komplex - und wenn erst mal die Scripts existieren, ist alles viel leichter nachvollziehbar.

Ich habe nun viel Zeit investiert, um zu testen, ob die Ergebnisse wirklich aussagekräftig sind.

Management Summery:

• Reine Abfragen: perfekt
• Abfragen und DML-Operationen ohne Locking-Probleme: perfekt
• DML-Operationen mit vielen Locking-Problemen: in den ersten Versuchen nicht gut...

Zuerst ein kleines Beispiel des Ergebnisses (in HTML - erzeugt aber auch per SQL-Script):

Hier sieht man schön, dass die Statements im ersten Lauf (capture) und im zweiten Lauf (replay) wieder auftreten und (bis auf ein paar interne Aufrufe) auch gleich oft ausgeführt werden.

Gestartet habe ich hier in 5 parallelen Session (zeitverschoben um jeweils 1 Sekunde aufgerufen) zuerst jeweils 100'000 Selects. Danach in jeder Session ein Update des gleichen Datensatzes, gefolgt von einer Pause von 20 sek. - und danach erst das Commit. Dadurch sind natürlich Lockingprobleme entstanden.
Diese waren aber nur beim Capture sichtbar, nicht beim Replay, d.h. die Update-Statements waren im zweiten Lauf nicht im Report, da sie zu schnell ausgeführt wurden und nicht unter die "Top 10" gelandet sind.

Das "Problem" ist, dass Oracle standardmässig die Transaktionen synchronisiert, um die gleiche Commit-Reihenfolge (logische Abfolge) sicherzustellen. Anders gesagt, Oracle startet beim Replay erst die nächste Transaktion, wenn die vorherige beendet ist - und damit werden natürlich Lockingprobleme im Multiuser-Betrieb ausgeschlossen...

Lösung:
Während des Replay den Parameter "synchronization" auf FALSE setzen:

 
BEGIN
   DBMS_WORKLOAD_REPLAY.PREPARE_REPLAY(synchronization => FALSE);
END;
/
 

Und damit waren für mich auch die DML-Operationen mit Locking-Problemen perfekt.
Aber aufpassen - dies muss nicht immer richtig sein. Hier kann die Transaktionsreihenfolge durcheinander kommen - und dies kann zu falschen Resultaten führen.

Deswegen: Bevor mit Database Replay Änderungen getestet werden, sollte erst einmal untersucht werden, ob Capture und Replay ohne Änderungen identisch sind - oder aber ob hier schon total unterschiedliche Ergebnisse auftreten!

Ansonsten: Für mich bis jetzt das heisseste Feature von 11g!

• Lizenzpflichtig
• Nur für Windows (ok, läuft auch mit Wine unter Linux)

In Laurent Schneider's Blog habe ich nun eine Alternative gefunden: Den Online SQL Formater SQLinForm.

Schnell mal getestet - cooles Tool

Auf jeden Fall geeignet, um Code lesbarer zu machen. Sicherlich auch, um Cursorsharing (etwas) zu verbessern.

Kleines Beispiel:
Folgende 4 Statements sind für Oracle unterschiedlich und sind nicht "sharable":

select * from emp;
SELECT * FROM emp;
Select * From emp;
select * froM emp;


SQLinForm formatiert dies richtigerweise auf:
SELECT * FROM emp;

Und dies kann beliebig komplexer werden - probieren Sie es aus

The use of functions - a function with other selects (eg. calculate availability of a part) - is slowing down our system when we do a select over our product file.
Is there some kind of rule when functions should be used or when we should try to create a more complex - combined - SQL that does not use the function.
Can functions be used in the where clause without loosing a lot of speed?

Ein guter, empfehlenswerte Artikel.

Was ich aber noch erwähnen würde:
Wenn ich aus SQL eine PL/SQL-Function aufrufe, die wiederum ein SQL ausführt, wird jeweils ein Kontext-Switch zwischen SQL-Engine und PL/SQL-Engine und nochmals SQL-Engine durchgeführt. Dieser dauert nicht sehr lang, sagen wir mal eine Millisekunde. Aber wenn ich dies 1'000'000 mal mache, sind das schon 2'000'000 ms - als mehr als eine halbe Stunde...

• Critical Patch Update - und Ihre Applikation funktioniert noch?
  Ein Critical Patch ist wichtig für die Security. Aber läuft dann die Datenbank noch?
  Macht die Applikation noch, was von ihr erwartet wird?
  In diesem Vortrag wird eine Methode des automatischen Testens vorgestellt.
  Ausserdem werden die Erfahrungen mit den CPUs präsentiert.
• End-to-End-Tracing live gezeigt
  Grid Control 10.2 verspricht echtes End-to-End-Tracing. Und es funktioniert wirklich.
  Nach der Definition von Applikationen kann man ein Drill-Down vom WebServer
  über Middletier bis zum einzelnen Statement in der Datenbank durchführen.
  Also das, was sich jeder schon gewünscht hat.
  In einer einstündigen Demo werden die Möglichkeiten und Grenzen live gezeigt.

Mehr Informationen - und den Anmeldelink findet ihr auf der DOAG-Seite.

Die Teilnahme ist wie immer kostenlos - aber nicht umsonst