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?