SQL Server 2025 –
Die DBA-Perspektive

Der Setup-Prozess selbst ist strukturell vertraut. Wer SQL Server 2019 oder 2022 installiert hat, findet sich sofort zurecht. Es gibt jedoch einige inhaltliche Änderungen, die vor der Installation bekannt sein sollten.

Mindestanforderungen

Neue Editionsstruktur beim Setup

Erstmals gibt es für die Developer Edition eine Aufteilung: Standard Developer und Enterprise Developer. Das ist ein echter Gewinn für Entwicklungs- und Testumgebungen – bisher war Developer immer Enterprise-Funktionsumfang, was dazu führte, dass Features genutzt wurden, die in der Produktions-Standard-Edition nicht verfügbar waren.

Azure Extension – standardmäßig aktiviert, oft nicht gewünscht

Der Installer bietet standardmäßig die Azure Extension für SQL Server an (für Azure Arc-Integration). In reinen on-premises Umgebungen ohne Azure Arc sollte dieser Schritt deaktiviert werden. Die Extension ist nicht gefährlich, erzeugt aber unnötige Netzwerkverbindungen nach außen und erfordert Azure-Zugangsdaten, die in vielen Unternehmen nicht vorhanden oder erlaubt sind.

Entfernte Features beim Setup

Folgende Komponenten sind aus dem Installer entfernt und können nicht mehr installiert werden:

• Data Quality Services (DQS) – eingestellt
• Master Data Services (MDS) – eingestellt
• Synapse Link – eingestellt
• SQL Server Reporting Services (SSRS) – ersetzt durch Power BI Report Server
• Machine Learning Services Packages (R/Python als eigenständiger Installer-Schritt) – neu strukturiert

Unbeaufsichtigte Installation mit Konfigurationsdatei

; SQL Server 2025 – Konfigurationsdatei für unbeaufsichtigte Installation
[OPTIONS]
ACTION = "Install"
FEATURES = SQLENGINE,REPLICATION,FULLTEXT,IS
INSTANCENAME = "MSSQLSERVER"
SQLSVCACCOUNT = "NT Service\MSSQLSERVER"
SQLSYSADMINACCOUNTS = "DOMAIN\DBAGruppe"
AGTSVCACCOUNT = "NT Service\SQLSERVERAGENT"
AGTSVCSTARTUPTYPE = "Automatic"
TCPENABLED = 1
NPENABLED = 0
BROWSERSVCSTARTUPTYPE = "Disabled"
SECURITYMODE = "SQL" ; Nur wenn Mixed Mode benötigt
SQLCOLLATION = "Latin1_General_CI_AS"
INSTALLSQLDATADIR = "D:\SQLData"
SQLUSERDBDIR = "D:\SQLData"
SQLUSERDBLOGDIR = "E:\SQLLog"
SQLTEMPDBDIR = "F:\SQLTempDB"
SQLTEMPDBLOGDIR = "F:\SQLTempDB"
SQLTEMPDBFILECOUNT = 8 ; 1 pro logischem CPU-Kern, max 8
AZUREEXTENSION = 0 ; Azure Extension deaktivieren

; Installation starten:
; setup.exe /ConfigurationFile=ConfigurationFile.ini /IACCEPTSQLSERVERLICENSETERMS

SQL Server 2025 kommt mit einigen geänderten Standardwerten aus der Box. Das Ziel ist „Secure by Default" – was bedeutet, dass restriktivere Defaults gesetzt sind als in Vorgängerversionen. Für DBAs heißt das: Bestehende Konfigurationsroutinen müssen geprüft werden.

Datenbankkompatibilitätslevel

Neu erstellte Datenbanken erhalten automatisch Kompatibilitätslevel 170. Bestehende Datenbanken behalten nach einem Upgrade ihren bisherigen Level. Viele der neuen Performance-Features (OPPO, erweiterte IQP-Funktionen) sind an Level 170 gebunden.

-- Aktuellen Level aller Benutzerdatenbanken anzeigen
SELECT
  name,
  compatibility_level,
  CASE compatibility_level
    WHEN 170 THEN 'SQL Server 2025'
    WHEN 160 THEN 'SQL Server 2022'
    WHEN 150 THEN 'SQL Server 2019'
    ELSE 'Älter'
  END AS Version
