Zeichnung: Links ein kleiner, leiser Server zwischen Pflanzen, daneben ein entspannter Mann mit Kaffee – die Suche ist schon fertig. Rechts ein riesiger, qualmender, brennender Server und ein verzweifelter Mann mit Kopfhörern – er sucht immer noch.
David gegen Goliath

Abrüsten. Und trotzdem schneller.

Optimierung heißt: erst messen, wo die Zeit wirklich bleibt – dann genau dort beheben, statt Hardware zu kaufen.

  • Neuen Server gekauft – und es ist immer noch langsam?
  • Der Nachtlauf ist morgens nicht fertig – und alle warten?
  • Niemand traut sich mehr an die alten Programme, weil keiner weiß, was daran hängt?
  • Was, wenn Ihr alter Server schneller wäre als der neue?
  • Im Tagesgeschäft hängt alles – und im Test ist nichts zu sehen?
  • Mehr Server, mehr Lizenzkosten – und die Wartezeit bleibt?
  • Ihr Server sucht die Nadel im ganzen Heuhaufen. Mit Optimierung greift er sofort zu.
  • Wie viel Hardware kaufen Sie noch, bevor jemand nachmisst, wo die Zeit bleibt?
  • Strom verbrennen für Arbeit, die niemand braucht?
  • Kleiner Rechner mit Optimierung: ein Wimpernschlag. Großer ohne: 18 Sekunden.

Gemessen im eigenen Labor

Ein Beispiel aus dem Labor: schwächerer Rechner, trotzdem schneller

Dieselbe Suche in einer Tabelle mit 100 Millionen Zeilen. Wartezeit in Sekunden, kürzer ist besser.

Starker Rechner ohne Optimierung8 statt 2 Prozessorkerne, 10-facher Arbeitsspeicher
17,8 s
Schwacher Rechner ohne OptimierungBasis
30,9 s
Schwacher Rechner MIT Optimierungderselbe schwache Rechner
unter 0,01 s
  • 4-mal so viele Prozessorkerne und 10-mal so viel Arbeitsspeicher machten die Suche nur 1,7-mal schneller – Messumstände ansehen ↓
  • Mit Optimierung war der schwache Rechner 14.864-mal schneller als der starke ohne – Laborwert, Messumstände ansehen ↓
  • lesende Datenzugriffe: 3.465.122 ohne Optimierung, 8 mit Optimierung.

Hier lag es an einer einzigen fehlenden Optimierung – eine Ursache von mehreren. Andere: Nachtläufe, die nicht fertig werden, Blockaden im Tagesgeschäft, gewachsene Programme, an die sich niemand mehr traut. Typische Anlässe ansehen →

Green IT: Dieselbe Suche brauchte ohne Optimierung rund 22 Sekunden Rechenzeit, mit Optimierung praktisch keine. Weniger Rechenarbeit heißt weniger Last für die Hardware (Stromverbrauch nicht gemessen).

Liegt das Problem woanders oder ist alles in Ordnung, sage ich Ihnen das. Lieber kein Auftrag als ein falscher.

Performance-Check anfragen → Genaue Messungen ansehen

So haben wir gemessen

Woher die 1,7 kommen: 30.934 ms (schwacher Rechner ohne Optimierung) geteilt durch 17.837 ms (starker Rechner ohne Optimierung), je Mittel aus 3 Messungen mit geleertem Zwischenspeicher. Beide Rechner wurden auf derselben Maschine nachgebildet: Der starke nutzte alle 8 Kerne und 13.000 MB Arbeitsspeicher, der schwache 2 Kerne und 1.300 MB, je Abfrage nur einen Kern. Festplatte und Speicherbandbreite waren bei beiden dieselben. Hat ein echter größerer Server zusätzlich schnellere Platten, kann der Gewinn durch Hardware größer ausfallen – das haben wir nicht gemessen.

Woher die 14.864 kommen: 17.837 ms (starker Rechner ohne Optimierung, Mittel aus 3 Messungen) geteilt durch 1,2 ms (schwacher Rechner mit Optimierung, Mittel aus 20 Messungen); vor jeder Messung wurde der Zwischenspeicher der Datenbank geleert. Zeiten um eine Millisekunde sind grob – schon bei 2 ms wären es rund 8.900-mal. Je nach Vergleich liegt der Faktor in diesem Lauf zwischen rund 3.900 (starker Rechner ohne gegen mit Optimierung, 4,6 ms) und rund 25.800 (schwacher Rechner ohne gegen mit Optimierung). Verlässlich ist die Zahl der gelesenen Seiten: 3.465.122 gegen 8.

