AlwaysOn & Migration

Distributed Availability Groups - Das DBA-Tool fuer Migration & Multi-Site

Zwei Cluster, eine Loesung: Wie Distributed AGs Server-Migrationen, OS-Wechsel und standortuebergreifende Disaster Recovery mit minimaler Downtime ermoeglichen - und warum dieses oft unterschaetzte Feature fuer jeden DBA unverzichtbar ist.

Was ist eine Distributed AG? Szenarien Setup Failover Stolpersteine Listener-Migration Fallback sqmSQLTool Fazit

Was ist eine Distributed Availability Group?

Eine verteilte Verfuegbarkeitsgruppe verbindet zwei separate Availability Groups ueber verschiedene Windows Server Failover Cluster (WSFC) hinweg. Die einzelnen AGs koennen sich an unterschiedlichen Orten befinden - ob lokal, in der Public Cloud oder plattformuebergreifend.

Klassische AG

Alle Knoten in einem WSFC
Maximal 8 Replicas
Kein gemeinsamer Storage
Abhaengig von Windows Cluster

Distributed AG

Verbindet zwei unabhaengige WSFC
Bis zu 18 Replicas (9+9)
Kein gemeinsamer Cluster
Vollstaendig in SQL Server verwaltet

Der entscheidende Vorteil: Durch die Aufteilung auf zwei Cluster wird der Netzwerk-Traffic ueber das WAN halbiert. Jede AG synchronisiert intern zwischen ihren eigenen Knoten - nur der Forwarding-Knoten schickt Daten an den zweiten Cluster.

Enterprise Edition Pflicht: Distributed AGs sind ausschliesslich in der SQL Server Enterprise Edition verfuegbar. Standard Edition wird nicht unterstuetzt.

Wann eine Distributed AG einsetzen?

Typische Einsatzszenarios

Migration on-premises nach Cloud (Azure, AWS)
Standortuebergreifende Disaster Recovery (zwei Rechenzentren)
Upgrade von SQL Server 2016/2019 auf 2022/2025
Wechsel des Betriebssystems (Windows nach Linux)
Wechsel der Hardware-Plattform ohne Downtime

In all diesen Szenarien ist die Distributed AG die eleganteste Loesung mit minimaler Downtime. Der Konfigurationsaufwand ist hoeher als bei einer klassischen AG - zahlt sich aber durch Flexibilitaet und geringere Netzwerklasten aus.

Szenario 1: Migration in die Cloud

Datenbanken lassen sich live mit minimaler Downtime von lokalen Systemen nach Azure, AWS oder in neue Rechenzentren verschieben. Die DAG synchronisiert im Hintergrund - beim Cutover erfolgt ein einfacher Failover. Die Applikation bemerkt den Wechsel kaum.

Szenario 2: Versions- und plattformuebergreifende Migration

Da beide AGs vollstaendig unabhaengig sind, kann die Ziel-AG eine neuere SQL-Version oder ein anderes Betriebssystem nutzen. SQL 2016 auf Windows nach SQL 2025 auf Linux - ohne Produktionsausfall.

Technisches Vorgehen - Schritt fuer Schritt

Voraussetzungen

Software

SQL Server Enterprise (ab 2016)
Auf beiden Seiten identisch
Database Mirroring Endpoints

Netzwerk

Port 1433 und 5022 offen
Namensaufloesung funktioniert
FQDN fuer Listener-URL verwenden

Authentifizierung

Service Account auf beiden Seiten
GRANT CONNECT ON ENDPOINT
GRANT CREATE ANY DATABASE

Erste AG (Quelle) erstellen

CREATE AVAILABILITY GROUP [OnPremAG] WITH (AUTOMATED_BACKUP_PREFERENCE = PRIMARY) FOR DATABASE [AdventureWorks] REPLICA ON N'OnPremNode1' WITH (ENDPOINT_URL = N'TCP://OnPremNode1.contoso.com:5022'), N'OnPremNode2' WITH (ENDPOINT_URL = N'TCP://OnPremNode2.contoso.com:5022');

Zweite AG (Ziel) vorbereiten