FROM sys.databases
WHERE database_id > 4 -- Systemdatenbanken ausschließen
ORDER BY name;

-- Level auf SQL Server 2025 anheben (nach Test!)
ALTER DATABASE MeineDatenbank
  SET COMPATIBILITY_LEVEL = 170;

TempDB – Best Practices bleiben, neue Governance kommt

Die TempDB-Empfehlungen (eine Datei pro logischem CPU-Kern, max. 8, gleiche Größe, Autogrowth deaktivieren) gelten unverändert. Neu in SQL Server 2025 ist die TempDB Space Resource Governance: DBAs können jetzt prozentuale Obergrenzen für TempDB-Nutzung pro Session oder Workload-Gruppe setzen. Das verhindert, dass einzelne unkontrollierte Abfragen die TempDB volllaufen lassen.

-- Workload-Gruppe mit TempDB-Limit erstellen
CREATE WORKLOAD GROUP BegrenzteTempDBNutzung
WITH (
  TEMPDB_MEMORY_PERCENT = 20 -- Max. 20% der TempDB für diese Gruppe
)
USING 'default';

-- Bestehende Gruppe anpassen
ALTER WORKLOAD GROUP [default]
WITH (TEMPDB_MEMORY_PERCENT = 80);

-- Resource Governor neu laden
ALTER RESOURCE GOVERNOR RECONFIGURE;

Protokoll-Konfiguration – TCP/IP prüfen

Der Installer aktiviert TCP/IP-Verbindungen standardmäßig. Named Pipes sollten für Server-zu-Server-Kommunikation deaktiviert bleiben. Browser-Dienst ist bei bekannten Ports ebenfalls nicht erforderlich und sollte deaktiviert sein.

Query Store – jetzt automatisch auf Sekundärrepliken

Query Store ist jetzt standardmäßig auch auf lesbaren Sekundärrepliken im Read-Write-Modus aktiv. Das bedeutet: Execution Plans und Performance-Daten werden auch für Lesezugriffe auf Sekundärrepliken erfasst – ohne manuellen Eingriff.

-- Query Store Status und Konfiguration prüfen
SELECT
  actual_state_desc,
  desired_state_desc,
  readonly_reason,
  current_storage_size_mb,
  max_storage_size_mb,
  query_capture_mode_desc,
  size_based_cleanup_mode_desc
FROM sys.database_query_store_options;

-- Query Store für eine Datenbank aktivieren / konfigurieren
ALTER DATABASE [MeineDatenbank]
SET QUERY_STORE = ON
(
  OPERATION_MODE = READ_WRITE,
  CLEANUP_POLICY = (STALE_QUERY_THRESHOLD_DAYS = 30),
  MAX_STORAGE_SIZE_MB = 1024,
  QUERY_CAPTURE_MODE = AUTO,
  SIZE_BASED_CLEANUP_MODE = AUTO
);

SQL Server 2025 ist das erste Release, das konsequent das Zero-Trust-Prinzip umsetzt – nicht als Marketing-Begriff, sondern als konkrete Änderung an Standardwerten und Protokollen. Einige dieser Änderungen sind Breaking Changes, die ohne Vorbereitung Verbindungsausfälle verursachen.

TLS 1.3 und TDS 8.0 – Verschlüsselung ist jetzt Standard

Alle neuen SQL Server 2025-Instanzen akzeptieren standardmäßig nur noch verschlüsselte Verbindungen (Encrypt=True ist Default). Verbindungsstrings ohne explizite Verschlüsselung werden abgelehnt. Das Protokoll dahinter ist TDS 8.0 mit TLS 1.3 – die Verschlüsselung beginnt bereits in der Pre-Login-Phase, nicht erst nach dem Handshake.

Granulares Security Cache Invalidation

Bisher wurde beim Ändern von Berechtigungen für einen Login der gesamte Server-Security-Cache invalidiert. Auf Systemen mit 20.000+ parallelen Verbindungen führte das zu messbaren Performance-Einbrüchen. SQL Server 2025 invalidiert nur noch den Cache des betroffenen Logins – alle anderen Verbindungen sind nicht betroffen.

