Umgang mit Oracle Toplink und die Suche nach DB Performance

O'zapft is!

Lars Wunderlich

Oracle Toplink ist der Klassiker unter den O/R Mapping Tools und erfreut sich trotz JDO-Open-Source-Lösungen und Container Managed Persistence durch Application Server weiterhin großer Beliebtheit. Toplink lässt sich schließlich auch standalone ohne und mit J2EE-Server gut für Großanwendungen einsetzen. Falsche Konfiguration und unglücklicher Einsatz können aber auch schnell zur Enttäuschung führen und in einer verzweifelten Suche nach Bottlenecks enden. Dieser Artikel erläutert Fallstricke und versteckte Performancequellen nicht nur für Toplink User.

Obwohl Toplink [1] als Unterprodukt des Oracle Application Server angeboten wird, pictureet es das gesamte Spektrum des objektrelationalen Mappings einfacher Java-Objekte bis hin zum Einsatz von Enterprise Entity Beans ab. Wobei wir uns primär auf Ersteres konzentrieren wollen. Man könnte sicher ein ganzes Buch über das Thema Datenbankperformance schreiben, dieser Artikel versucht trotzdem wesentliche Aspekte in der Anwendung von Toplink und bei der Suche nach Geschwindigkeitsreservoirs aufzuzeigen.

Abb. 2: Angriffspunkte für Performancemessungen

Interessanterweise wird die Performance von Java-Applikationen immer noch häufiger angezweifelt als die von Datenbanken oder DBM-Systemen. Dabei beginnt für viele Performancehungrige hier das unentdeckte Land. Wissen Sie, wie viele Connections von der Datenbank Ihnen zur Verfügung stehen? Welche SQLs werden am häufigsten ausgeführt? Welche Indizes auf Where– oder OrderBy-Elemente fehlen? Wie exakt sind Ihre Where-Bedingungen formuliert? Welche Teile von dynamischem JDBC lassen sich durch statistische Datenbank-Views optimieren? Welche Zugriffspfade nimmt der Datenbank-Optimizer bei der Erzeugung Ihrer Ergebnismenge? Wie viele Full-Table Scans laufen auf Ihrer Anwendung? Wann wurden die Statistiktablen der Datenbank das letzte Mal aktualisiert? Wann lief der letzte Reorg der Datenbank? Wie sieht der Isolation Level für parallele Datenbankzugriffe auf Ihrer Datenbank aus? Wie viel Speicher hat ihr DBMS, auf welchem Dateisystem geschieht die Datenorganisation? Wie groß sind Prefetching und Logfile-Größen? …Sie sehen, das Thema Performance lässt Freiraum für enormes Potenzial in allen Bereichen. Vermindern Sie beim Design neuer Anwendungen das Risiko von Fehlern durch Verringerung der Komplexität und machen Sie jede einzelne Architekturkomponente für sich messbar, um an den wirklich großen Performanceschrauben zu drehen. Caching ist nur einer von vielen Lösungsansätzen dabei.Lars Wunderlich arbeitet in seiner Funktion als Software Engineer als Systemarchitekt und OO-Coach im Bereich der Entwicklung von Unternehmensanwendungen mit J2EE-Technologie bei TUI InfoTec.Links und Literatur[1] otn.oracle.com/products/ias/toplink/[2] java.sun.com/products/jta/[3] www.pocketsoap.com/tcptrace/[4] java.sun.com/products/JavaManagement/[5] eclipse.org/aspectj/[6] www.quest.com/jprobe/

Geschrieben von
Lars Wunderlich
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.