SQL Server Freelancer – Administration, Betrieb und Entwicklung aus einer Hand

Positionierung

SQL Server ist die Datenbankplattform, mit der ich am längsten und am intensivsten gearbeitet habe. Seit 1994 bin ich in der Datenbankwelt tätig, und SQL Server begleitet mich von Version 2000 bis zur aktuellen Generation 2022 und 2025. In dieser Zeit habe ich nahezu jeden Aspekt der Plattform kennengelernt: die tägliche Administration umfangreicher, virtualisierter Serverparks, den Aufbau und Betrieb von Hochverfügbarkeitslösungen, die Konzeption von Sicherheitsarchitekturen, die Planung von Patching-Zyklen und die Durchführung komplexer Versionsmigrationen. Hinzu kommt das vollständige Entwicklungsspektrum mit SSIS, SSRS, SSAS, T-SQL und PowerShell.

Was mich von Spezialisten für einen einzigen SQL-Server-Bereich unterscheidet, ist die Breite dieser Erfahrung. Ein reiner DBA kennt den Betrieb, weiß aber oft wenig über die ETL-Logik, die auf dem Server läuft. Ein reiner Entwickler kennt T-SQL, hat aber selten tiefes Wissen über Always On, Backup-Strategien oder Berechtigungskonzepte. Ich arbeite auf beiden Ebenen: Ich administriere die Infrastruktur, auf der Anwendungen laufen, und ich entwickle die Anwendungen selbst. Diese Verbindung erspart dem Auftraggeber Koordinationsaufwand und schließt Wissenslücken, die sonst zwischen Administration und Entwicklung entstehen.

Die MCSA-Zertifizierung für SQL Server 2012 (MOC 70-461, 70-462, 70-463, 70-466) unterlegt diese Breite mit formalisiertem Wissen: Datenbankentwicklung, -administration, -implementierung und Business-Intelligence-Reporting. Diese Prüfungen deckten genau das Spektrum ab, das ich in der Praxis täglich ausübe – von der T-SQL-Abfrageoptimierung über die Serverinstallation und -konfiguration bis zum Aufbau von SSAS-Cubes.

Auftraggeber holen mich typischerweise dann, wenn ein SQL-Server-Umfeld zuverlässig laufen muss und wenn gleichzeitig Entwicklungsaufgaben anfallen – sei es ein neues ETL-Paket, ein Report, eine geplante Migration oder eine Performance-Analyse. In solchen Fällen deckt eine Person das gesamte Spektrum ab, was die Zusammenarbeit deutlich einfacher macht, als es mit mehreren Spezialisten der Fall wäre.

Spektrum als SQL Server Freelancer

SQL Server ist eine umfangreiche Plattform, die weit mehr als eine relationale Datenbank ist. Im Lauf der Versionen hat Microsoft die Plattform um zahlreiche Dienste und Funktionen erweitert, die für sehr unterschiedliche Aufgaben eingesetzt werden. Als Freelancer, der über alle diese Bereiche hinweg tätig ist, biete ich ein Leistungsspektrum, das von der reinen Datenbankinstanz bis zur vollständigen BI-Plattform reicht.

Datenbankmodul und Administration

Das Herzstück ist das relationale Datenbankmodul. Hier liegt der Schwerpunkt der Administration: Serverinstallation und -konfiguration, Instanzmanagement, Speicher- und Netzwerkkonfiguration, Ressourcensteuerung über den Resource Governor, Wartungsfenster und die gesamte Bandbreite an DBA-Aufgaben, die einen SQL-Server-Betrieb am Laufen halten. Bei einem Finanzdienstleister habe ich einen Park von rund 80 virtualisierten SQL-Server-Instanzen betreut – eine Aufgabe, die ohne konsequente Automatisierung und klare Prozesse nicht beherrschbar wäre.

Integration Services, Reporting Services, Analysis Services

SSIS ist mein primäres ETL-Werkzeug seit der ersten Version. Ich habe Hunderte von Paketen gebaut, migriert und optimiert – von einfachen Dateiladern bis zu komplexen, parametrisierten Strecken mit Fehlerbehandlung, Logging und automatisiertem Deployment über SSISDB und SQL Agent. SSRS ergänzt das Bild auf der Reporting-Seite: paginated Reports, Subscriptions, Datenbankparameter und die Bereitstellung für verschiedene Zielgruppen. SSAS schließlich deckt die analytische Seite ab: tabellarische Modelle für Power BI, aber auch klassische mehrdimensionale Würfel mit MDX.

Hochverfügbarkeit und Betriebssicherheit

SQL Server bietet mehrere Hochverfügbarkeitstechnologien, die sich in Schutzumfang, Komplexität und Kosten unterscheiden. Always On Availability Groups sind heute der Standard für unternehmenskritische Datenbanken. Failover Cluster Instances schützen auf Instanzebene. Log Shipping ist die bewährte, einfache Lösung für sekundäre Standorte. Datenbankspiegelung ist veraltet, aber in älteren Umgebungen noch anzutreffen. Die Wahl der richtigen Lösung hängt von RPO, RTO, Budget und vorhandener Infrastruktur ab – eine Entscheidung, die ich in vielen Projekten mit begleitet habe.

• SQL Server 2000–2025: Administration, Entwicklung, Migration
• Integration Services (SSIS): ETL-Entwicklung, Migration, Deployment
• Reporting Services (SSRS): Reports, Subscriptions, Parameterisierung
• Analysis Services (SSAS): Tabellarische Modelle, MDX-Cubes
• Always On, Failover Cluster, Log Shipping, Replikation
• Backup-Strategien, Point-in-Time-Recovery, Restore-Tests
• Sicherheit: Berechtigungen, Audit, Transparent Data Encryption
• Automatisierung: PowerShell, dbatools, T-SQL, SQL Agent
• Performance-Analyse: Ausführungspläne, Wait Statistics, Index-Tuning

PowerShell und Automatisierung

Was früher manuelle Arbeit war, lässt sich mit PowerShell und dem dbatools-Modul automatisieren. Inventarisierung von Serverparks, Patching nach Skript, Server-Konfiguration per Policy, Backup-Verifikation, Deployment von SSIS-Paketen: All das lässt sich skriptgesteuert ausführen und in SQL Agent oder einen CI/CD-Workflow einbetten. Diese Automatisierungsebene ist der Unterschied zwischen einem Serverpark, der ständig manuelle Eingriffe erfordert, und einem, der nach definierten Prozessen läuft.

