Wir untersuchen, wo in der gesamten Verarbeitungskette Zeit und Ressourcen verbraucht werden. Dazu verbinden wir das Verhalten des Geschäftsprozesses mit Messdaten aus Anwendung, Datenbank, Infrastruktur und Hintergrundverarbeitung.
Erst wenn Ursache, Auswirkung und Abhängigkeiten nachvollziehbar sind, bewerten wir mögliche Veränderungen an Architektur, Datenstrukturen, SQL, PL/SQL und Verarbeitung.
Eine langsame Anwendung beweist noch kein langsames SQL. Wartezeiten können durch Storage, Speicher, Sperren, konkurrierende Transaktionen, ungünstige Ausführungspläne, wachsende Datenmengen, häufige Datenbankaufrufe oder überlagerte Hintergrundverarbeitung entstehen.
Ein lokaler Engpass lässt sich möglicherweise beseitigen und gleichzeitig an anderer Stelle verschärfen. Deshalb betrachten wir nicht nur einzelne Abfragen, sondern den vollständigen Geschäftsvorgang unter seinen realen Betriebsbedingungen.
01 · Ergebnis
Das relevante Ergebnis bestimmen
Performance ist nur im Kontext eines erwarteten Ergebnisses sinnvoll messbar. Gemeinsam mit Fachseite und Betrieb bestimmen wir deshalb zunächst:
welcher Geschäftsvorgang betroffen ist
welches Ergebnis innerhalb welcher Zeit benötigt wird
welche Datenmengen verarbeitet werden
wie viele Benutzer oder Prozesse gleichzeitig arbeiten
welche zeitlichen Lastspitzen auftreten
welche Stapel- und Hintergrundprozesse beteiligt sind
welche nachfolgenden Abläufe vom Ergebnis abhängen
welche Service- oder Betriebsanforderungen gelten
So entsteht ein gemeinsamer Bezugspunkt für Messung und Bewertung. Ohne diesen Bezug kann eine technische Verbesserung am eigentlichen Kundenproblem vorbeigehen.
02 · Messung
Die Verarbeitungskette unter Last messen
Wir verfolgen den betroffenen Vorgang von der Anwendung über Datenbankprozesse und Speicherbereiche bis zu den physischen Ressourcen.
Dabei betrachten wir abhängig von System, Auftrag und verfügbaren Diagnoseinformationen:
Antwortzeiten und Durchsatz
Verteilung der Zeit auf Verarbeitung und Warten
Datenbank- und Anwendungsaufrufe
Lese- und Schreibvolumen
Speicher- und I/O-Nutzung
Sperren und konkurrierende Transaktionen
Batch-, Job- und Schnittstellenketten
zeitliche Überlagerungen
Wachstum und Verteilung der Daten
Verhalten bei steigender Parallelität
Die Messung soll nicht möglichst viele technische Werte erzeugen. Sie soll erklären, welcher Teil der Verarbeitung das fachliche Ergebnis begrenzt.
03 · Ursachen
Symptome und Ursachen unterscheiden
Hoher Ressourcenverbrauch ist zunächst nur eine Beobachtung. Er erklärt noch nicht, wodurch das Problem entsteht und welche Veränderung tatsächlich helfen würde.
Wir unterscheiden deshalb zwischen:
dem für den Anwender sichtbaren Symptom
dem unmittelbar begrenzenden Verarbeitungsschritt
der technischen oder strukturellen Ursache
den Bedingungen, unter denen das Problem auftritt
den Auswirkungen auf andere Anwendungen und Prozesse
Eine langsame Abfrage kann beispielsweise aus einem ungeeigneten Ausführungsplan entstehen. Die Ursache kann jedoch auch in veralteten Statistiken, einer veränderten Datenverteilung, fehlender Partitionierung oder konkurrierender Verarbeitung liegen.
Diese Trennung verhindert, dass Symptome mit hohem Aufwand behandelt werden, während die eigentliche Ursache bestehen bleibt.
04 · Optimierungsoptionen
Optimierungsoptionen aus dem Befund ableiten
Aus dem Ursachenbild entwickeln wir mögliche Veränderungen. Abhängig vom Befund können sie unterschiedliche Ebenen betreffen:
Arbeitsablauf und zeitliche Steuerung
Datenmodell und Datenverteilung
Tabellen, Indizes und Partitionierung
SQL und PL/SQL
Materialized Views und vorberechnete Datenbestände
Speicher- und Instanzkonfiguration
Parallelität und Transaktionsverhalten
Batch-Größen und Verarbeitungsketten
Archivierung und Datenlebenszyklus
Infrastruktur und Storage
Nicht jede technisch mögliche Maßnahme ist wirtschaftlich oder betrieblich sinnvoll. Wir bewerten deshalb nicht nur die erwartete Beschleunigung, sondern auch Aufwand, Nebenwirkungen, Wartbarkeit und Risiken.
05 · Gesamtbetrieb
Auswirkungen auf den Gesamtbetrieb bewerten
Eine lokale Verbesserung darf nicht unbemerkt andere Prozesse verschlechtern. Zusätzliche Indizes können Schreibvorgänge verteuern. Parallelisierung kann die Laufzeit eines Jobs verkürzen und gleichzeitig konkurrierende Anwendungen verdrängen. Vorberechnete Datenbestände können Lesevorgänge entlasten, benötigen aber Speicher, Aktualisierungsverfahren und Kontrollen.
Für wesentliche Optionen beschreiben wir daher Auswirkungen auf:
Antwortzeit und Durchsatz
Schreib- und Leseverarbeitung
konkurrierende Anwendungen
Speicher- und Infrastrukturbedarf
Lade-, Wartungs- und Sicherungsverfahren
Datenaktualität und Datenintegrität
Wiederanlauf und Fehlerbehandlung
Entwicklungs- und Betriebsaufwand
Release- und Migrationsfähigkeit
Damit wird aus einer technischen Tuningidee eine nachvollziehbare Architektur- und Betriebsentscheidung.
06 · Vergleich
Veränderungen vergleichbar prüfen
Soweit Messumgebung, Berechtigungen und Auftrag es erlauben, vergleichen wir den Zustand vor und nach einer Veränderung unter nachvollziehbaren Bedingungen.
Dabei betrachten wir nicht nur die Laufzeit einer Einzelabfrage, sondern beispielsweise:
Wirkung auf den vollständigen Geschäftsvorgang
Durchsatz bei vergleichbarer Last
Ressourcenverbrauch
Verhalten unter Parallelität
Auswirkungen auf andere Verarbeitung
mögliche Regressionen
Stabilität über längere Verarbeitungszeiträume
Wo ein unmittelbarer Vergleich nicht möglich ist, kennzeichnen wir Annahmen, Unsicherheiten und noch erforderliche Nachweise ausdrücklich.
07 · Entscheidung
Optionen entscheidungsfähig aufbereiten
Wir verdichten technische Messdaten und Befunde zu priorisierten Handlungsoptionen. Für jede wesentliche Option werden beschrieben:
adressierte Ursache
erwartete Wirkung
betroffene Systeme und Prozesse
notwendige Voraussetzungen
mögliche Nebenwirkungen
erforderliche Mitwirkung
Prüf- und Vergleichskriterien
verbleibende Risiken
zuständige Entscheidungsstellen
Die Entscheidung über Umsetzung, Investition und produktive Freigabe verbleibt bei den jeweils verantwortlichen Stellen.