Sven’s Technik-Blog

Auch ich möchte mit einer Reihe über Features von 11g starten. Ich will dabei nicht berichten, wie einfach es ist, eine bestimmte Funktionalität einzusetzen (dafür gibt es viele andere Blogs, auf die ich gern verweisen werde). Mein Ziel ist es, das Feature zu bewerten und über mögliche Probleme zu informieren.

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!