Dieser breite Werkzeugkasten ist kein Selbstzweck. Die Stärke liegt im Zusammenspiel: Wer SSIS-Pakete schreibt und gleichzeitig den Server administriert, sieht sofort, wenn ein Paket den Server durch schlechte Abfragen oder übermäßiges Logging belastet. Wer Backup-Strategien entwirft und gleichzeitig die Restore-Prozesse im SQL Agent automatisiert, testet Wiederherstellung als Teil des normalen Betriebs, nicht nur im Notfall. Diese Querverbindungen zwischen Betrieb und Entwicklung zu nutzen, ist meine Stärke.

Administration großer Serverlandschaften

Die Administration eines einzelnen SQL-Server-Clusters ist eine überschaubare Aufgabe. Die Administration eines Parks von 80 oder mehr virtualisierten SQL-Server-Instanzen ist eine andere Disziplin: Hier geht es um Prozesse, Automatisierung, Übersicht und Wiederholbarkeit. Konfigurationsänderungen müssen auf Dutzenden von Instanzen einheitlich und rückverfolgbar durchgeführt werden. Patching muss koordiniert und risikoarm ablaufen. Performance-Probleme müssen schnell lokalisiert werden, ohne jede Instanz einzeln zu durchsuchen.

Bei einem Finanzdienstleister habe ich genau dieses Umfeld betreut: rund 80 virtualisierte SQL-Server-Instanzen in einem Rechenzentrumsverbund, heterogen in Version und Konfiguration, im Regelbetrieb von der Applikationsseite stark beansprucht. Die Aufgabe umfasste Performance-Analyse und -optimierung, Audit-Konfiguration, Berechtigungsbereinigung, Patching und die Vorbereitung von Migrations-Projekten. Eine systematische Vorgehensweise und Automatisierung über PowerShell und dbatools waren dabei keine Option, sondern Notwendigkeit.

Typische SQL-Server-Landschaft in einem mittleren Rechenzentrum: mehrere physische Hosts mit virtualisierten Instanzen, unterteilt nach Umgebungen und Verwendungszweck. Administration, Patching und Monitoring greifen über alle Schichten hinweg.

Inventarisierung und Übersicht als Grundlage

Vor jeder weiteren Maßnahme steht die Inventarisierung. Wer nicht weiß, welche Instanzen existieren, welche Version sie laufen, welche Datenbanken aktiv sind und wie groß sie sind, kann weder sinnvoll patchen noch sinnvoll Prioritäten setzen. Mit dbatools lässt sich ein vollständiges Inventar in Minuten erheben und in einer zentralen Steuertabelle ablegen. Dieses Inventar ist die Grundlage für alle weiteren Prozesse: Patching, Konfigurationsabgleich, Kapazitätsplanung und Reporting.

Konfiguration nach Standards durchsetzen

Einer der häufigsten Schwachpunkte in gewachsenen Serverparks ist Konfigurationsinkonsistenz. Instanzen wurden zu verschiedenen Zeiten von verschiedenen Personen installiert und konfiguriert. Max Server Memory, Parallelitätseinstellungen (MAXDOP, Cost Threshold), tempdb-Konfiguration und Error-Log-Einstellungen weichen voneinander ab. Mit PowerShell-Skripten lassen sich Soll-Konfigurationen definieren und gegen den Ist-Zustand aller Instanzen prüfen – und Abweichungen gezielt korrigieren, ohne jeden Server manuell anzufassen.

• Vollständiges Inventar über dbatools: Instanzen, Versionen, Datenbanken, Größen
• Konfigurationsabgleich: Soll vs. Ist, automatisierte Korrektur bei Abweichungen
• Performance-Monitoring: Wait Statistics, Ausführungspläne, fehlende Indizes
• Speicher- und Kapazitätsplanung: Wachstumstrends, Platzkritikalität
• SQL Agent: Jobs, Alerts, Operators, Maintenance Plans kontrollieren
• Standardisiertes Deployment von Änderungen über alle Instanzen

Der operative Betrieb in einem großen Serverpark stellt auch besondere Anforderungen an das Monitoring. Einzelinstanz-Werkzeuge reichen nicht aus; es braucht eine Ansicht über alle Instanzen hinweg, die auffällige Wait-Statistiken, lange laufende Abfragen, fehlgeschlagene Jobs und kritische Platzsituationen früh anzeigt. Diese Übersicht kann über ein zentrales Management Data Warehouse, über Policy-Based Management oder über ein externes Monitoring-Werkzeug realisiert werden – je nach vorhandener Infrastruktur und Team-Präferenzen.

Hochverfügbarkeit und Disaster Recovery

Hochverfügbarkeit und Disaster Recovery sind zwei unterschiedliche Konzepte, die oft verwechselt werden. Hochverfügbarkeit (HA) schützt vor kurzfristigen Ausfällen – einem Serverfehler, einem Betriebssystem-Absturz, einem Hardware-Defekt – und ermöglicht einen schnellen, oft automatischen Schwenk auf ein Standby-System. Disaster Recovery (DR) schützt vor katastrophalen Ereignissen, die einen gesamten Standort betreffen, und definiert, wie ein System nach einem solchen Ereignis wiederhergestellt werden kann. Beide Konzepte zusammen bilden die Grundlage einer belastbaren SQL-Server-Infrastruktur.

SQL Server bietet für HA/DR ein abgestuftes Werkzeugkasten. Always On Availability Groups sind heute der Standard für kritische Workloads: Mehrere Replikas halten synchrone oder asynchrone Kopien der Datenbanken, ein Listener ermöglicht transparentes Failover für Anwendungen. Failover Cluster Instances (FCI) schützen auf Instanzebene über Windows Server Failover Clustering und freigegebenen Storage. Log Shipping ist die einfachere, robuste Alternative für Szenarien, in denen kein gemeinsamer Storage zur Verfügung steht und ein gewisser Datenverlust akzeptabel ist.

HA/DR-Architektur auf Basis von Always On Availability Groups: primäres Replikat am Hauptstandort, synchrones sekundäres Replikat für HA, asynchrones Replikat am DR-Standort. Der Listener ermöglicht Anwendungen eine standortunabhängige Verbindung.