Labor mit synthetischen Testdaten, kalter Zwischenspeicher. Die Rechner wurden auf einem 8-Kern-Rechner nachgebildet; Geschwindigkeit von Festplatte und Speicherbus ist nicht nachgebildet. Zu Green IT gemessen ist nur die Rechenzeit: rund 22 Sekunden Prozessorzeit je Suche ohne Optimierung, praktisch keine mit. Den Stromverbrauch haben wir nicht gemessen. Alle Messprotokolle

Manuel Hagen · Datenbankexperte für Microsoft SQL Server

Ihr SQL Server ist zu langsam? Ich finde die Ursache, behebe sie und messe die Wirkung nach.

Masken und Berichte, die Sekunden brauchen. Deadlocks und Timeouts. Nachtläufe, die morgens nicht fertig sind. Ich analysiere Ausführungspläne, Indizes und Sperren, setze an der wirksamsten Stelle an und belege jede Verbesserung mit einer Vorher-Nachher-Messung – im laufenden Betrieb, oft ohne neue Hardware und ohne Änderung an Ihrer Anwendung.

Erstgespräch vereinbaren Vorgehen & Messwerte ansehen

20 Minuten, unverbindlich: Sie schildern Symptom, SQL-Server-Version und Datenmenge. Ich sage Ihnen ehrlich, ob die Ursache in der Datenbank liegt und ob ich der Richtige dafür bin.

  • 64 Mrd. Zeilen · 4 TBProduktionsdatenbank als App-Owner verantwortet (NXP)
  • rund 130 Prozedurensaniert, mit schriftlicher Referenz des Kunden
  • ×358 schnellerdurch passenden Index, im eigenen Labor gemessen (10 Mio. Zeilen)
  • 30+ JahreDatenbanken und Unternehmensanwendungen
Manuel Hagen

Ich bin Manuel Hagen, freiberuflicher Diplom-Wirtschaftsinformatiker (FH) aus Buxtehude bei Hamburg. Seit mehr als 30 Jahren verbinde ich Datenbanken, Software und betriebliche Abläufe, unter anderem als technischer App-Owner einer Produktionsdatenbank mit 64 Mrd. Zeilen bei NXP Semiconductors. Sie arbeiten direkt mit mir, ohne Vermittler.

Typische Anlässe

Erkennen Sie eines dieser Symptome?

Hinter langsamen Datenbanken stecken meist wenige, wiederkehrende Ursachen. Ich finde sie durch Messung, nicht durch Vermutung – und sage Ihnen auch, wenn das Problem woanders liegt.

Antwortzeiten

„Masken und Berichte brauchen Sekunden bis Minuten.“

Was ich tue:

Ausführungsplan und Lesevorgänge messen, fehlende oder falsch aufgebaute Indizes, Datentyp-Konflikte (z. B. nvarchar gegen varchar) und Parameter Sniffing beheben. Im Labor sank ein Tabellen-Scan von 349.716 auf 11 Lesevorgänge.

Index-Messung Stufe für Stufe →
Nachtlauf

„Der Nachtlauf ist morgens nicht fertig und bremst alles daneben.“

Was ich tue:

Zu große Transaktionen auflösen, Cursor-Schleifen durch mengenorientiertes SQL ersetzen, Sperrketten beseitigen. In Kundenprojekten habe ich Nachtläufe auf diese Weise von mehreren Stunden auf gut eine Stunde verkürzt.

Vier Praxisfälle ansehen →
Deadlocks & Timeouts

„Blockaden im Tagesgeschäft, die sich im Test nie nachstellen lassen.“

Was ich tue:

Sperrketten und dynamisch zusammengesetztes SQL analysieren, in feste, parametrisierte Prozeduren mit stabilem Ausführungsplan überführen, Transaktionen verkleinern, passende Isolationsstufe wählen.

Praxisfall: Fehler nur in der Produktion →
Gewachsener Code

„Niemand traut sich mehr an die gewachsenen Stored Procedures.“

Was ich tue:

Erst alle Abhängigkeiten sichtbar machen, dann aufgezeichnete Fälle per Prüfsumme gegen den Altcode testen und schrittweise entflechten. Referenz: rund 130 Prozeduren bei einem internationalen Spirituosenkonzern, im laufenden Betrieb.