-- In SQL Server 2025: nur L1-Cache wird invalidiert, L2 bleibt unberührt
GRANT SELECT ON dbo.Transaktionen TO [L1];

-- Sicherheits-Cache-Status einsehen (neue DMV in 2025)
SELECT
  login_name,
  cache_invalidation_count,
  last_invalidation_time
FROM sys.dm_exec_security_cache_stats
ORDER BY cache_invalidation_count DESC;

PBKDF2 für SQL-Logins

Passwörter für SQL Server Authentication Logins werden jetzt mit PBKDF2 (RFC 2898) und 100.000 Iterationen gehasht statt mit dem bisherigen einfachen SHA-512-Hash. Das macht Brute-Force-Angriffe auf gestohlene Password-Hashes um Größenordnungen langsamer. Der Wechsel erfolgt automatisch – bestehende Logins werden beim nächsten Passwortänderung migriert.

Neue Datenbankrollen für spezifische Aufgaben

SQL Server 2025 führt granulare, vordefinierte Datenbankrollen für neue Aufgabenbereiche ein – u.a. für externe REST-API-Aufrufe und KI-Modell-Ausführung. Das ermöglicht es DBAs, das Least-Privilege-Prinzip auch für moderne Workloads durchzusetzen, ohne sysadmin-Rechte vergeben zu müssen.

Verbindungs-Inventur vor dem Upgrade

-- Alle aktuell aktiven Verbindungen und deren Verschlüsselungsstatus
SELECT
  s.session_id,
  s.login_name,
  s.program_name,
  s.host_name,
  c.encrypt_option,
  c.auth_scheme,
  c.net_transport,
  c.protocol_version
FROM sys.dm_exec_sessions s
INNER JOIN sys.dm_exec_connections c ON s.session_id = c.session_id
WHERE s.is_user_process = 1
  AND c.encrypt_option = 'FALSE' -- Nur unverschlüsselte Verbindungen
ORDER BY s.login_name;

SQL Server 2025 bringt die umfangreichsten AlwaysOn-Verbesserungen seit der Einführung von Availability Groups in SQL Server 2012. Viele Änderungen adressieren direkt Probleme, über die DBAs in der Community seit Jahren diskutieren.

Vollständige Backups auf Sekundärrepliken

Bisher konnten auf Sekundärrepliken nur Copy-Only-Backups erstellt werden. SQL Server 2025 erlaubt jetzt vollständige, differentielle und Log-Backups auf Sekundärrepliken. Das entlastet den Primary erheblich und ermöglicht eine echte Verteilung der Backup-Last.

-- Backup-Präferenz auf Sekundärreplika setzen
ALTER AVAILABILITY GROUP [AG_Produktion]
  MODIFY BACKUP_PRIORITY = 50 -- 0=Primary, 50=Bevorzugt Secondary, 100=Nur Secondary
  ON SECONDARY;

-- Vollständiges Backup auf aktivem Sekundärreplika (SQL Server 2025)
BACKUP DATABASE [MeineDatenbank]
  TO DISK = N'\\backup\MeineDatenbank_Full.bak'
  WITH
    COMPRESSION,
    ALGORITHM = 'ZSTD', -- Neuer Kompressionsalgorithmus
    CHECKSUM,
    STATS = 10;

-- Differentielles Backup auf Sekundärreplika (neu in 2025)
BACKUP DATABASE [MeineDatenbank]
  TO DISK = N'\\backup\MeineDatenbank_Diff.bak'
  WITH DIFFERENTIAL, COMPRESSION, ALGORITHM = 'ZSTD', CHECKSUM;

Schnelleres Failover durch Log-Record-Caching

Ein neuer Caching-Mechanismus beschleunigt das Replay von Log-Records auf Sekundärrepliken während und nach einem Failover. Sekundärrepliken müssen weniger Zeit für das Aufholen nach einem Failover aufwenden – die effektive Failover-Zeit sinkt. Das ist besonders relevant für AGs mit hohem Transaktionsvolumen, wo Sekundärrepliken bisher nach einem Failover messbar nachhinken konnten.