Always On Availability Groups: Konzeption und Betrieb

Die Konfiguration einer Always On Availability Group ist kein Einmalprojekt, sondern ein dauerhafter Betriebsauftrag. Nach der initialen Einrichtung müssen Replikations-Health, Log-Transport-Latenzen und Synchronisierungsstatus kontinuierlich überwacht werden. Die DMVs sys.dm_hadr_availability_replica_states und sys.dm_hadr_database_replica_states liefern die wesentlichen Kennzahlen – ergänzt durch SQL Server Agent Alerts auf kritische HADR-Zustände und regelmäßige Failover-Tests, die sicherstellen, dass ein Schwenk im Ernstfall tatsächlich gelingt.

RPO und RTO als Planungsgrundlage

Jede HA/DR-Entscheidung beginnt mit den Anforderungen: Wie viel Datenverlust ist maximal tolerierbar (Recovery Point Objective, RPO)? Wie schnell muss das System nach einem Ausfall wieder verfügbar sein (Recovery Time Objective, RTO)? Ein synchrones Always-On-Replikat sichert RPO=0 – kein Datenverlust –, erfordert aber ausreichend Bandbreite und Latenz zwischen den Standorten. Ein asynchrones Replikat oder Log Shipping akzeptiert einen definierten Datenverlust, kommt aber mit schlechterer Netzwerkverbindung aus. Diese Abwägung ist keine rein technische, sondern eine fachliche Entscheidung, die ich gemeinsam mit dem Auftraggeber treffe.

-- Zeigt den aktuellen Replikationsstatus aller AG-Replikate
-- inkl. Synchronisierungsverzoegerung (log send/redo queue).
SELECT
    ag.name                       AS availability_group,
    ar.replica_server_name        AS replica,
    ars.role_desc                 AS role,               -- PRIMARY oder SECONDARY
    ars.synchronization_health_desc AS health,
    ars.connected_state_desc      AS connected,
    -- Rueckstand beim Senden und Wiederholen des Logs (KB)
    drs.log_send_queue_size       AS log_send_queue_kb,
    drs.redo_queue_size           AS redo_queue_kb,
    -- Geschaetzte Zeit bis zum Aufholen (Sekunden)
    drs.log_send_rate             AS log_send_rate_kbps,
    drs.redo_rate                 AS redo_rate_kbps
FROM sys.availability_groups               ag
JOIN sys.availability_replicas             ar  ON ag.group_id  = ar.group_id
JOIN sys.dm_hadr_availability_replica_states ars ON ar.replica_id = ars.replica_id
JOIN sys.dm_hadr_database_replica_states   drs ON ar.replica_id = drs.replica_id
ORDER BY ag.name, ars.role_desc;

Diese Abfrage gibt auf einen Blick den Gesundheitszustand aller Replikate und den aktuellen Rückstand beim Log-Transport aus. Kritische Werte sollten über SQL Agent Alerts überwacht werden, damit Probleme frühzeitig erkannt werden.

Failover-Tests sind ebenso wichtig wie der Aufbau der HA-Lösung selbst. Eine Availability Group, die noch nie geschwenkt wurde, ist ein ungetestetes Sicherheitsnetz. Ich empfehle regelmäßige, geplante Failover-Tests in Wartungsfenstern, bei denen der Schwenk und die anschließende Rückkehr zum primären Replikat vollständig durchgespielt werden. Nur so lässt sich sicherstellen, dass Anwendungen, Verbindungsstrings und Monitoring korrekt reagieren.

Sicherheit, Audit und Berechtigungen

Sicherheit auf SQL Server umfasst mehrere Ebenen, die zusammenwirken müssen: Authentifizierung (wer darf sich verbinden?), Autorisierung (auf was darf eine Identität zugreifen?), Audit (was ist wann passiert?), Verschlüsselung (sind Daten im Ruhezustand und auf dem Transportweg geschützt?) und Härtung (ist der Server selbst so konfiguriert, dass Angriffsflächen minimiert sind?). In regulierten Umgebungen – Finanzsektor, öffentliche Verwaltung – ist die Einhaltung dieser Ebenen oft eine formale Voraussetzung für den Betrieb.

Bei einem Finanzdienstleister habe ich umfangreiche Sicherheits- und Audit-Konfigurationen durchgeführt: Berechtigungsbereinigungen auf Datenbankebene, Einrichtung von SQL Server Audit für sicherheitsrelevante Ereignisse, Überprüfung und Härtung von Serverlogins sowie die Dokumentation des Ist-Zustands als Grundlage für die interne Revision. Diese Arbeit setzt tiefes Wissen über die Berechtigungsstruktur von SQL Server voraus – von Server-Principals über Datenbankrollen bis zu objektbezogenen Berechtigungen.

Authentifizierung und Login-Konzept

SQL Server unterstützt Windows-Authentifizierung und SQL-Server-Authentifizierung. Windows-Authentifizierung über Active Directory ist in Unternehmensumgebungen vorzuziehen: Passwörter werden zentral verwaltet, Kerberos ermöglicht Delegation, und der Zugriff endet automatisch, wenn ein Konto in AD deaktiviert wird. SQL-Server-Logins sollten auf Ausnahmen beschränkt sein – technische Servicekonten, Altlasten – und konsequent mit starken Passwörtern und erzwungener Passwort-Policy betrieben werden.

Berechtigungen nach dem Least-Privilege-Prinzip

Das Least-Privilege-Prinzip fordert, dass jeder Login, jeder Datenbankbenutzer und jede Anwendung nur die Rechte erhält, die für die jeweilige Aufgabe tatsächlich notwendig sind. In der Praxis weichen gewachsene Umgebungen von diesem Ideal stark ab: sa-Logins sind aktiviert, Entwickler haben sysadmin-Rechte, Anwendungskonten sind Mitglieder der db_owner-Rolle. Eine sorgfältige Berechtigungsaufnahme – gefolgt von einer schrittweisen Bereinigung mit Regressionstests – ist die Grundlage für einen sicheren Betrieb.