CREATE AVAILABILITY GROUP [AzureAG] WITH (AUTOMATED_BACKUP_PREFERENCE = SECONDARY) REPLICA ON N'SQLVM1' WITH (ENDPOINT_URL = N'TCP://SQLVM1.contoso.com:5022'), N'SQLVM2' WITH (ENDPOINT_URL = N'TCP://SQLVM2.contoso.com:5022');

Distributed AG erstellen (auf Primary) → sqmSQLTool: New-sqmDistributedAvailabilityGroup

CREATE AVAILABILITY GROUP [DistributedAG] WITH (DISTRIBUTED) AVAILABILITY GROUP ON 'OnPremAG' WITH ( LISTENER_URL = 'TCP://OnPremAGListener.contoso.com:5022', AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL, SEEDING_MODE = AUTOMATIC ), 'AzureAG' WITH ( LISTENER_URL = 'TCP://AzureAGListener.contoso.com:5022', AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL, SEEDING_MODE = AUTOMATIC );

Secondary AG joinen (auf Secondary Cluster)

ALTER AVAILABILITY GROUP [DistributedAG] JOIN AVAILABILITY GROUP ON 'OnPremAG' WITH ( LISTENER_URL = 'TCP://OnPremAGListener.contoso.com:5022', AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL, SEEDING_MODE = AUTOMATIC ), 'AzureAG' WITH ( LISTENER_URL = 'TCP://AzureAGListener.contoso.com:5022', AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL, SEEDING_MODE = AUTOMATIC ); -- AutoSeed auf Secondary AG erlauben: ALTER AVAILABILITY GROUP [AzureAG] GRANT CREATE ANY DATABASE;

Failover & Cutover

Synchronisationsstatus pruefen → sqmSQLTool: Get-sqmDistributedAgHealth

SELECT AGs.name, DB_NAME(database_id) AS DBName, synchronization_state_desc, last_hardened_lsn FROM sys.dm_hadr_database_replica_states replicaStates JOIN sys.availability_groups AGs ON AGs.group_id = replicaStates.group_id WHERE (is_distributed = 1) OR (is_primary_replica = 1)

Vor dem Failover: log_send_queue_size muss 0 sein. Kein offener Rueckstand - sonst droht Datenverlust.

Auf SYNCHRONOUS_COMMIT umstellen vor dem Failover

Die Distributed AG laeuft waehrend des Seedens auf ASYNCHRONOUS_COMMIT - das minimiert die Netzwerklast. Vor dem geplanten Failover muss auf SYNCHRONOUS_COMMIT umgestellt werden um sicherzustellen dass kein Datenverlust entsteht.

-- Auf BLBNBGFAPDBA1 (Primary) - vor dem Failover: ALTER AVAILABILITY GROUP [DAG_AG_OLD_AG_NEW] MODIFY AVAILABILITY GROUP ON 'AG_OLD' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT), 'AG_NEW' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)

Warten bis HEALTHY! Erst wenn synchronization_health_desc = HEALTHY und log_send_queue_size = 0 den Failover starten.

-- Pruefen ob bereit: SELECT ag.name, ar.replica_server_name, ars.role_desc, ars.synchronization_health_desc FROM sys.availability_groups ag JOIN sys.availability_replicas ar ON ar.group_id = ag.group_id JOIN sys.dm_hadr_availability_replica_states ars ON ars.replica_id = ar.replica_id WHERE ag.is_distributed = 1

Nach dem Failover kann auf ASYNCHRONOUS_COMMIT zurueckgestellt werden - falls die alte AG noch als Secondary weiterlaeuft und Netzwerkbandbreite geschont werden soll.

SYNCHRONIZED + IN_RECOVERY - Was bedeutet das?

Wer auf dem Zielnode die Datenbankzustaende prueft, sieht haeufig eine Kombination die auf den ersten Blick widersprüchlich wirkt:

Spalte	Wert	Bedeutung
`synchronization_state_desc`	SYNCHRONIZED	Log ist aufgeholt - kein Rueckstand zum Primary
`database_state_desc`	IN_RECOVERY	Secondary wendet permanent Log-Bloecke an

Das ist vollkommen normal! Ein AlwaysOn Secondary ist immer im Recovering-Modus - er empfaengt und wendet staendig Log-Bloecke an. Das ist kein Fehler, sondern Design. Primary zeigt ONLINE, Secondary zeigt IN_RECOVERY - beide koennen gleichzeitig SYNCHRONIZED sein.