TLS 1.3 für AG-interne Kommunikation

Die Kommunikation zwischen Repliken kann jetzt ebenfalls auf TLS 1.3 / TDS 8.0 erzwungen werden. Bei neuen AGs kann das direkt beim Erstellen konfiguriert werden; bei bestehenden AGs nach dem Upgrade.

-- Neue AG mit TLS 1.3-Verschlüsselung erstellen
CREATE AVAILABILITY GROUP [AG_Secure]
WITH (
  CLUSTER_TYPE = WSFC,
  CLUSTER_CONNECTION_OPTIONS = 'Encrypt=Strict', -- Neu in 2025
  AUTOMATED_BACKUP_PREFERENCE = SECONDARY,
  DB_FAILOVER = ON
)
FOR DATABASE [MeineDatenbank]
REPLICA ON
  'SQL01' WITH (
    ENDPOINT_URL = 'TCP://sql01.intern:5022',
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
    FAILOVER_MODE = AUTOMATIC
  ),
  'SQL02' WITH (
    ENDPOINT_URL = 'TCP://sql02.intern:5022',
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
    FAILOVER_MODE = AUTOMATIC
  );

-- Bestehende AG auf Strict Encryption umstellen
ALTER AVAILABILITY GROUP [AG_Produktion]
  MODIFY CLUSTER_CONNECTION_OPTIONS = 'Encrypt=Strict';
-- Anschließend Failover durchführen, damit die Einstellung wirksam wird

Query Store auf Sekundärrepliken – Diagnose wo die Last ist

Query Store ist auf lesbaren Sekundärrepliken jetzt im Read-Write-Modus aktiv. Das bedeutet: Performance-Regressions, schlechte Execution Plans und langsame Abfragen auf Sekundärrepliken können direkt am Ort des Geschehens diagnostiziert werden – nicht mehr nur indirekt über den Primary.

-- Auf Sekundärreplika ausführen – jetzt auch dort im Query Store erfasst
SELECT TOP 20
  qt.query_sql_text,
  rs.avg_duration / 1000.0 AS avg_ms,
  rs.avg_logical_io_reads AS avg_reads,
  rs.count_executions,
  qp.query_plan
FROM
  sys.query_store_query_text qt
  JOIN sys.query_store_query q ON qt.query_text_id = q.query_text_id
  JOIN sys.query_store_plan qp ON q.query_id = qp.query_id
  JOIN sys.query_store_runtime_stats rs
                  ON qp.plan_id = rs.plan_id
WHERE rs.last_execution_time > DATEADD(HOUR, -1, GETUTCDATE())
ORDER BY rs.avg_duration DESC;

Verbesserte AG-Diagnostik

Microsoft hat neue DMV-Inhalte und Extended Events für die AG-Diagnose hinzugefügt. Failover-Ursachen, Synchronisierungsverzögerungen und Replica-Status lassen sich jetzt detaillierter analysieren als in SQL Server 2022.

-- AG-Gesundheit und Synchronisierungsverzögerung aller Repliken
SELECT
  ag.name AS AG_Name,
  ar.replica_server_name AS Replika,
  ars.role_desc AS Rolle,
  ars.synchronization_health_desc AS SyncHealth,
  ars.connected_state_desc AS Verbindung,
  ars.last_commit_time AS LetzterCommit,
  DATEDIFF(SECOND,
    ars.last_commit_time,
    GETDATE()) AS VerzögerungSek
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
ORDER BY ag.name, ars.role_desc;

SQL Server 2025 enthält mehr als 40 Engine-Verbesserungen. Einige wirken automatisch nach dem Upgrade, andere sind an den Kompatibilitätslevel 170 gebunden. Der wichtigste Grundsatz: nichts ändert sich ohne Test – auch vermeintlich transparente Optimierungen können in seltenen Fällen Regressionen verursachen.

OPPO – Parametersniffing endlich addressiert