-- Zeigt alle Server-Principals (Logins) und ihre Rollen- und Einzelberechtigungen.
-- Grundlage fuer das Berechtigungs-Audit und die Bereinigung.
SELECT
    sp.name                     AS login_name,
    sp.type_desc                AS login_type,       -- WINDOWS_LOGIN, SQL_LOGIN usw.
    sp.is_disabled              AS is_disabled,
    -- Zugehoerige Serverrollen
    STUFF((
        SELECT ', ' + r.name
        FROM sys.server_role_members srm
        JOIN sys.server_principals   r ON srm.role_principal_id = r.principal_id
        WHERE srm.member_principal_id = sp.principal_id
        FOR XML PATH(''), TYPE).value('.','NVARCHAR(MAX)'),1,2,'')
        AS server_roles,
    -- Explizit gewaehlte Berechtigungen (GRANT/DENY)
    STUFF((
        SELECT ', ' + perm.state_desc + ' ' + perm.permission_name
        FROM sys.server_permissions perm
        WHERE perm.grantee_principal_id = sp.principal_id
        FOR XML PATH(''), TYPE).value('.','NVARCHAR(MAX)'),1,2,'')
        AS explicit_permissions
FROM sys.server_principals sp
WHERE sp.type IN ('S','U','G')   -- SQL-, Windows-User und Gruppen
  AND sp.name NOT LIKE '##%'     -- interne Konten ausschliessen
ORDER BY sp.type_desc, sp.name;

Diese Abfrage liefert eine vollständige Übersicht aller Logins, ihrer Serverrollen und explizit erteilten Berechtigungen – der erste Schritt jedes Sicherheits-Audits.

SQL Server Audit und C2-Audit

SQL Server Audit erlaubt feingranulares, serverweites und datenbankspezifisches Logging von Sicherheitsereignissen: erfolgreiche und fehlgeschlagene Anmeldungen, Schema-Änderungen, Berechtigungsänderungen, SELECT auf sensible Tabellen. Die Audit-Logs lassen sich in das Windows-Sicherheitsprotokoll, in Dateien oder in eine Datenbanktabelle schreiben. In regulierten Umfeldern ist die unveränderliche Ablage in Dateien mit Signatur oder in externen Log-Systemen Pflicht, damit Audit-Trails nicht nachträglich verändert werden können.

Transparent Data Encryption

Transparent Data Encryption (TDE) verschlüsselt Datenbankdateien auf Betriebssystemebene, sodass ein direkter Zugriff auf die .mdf- und .ldf-Dateien ohne SQL Server keinen Klartext liefert. TDE ist für Umgebungen relevant, in denen Datenschutz auf Storage-Ebene gefordert ist, etwa bei Cloud-Backups oder bei der Übergabe von Datenbankdateien. Die Schlüsselverwaltung ist der kritische Punkt: Der Database Master Key und das Zertifikat müssen sicher gesichert und separat aufbewahrt werden – ein verlorener Schlüssel bedeutet, dass die Datenbank nicht mehr entschlüsselt werden kann.

Backup- und Restore-Strategie

Ein Backup, das nicht getestet wurde, ist kein Backup. Dieser Satz klingt abgedroschen, wird aber in der Praxis erschreckend häufig ignoriert. SQL Server bietet eine mächtige und flexible Backup-Infrastruktur: Vollsicherungen, differenzielle Sicherungen, Transaktionsprotokoll-Sicherungen und die Kombination dieser Typen in einer Restore-Kette, die Point-in-Time-Recovery ermöglicht. Diese Flexibilität muss durch eine durchdachte Strategie genutzt werden, die RPO und RTO der jeweiligen Datenbanken berücksichtigt.

Die Backup-Strategie beginnt mit der Klassifizierung der Datenbanken nach Kritikalität: Wie aktuell müssen die Daten im Ernstfall sein? Wie schnell muss die Datenbank wiederhergestellt sein? Eine OLTP-Datenbank, die Transaktionen im Minutentakt verarbeitet, braucht häufige Log-Backups und eine kurze Restore-Kette. Eine Reporting-Datenbank, die einmal täglich geladen wird, kommt mit täglichen Vollbackups aus. Und eine Archivdatenbank braucht möglicherweise nur ein wöchentliches Backup in den Cold-Storage.

Backup mit Komprimierung und Prüfsummen

SQL Server-Backup-Komprimierung reduziert die Backup-Größe typischerweise um 60–80 %. Sie kostet etwas CPU, spart aber erheblich Speicher- und Netzwerkkapazität. In fast allen modernen Umgebungen ist Komprimierung daher standardmäßig zu aktivieren. Mindestens genauso wichtig ist die Verwendung von CHECKSUM, die Datenbankseiten auf Konsistenz prüft und das Backup-Set mit einem Prüfcode versieht, der bei der Wiederherstellung verifiziert werden kann. Ohne Prüfsummen kann ein Backup-Set korrupt sein, ohne dass das beim Schreiben auffällt – ein stilles Risiko.

-- Erstellt ein vollstaendiges Backup mit Komprimierung und Pruefsumme.
-- COPY_ONLY verhindert, dass das Backup die regulaere Backup-Kette unterbricht.
BACKUP DATABASE [Produktionsdatenbank]
TO  DISK = N'\\backup-server\sql-backups\Produktionsdatenbank_full_20250101.bak'
WITH
    COMPRESSION,                 -- Backup-Groesse um typisch 60-80% reduzieren
    CHECKSUM,                    -- Pruefsumme fuer spaeteren Integritaetstest
    STATS = 10,                  -- Fortschrittsanzeige alle 10 Prozent
    NAME = N'Vollsicherung Produktionsdatenbank 2025-01-01',
    DESCRIPTION = N'Regelmaessige Vollsicherung fuer Point-in-Time-Restore',
    COPY_ONLY;                   -- Backup-Kette nicht unterbrechen

-- Integritaet des fertigen Backups sofort verifizieren
RESTORE VERIFYONLY
FROM DISK = N'\\backup-server\sql-backups\Produktionsdatenbank_full_20250101.bak'
WITH CHECKSUM;

COPY_ONLY eignet sich für Ad-hoc-Sicherungen, die die reguläre Differential-Kette nicht unterbrechen sollen. Das anschließende RESTORE VERIFYONLY prüft Lesbarkeit und Prüfsumme, ohne die Datenbank zurückzuschreiben.