Fazit: Alle Datenbanken SYNCHRONIZED = Failover kann ausgefuehrt werden - unabhaengig davon ob database_state_desc IN_RECOVERY zeigt.

Failover durchfuehren → sqmSQLTool: Test-sqmDistributedAgReadiness + Invoke-sqmDistributedFailover

-- Applikation stoppen, dann: ALTER AVAILABILITY GROUP [DistributedAG] FAILOVER;

Distributed AG aufloesen (nach erfolgreichem Cutover)

DROP AVAILABILITY GROUP [DistributedAG]; -- Die AzureAG bleibt als neue produktive AG bestehen.

Was passiert mit der alten AG?

Nach dem Failover nimmt die alte AG die Rolle Secondary in der Distributed AG ein. Sie laeuft weiter - die Datenbanken sind synchronisiert aber nur lesbar. Das ist kein Fehler, sondern der eingebaute Rollback-Plan.

Ebene	Zustand nach Failover
Distributed AG Rolle	SECONDARY
Lokale AG intern	Primaer-Knoten bleibt Primaer in OnPremAG
Datenbanken	SYNCHRONIZED - nur lesbar
Schreibzugriff	Nicht moeglich

Rollback moeglich: Solange die Distributed AG noch existiert, kann bei Problemen einfach zurueckgefailt werden - nochmal ALTER AVAILABILITY GROUP [DistributedAG] FAILOVER auf dem alten Primary.

Erst nach stabiler Produktionsphase: Aufraumen

-- Schritt 1: Distributed AG aufloesen DROP AVAILABILITY GROUP [DistributedAG]; -- Schritt 2: Alte AG dekommissionieren (erst nach Verifikation!) DROP AVAILABILITY GROUP [OnPremAG];

Nicht sofort abschalten! Die alte AG ist der Fallback. Erst nach einer stabilen Produktionsphase (empfohlen: mindestens 24-48 Stunden) dekommissionieren.

Herausforderungen & Stolpersteine