Optional Parameter Plan Optimization (OPPO) ist die Antwort auf ein der häufigsten Performance-Beschwerden: der gecachte Plan für eine Abfrage passt nicht zu den aktuellen Parameterwerten. Bisher musste man mit OPTION (RECOMPILE), Stored Procedure-Restrukturierung oder Query Store-Erzwingungen arbeiten. OPPO ermöglicht es dem Optimizer, für bestimmte Parameterwert-Konstellationen dynamisch einen besseren Plan zu wählen.

-- Workaround: RECOMPILE erzwingen
SELECT *
FROM dbo.Transaktionen
WHERE KundeID = @KID
  AND Datum > @VonDatum
OPTION (RECOMPILE);
-- Nachteil: kein Plan-Caching,
-- hohe Kompilierungskosten

-- OPPO wirkt automatisch bei Level 170
-- Optimizer wählt Plan basierend auf
-- tatsächlichen Parameterwerten
SELECT *
FROM dbo.Transaktionen
WHERE KundeID = @KID
  AND Datum > @VonDatum;
-- Kein RECOMPILE nötig,
-- kein Code-Eingriff

TID-Locking und Lock-After-Qualification (LAQ)

SQL Server 2025 führt Transaction ID (TID) Locking ein: Locks werden nicht mehr per Zeilenreferenz, sondern per Transaktions-ID verwaltet. Das reduziert Lock-Memory-Overhead und senkt LCK_M_IX-Wait-Zeiten unter Last messbar. Lock-After-Qualification (LAQ) verzögert das Setzen von Locks bis nach der Prädikat-Auswertung – weniger Zeilen werden unnötig gesperrt.

Accelerated Database Recovery (ADR) jetzt auch für TempDB

ADR – eingeführt in SQL Server 2019 für Benutzerdatenbanken – ist jetzt auch für TempDB aktiv. Das reduziert die Menge an Version-Store-Daten in TempDB und verbessert die Recovery-Zeit nach unerwarteten Abbrüchen von langen Transaktionen.

Optimiertes sp_executesql

Dynamisches SQL über sp_executesql konnte in früheren Versionen Kompilierungsstürme verursachen, weil jeder Aufruf als einzigartig behandelt wurde. SQL Server 2025 serialisiert Kompilierungen ähnlich wie bei Stored Procedures – deutlich weniger CPU-Overhead bei häufig ausgeführtem dynamischem SQL.

Columnstore-Verbesserungen

Ordered Non-Clustered Columnstore Indexes erlauben jetzt eine definierte Sortierung. Online-Index-Builds sind schneller, und das Shrinking von Dateien mit Columnstore-Indizes blockiert nicht mehr für lange Zeiträume.

-- Geordneter Non-Clustered Columnstore Index (neu in SQL Server 2025)
-- Verbessert analytische Abfragen mit ORDER BY erheblich
CREATE NONCLUSTERED COLUMNSTORE INDEX NCCI_Transaktion_Datum
  ON dbo.Transaktion (KundeID, BetragEur, TransDatum)
  ORDER (TransDatum) -- Sortierung für Zeitreihenabfragen
  WITH (ONLINE = ON);

-- Verifikation: Fragmentierung und Zeilengruppen-Qualität
SELECT
  i.[name] AS Indexname,
  css.row_group_id,
  css.state_desc,
  css.total_rows,
  css.deleted_rows,
  css.size_in_bytes / 1024 AS GroesseKB
FROM sys.column_store_segments css
INNER JOIN sys.indexes i ON css.object_id = i.object_id
                     AND css.index_id = i.index_id
WHERE i.[name] = 'NCCI_Transaktion_Datum'
ORDER BY css.row_group_id;

SQL Server 2025 führt den ZSTD-Kompressionsalgorithmus für Backups ein und ergänzt die bestehende Backup-Kompression erheblich. Für DBAs, die täglich Backup-Strategien verantworten, ist das die greifbarste sofort nutzbare Verbesserung.

ZSTD vs. bisherige Kompression

-- Vollbackup mit ZSTD auf Netzwerkshare
BACKUP DATABASE [Produktion]
  TO DISK = N'\\nas01\backup\Produktion_Full_20260419.bak'
  WITH
    COMPRESSION,
    ALGORITHM = 'ZSTD', -- Neu in SQL Server 2025
    CHECKSUM,
    STATS = 5,
    DESCRIPTION = N'Vollbackup Produktion 2026-04-19';