-- Stellt eine Datenbank zu einem bestimmten Zeitpunkt wieder her.
-- Schritt 1: Vollsicherung einspielen (NORECOVERY = weitere Backups folgen)
RESTORE DATABASE [Produktionsdatenbank_test]
FROM DISK = N'\\backup-server\sql-backups\Produktionsdatenbank_full_20250101.bak'
WITH
    MOVE N'Produktionsdatenbank'      TO N'D:\Data\Produktionsdatenbank_test.mdf',
    MOVE N'Produktionsdatenbank_log'  TO N'L:\Log\Produktionsdatenbank_test.ldf',
    NORECOVERY,                      -- Datenbank bleibt im Wiederherstellungsmodus
    STATS = 10;

-- Schritt 2: Differenzielles Backup einspielen (optional, falls vorhanden)
RESTORE DATABASE [Produktionsdatenbank_test]
FROM DISK = N'\\backup-server\sql-backups\Produktionsdatenbank_diff_20250101_1200.bak'
WITH NORECOVERY, STATS = 10;

-- Schritt 3: Log-Backups bis zum Zielzeitpunkt einspielen
RESTORE LOG [Produktionsdatenbank_test]
FROM DISK = N'\\backup-server\sql-backups\Produktionsdatenbank_log_20250101_1400.trn'
WITH
    STOPAT = '2025-01-01T14:23:00',  -- Gewuenschter Wiederherstellungszeitpunkt
    NORECOVERY, STATS = 5;

-- Schritt 4: Datenbank online bringen (nach dem letzten Log-Backup)
RESTORE DATABASE [Produktionsdatenbank_test] WITH RECOVERY;

Point-in-Time-Recovery ist die mächtigste Fähigkeit des SQL Server Backup-Systems. Voraussetzung ist das vollständige Recovery Model und lückenlose Log-Backups zwischen den Vollsicherungen.

Backup-Überwachung und Restore-Tests

Backup-Überwachung bedeutet nicht nur, zu prüfen, ob Jobs erfolgreich abgeschlossen sind. Es bedeutet auch zu prüfen, ob tatsächlich Backups vorhanden sind, die innerhalb des definierten Backup-Intervalls liegen. In der msdb-Datenbank speichert SQL Server die Backup-Historie – eine tägliche Abfrage, die Datenbanken ohne aktuelles Backup meldet, ist ein elementares Monitoring-Instrument. Darüber hinaus sind regelmäßige Restore-Tests unverzichtbar: Mindestens einmal im Quartal sollte eine vollständige Restore-Übung stattfinden, bei der die Wiederherstellungszeit gemessen und dokumentiert wird.

Patching und Wartung

Patching ist eine der ungeliebtesten, aber wichtigsten DBA-Aufgaben. Ungepatchte SQL-Server-Instanzen sind ein Sicherheitsrisiko und ein Stabilitätsrisiko zugleich: Bekannte Sicherheitslücken sind ausnutzbar, und viele Bugfixes für Datenkorrektions- und Datenverlust-Szenarien erscheinen erst in Cumulative Updates. Wer keine aktuellen Cumulative Updates einspielt, schleppt möglicherweise bekannte Fehler jahrelang mit.

SQL Server veröffentlicht Cumulative Updates (CUs) monatlich und Service Packs (in älteren Versionen) quartalsweise. Die Empfehlung von Microsoft lautet, immer auf dem aktuellen CU des unterstützten Branches zu bleiben. In der Praxis heißt das: Ein strukturierter Patching-Prozess, der regelmäßig neue CUs testet und einspielt, ist keine Option für hochwertige SQL-Server-Umgebungen, sondern Pflicht.

Patching-Prozess in großen Serverparks

In einem Park von 80 Instanzen kann kein Mensch jede Instanz manuell patchen. PowerShell und dbatools ermöglichen es, den Patch-Status aller Instanzen zu erheben, veraltete Instanzen zu identifizieren und Patches koordiniert über definierte Umgebungen auszurollen – erst Test, dann UAT, dann Produktion. Jeder Schritt wird protokolliert; Abweichungen werden gemeldet. Dieser Prozess dauert typischerweise zwei bis vier Wochen pro CU-Zyklus und lässt sich weitgehend automatisieren.

Wartungsfenster und Online-Operationen

Nicht jede Wartungsoperation erfordert Downtime. Index-Rebuild und -Reorganisation lassen sich online ausführen; UPDATE STATISTICS kann im Hintergrund laufen; Availability Groups erlauben einen planmäßigen Failover, der Wartungsarbeiten am bisherigen Primär-Server ermöglicht, während die Sekundär-Instanz die Last übernimmt. Die Kunst liegt darin, Wartungsfenster so zu planen, dass sie die Verfügbarkeit für Benutzer minimal beeinflussen – und das erfordert Kenntnis der Last-Profile der jeweiligen Instanz.

• CU-Stand aller Instanzen zentral erheben und veraltete Instanzen priorisieren
• Rollout: Test → UAT → Produktion mit Protokollierung und Rollback-Option
• Online-Index-Rebuild und -Reorganisation im Wartungsfenster automatisieren
• UPDATE STATISTICS nach größeren Datenänderungen einplanen
• DBCC CHECKDB regelmäßig ausführen und Ergebnisse dokumentieren
• TempDB-Konfiguration nach Wartungsmaßnahmen überprüfen

Neben dem Patching gehört das Überprüfen der Datenbankintegrität mit DBCC CHECKDB zu den elementaren Wartungsaufgaben. CHECKDB prüft, ob Datenbankseiten konsistent sind und ob Indizes zur Tabelle passen. Fehler, die CHECKDB meldet, sind häufig die ersten Anzeichen eines Hardware-Problems; werden sie ignoriert, können sie zu ernstem Datenverlust führen. In einem gut betriebenen SQL-Server-Umfeld läuft CHECKDB mindestens wöchentlich auf jeder Produktionsdatenbank, und die Ergebnisse werden protokolliert.

Versions-Upgrades und Migration

SQL-Server-Versionen haben ein definiertes End-of-Support-Datum. Mit dem Ablauf des Extended Support endet die Versorgung mit Sicherheitspatches, was den Weiterbetrieb zu einem kalkulierten Risiko macht. Versionsmigrationen sind daher eine regelmäßige Aufgabe im SQL-Server-Betrieb – und eine, die sorgfältig geplant sein will, weil Inkompatibilitäten zwischen Versionen, geänderte Standardeinstellungen und veraltete Features auf jeder Seite Überraschungen bereithalten können.