Vorgehen bei der Sanierung →
Datenwachstum

„Die Datenmenge ist explodiert, das Setup skaliert nicht mehr.“

Was ich tue:

Architektur für sehr große Datenbanken: Partitionierung für die Datenpflege, Insert-only und temporale Tabellen, entkoppelte Queues, Migration in Teilschritten im 24/7-Betrieb. Erfahrung aus 64 Mrd. Zeilen bei NXP.

Praxisfall Halbleiterproduktion →
Hardware-Reflex

„Der nächste Vorschlag lautet: ein größerer Server.“

Was ich tue:

Erst messen, dann investieren. Im Labor (100 Mio. Zeilen) war ein Server mit 8 statt 2 Kernen und zehnfachem Speicher ohne Index nur 1,7-mal so schnell; mit passendem Index war schon der kleine Server 14.864-mal so schnell wie der große ohne (Laborwert mit synthetischen Daten; Zeiten um 1 ms sind grob – schon bei 2 ms wären es rund 8.900-mal). Wann Hardware doch richtig ist, sage ich Ihnen ebenso.

Rechnung: Index gegen Lizenzkosten →
Leistungen & Einstieg

In drei Schritten von der Vermutung zur gemessenen Lösung

Sie entscheiden nach jedem Schritt, ob es weitergeht. Bevor ich etwas umsetze, halten wir Umfang, Aufwand und Abnahmekriterien schriftlich fest.

Schritt 1

Erstgespräch

20 Minuten · unverbindlich · Telefon oder Video

  • Sie schildern Symptom, seit wann es auftritt und welche Abfragen oder Jobs betroffen sind.
  • Ich frage nach Version, Edition und Datenmenge und sage Ihnen ehrlich, ob die Ursache wahrscheinlich in der Datenbank liegt.
  • Kein Zugriff auf Ihre Systeme nötig.
Erstgespräch vereinbaren →
Schritt 2 · Einstiegsangebot

Performance-Check

Der Beweis an Ihrem eigenen System

  • Messen, wo die Zeit verloren geht: Wartezeiten, teuerste Abfragen, Sperren.
  • Ursache an Ihrer kritischsten Abfrage oder Ihrem Nachtlauf eingrenzen: Ausführungsplan, Lesevorgänge.
  • Maßnahmen nach Wirkung ordnen, jede mit messbarem Erfolgskriterium und Rückweg; die wichtigste nach Ihrer Freigabe umsetzen.
  • Vorher und nachher per Skript messen – mit denselben Skripten wie im Labor.
  • Sie erhalten: Kurzfassung für die Leitung, technische Befunde mit Messwerten, Maßnahmenliste und alle verwendeten Skripte.

Beispielbefund ansehen (PDF, Labordaten) →

Performance-Check anfragen →
Schritt 3

Umsetzung & Sanierung

Als Einzelaufgabe oder Mitarbeit in Ihrem Team

  • Index- und Abfrage-Tuning in der Breite.
  • Sanierung gewachsener Stored Procedures, abgesichert durch Prüfsummentests.
  • Architektur und Migration sehr großer Datenbanken im laufenden Betrieb.
  • Dokumentation und Übergabe, damit Ihr Team ohne mich weiterarbeiten kann.
Vorgehen im Detail →
Gemessen statt behauptet

Was gezielte Optimierung bringt: zwei Labormessungen und ein Praxisfall

Messprotokolle aus Kundensystemen bleiben beim Kunden. Deshalb stelle ich typische Ursachen im eigenen SQL-Labor nach: synthetische Testdaten, keine Kundendaten, Messung per Skript und jederzeit wiederholbar.

×358 schneller

Fehlender Index

10 Mio. Zeilen: Ein abdeckender Index ersetzt den Tabellen-Scan durch einen gezielten Index-Zugriff – ohne neue Hardware und ohne Änderung an der Anwendung.

Vorher (Scan)
349.716 Reads
Mit Index
11 Reads (×31.792)

Stufenübersicht · Messdaten & Ausführungspläne →

3 statt 27.469 Reads

Falscher Datentyp im Parameter

Schickt die .NET-Anwendung Unicode (nvarchar) an eine varchar-Spalte mit SQL-Sortierung, muss SQL Server jeden Indexeintrag umwandeln und liest den ganzen Index:

nvarchar (Scan)
27.469 Reads · 446 ms
Passend (Seek)
3 Reads · 2,7 ms

Zehn weitere Messreihen · Messdaten zur Sortierung →

Praxis · Milliardenbereich

Hochlast in der Produktion

Bei NXP Semiconductors wurden monatlich rund 1,4 Mrd. neue Seriennummern gegen 64 Mrd. Bestandszeilen auf Duplikate geprüft – entkoppelt über Redis-Queues:

Direkt (Sperren)
Blockaden / Timeouts
Redis-Queue
< 15 ms Reaktionszeit

Praxisfall Halbleiterproduktion →

Praxisfälle

Aus der Praxis: Ausgangslage, Vorgehen, Ergebnis

Vier Projekte, die zeigen, wie ich arbeite; weitere Fälle stehen auf der Seite Datenbankoptimierung.

VLDB · 64 Mrd. Zeilen · 4 TB

NXP Semiconductors: Duplikatprüfung in der Halbleiterfertigung

Ausgangslage: Als technischer App-Owner verantwortete ich die Qualitätssicherungs-Plattform TDLog: 64 Milliarden Bestandsdatensätze (4 TB), monatlich rund 1,4 Milliarden neue Datensätze aus den weltweiten Fertigungslinien, die in Echtzeit gegen den gesamten Bestand auf Duplikate geprüft werden mussten. Eine Verzögerung hätte die Fertigung aufgehalten.

Vorgehen & Ergebnis: Insert-only-Architektur mit temporaler Datenhaltung, entkoppelte Redis-Queues für Verarbeitung unter 15 ms, verteilte Satelliten-Datenbanken an asiatischen Produktionsstandorten mit Replikation zur Zentrale. Die 64 Milliarden Datensätze wurden batchweise migriert, parallel zum laufenden 24/7-Produktionsbetrieb und ohne Produktionsstillstand.

  • MS SQL Server
  • 64 Mrd. Zeilen · 4 TB
  • 1,4 Mrd. Zeilen/Monat
  • Insert-only & temporal
  • Redis-Queues
  • Docker-Microservices
  • Azure DevOps CI/CD
Sanierung · rund 130 Prozeduren im laufenden Betrieb

Internationaler Spirituosenkonzern: gewachsene MSSQL-Prozeduren saniert

Ausgangslage: Rund 130 historisch gewachsene MSSQL-Prozeduren für die nächtliche Datenkonsolidierung und Fehlerkorrektur. Tief verschachtelte Logik und unklare Abhängigkeiten führten zu langen Laufzeiten und blockierten Folgesysteme.

Vorgehen & Ergebnis: Prozedurenlandschaft systematisch analysiert, entflochten und in weiten Teilen durch wartbare, deutlich schnellere T-SQL-Lösungen abgelöst – im laufenden Betrieb, ohne Betriebsunterbrechung, abgesichert durch Prüfsummentests.

„Herr Hagen verfügt über eine außergewöhnlich tiefgehende technische Expertise in den Bereichen Datenbanken, Anwendungsarchitektur und Performance-Optimierung. […] Durch seine Tätigkeit konnten Transparenz, Wartbarkeit, Stabilität und Performance der eingesetzten IT-Systeme signifikant verbessert werden.“

— aus dem schriftlichen Referenzschreiben des Kunden

Vorgehen bei der Prozedur-Sanierung →

COMPIDDA · Abhängigkeitsanalyse

Vor dem Umbau: sehen, was an einer Tabelle hängt

Bevor gewachsene Datenbanken oder Anwendungen umgebaut werden, muss klar sein, welche Prozeduren, Views, Jobs, Pakete und Anwendungszugriffe betroffen sind. Dafür setze ich mein eigenes Werkzeug COMPIDDA ein: Es liest Datenbankobjekte und Quellcode aus und zeigt die Abhängigkeiten als Diagramm mit exakter Fundstelle.

Abhängigkeitsdiagramm einer gewachsenen Software- und Datenbanklandschaft, erstellt mit COMPIDDA
Abhängigkeitsdiagramm · Drilldown bis zur Fundstelle Vollansicht ↗

Die Auswertung läuft vollständig bei Ihnen und arbeitet deterministisch, ohne KI. Was sich nicht eindeutig auflösen lässt, bleibt sichtbar markiert; die fachliche Bewertung liegt bei Ihren Verantwortlichen.