-- Backup auf Azure Blob Storage mit Managed Identity (kein Passwort)
BACKUP DATABASE [Produktion]
  TO URL = N'https://meinstorage.blob.core.windows.net/backups/Prod.bak'
  WITH
    COMPRESSION,
    ALGORITHM = 'ZSTD',
    CHECKSUM,
    CREDENTIAL = N'ManagedIdentityCredential'; -- Keine SAS-Token nötig

-- Backup-Integrität prüfen
RESTORE VERIFYONLY
  FROM DISK = N'\\nas01\backup\Produktion_Full_20260419.bak'
  WITH CHECKSUM;

Backup-Restore-Kompatibilität beachten

Full-Text Search: Neuaufbau der Indizes nach Upgrade

SQL Server 2025 ersetzt alle Legacy Word Breaker-Binaries durch moderne Implementierungen. Bestehende Full-Text-Indizes werden als Version 1 markiert und können sofort nach dem Upgrade Fehler (Msg 30010) verursachen. Der Neuaufbau der Indizes ist zwingend erforderlich.

-- Alle Full-Text Indizes und deren Version prüfen
SELECT
  OBJECT_NAME(object_id) AS Tabelle,
  index_version, -- 1 = Legacy (veraltet), 2 = Neu (SQL 2025)
  full_text_catalog_id,
  change_tracking_state_desc
FROM sys.fulltext_indexes;

-- Full-Text Katalog neu befüllen (Version 1 → Version 2)
ALTER FULLTEXT CATALOG [MeinKatalog] REBUILD;

-- Oder pro Tabelle:
ALTER FULLTEXT INDEX ON dbo.Dokumente START FULL POPULATION;

Abseits der großen Feature-Ankündigungen gibt es in SQL Server 2025 eine Reihe von Verbesserungen, die im Tagesgeschäft des DBA direkt spürbar werden.

In-Memory OLTP deaktivieren ohne Datenverlust

Wer In-Memory OLTP (Hekaton) in einer Datenbank aktiviert hatte und jetzt davon wegmöchte, musste bisher alle speicheroptimierten Tabellen löschen, bevor die Funktion deaktiviert werden konnte. Das verursachte auch Probleme mit VSS-Backups. SQL Server 2025 erlaubt das Deaktivieren von In-Memory OLTP ohne vorheriges Löschen der Objekte.

-- In-Memory OLTP-Filegroup aus Datenbank entfernen (ohne Datenverlust)
-- Voraussetzung: keine aktiven Transaktionen auf speicheroptimierten Tabellen
ALTER DATABASE [MeineDatenbank]
  REMOVE FILE [InMemory_Container]
  WITH (WAIT_AT_LOW_PRIORITY (MAX_DURATION = 5 MINUTES,
                ABORT_AFTER_WAIT = BLOCKERS));

-- Datenbank-Status nach Entfernung prüfen
SELECT
  name,
  is_memory_optimized_elevate_to_snapshot_on,
  FILEGROUPPROPERTY(name, 'IsMemoryOptimized') AS IsMemoryOptimized
FROM sys.filegroups;

SSMS 22 – 64-Bit, Git-Integration, Copilot

SQL Server Management Studio 22 ist der Begleit-Client für SQL Server 2025. Wichtigste Neuerungen für den DBA-Alltag:

• 64-Bit-Prozess – kein Speicherlimit mehr bei großen Ergebnismengen und langen Skripten
• Git-Integration – T-SQL-Skripte direkt im SSMS mit Git verwalten
• Copilot (Preview) – natürlichsprachliche Abfragegenerierung und Execution-Plan-Erklärung
• Query Store-Dashboard – deutlich verbesserte Visualisierung von Plan-Regressions

Nützliche neue T-SQL-Funktionen für den Betrieb

-- IS [NOT] DISTINCT FROM – NULL-sicherer Vergleich (kein = NULL Fehler mehr)
SELECT *
FROM dbo.Konto
WHERE Status IS NOT DISTINCT FROM @Status;
-- Entspricht: WHERE (Status = @Status) OR (Status IS NULL AND @Status IS NULL)