Eine SQL-Server-Migration ist selten ein reines Datenbankprojekt. Sie berührt Anwendungen, Deployment-Prozesse, Monitoring-Konfigurationen und oft auch das Betriebssystem. Ich habe Migrationen über mehrere Versionsgenerationen hinweg begleitet: von SQL Server 2000 auf 2008, von 2012 auf 2016, von 2016 auf 2019 und 2022. Jeder Sprung hat seine eigenen Tücken, die ich aus Erfahrung kenne.

Vorgehensmodell: Analyse, Test, Migration, Absicherung

Migrations-Projekte folgen bei mir einem vierstufigen Muster. Zunächst die Analyse: Welche Objekte nutzen veraltete Features? Welche Kompatibilitätsgrade sind gesetzt? Gibt es Anwendungen, die sich auf undokumentierte Verhaltensweisen verlassen? Das Database Experimentation Assistant (DEA) und das SQL Server Upgrade Advisor sind hilfreiche Werkzeuge, aber kein Ersatz für manuelle Code-Durchsicht. Dann der Test: Migration in eine Testumgebung, Anwendungstests, Performance-Vergleich mit Baseline-Metriken aus dem alten System. Dann die eigentliche Migration: oft als Backup/Restore in die neue Version, gefolgt von einer kontrollierten Umschaltung. Schließlich die Absicherung: Altsystem für eine definierte Zeit als Fallback vorhalten, bevor es abgeschaltet wird.

Kompatibilitätsstufen und neue Features nutzen

Die Datenbankkompatibilitätsstufe ist ein mächtiges Instrument, um Migrationen zu entschleunigen. Eine Datenbank kann in SQL Server 2022 mit Kompatibilitätsstufe 130 (SQL Server 2016-Verhalten) betrieben werden, was Anwendungstests unter kontrollierten Bedingungen erlaubt, bevor die volle Kompatibilität aktiviert wird. Neue Features wie verbesserte Query Store Insights, Intelligent Query Processing oder beschleunigte Datenbankwiederherstellung (ADR) stehen erst nach dem Anheben der Kompatibilitätsstufe zur Verfügung.

• Analyse: Features, Kompatibilitätsgrade, Abhängigkeiten, Anwendungsverhalten
• Testmigration: Backup/Restore, Anwendungstests, Performance-Baseline-Vergleich
• Rollout: Backup/Restore oder Availability-Group-basiertes Failover-Upgrade
• Parallelbetrieb: Altsystem als Fallback bis zur nachgewiesenen Stabilität
• Kompatibilitätsstufe schrittweise anheben und neue Features aktivieren
• Altlasten: veraltete Syntax, deprecated Features, sp_optionname-Einstellungen

Besondere Sorgfalt verdienen veraltete Syntax-Elemente, die SQL Server zwar noch akzeptiert, aber in kommenden Versionen entfernen wird: der alte outer-join-Operator (*=), veraltete Systemtabellen statt DMVs, GROUP BY ALL, nicht-ANSI-konforme NULL-Vergleiche. Ein Inventar dieser Altlasten und ihre schrittweise Bereinigung ist Teil jeder sorgfältigen Migration – und verhindert, dass die nächste Migration noch schwieriger wird als die aktuelle.

Automatisierung mit PowerShell und T-SQL

Manuelle, wiederkehrende Aufgaben in SQL-Server-Umgebungen sind nicht nur Zeitfresser, sondern Fehlerquellen. Wer 80 Instanzen von Hand konfiguriert, riskiert Inkonsistenz. Wer Backups manuell überwacht, übersieht Lücken. Wer Patches manuell einspielt, vergisst Instanzen. PowerShell und das dbatools-Modul sind meine primären Werkzeuge, um repetitive DBA-Aufgaben in verlässliche, wiederholbare Prozesse zu verwandeln.

Das dbatools-Modul enthält über 600 Cmdlets für nahezu jede denkbare SQL-Server-DBA-Aufgabe: Instanz-Inventarisierung, Datenbankbereitstellung, Berechtigungsverwaltung, Backup und Restore, Migration, HADR-Überwachung. Die Cmdlets folgen einer einheitlichen Sprache und lassen sich zu Skripten und Pipelines komponieren, die vollständige Workflows abdecken – von der Inventarisierung über den Patch bis zur Dokumentation.

# Erhebt ein vollstaendiges SQL-Server-Inventar aus einer Liste von Servern.
# Speichert Instanzdaten, Datenbankgroessen und CU-Stand in einer zentralen Tabelle.

Import-Module dbatools

# Liste der zu pruefenden Server (z.B. aus einer CSV-Datei oder einem CMDB-Export)
$servers = Get-Content -Path 'C:\admin\sql_server_list.txt'

$inventory = foreach ($server in $servers) {
    try {
        $inst = Connect-DbaInstance -SqlInstance $server -ErrorAction Stop

        # Instanz-Basisdaten abrufen
        $info = Get-DbaInstanceProperty -SqlInstance $inst |
            Select-Object SqlInstance, BuildNumber, ProductVersion, ProductLevel,
                          Edition, Collation, MaxMemory, MinMemory

        # Alle Datenbanken mit Groesse und Status
        $dbs = Get-DbaDatabase -SqlInstance $inst |
            Select-Object SqlInstance, Name, Status, RecoveryModel,
                          @{ Name='SizeMB'; Expression={ [math]::Round($_.Size,2) } },
                          LastBackupDate, LastLogBackupDate

        [PSCustomObject]@{
            Server        = $server
            Build         = $info.BuildNumber
            Version       = $info.ProductVersion
            Edition       = $info.Edition
            DatabaseCount = ($dbs | Measure-Object).Count
            # Datenbanken ohne Backup in den letzten 24 Stunden markieren
            NeedBackup    = ($dbs | Where-Object { $_.LastBackupDate -lt (Get-Date).AddDays(-1) }).Name -join '; '
        }
    }
    catch {
        # Fehlerhafte Verbindungen protokollieren, nicht abbrechen
        [PSCustomObject]@{ Server = $server; Build = 'ERROR'; Version = $_.Exception.Message }
    }
}

# Ergebnis als CSV exportieren und in Steuertabelle laden
$inventory | Export-Csv -Path 'C:\admin\sql_inventory.csv' -NoTypeInformation -Encoding UTF8
Write-Host "Inventar fuer $($inventory.Count) Instanzen erstellt."