Oracle → MS SQL · Blazor

Importgroßhandel: Desktop-Anwendung mit Oracle ins Web gebracht

Ausgangslage: Eine über mehr als 20 Jahre gewachsene VB-/WinForms-Anwendung mit Oracle-Datenbank sollte abgelöst werden. Ziel war eine Blazor-Webanwendung mit MS SQL Server.

Vorgehen & Ergebnis: Bestehende Komponenten und Anwendungsfälle selbstständig analysiert, neue Architektur geplant und umgesetzt, die neuen Funktionen mit NUnit und Selenium in einer eigenen Testumgebung geprüft. Fachliche Abläufe blieben erhalten, die Technik wurde ersetzt.

  • Oracle → MS SQL
  • C# / Blazor
  • Entity Framework Core
  • NUnit / Selenium
Ablauf

Messen, eingrenzen, abstimmen, beheben, nachmessen

Jeder Einsatz folgt derselben Reihenfolge. Sie sehen zu jedem Zeitpunkt, was ich tue, warum, und wie es sich zurücknehmen lässt.

  1. 1

    Messen

    Wo geht die Zeit verloren: Rechenzeit, Ein- und Ausgabe, Sperren oder Netzwerk? Grundlage sind Systemsichten, Abfragestatistiken und Ausführungspläne – nicht die Inhalte Ihrer Tabellen.

  2. 2

    Eingrenzen

    Meist verursachen wenige Abfragen, Prozeduren oder Jobs den größten Teil der Last. Diese untersuche ich einzeln: Ausführungsplan, Lesevorgänge, Wartezeiten, Sperrverhalten.

  3. 3

    Abstimmen

    Sie erhalten die Maßnahme mit erwarteter Wirkung, Risiko und Rückweg. Umgesetzt wird erst nach Ihrer Freigabe – gern gemeinsam mit Ihrem Team oder Ihrem Dienstleister.

  4. 4

    Beheben

    Index vor Code vor Hardware. Größere Umbauten sichern wir vorab mit automatisierten Tests und Prüfsummen über aufgezeichnete Fälle ab. Für jeden Schritt gibt es einen Stand, auf den sich zurückschalten lässt.

  5. 5

    Nachmessen & übergeben

    Dieselbe Messung wie vorher, per Skript. Ihr Team erhält Ergebnis, Begründung und Dokumentation, damit es ohne mich weiterarbeiten kann.

Sicherheit & Rahmenbedingungen

Was Sie als IT-Verantwortlicher vorher wissen sollten

Ihre Daten bleiben bei Ihnen

Die Diagnose liest nur: Systemsichten, Abfragestatistiken und Ausführungspläne (Berechtigung VIEW SERVER STATE), keine Tabelleninhalte. Die Diagnose-Skripte können Sie vorab einsehen. Ich arbeite nur auf Ihren Systemen; Datenexporte, Sicherungen oder Testdaten per E-Mail nehme ich nicht an. Kundendaten, Schemas und Messprotokolle gebe ich nicht weiter.

Kein Eingriff ohne Freigabe

Änderungen an Indizes, Prozeduren oder Konfiguration setze ich erst nach Ihrer Zustimmung um, nach Ihrem Änderungsprozess und mit vorbereitetem Rückweg.

Zugang nach Ihren Regeln

Remote über den Zugang, den Sie bereitstellen, per Bildschirmfreigabe, bei der Sie die Steuerung behalten, oder vor Ort nach Absprache. Eine Geheimhaltungsvereinbarung (NDA) unterschreibe ich auf Wunsch vor dem ersten Blick ins System.

Direkt mit dem Experten

Kein Vertrieb, keine Vermittlungsebene, kein wechselnder Ansprechpartner: Das Erstgespräch führen Sie mit mir, und ich bin es auch, der die Arbeit macht.

Wissen bleibt im Haus

Ich erkläre Ursachen und Maßnahmen so, dass Ihr Team sie nachvollziehen und künftig selbst erkennen kann. Zum Ergebnis gehören Skripte, Tests und Dokumentation.

Ehrliche Einschätzung

Liegt das Problem nicht in der Datenbank, oder reicht ein Standardwerkzeug, sage ich das. Lieber kein Auftrag als ein falscher.

Über mich

Manuel Hagen – Datenbankexperte mit Blick für Abläufe und Kosten

Werdegang