-- GREATEST / LEAST über mehrere Spalten
SELECT
  KontoID,
  GREATEST(Limit1, Limit2, ÜberzugsLimit) AS MaxLimit,
  LEAST (Zins1, Zins2, MinZins) AS MinZins
FROM dbo.Konditionen;

-- RegEx: IBAN-Format validieren
SELECT
  KontoID, IBAN,
  REGEXP_LIKE(IBAN, N'^[A-Z]{2}\d{2}[A-Z0-9]{4}\d{7}[A-Z0-9]{0,16}$')
    AS IBANFormatOK
FROM dbo.Bankverbindung;

-- PRODUCT()-Aggregat für Zinseszinsberechnung
SELECT
  PortfolioID,
  PRODUCT(1 + MonatsRendite) - 1 AS KumulierteRendite
FROM dbo.Monatsrenditen
GROUP BY PortfolioID;

-- BASE64_ENCODE / BASE64_DECODE für sichere Übertragung
SELECT
  BASE64_ENCODE(CAST('Geheimtext' AS VARBINARY(100))) AS Encoded,
  CAST(BASE64_DECODE('R2VoZWltdGV4dA==') AS VARCHAR(100)) AS Decoded;

SQL Server 2025 entfernt und depreciert mehr Features als ein typisches Minor-Release. DBAs müssen diese Liste gegen ihre aktuelle Umgebung abgleichen.

SQL Server 2025 ist ein überzeugendes Release – die AlwaysOn-Verbesserungen, ZSTD, OPPO und die Sicherheitsverbesserungen sind reale Mehrwerte für den Betrieb. Aber: Breaking Changes bei Verschlüsselung und Verbindungen erfordern sorgfältige Vorbereitung.

Empfohlene Upgrade-Reihenfolge

1. Inventur durchführen: Alle Verbindungsstrings, Linked Server, Replikations-Topologien, FTS-Indizes und verwendete Features dokumentieren
2. Entwickler-Edition upgraden: SQL Server 2025 Enterprise/Standard Developer in der Entwicklungsumgebung installieren – erste Erfahrungen sammeln
3. Staging-Upgrade mit echten Daten: Anonymisierte Produktionsdaten einspielen, alle Anwendungen testen, Breaking Changes identifizieren
4. Auf CU1 warten: Das erste Cumulative Update (CU1 erschien Frühjahr 2026) schließt bekannte RTM-Lücken. Für Produktion empfiehlt sich mindestens CU1
5. Verbindungsstrings anpassen: Alle Anwendungen auf Encrypt=True umstellen, Zertifikate für Linked Server konfigurieren
6. FTS-Indizes neu aufbauen: Nach dem Upgrade sofort, nicht aufschieben
7. Kompatibilitätslevel schrittweise anheben: Erst Instanz upgraden, Betrieb stabilisieren, dann Datenbanken auf Level 170 migrieren
8. SSMS 22 installieren: Parallel möglich – kein Deinstallieren von SSMS 18/19 erforderlich

Pre-Upgrade-Checkliste

• Verbindungsstrings Inventur: Alle Encrypt=False-Verbindungen identifiziert und auf True umgestellt?
• OLE DB Driver: Alle Anwendungsserver und Linked-Server-Quellen auf OLE DB Driver ≥ 19 aktualisiert?
• Linked Server Zertifikate: Trusted Certificates für alle Linked-Server-Verbindungen konfiguriert?
• Replikation: Remote-Distributor mit gültigem Zertifikat versehen oder trust_distributor_certificate=yes gesetzt?
• Full-Text Search: FTS-Kataloge und Rebuild-Plan nach Upgrade vorbereitet?
• Entfernte Features: DQS, MDS, SSRS, SQL Mail in der Umgebung aktiv? Migrationsplan vorhanden?
• AG-Zertifikate: Für geplante TLS 1.3 AG-Kommunikation: Zertifikate auf allen Repliken installiert?
• Rollback-Plan: Datenbankkompatibilitätslevel als Fallback-Option definiert? Backup-Strategie für Pre-Upgrade-Zustand?