Am Anfang war sie schnell. Inzwischen dauert der Aufruf einer Übersicht mehrere Sekunden, ein Bericht wird von den Anwendern nur noch morgens vor der Arbeit gestartet, und in Spitzenzeiten hört man den Satz: „Das System ist wieder langsam."
Meist ist nicht die Anwendung schlechter geworden, sondern die Datenmenge größer — bis zu dem Punkt, an dem eine Abfrage nicht mehr funktioniert, die jahrelang unauffällig war.
Zuerst messen, dann ändern
Performance-Arbeit ohne Messung ist Raten mit Rechnung. Wir fangen deshalb immer bei der Frage an, wo die Zeit tatsächlich bleibt:
- Welche Seiten sind betroffen? Die APEX-Aktivitätsprotokolle zeigen Laufzeiten je Seite und wie oft sie aufgerufen werden. Eine Seite, die drei Sekunden braucht und hundertmal am Tag geöffnet wird, ist wichtiger als eine, die zehn Sekunden braucht und einmal im Monat.
- Was passiert auf diesen Seiten? Welche Statements laufen wirklich, wie sehen ihre Ausführungspläne aus, wie viele Zeilen werden angefasst, um am Ende zwanzig anzuzeigen.
- Wann tritt es auf? Immer, oder nur bei Lastspitzen, im Monatsabschluss, während eines Batch-Laufs?
- Wo endet unsere Anwendung? Manchmal wartet nicht die Datenbank, sondern ein Fremdsystem am anderen Ende einer Schnittstelle.
Erst danach entsteht eine Liste von Maßnahmen — nach erwartetem Effekt und Aufwand sortiert, damit Sie entscheiden können, was sich lohnt.
Was in der Praxis die Zeit kostet
Die Ursachen wiederholen sich, in gewachsenen Anwendungen fast unabhängig von der Branche:
- Abfragen, die mit der Datenmenge nicht mitgewachsen sind. Fehlende oder falsche Indizes, Filter, die erst nach dem Laden greifen, Sortierungen über Millionen Zeilen.
- Berichte ohne Vorfilterung. Eine Übersicht, die grundsätzlich alles lädt, weil zum Zeitpunkt der Entwicklung „alles" ein paar hundert Zeilen waren.
- Logik in Schleifen. PL/SQL, das Zeile für Zeile abarbeitet, was ein einzelnes Statement erledigen könnte.
- Arbeit, die bei jedem Seitenaufruf neu passiert. Berechnungen und Abfragen, deren Ergebnis sich nur selten ändert.
- Zu viel auf einer Seite. Zehn Regionen, die alle beim Aufbau der Seite ihre Daten holen, statt bei Bedarf.
- Veraltete Versionen. Manche Verbesserung ist kein Tuning, sondern ein Update — dann sagen wir das.
Was Sie danach in der Hand haben
Sie erhalten eine Bestandsaufnahme, die benennt, welche Seiten wie viel Zeit kosten, worin die Ursache liegt und welche Maßnahme welchen Effekt hätte. Was umgesetzt wird, entscheiden Sie — durch uns, durch Ihr eigenes Team oder gemeinsam.
Dieser letzte Punkt ist uns wichtig: Performance-Arbeit ist der Bereich, in dem sich Wissen am schnellsten überträgt. Wenn Ihre Entwickler dabei sind, wenn ein Ausführungsplan gelesen und ein Statement umgeschrieben wird, erkennen sie das Muster beim nächsten Mal selbst. Wir arbeiten deshalb gern mit Ihrem Team statt an ihm vorbei.
Aus über 25 Jahren Arbeit mit Oracle-Datenbanken kennen wir beide Seiten — die APEX-Ebene und das, was darunter in der Datenbank passiert. Erfahrungsgemäß liegt die Ursache häufiger unten als oben.
Wenn die Architektur die Bremse ist
Es gibt Fälle, in denen einzelne Optimierungen nicht reichen: wenn ein Datenmodell für einen anderen Zweck gebaut wurde, wenn Auswertung und Erfassung sich gegenseitig blockieren, wenn eine Anwendung Aufgaben übernommen hat, für die sie nie gedacht war. Dann ist Tuning nur eine Verzögerung des eigentlichen Problems.
In dieser Lage sagen wir es deutlich und rechnen beide Wege vor: weiter optimieren oder den betroffenen Teil neu bauen. Was von beidem sinnvoll ist, hängt davon ab, wie lange die Anwendung noch tragen soll — nicht davon, was für uns der größere Auftrag wäre.
Ihr nächster Schritt
Sagen Sie uns, welche Seite oder welcher Bericht am meisten stört und seit wann. Häufig lässt sich schon im Erstgespräch einschätzen, ob es sich um einen einzelnen Engpass oder ein grundsätzliches Thema handelt.
Direkt Termin vereinbaren oder
Häufige Fragen zu Performance-Problemen
Woran liegt es meistens, wenn eine APEX-Anwendung langsam ist? Fast immer an Datenmengen, die beim Bau der Anwendung niemand erwartet hat, und an SQL, das damit nicht umgehen kann: fehlende Indizes, Abfragen über zu viele Zeilen, Berichte ohne sinnvolle Vorfilterung, Logik in Schleifen statt im Statement. Deutlich seltener ist die APEX-Ebene selbst schuld — und noch seltener die Hardware, obwohl sie oft zuerst verdächtigt wird.
Wie finden Sie heraus, wo die Zeit verloren geht? Mit Messung statt Vermutung: APEX-Aktivitätsprotokolle zeigen, welche Seiten wie lange brauchen und wie oft sie aufgerufen werden. Für die auffälligen Seiten sehen wir uns die tatsächlich ausgeführten Statements und ihre Ausführungspläne an. Erst wenn klar ist, wo die Zeit bleibt, wird etwas geändert.
Müssen Sie dafür die Anwendung umbauen? In der Regel nicht. Die meisten Verbesserungen entstehen an einzelnen Stellen: ein Index, eine umgeschriebene Abfrage, ein Bericht, der nicht mehr ungefiltert alles lädt, eine teure Berechnung, die nicht bei jedem Seitenaufruf neu läuft. Ein Umbau ist erst nötig, wenn die Architektur selbst nicht trägt — und dann sagen wir das, statt an Symptomen weiterzuarbeiten.
Können Sie garantieren, dass es danach schneller ist? Eine Zahl garantieren wir nicht, bevor wir gemessen haben. Was wir zusagen können: Nach der Analyse wissen Sie, welche Stellen wie viel Zeit kosten, welche Maßnahme welchen Effekt hätte und was davon Aufwand lohnt. Es kommt vor, dass die ehrliche Antwort lautet: Die größte Bremse liegt außerhalb der Anwendung — etwa in einem Fremdsystem, das auf Anfragen wartet.
Was ist, wenn die Anwendung nur zu bestimmten Zeiten langsam ist? Das ist ein wichtiger Hinweis und meist der ergiebigste Fall: Lastspitzen, nächtliche Batch-Läufe, ein Monatsabschluss, gleichzeitige Reports. Solche Muster sind in den Protokollen sichtbar, wenn man über einen längeren Zeitraum hinsieht statt auf einen Moment.
Weiter: Support und Übernahme · Migration von Oracle Forms · Neuentwicklung · zurück zur Übersicht Oracle APEX.