Ich bin Manuel Hagen, freiberuflicher Datenbankexperte und Diplom-Wirtschaftsinformatiker (FH). Seit mehr als 30 Jahren verbinde ich Datenbanken, Software und betriebliche Abläufe. Sie arbeiten direkt mit mir – von der ersten Messung bis zur Übergabe an Ihr Team.

Mein Weg führte vom Budget-Controlling bei der PHOENIX-AG in die Datenbank- und Anwendungsentwicklung. Daher rechne ich bei jeder Maßnahme mit, was sie kostet und was sie spart. Das berufsbegleitende Studium an der FOM hat diese Perspektive vertieft.

Bei NXP Semiconductors war ich als Software Engineer und später FullStack Software Engineer tätig. Als technischer App-Owner für TDLog habe ich Datenbank, Backend, Tests und Deployment verantwortet und das Team bei Architektur, Planung und Einarbeitung unterstützt.

Als Freiberufler habe ich unter anderem Studien-Reporting für medizinische Studien entwickelt, gewachsene Prozedurenlandschaften saniert und Desktop-Anwendungen mit Oracle zu MS SQL und Blazor modernisiert. Typische Ursachen langsamer Datenbanken stelle ich im eigenen SQL-Labor nach und veröffentliche die Messungen.

  • 01 Erst messen, dann ändern.

    Keine Maßnahme ohne Messung vorher und nachher.

  • 02 Die wirksamste Stelle zuerst.

    Index vor Code vor Hardware – wenige Eingriffe mit großer Wirkung.

  • 03 Bestand respektieren.

    Gewachsene Systeme werden schrittweise verbessert, nicht reflexartig ersetzt.

  • 04 Wissen teilen.

    Ich erkläre Ursachen verständlich und unterstütze Entwicklungs- und Supportteams mit Datenbank-Coaching.

Referenzen

Was Auftraggeber und Arbeitgeber schriftlich festgehalten haben

Festanstellungen bei NXP Semiconductors und der PHOENIX-AG, freiberufliche Projekte in Halbleiterproduktion, medizinischem Studien-Reporting und Unternehmensanwendungen.

Komplexe Systeme durchdringen

„… in der Lage, auch komplexe und historisch gewachsene Systemlandschaften schnell zu durchdringen und nachhaltig zu verbessern. Durch seine Tätigkeit konnten Transparenz, Wartbarkeit, Stabilität und Performance der eingesetzten IT-Systeme signifikant verbessert werden.“

Auszug aus der Referenz · internationaler Spirituosenkonzern

Verständlich für Technik und Fachbereich

„Besonders hervorzuheben ist seine Fähigkeit, technische Modernisierung konsequent mit organisatorischen Prozessen zu verbinden und IT-Themen sowohl technisch fundiert als auch fachlich verständlich zu vermitteln.“

Auszug aus der Referenz · internationaler Spirituosenkonzern

Zuverlässig im 24/7-Betrieb

„Herr Hagen war in ganz besonders hohem Maße zuverlässig … zeigte vor allem aber auch immer wieder vollen Einsatz, wenn es darum ging, den operativen Betrieb sicherzustellen.“

Auszug aus dem Zeugnis · NXP Semiconductors

Termintreu und klar in der Abstimmung

„He completed his work on time and he has a good communication with his lead on the status of each deliverable he is assigned with.“

Auszug aus der Referenz · Clario (USA)

  • NXP SemiconductorsFrüherer Arbeitgeber · TDLog
  • ClarioMedical · ehem. ERT
  • ERTMedical · Studien-Reporting
  • VeotecMedical
  • Stockspiritsehem. Borco
  • PHOENIX-AGFrüherer Arbeitgeber · Controlling & IT
  • FeuerbestattungenKrematoriumsablaufsteuerung

Kurze Auszüge aus schriftlichen Referenzen im Originalwortlaut; Auslassungen sind mit „…“ bzw. „[…]“ gekennzeichnet. Vollständige Nachweise erhalten Sie auf Anfrage.

Außerdem

Weitere Leistungen rund um Ihre Daten

Wenn die Datenbank nicht das einzige Problem ist: Diese Aufgaben übernehme ich ebenfalls, meist im Anschluss an eine Optimierung.

Anwendungen modernisieren

Desktop- und Oracle-Anwendungen schrittweise nach MS SQL Server und Blazor überführen, ohne fachliche Abläufe zu verlieren. Umsetzung mit C#/.NET und Entity Framework Core, abgesichert durch automatisierte Tests.