Problem	Details & Loesung
Keine GUI	Distributed AGs lassen sich nicht ueber den SSMS-Assistenten erstellen. Rein T-SQL - oder sqmSQLTool verwenden.
FQDN Pflicht	LISTENER_URL muss den vollstaendigen DNS-Namen enthalten (TCP://server.domain.local:5022). Kurzname schlaegt fehl.
Service Account	Der Service Account des Quellservers muss auf dem Zielserver als Login existieren und GRANT CONNECT ON ENDPOINT haben.
Netzwerk & Firewall	Port 5022 zwischen beiden Clustern muss offen sein. Keine Deep-Inspection, kein Bandwidth-Throttling.
Systemdatenbanken	Logins, SQL Agent Jobs und Linked Server migrieren nicht automatisch. dbatools hilft: Copy-DbaLogin, Copy-DbaAgentJob.

Ausblick SQL Server 2025

Mit SQL Server 2025 wird die interne Synchronisation der Distributed AG weiter optimiert:

Netzwerk-Effizienz

Weniger Bandbreitenverbrauch bei der Replikation ueber lange Distanzen durch verbesserte Komprimierung.

Cloud-Performance

Bessere Performance in Cloud- und Multi-Datacenter-Szenarien durch optimierte Latenz-Kompensation.

Abwaertskompatibel

Vollstaendige Kompatibilitaet zu bestehenden Distributed AGs - kein Rebuild erforderlich.

Listener-Migration - Der kritischste Schritt

Nach dem Distributed AG Failover laufen alle Schreibzugriffe auf dem neuen Cluster. Clients verbinden sich aber noch ueber den alten Listener. Der Listener muss zum neuen Cluster wandern - und dabei lauern die groessten Fallstricke.

Die zwei Listener - und warum es beide gibt

Listener_PROD (der alte)

Liegt auf dem alten Cluster
Der DNS-Name den alle Applikationen kennen
Verbindungsstring in jeder Config-Datei
Darf sich nie aendern - sonst muessen alle Apps angepasst werden
Ziel: zum neuen Cluster wandern

Listener_TEMP (der neue)

Liegt auf dem neuen Cluster
Wurde beim Aufbau der neuen AG benoetigt
Die Distributed AG braucht eine LISTENER_URL auf beiden Seiten
Nur intern verwendet - keine Applikation kennt ihn
Wird nach Migration geloescht

Warum braucht die Distributed AG ueberhaupt einen Listener_TEMP?
Die Distributed AG kommuniziert zwischen den Clustern ausschliesslich ueber Listener-URLs. Beim Erstellen der Distributed AG muss fuer beide AGs eine LISTENER_URL angegeben werden. Da Listener_PROD noch auf dem alten Cluster liegt, braucht die neue AG einen eigenen temporaeren Listener - nur fuer den Aufbau der Distributed AG Verbindung.

Ausgangslage

Alter Cluster: AG_OLD <--- Listener_PROD (Applikationen verbinden sich hier) (wird von Distributed AG als LISTENER_URL verwendet) Neuer Cluster: AG_NEW <--- Listener_TEMP (nur intern, kein App-Zugriff) (wird von Distributed AG als LISTENER_URL verwendet) Ziel nach Migration: Neuer Cluster: AG_NEW <--- Listener_PROD (Applikationen folgen dem Namen automatisch) <--- Listener_TEMP (loeschen nach Validierung)

KRITISCHER FEHLER aus der Praxis: Wenn das AD-Team die Cluster-Ressource loescht bevor der Listener aus der SQL AG entfernt wurde, gehen ALLE Datenbanken sofort in den RECOVERY MODE. Die SQL AG verliert ihre Listener-Ressource und reagiert mit einem Notfall-Shutdown der Datenbanken.

Die richtige Reihenfolge

Distributed AG Failover - auf SQLNODE1 (alter Primary)

ALTER AVAILABILITY GROUP [DAG_AG_OLD_AG_NEW] FAILOVER

Ab jetzt ist AG_NEW der neue Primary. Clients verbinden aber noch ueber Listener_PROD auf den alten Cluster!

DU ZUERST: Listener aus ALTER AG entfernen - auf SQLNODE1

-- BEVOR das AD-Team irgendwas anfasst! ALTER AVAILABILITY GROUP [AG_OLD] REMOVE LISTENER N'Listener_PROD'

Erst wenn dieser Befehl erfolgreich ist: AD-Team informieren und gruenes Licht geben!

AD-Team: Cluster-Ressource tauschen

Alter Cluster: Listener_PROD Ressource loeschen Neuer Cluster: Listener_PROD Ressource neu anlegen - Gleicher Name: Listener_PROD - IP-Adresse: 10.0.1.50 - Ressource online bringen - SPNs aktualisieren!

Listener zur neuen AG hinzufuegen - auf SQLNODE3 (neuer Primary)

Das AD-Team hat die Cluster-Ressource bereits angelegt - daher OHNE IP-Angabe. SQL Server findet die vorhandene Cluster-Ressource automatisch.

-- RICHTIG: Cluster-Ressource existiert bereits - nur Port angeben! ALTER AVAILABILITY GROUP [AG_NEW] ADD LISTENER N'Listener_PROD' (PORT = 1433) -- FALSCH: IP angeben wenn Ressource schon existiert = Konflikt-Fehler! -- ALTER AVAILABILITY GROUP [AG_NEW] -- ADD LISTENER N'Listener_PROD' (WITH IP ((N'10.0.1.50', N'255.255.255.0')), PORT = 1433)

Pruefe vorher: Ist die Cluster-Ressource online? Get-ClusterResource | Where-Object Name -eq 'Listener_PROD'

Validierung - auf SQLNODE3

-- Alle Datenbanken ONLINE? SELECT name, state_desc FROM sys.databases WHERE database_id > 4 -- Listener vorhanden? SELECT dns_name, port FROM sys.availability_group_listeners -- Verbindung testen: sqlcmd -S Listener_PROD -Q "SELECT @@SERVERNAME, @@VERSION"

DNS-Cache auf Clients leeren

ipconfig /flushdns

DNS-TTL vorab auf 300 Sekunden reduzieren - dann propagiert die neue IP schneller.

Mit sqmSQLTool automatisiert

# Schritt 2: Listener aus alter AG entfernen (BEVOR AD-Team!) Prepare-sqmListenerForMigration ` -SqlInstance "SQLNODE1" ` -AvailabilityGroupName "AG_OLD" ` -ListenerName "Listener_PROD" # --> Erst jetzt AD-Team gruenes Licht geben! # Schritt 4: Listener in neue AG eintragen Complete-sqmListenerMigration ` -SqlInstance "SQLNODE3" ` -TargetAgName "AG_NEW" ` -ListenerName "Listener_PROD"

Uebersicht: Wer macht was wo

Schritt	Wer	Wo
Distributed AG Failover	DBA	SQLNODE1 (alter Primary)
REMOVE LISTENER	DBA zuerst!	SQLNODE1 (alte AG)
Cluster-Ressource tauschen + SPNs	AD-Team	Beide Cluster
ADD LISTENER	DBA	SQLNODE3 (neue AG)
Validierung + DNS flush	DBA + App-Team	SQLNODE3 + Clients

Listener_TEMP nicht sofort loeschen! Erst nach erfolgreicher Validierung und stabiler Produktionsphase entfernen. Er ist der Fallback falls etwas schiefgeht.

Fallback-Szenarien

Die Distributed AG ist so konzipiert, dass ein Rueckweg immer moeglich ist - solange die richtige Reihenfolge eingehalten und nichts voreilig geloescht wird.

Szenario 1: Probleme nach Distributed AG Failover

Der Failover wurde ausgefuehrt, aber auf dem neuen System gibt es Probleme. Die alte AG laeuft noch als Secondary - Rueckfall ist einfach:

-- Auf SQLNODE3 (neuer Primary) - Rueckfall zum alten System: ALTER AVAILABILITY GROUP [DAG_AG_OLD_AG_NEW] FAILOVER -- AG_OLD ist wieder Primary, Clients verbinden wieder ueber Listener_PROD -- (Listener_PROD ist zu diesem Zeitpunkt noch auf dem alten Cluster)

Voraussetzung: Die Distributed AG muss noch existieren. Nicht vorher DROP AVAILABILITY GROUP ausfuehren!

Szenario 2: Probleme nach Listener-Migration

Listener_PROD wurde bereits auf den neuen Cluster verschoben, aber Clients koennen nicht verbinden oder Datenbanken sind nicht erreichbar:

-- Schritt 1: Listener aus neuer AG entfernen ALTER AVAILABILITY GROUP [AG_NEW] REMOVE LISTENER N'Listener_PROD' -- Schritt 2: AD-Team - Listener_PROD Cluster-Ressource zurueck auf alten Cluster -- Schritt 3: Listener zurueck in alte AG eintragen ALTER AVAILABILITY GROUP [AG_OLD] ADD LISTENER N'Listener_PROD' (PORT = 1433) -- Schritt 4: Distributed AG Failover zurueck auf altes System ALTER AVAILABILITY GROUP [DAG_AG_OLD_AG_NEW] FAILOVER

Listener_TEMP hilft hier: Waehrend Listener_PROD zurueckgewechselt wird, ist der neue Cluster weiterhin ueber Listener_TEMP erreichbar - fuer interne Diagnose und Monitoring.

Szenario 3: Datenbanken in RECOVERY MODE nach Listener-Wechsel

Klassischer Fehler: Das AD-Team hat die Cluster-Ressource geloescht bevor der Listener aus der SQL AG entfernt wurde. Alle Datenbanken sind in RECOVERY MODE.

-- Diagnose: Welche DBs sind betroffen? SELECT name, state_desc FROM sys.databases WHERE state_desc != 'ONLINE' AND database_id > 4 -- Loesung: AG Listener neu eintragen (wenn Cluster-Ressource schon neu angelegt) ALTER AVAILABILITY GROUP [AG_NEW] ADD LISTENER N'Listener_PROD' (PORT = 1433) -- Wenn Cluster-Ressource noch nicht neu angelegt: AD-Team zuerst! -- Danach kommen Datenbanken automatisch zurueck ONLINE

Sobald der Listener wieder korrekt in der SQL AG registriert ist, kommen alle Datenbanken automatisch aus dem RECOVERY MODE zurueck - kein manuelles Eingreifen noetig.

Was wann geloescht werden darf

Objekt	Loeschen erst wenn...
Distributed AG	Neue AG laeuft stabil, alle Tests bestanden, Produktionsphase > 24h
AG_OLD (alte AG)	Distributed AG bereits geloescht, keine Abhaengigkeiten mehr
Listener_TEMP	Listener_PROD auf neuer AG aktiv und getestet, keine App verwendet Listener_TEMP
Alte Server	Alles oben erledigt + Backups vorhanden + Change-Freigabe

sqmSQLTool - Automatisierung der Distributed AG

Alle beschriebenen Schritte lassen sich mit sqmSQLTool automatisieren. Die Funktionen uebernehmen FQDN-Konfiguration, Service Account Grants, AutoSeed-Berechtigungen und Validierung - und ersetzen die manuellen T-SQL-Bloecke aus diesem Artikel.

Schritt	sqmSQLTool Funktion	Beschreibung
Distributed AG aufbauen	`New-sqmDistributedAvailabilityGroup`	Erstellt die Distributed AG auf Primary und Secondary inkl. FQDN, Service Account Login, GRANT CONNECT und GRANT CREATE ANY DATABASE.
Datenbank hinzufuegen	`Add-sqmDatabaseToDistributedAg`	Fuegt eine einzelne Datenbank zur Distributed AG hinzu und startet AutoSeed.
Synchronisation ueberwachen	`Get-sqmDistributedAgHealth`	Health-Report fuer alle Distributed AGs: Sync-Status, LSN-Lag, Replica-Zustand, Datenbankstatus. Output als TXT und CSV.
Failover-Bereitschaft pruefen	`Test-sqmDistributedAgReadiness`	Prueft alle Voraussetzungen vor dem Failover. Gibt Readiness-Score 0-100 zurueck. Empfehlung: erst ab Score > 90 failovern.
Failover durchfuehren	`Invoke-sqmDistributedFailover`	Kontrollierter Failover mit Sicherheitspruefungen. Benoetigt explizites -Force oder ShouldProcess-Bestaetigung.
Listener vorbereiten	`Prepare-sqmListenerForMigration`	Entfernt SQL AG-Abhaengigkeit vom Listener BEVOR das Cluster-Team die Ressource loescht. Verhindert RECOVERY MODE auf allen Datenbanken.
Listener abschliessen	`Complete-sqmListenerMigration`	Re-registriert den Listener nach Cluster-Neuanlage. Validiert dass alle Datenbanken ONLINE zurueckkehren.
Konfiguration exportieren	`Export-sqmAlwaysOnConfiguration`	Exportiert die vollstaendige AG-Konfiguration als Dokumentation vor und nach der Migration.

Beispiel: Kompletter Aufbau mit sqmSQLTool

# 1. Distributed AG erstellen New-sqmDistributedAvailabilityGroup ` -PrimaryInstance "OnPremNode1" ` -PrimaryAgName "OnPremAG" ` -PrimaryFqdn "OnPremNode1.contoso.com" ` -SecondaryInstance "SQLVM1" ` -SecondaryAgName "AzureAG" ` -SecondaryFqdn "SQLVM1.contoso.com" ` -ServiceAccount "CONTOSO\SqlServiceAccount" ` -SeedingMode Automatic # 2. Synchronisation ueberwachen Get-sqmDistributedAgHealth -SqlInstance "OnPremNode1" # 3. Readiness pruefen vor Failover Test-sqmDistributedAgReadiness -SqlInstance "OnPremNode1" -TargetInstance "SQLVM1" # 4. Failover ausfuehren Invoke-sqmDistributedFailover ` -SqlInstance "SQLVM1" ` -AvailabilityGroupName "DistributedAG" ` -Force

sqmSQLTool auf GitHub: Alle Funktionen sind Open Source und koennen direkt fuer eigene Migrationen verwendet werden.
https://github.com/JankeUwe/sqmSQLTool

Empfehlung fuer den Einsatz

Skriptvorlagen verwenden, Failover gruendlich in einer Staging-Umgebung testen. sqmSQLTool automatisiert den kompletten Aufbau inklusive FQDN-Konfiguration, Service Account Grants und AutoSeed-Berechtigungen.

sqmSQLTool auf GitHub