Dieses Skript erhebt ein vollständiges Inventar über beliebig viele Instanzen. Fehlerhafte Verbindungen werden protokolliert, ohne den Lauf abzubrechen. Das Ergebnis kann direkt in eine Steuertabelle geladen und als Grundlage für Patching und Monitoring genutzt werden.

-- Legt einen neuen SQL-Agent-Job an, der eine Wartungsaufgabe ausfuehrt.
-- Alle Schritte werden als T-SQL im Kontext des SQL Agent ausgefuehrt.
USE msdb;
GO

-- Job anlegen
EXEC sp_add_job
    @job_name        = N'DBA - Woechentliche Integritaetspruefung',
    @description     = N'Fuehrt DBCC CHECKDB auf allen Benutzerdatenbanken aus.',
    @category_name   = N'Database Maintenance',
    @owner_login_name= N'sa',
    @enabled         = 1;

-- Jobschritt: T-SQL-Skript, das CHECKDB ausfuehrt
EXEC sp_add_jobstep
    @job_name        = N'DBA - Woechentliche Integritaetspruefung',
    @step_name       = N'CHECKDB alle Benutzerdatenbanken',
    @subsystem       = N'TSQL',
    @command         = N'
DECLARE @sql NVARCHAR(MAX) = N'''';
-- Alle Benutzerdatenbanken iterieren
SELECT @sql += N''DBCC CHECKDB ('' + QUOTENAME(name) + N'') WITH NO_INFOMSGS;'' + CHAR(13)
FROM sys.databases
WHERE database_id > 4   -- nur Benutzerdatenbanken, keine Systemdatenbanken
  AND state_desc = ''ONLINE'';
EXEC sp_executesql @sql;',
    @on_success_action = 1,   -- naechsten Schritt ausfuehren
    @on_fail_action    = 2;   -- Job beenden und als Fehler melden

-- Zeitplan: jeden Sonntag um 01:00 Uhr
EXEC sp_add_schedule
    @schedule_name   = N'Sonntags 01:00 Uhr',
    @freq_type       = 8,       -- woechentlich
    @freq_interval   = 1,       -- Sonntag
    @active_start_time= 010000; -- 01:00:00 Uhr

EXEC sp_attach_schedule
    @job_name        = N'DBA - Woechentliche Integritaetspruefung',
    @schedule_name   = N'Sonntags 01:00 Uhr';

EXEC sp_add_jobserver
    @job_name        = N'DBA - Woechentliche Integritaetspruefung';
GO

Über sp_add_job, sp_add_jobstep und sp_add_schedule lassen sich SQL Agent Jobs vollständig per T-SQL erstellen und konfigurieren – reproduzierbar, versionierbar und ohne SSMS-Klickstrecken.

Automatisierung im Betriebsalltag

Automatisierung ist kein Einmalprojekt, sondern eine Haltung. Jede Aufgabe, die ich mehr als zweimal manuell ausführe, wandert in ein Skript. Jedes Skript, das verlässlich läuft, kommt in den SQL Agent oder in eine CI/CD-Pipeline. Dieser Grundsatz hat sich in großen Serverparks als entscheidend erwiesen: Nur wer repetitive Aufgaben automatisiert, hat genug Kapazität für die wirklich anspruchsvollen Probleme – Performance-Analyse, Architekturentscheidungen, komplexe Migrationen.

Entwicklungsbreite: SSIS, SSRS, SSAS, T-SQL

SQL Server ist nicht nur eine Datenbank-Engine, sondern eine vollständige Plattform für Datenbewegung, Berichtswesen und analytische Verarbeitung. Als Generalist auf dieser Plattform decke ich die volle Breite der Entwicklungsdisziplinen ab: ETL-Entwicklung mit SSIS, Berichtserstellung mit SSRS, analytische Modelle mit SSAS, T-SQL-Entwicklung für Stored Procedures, Views und Triggers sowie die Integration in übergeordnete Prozesse über SQL Agent und PowerShell.

SSIS: ETL-Entwicklung und Deployment

Integration Services ist mein wichtigstes ETL-Werkzeug. Ich habe SSIS-Projekte in den Versionen 2005 bis 2022 entwickelt und migriert: einfache Dateiladesystemme, komplexe Delta-Load-Szenarien mit Slowly Changing Dimensions, parameterisierte Strecken für Multi-Mandanten-Umgebungen und vollautomatisierte Deployment-Prozesse über den SSIS-Katalog (SSISDB) und SQL Agent. Bei einem Industrieunternehmen habe ich SSIS-Pakete von Version 2016 auf 2022 migriert und gleichzeitig den gesamten Build-Prozess auf Azure DevOps umgestellt. Bei einer Sparkasse habe ich Java- und Oracle-basierte ETL-Prozesse vollständig durch SSIS-Strecken ersetzt und dabei Performance und Wartbarkeit deutlich verbessert.

SSRS: Reports und Subscriptions

Reporting Services deckt paginated Reports ab, die tabellarisch, matrixförmig oder als Chart gerendert werden können. Ich habe SSRS-Reports für operative und analytische Zwecke gebaut, Subscriptions für automatisierten E-Mail-Versand konfiguriert und parameterisierte Reports entwickelt, die von Benutzergruppen mit unterschiedlichen Berechtigungen genutzt werden. Die Integration von SSRS mit SSAS-Cubes für MDX-basierte Berichte gehört ebenso zum Repertoire.

SSAS: Tabular und Multidimensional

Analysis Services unterstützt zwei Modelle: das klassische mehrdimensionale Modell mit OLAP-Cubes und MDX sowie das modernere tabellarische Modell, das die Grundlage für Power BI Premium bildet. Ich habe tabellarische SSAS-Modelle als zentrale semantische Schicht zwischen Datenbank und Power BI entwickelt – mit berechneten Spalten, Measures in DAX, Row-Level-Security und optimierten Partitionen für schnelle Verarbeitung. Mehrdimensionale Modelle habe ich in älteren Umgebungen gebaut und gewartet, einschließlich MDX-Abfragen für SSRS-Reports.

T-SQL: Entwicklung und Optimierung

T-SQL ist die Sprache, in der SQL-Server-Logik lebt. Stored Procedures, Views, Functions, Triggers, dynamisches SQL, Common Table Expressions (CTEs), Fensterfunktionen, Partitionierung und columnstore-Index-Nutzung – all das gehört zu meinem Werkzeugkasten. Ich entwickle T-SQL mit Blick auf Wartbarkeit und Performance: saubere Formatierung, Kommentare, Parametrisierung gegen SQL Injection, und ein Auge auf Ausführungspläne, die verraten, ob die Abfrage so läuft, wie sie soll.

Diese Entwicklungsbreite ergänzt die Administrationsaufgaben auf natürliche Weise. Wenn eine SSIS-Strecke Performanceprobleme verursacht, verstehe ich sowohl die ETL-Logik als auch die Auswirkungen auf den SQL-Server-Index-Zustand. Wenn eine SSAS-Verarbeitung lange dauert, kann ich sowohl das tabellarische Modell als auch die Quelldatenbank optimieren. Diese Querverbindungen machen den Unterschied zwischen einem Spezialisten, der nur seine Disziplin kennt, und einem Generalisten, der die gesamte Plattform überblickt.

Vorgehen in der Zusammenarbeit

Der Einstieg in ein neues SQL-Server-Engagement beginnt immer mit Zuhören und Bestandsaufnahme, nicht mit Lösungen. Bevor ich eine Empfehlung ausspreche, verschaffe ich mir ein Bild der vorhandenen Landschaft: Versionen, Konfigurationen, vorhandene Skripte und Prozesse, offene Schwachstellen und die Erwartungen der Beteiligten. Diese Bestandsaufnahme dauert typischerweise ein bis zwei Tage, spart aber Wochen an fehlgeleiteter Arbeit.

• Bestandsaufnahme: Instanzen, Versionen, Konfigurationen, Prozesse, Schwachstellen
• Priorisierung: Kritische Risiken zürst – Backup, HA, Sicherheitslücken
• Umsetzung: Schrittweise, mit Tests und Rollback-Option bei jedem Schritt
• Automatisierung: Wiederholbare Prozesse in Skripte und Jobs überführen
• Dokumentation: Konfigurationen, Entscheidungen und Betriebsabläufe festhalten
• Übergabe: Wissen auf das interne Team übertragen, nicht abhängig machen

Ich arbeite remote, hybrid und vor Ort. Für viele DBA-Aufgaben – Monitoring, Analyse, Scripting – ist Remote ausreichend und effizienter. Für initiale Bestandsaufnahmen, sensible Migrationen und die Übergabe an interne Teams ist persönliche Anwesenheit oft wertvoller. Ich richte mich nach dem, was im Projekt sinnvoll ist.

Eine besondere Stärke ist meine Erfahrung in regulierten Umgebungen. Im Finanzsektor und in der öffentlichen Verwaltung gelten strengere Anforderungen an Dokumentation, Rückverfolgbarkeit und Sicherheit. Ich kenne diese Anforderungen aus langjähriger Arbeit in solchen Umgebungen und bringe die entsprechende Sorgfalt mit – ohne dabei die operative Effizienz zu opfern.

Was alle meine Projekte verbindet, ist der Anspruch, dass am Ende des Engagements das interne Team eigenständig weiterarbeiten kann. Das bedeutet, dass ich Wissen übertrage, nicht anreichere. Skripte, die nur ich verstehe, und Konfigurationen, die nur ich kenne, sind kein Projekterfolg. Dokumentierte Prozesse, nachvollziehbare Skripte und ein Team, das die Lösung trägt, sind das Ziel.

Typische Leistungen als SQL Server Freelancer

Das Spektrum meiner SQL-Server-Leistungen deckt die gesamte Plattform ab – von der Grundlagenarbeit in der Administration bis zur komplexen Entwicklungsaufgabe. Je nach Projektphase und Bedarf übernehme ich einzelne Bereiche oder das vollständige Spektrum.

• SQL Server Administration: Installation, Konfiguration, Betrieb, Monitoring
• Performance-Analyse: Wait Statistics, Ausführungspläne, Index-Tuning, Query Store
• Hochverfügbarkeit: Always On Availability Groups, Failover Cluster Instances, Log Shipping
• Disaster Recovery: Backup-Strategie, Point-in-Time-Recovery, Restore-Tests, DR-Planung
• Sicherheit: Berechtigungskonzept, Audit-Konfiguration, TDE, Login-Härtung
• Patching und Wartung: CU-Rollout, DBCC CHECKDB, Wartungsfenster, Index-Wartung
• Versionsmigrationen: Analyse, Test, Migration, Kompatibilitätsstufenmanagement
• Automatisierung: PowerShell-Skripte, dbatools-Workflows, SQL Agent Jobs
• ETL-Entwicklung mit SSIS: Entwicklung, Migration, Deployment, Performance
• Reporting mit SSRS: Reports, Subscriptions, Parameterisierung, RLS
• Analytische Modelle mit SSAS: Tabellarisch (DAX), Multidimensional (MDX)
• T-SQL-Entwicklung: Stored Procedures, Views, CTEs, Fensterfunktionen, Partitionierung
• Azure-Integration: Azure SQL, SQL Server on Azure VM, Azure Data Factory mit SQL Server

Diese Leistungsbreite bedeutet nicht, dass ich jedes Thema gleich tief bearbeite. Performance-Tuning und Hochverfügbarkeit sind Bereiche, in denen ich besonders intensiv gearbeitet habe; SSAS-Entwicklung und T-SQL-Optimierung sind Disziplinen, die ich täglich ausübe. Die Breite ermöglicht es, Projekte ohne Schnittstellenverluste zu begleiten, die Tiefe in den jeweiligen Bereichen sichert die Qualität.

Ob es um eine kurzfristige Unterstützung bei einem akuten Performance-Problem geht, um die Vorbereitung einer Versionsmigration über mehrere Monate, um den Aufbau einer neuen SSIS-Landschaft oder um die langfristige Betreuung eines SQL-Server-Parks – ich steige dort ein, wo der Bedarf am größten ist, und passe Aufwand und Fokus dem Projekt an. Diese Flexibilität ist gerade für Organisationen wertvoll, die keinen Vollzeit-DBA beschäftigen, aber dennoch auf eine zuverlässige SQL-Server-Infrastruktur angewiesen sind.

Ausgewählte anonymisierte Referenzprojekte

Häufige Fragen zum SQL Server Freelancer