Datenintegration & Migration

Schnittstellen, ETL-Strecken (SSIS, REST, CSV/XML/JSON, SFTP) und Datenmigrationen, die im laufenden Betrieb in Teilschritten erfolgen und sich zurücknehmen lassen.

Abhängigkeitsanalyse

Gewachsene Datenbank- und Anwendungslandschaften mit COMPIDDA auslesen: Welche Prozedur, welcher Job, welcher Anwendungszugriff ist von einer geplanten Änderung betroffen?

Werkzeuge: MS SQL Server (SSMS, SSIS, SSRS) · Oracle PL/SQL · PostgreSQL · MySQL · Redis · C#/.NET · Blazor · Entity Framework Core · NUnit · PowerShell · Docker · Azure DevOps. Die Auswahl folgt dem Problem; was gut funktioniert, wird eingebunden statt ersetzt.

Häufige Fragen

Was IT-Verantwortliche vor dem ersten Gespräch fragen

Brauchen Sie Zugriff auf unsere Produktionsdaten?

Für die Diagnose nicht. Systemsichten, Abfragestatistiken und Ausführungspläne zeigen, wo Zeit verloren geht, ohne dass ich Tabelleninhalte lese. Für Änderungen wie neue Indizes arbeiten wir nach Ihrem Freigabeprozess; auf Wunsch setzt Ihr Team die Änderung selbst um und ich begleite.

Was kostet das?

Das hängt vom Umfang ab, deshalb nenne ich hier keinen Pauschalpreis. Das Erstgespräch ist unverbindlich. Für den Performance-Check vereinbaren wir Umfang und Aufwand vorab schriftlich, sodass Sie vor dem Start wissen, woran Sie sind. Zum Vergleich: Ein größerer Server mit zusätzlichen SQL-Server-Kernlizenzen kostet schnell ein Vielfaches – die Rechnung steht auf der Seite Datenbankoptimierung.

Arbeiten Sie remote oder vor Ort?

Beides, nach Absprache. Analysen lassen sich meist über einen gesicherten Fernzugang erledigen, den Sie bereitstellen; Workshops und Übergaben gern vor Ort. Mein Standort ist Buxtehude bei Hamburg.

Und wenn das Problem gar nicht die Datenbank ist?

Dann sage ich Ihnen das. Die Messung zeigt, ob die Zeit in der Datenbank, im Netzwerk, in der Anwendung oder an der Hardware verloren geht. Es gibt auch Fälle, in denen neue Hardware die richtige Antwort ist – etwa wenn Berichte konstruktionsbedingt alle Zeilen lesen müssen. Dann begründe ich das mit Zahlen.

Wann reicht Optimierung, wann ist eine Modernisierung nötig?

Optimierung lohnt sich, wenn die Anwendung fachlich passt und nur an bestimmten Stellen zu langsam ist: einzelne Abfragen, ein Bericht, ein Nachtlauf. Eine Modernisierung wird zum Thema, wenn die Technik den Betrieb einschränkt – etwa weil eine Komponente nicht mehr unterstützt wird oder jede Änderung an anderer Stelle Fehler auslöst. Oft verschafft die Optimierung die Zeit für den größeren Umbau.

Was, wenn die Anwendung während der Arbeit weiterlaufen muss?

Das ist der Normalfall. Geändert wird in kleinen Schritten, jeder mit automatisierten Tests vorab und einem Stand, auf den sich zurückschalten lässt. Kritische Bereiche kommen zuletzt, wenn sich der Weg bewährt hat. Das verteilt das Risiko auf kurze, planbare Fenster statt auf ein Wochenende, an dem alles gleichzeitig gutgehen muss.

Kontakt

Schildern Sie mir Ihr Performance-Problem

20 Minuten, unverbindlich. Sie beschreiben Symptome und Umgebung; ich sage Ihnen ehrlich, ob und wie ich helfen kann und wie ein Performance-Check bei Ihnen aussähe.

Anfrage

Erstgespräch vorbereiten

Worum geht es? Mehrfachauswahl

Eingaben werden nur in Ihrem Browser geprüft und nicht übertragen. Anschließend öffnet sich die vorbereitete E-Mail in Ihrem Mailprogramm; Sie entscheiden, ob Sie sie senden.

Erstgespräch