Was ist eine eingeschlossene Verfügbarkeitsgruppe?

Gilt für: SQL Server 2022 (16.x)

Eine eigenständige Verfügbarkeitsgruppe ist eine Always On-Verfügbarkeitsgruppe (AG), die Folgendes unterstützt:

• Verwalten von Metadatenobjekten (Benutzer, Anmeldungen, Berechtigungen, SQL-Agent-Aufträge usw.) auf AG-Ebene zusätzlich zur Instanzebene.

• spezialisierte Systemdatenbanken innerhalb der AG.

In diesem Artikel werden die Ähnlichkeiten, Unterschiede und Funktionen von eigenständigen AGs beschrieben.

Übersicht

AGs bestehen in der Regel aus einer oder mehreren Benutzerdatenbanken, die als koordinierte Gruppe funktionieren sollen und in einigen Knoten in einem Cluster repliziert werden. Wenn es einen Fehler im Knoten oder bei der Integrität von SQL Server auf dem Knoten gibt, der die primäre Kopie hostet, wird die Datenbankgruppe als Einheit auf einen anderen Replikatknoten in der AG verschoben. Alle Benutzerdatenbanken werden in allen Replikaten der AG synchronisiert, entweder im synchronen oder asynchronen Modus.

Dies funktioniert gut für Anwendungen, die nur mit dieser Gruppe von Benutzerdatenbanken interagieren. Schwierig kann es werden, wenn Anwendungen auch Objekte wie Benutzer, Anmeldungen, Berechtigungen, Agent-Aufträge usw. benötigen, die in einer der Systemdatenbanken gespeichert sind (master oder msdb). Damit die Anwendungen reibungslos und vorhersagbar funktionieren, muss der Administrator manuell sicherstellen, dass alle Änderungen an diesen Objekten in allen Replikatinstanzen in der AG dupliziert werden. Wenn eine neue Instanz in die AG eingefügt wird, kann für die Datenbanken in einem einfachen Prozess automatisch oder manuell ein Seed ausgeführt werden. Dann müssen aber alle Anpassungen an den Systemdatenbanken auf der neuen Instanz neu konfiguriert werden, um den anderen Replikaten zu entsprechen.

Eingeschlossene AGs erweitern das Konzept der Datenbankgruppenreplikation, indem relevante Teile der Datenbanken master und msdb einbezogen werden. Stellen Sie sich sie als Ausführungskontext für Anwendungen vor, die die eigenständige AG verwenden. Der Gedanke dahinter: Die Umgebung einer eigenständigen Verfügbarkeitsgruppe enthält Einstellungen, die sich auf die Anwendungen auswirken, die die Verfügbarkeitsgruppe nutzt. Daher betrifft diese Umgebung alle Datenbanken, mit denen die Anwendung interagiert, die von der Anwendung verwendete Authentifizierung (Anmeldungen, Benutzer, Berechtigungen), alle geplanten Aufträge, die sie ausführen soll, sowie andere Konfigurationseinstellungen, die sich auf die Anwendung auswirken.

Dies ist ein Unterschied zu eigenständigen Datenbanken, die einen anderen Mechanismus für die Benutzerkonten verwenden und die Benutzerinformationen in der Datenbank selbst speichern. Eigenständige Datenbanken replizieren nur Anmeldeinformationen und Benutzer, und der Geltungsbereich einer replizierten Anmeldung oder eines replizierten Benutzers ist auf diese einzelne Datenbank (und ihre Replikate) beschränkt.

Im Gegensatz dazu können Sie in einer enthaltenen Verfügbarkeitsgruppe Benutzer, Anmeldungen und Berechtigungen auf Verfügbarkeitsgruppenebene erstellen, und diese sind automatisch in allen Replikaten in der Verfügbarkeitsgruppe sowie in allen Datenbanken innerhalb dieser enthaltenen Verfügbarkeitsgruppe konsistent. Dies erspart Administratoren die manuelle Eingabe all dieser Änderungen.

SQL Server 2025-Änderungen

In der Vorschau von SQL Server 2025 (17.x) wird die Unterstützung für verteilte Verfügbarkeitsgruppen für enthaltene Verfügbarkeitsgruppen eingeführt.

Unterschiede

Es gibt einige praktische Unterschiede, die beim Arbeiten mit eigenständigen Verfügbarkeitsgruppen zu berücksichtigen sind: Beispielsweise werden eigenständige Systemdatenbanken erstellt, und Verbindungen werden auf der Ebene der eigenständigen Verfügbarkeitsgruppe erzwungen, nicht auf Instanzebene hergestellt.

Enthaltene Systemdatenbanken

Jede enthaltene AG verfügt über eigene master- und msdb-Systemdatenbanken, die nach dem Namen der Verfügbarkeitsgruppe benannt sind. In der enthaltenen AG MyContainedAG gibt es beispielsweise Datenbanken mit den Namen MyContainedAG_master und MyContainedAG_msdb. Diese Systemdatenbanken werden automatisch auf neue Replikate ge-seeded, und Updates werden, genauso wie bei allen anderen Datenbanken in einer Verfügbarkeitsgruppe, auf diese Datenbanken repliziert. Dies bedeutet, dass beim Hinzufügen eines Objekts wie einer Anmeldung oder eines Agentenauftrags bei der Verbindung mit der eigenständigen AG, wenn die eigenständige AG nicht zu einer anderen Instanz führt, die Verbindung mit der eigenständigen AG herstellt, weiterhin die Agentenaufträge angezeigt werden und sich mit dem in der eigenständigen AG erstellten Login authentifizieren können.

Wichtig

Eigenständige AGs sind ein Mechanismus, durch den die Konfigurationen der Ausführungsumgebung in den Replikaten einer Verfügbarkeitsgruppe konsistent bleiben. Sie stellen keine Sicherheitsgrenze dar. Es gibt keine Grenze, die eine Verbindung zu einer eigenständigen AG beim Zugriff auf Datenbanken außerhalb der AG einhält, zum Beispiel.

Die Systemdatenbanken in einer neu erstellten eigenständigen AG sind keine Kopien aus der Instanz, in der der CREATE AVAILABILITY GROUP Befehl ausgeführt wird. Sie sind zunächst leere Vorlagen ohne Daten. Unmittelbar nach der Erstellung werden die Administratorkonten der Instanz, die die eigenständige Verfügbarkeitsgruppe erstellt, in die eigenständige AG master kopiert. Auf diese Weise kann sich der Administrator bei der eigenständigen AG anmelden und die restliche Konfiguration einrichten.

Wenn Sie lokale Benutzer oder Konfigurationen in Ihrer Instanz erstellen, werden sie nicht automatisch angezeigt, wenn Sie Ihre eigenständigen Systemdatenbanken erstellen, und sie sind nicht sichtbar, wenn Sie eine Verbindung mit der eigenständigen AG herstellen. Sobald die Benutzerdatenbank einer eigenständigen AG zugeordnet wurde, wird sie für die Benutzerinnen und Benutzer sofort unzugänglich. Sie müssen sie manuell in den eigenständigen Systemdatenbanken im Kontext der eigenständigen en AG neu erstellen, indem Sie eine direkte Verbindung mit der Datenbank oder mithilfe des Listener-Endpunkts herstellen. Die Ausnahme hierbei ist, dass alle Anmeldungen in der SysAdmin-Rolle in der übergeordneten Instanz während der Erstellung der eigenständigen AG in die neue AG-spezifische master Datenbank kopiert werden.

Anmerkung

Da die master-Datenbank für jede eigenständige Verfügbarkeitsgruppe separat ist, werden Serverbereichsaktivitäten, die im Kontext der eigenständigen en VG ausgeführt werden, nur in der eigenständigen en Systemdatenbank gespeichert. Dazu gehört die Überwachung. Wenn Sie Aktivitäten auf Serverebene mit der SQL Server-Überwachung überwachen, müssen Sie dieselben Serverüberwachungen in jeder enthaltenen AG erstellen.

Anfängliche Datensynchronisierung

Die enthaltenen Systemdatenbanken unterstützen nur automatisches Seeding als erste Methode zur Datensynchronisierung.

In SQL Server 2022 (16.x) und früheren Versionen müssen Verfügbarkeitsgruppen während der Erstellung automatisch Seeding ausführen. Wenn Sie die CREATE AVAILABILITY GROUP Anweisung oder den Assistenten für neue Verfügbarkeitsgruppen in SQL Server Management Studio verwenden, schließen Sie nur Benutzerdatenbanken ein, die das automatische Seeding unterstützen. Um große Datenbanken mithilfe von manuellem Seeding (JOIN ONLY) hinzuzufügen, warten Sie, bis die eigenständige AG erstellt ist.

In SQL Server 2025 (17.x) Preview verwenden enthaltene Systemdatenbanken immer automatische Seeding, auch wenn die CREATE AVAILABILITY GROUP Anweisung manuelle Seeding angibt. Sie können den Seedingmodus auf manuell einstellen, um eine geschlossene AG zu erstellen, und später Benutzerdatenbanken mithilfe anderer Synchronisierungsmethoden außer automatischem Seeding hinzufügen.

Eine eigenständige Systemdatenbank wiederherstellen

Führen Sie die folgenden Schritte aus, um Sicherungen von enthaltenen Systemdatenbanken wiederherzustellen:

1. Legen Sie die eigenständige AG ab.

2. Stellen Sie die eigenständigen master und msdb Datenbanken auf dem ursprünglichen primären Replikat der eigenständigen AG wieder her.

3. Entfernen Sie die enthaltene master und msdb Datenbank aus den sekundären Replikaten.

4. Erstellen Sie die enthaltene AG auf dem primären Replikat neu, indem Sie den ursprünglichen Namen und die Knoten mit der Syntax WITH (CONTAINED, REUSE_SYSTEM_DATABASES) und SEEDING_MODE = AUTOMATIC verwenden.

Wenn Sie eine enthaltene Verfügbarkeitsgruppe neu erstellen, schließen Sie keine enthaltenen Systemdatenbanken in die CREATE AVAILABILITY GROUP Anweisung ein. SQL Server erkennt sie automatisch, wenn REUSE_SYSTEM_DATABASES angegeben ist. In SQL Server 2022 (16.x) und früheren Versionen sind nur kleine Benutzerdatenbanken enthalten, die das automatische Seeding unterstützen. Fügen Sie große Datenbanken separat hinzu, nachdem die eigenständige AG erstellt wurde, unter Verwendung von „JOIN ONLY“.

Eigenständige Verfügbarkeitsgruppenaufträge

Aufträge, die zu einer eingeschlossenen Verfügbarkeitsgruppe gehören, werden nur auf dem primären Replikat ausgeführt. Sie werden nicht auf sekundären Replikaten ausgeführt.

Verbindung herstellen (eingeschlossene Umgebung)

Es ist wichtig, den Unterschied zwischen der Verbindung mit der Instanz und dem Herstellen einer Verbindung mit der eigenständigen AG zu unterscheiden. Die einzige Möglichkeit für den Zugriff auf die Umgebung der eigenständigen Verfügbarkeitsgruppe besteht darin, eine Verbindung mit dem Listener der eigenständigen Verfügbarkeitsgruppe herzustellen oder eine Verbindung mit einer Datenbank herzustellen, die sich in der eigenständigen Verfügbarkeitsgruppe befindet.

"Persist Security Info=False;
User ID=MyUser;Password=*****;
Initial Catalog=MyContainedDatabase;
Server=MyServer;"

Wo MyContainedDatabase befindet sich eine Datenbank innerhalb der eigenständigen AG, mit der Sie interagieren möchten.

Dies bedeutet, dass Sie einen Listener für die eigenständige AG erstellen müssen, um eine eigenständige AG effektiv zu nutzen. Wenn Sie eine Verbindung mit einer der Instanzen herstellen, die die eigenständige Verfügbarkeitsgruppe hosten, anstatt eine direkte Verbindung mit der eigenständigen Verfügbarkeitsgruppe über den Listener herzustellen, befinden Sie sich in der Umgebung der Instanz, nicht in der eigenständigen Verfügbarkeitsgruppe.

Ein Beispiel: Wenn Ihre Verfügbarkeitsgruppe MyContainedAG auf dem Server SERVER\MSSQLSERVERgehostet wird und Sie keine Verbindung mit dem Listener MyContainedAG_Listener, sondern mithilfe von SERVER\MSSQLSERVER eine Verbindung mit der Instanz herstellen, befinden Sie sich in der Umgebung der Instanz und nicht in der Umgebung von MyContainedAG. Dies bedeutet, dass Sie nur die Inhalte (Benutzer, Berechtigungen, Aufträge usw.) sehen, die in den Systemdatenbanken der Instanz enthalten sind. Um auf die Inhalte in den eigenständigen Systemdatenbanken der eigenständigen AG zuzugreifen, stellen Sie stattdessen eine Verbindung mit dem eigenständigen AG-Listener (MyContainedAG_Listenerz. B.) her. Wenn Sie über den eigenständigen AG-Listener mit der Instanz verbunden sind, werden Sie mastertatsächlich an die eigenständige master Datenbank umgeleitet (zum Beispiel MyContainedAG_master).

Schreibgeschütztes Routing und eigenständige Verfügbarkeitsgruppen

Wenn Sie das schreibgeschützte Routing so konfigurieren, dass Verbindungen mit Leseabsicht zu einem sekundären Replikat umgeleitet werden (siehe Konfigurieren des schreibgeschützten Routings für eine AlwaysOn-Verfügbarkeitsgruppe) und Sie eine Verbindung mit einer Anmeldung herstellen möchten, die nur in der eigenständigen AG erstellt wird, gibt es einige zusätzliche Überlegungen:

• Sie müssen eine Datenbank angeben, die Teil der eigenständigen AG in der Verbindungszeichenfolge ist
• Der in der Verbindungszeichenfolge angegebene Benutzer muss über die Berechtigung zum Zugriff auf die Datenbanken in der eigenständigen AG verfügen.

Beispiel: In der folgenden Verbindungszeichenfolge ist AdventureWorks eine Datenbank in der eigenständigen Verfügbarkeitsgruppe mit MyContainedListener, und MyUser ist ein Benutzer, der in der eigenständigen Verfügbarkeitsgruppe definiert ist, aber in keiner der teilnehmenden Instanzen.

"Persist Security Info=False;
User ID=MyUser;Password=*****;
Initial Catalog=AdventureWorks;
Server=MyContainedListener;
ApplicationIntent=ReadOnly"

Diese Verbindungszeichenfolge würde Sie mit der lesbaren sekundären Komponente verbinden, die Teil der ReadOnly Routing-Konfiguration ist, und Sie befinden sich im Kontext der eigenständigen AG.

Unterschiede zwischen der Verbindung mit der Instanz und der Verbindung mit der enthaltenen Verfügbarkeitsgruppe

• Wenn eine Verbindung mit einer eigenständigen AG hergestellt wird, sehen Die Nutzer nur Datenbanken in der eigenständigen AG plus tempdb.
• Auf Instanzebene lauten die eigenständigen Verfügbarkeitsgruppe master und msdb Namen sind [contained AG]_master und [contained AG]_msdb. Innerhalb der eingeschlossenen AG lauten die Namen master und msdb.
• Die Datenbank-ID für die eigenständige Verfügbarkeitsgruppe master ist 1 von innerhalb der eigenständigen Verfügbarkeitsgruppe, aber etwas anderes, wenn sie mit der Instanz verbunden ist.
• Während Benutzer Datenbanken außerhalb der eigenständigen AG sys.databases nicht sehen, wenn sie in einer eigenständigen en AG-Verbindung verbunden sind, können sie auf diese Datenbanken mit dreiteiligem Namen oder über den USE Befehl zugreifen.
• Die Serverkonfiguration sp_configure kann über die eigenständige AG-Verbindung gelesen werden, kann aber nur von Instanzebene geschrieben werden.
• Über Verbindungen mit eigenständigen AGs können Systemadministratoren Vorgänge auf Instanzebene ausführen, z. B. Herunterfahren von SQL Server.
• Die meisten Vorgänge auf Datenbankebene, Endpunktebene oder AG-Ebene können nur von Instanzenverbindungen ausgeführt werden, nicht eigenständigen AG-Verbindungen.

Interaktionen mit anderen Features

Es gibt zusätzliche Überlegungen bei der Verwendung bestimmter Features mit eigenständigen AGs, und es gibt einige Features, die derzeit nicht unterstützt werden.

Sichern

Verfahren zum Sichern von Datenbanken in einer umschlossenen AG sind dieselben wie bei allen Sicherungsprozeduren für Benutzerdatenbanken. Dies gilt sowohl für die enthaltenen AG-Nutzerdatenbanken als auch für die darin enthaltenen AG-Systemdatenbanken.

Wenn der Sicherungsspeicherort lokal ist, werden die Sicherungsdateien auf dem Server platziert, auf dem der Sicherungsauftrag ausgeführt wird. Dies bedeutet, dass Sich Ihre Sicherungsdateien an verschiedenen Speicherorten befinden.

Wenn sich der Sicherungsspeicherort in einer Netzwerkressource befindet, benötigen alle Server, die Replikate hosten, Zugriff auf diese Ressource.

Verteilte Verfügbarkeitsgruppen

Eine verteilte Verfügbarkeitsgruppe ist eine spezielle Art von Verfügbarkeitsgruppe, die sich über zwei zugrunde liegende Verfügbarkeitsgruppen erstreckt. Wenn Sie eine verteilte Verfügbarkeitsgruppe konfigurieren, werden Änderungen, die am globalen primären Replikat (dem primären Replikat Ihrer ersten AG) vorgenommen wurden, dann in das primäre Replikat Ihrer zweiten AG repliziert, die als Forwarder bezeichnet wird.

Ab SQL Server 2025 (17.x) Preview können Sie eine verteilte Verfügbarkeitsgruppe zwischen zwei enthaltenen AGs konfigurieren. Da eine eigenständige Verfügbarkeitsgruppe auf eigenständige master und msdb Systemdatenbanken angewiesen ist, muss die zweite Verfügbarkeitsgruppe (Weiterleitung) dieselbe eigenständige Verfügbarkeitsgruppen-Systemdatenbank wie die globale primäre haben, um eine verteilte Verfügbarkeitsgruppe zu erstellen.

Wenn Sie beabsichtigen, eine eigenständige AG als Weiterleitung in einer verteilten Verfügbarkeitsgruppe zu nutzen, müssen Sie die eigenständige AG mithilfe der AUTOSEEDING_SYSTEM_DATABASES-Klausel für die WITH | CONTAINED-Option der CREATE AVAILABILITY GROUP-Anweisung erstellen. Die AUTOSEEDING_SYSTEM_DATABASES-Klausel weist SQL Server an, das Erstellen seiner eigenen eigenständigen AG-Systemdatenbanken zu überspringen und stattdessen das Seeding der eigenständigen AG-Systemdatenbanken von der globalen primären Datenbank auszuführen.

Ressourcengouverneur

In SQL Server 2022 (16.x) vor dem kumulativen Update 18 und in älteren Versionen von SQL Server wird das Konfigurieren oder Verwenden der Ressourcenkontrolle für enthaltene Verfügbarkeitsgruppenverbindungen nicht unterstützt.

Beginnend mit SQL Server 2022 (16.x) kumulativem Update 18 wird die Ressourcenkontrolle für eine Instanzverbindung konfiguriert, wird der Ressourcenverbrauch für Instanzenverbindungen oder eigenständige Verfügbarkeitsgruppenverbindungen erwartungsgemäß gesteuert. Wenn Sie versuchen, die Ressourcenkontrolle für eine enthaltene Verfügbarkeitsgruppenverbindung zu konfigurieren, wird eine Fehlermeldung angezeigt.

Ressourcenkontrolle funktioniert auf Instanzebene des Datenbankmoduls. Die Konfiguration der Ressourcenkontrolle auf Instanzebene wird nicht an Verfügbarkeitsreplikate weitergegeben. Sie müssen die Ressourcenkontrolle für jede Instanz konfigurieren, die ein Verfügbarkeitsreplikat hosten.

Tipp

Es wird empfohlen, die gleiche Ressourcenkontrolle-Konfiguration für alle Datenbankmodulinstanzen zu verwenden, die Verfügbarkeitsreplikate hosten, um ein konsistentes Verhalten zu gewährleisten, wenn Verfügbarkeitsgruppenfailover auftreten.

Weitere Informationen finden Sie unter Konfigurationsbeispiele für Ressourcengouverneur und Ressourcengouverneur und bewährte Methoden.

Erfassung geänderter Daten

Change Data Capture (CDC) wird als SQL-Agent-Aufträge implementiert, sodass der SQL-Agent auf allen Instanzen mit Replikaten in der eigenständigen AG ausgeführt werden muss.

Wenn Sie die Änderungsdatenerfassung mit einer eigenständigen AG verwenden möchten, stellen Sie beim Konfigurieren von CDC eine Verbindung mit dem AG-Listener her, damit die CDC-Metadaten mithilfe der eigenständigen Systemdatenbanken konfiguriert werden.

Protokollversand

Der Protokollversand kann konfiguriert werden, wenn sich die Quelldatenbank in der eigenständigen AG befindet. Ein Protokollversandziel wird jedoch nicht innerhalb einer eigenständigen AG unterstützt. Darüber hinaus muss ein zusätzlicher Schritt ausgeführt werden, um den Protokollversandauftrag zu ändern, nachdem CDC konfiguriert wurde.

Führen Sie die folgenden Schritte aus, um den Protokollversand mit einer eigenständigen AG zu konfigurieren:

1. Stellen Sie eine Verbindung mit dem eigenständigen AG-Listener her.
2. Konfigurieren Sie den Protokollversand wie sonst auch.
3. Ändern Sie nach der Konfiguration des Protokollversandauftrags den Auftrag, um eine Verbindung mit dem eigenständigen AG-Listener herzustellen, bevor Sie eine Sicherung erstellen.

Transparent Data Encryption (TDE)

Um Transparent Data Encryption (TDE) mit Datenbanken in einer eigenständigen Verfügbarkeitsgruppe zu verwenden, installieren Sie den Datenbankhauptschlüssel (Database Master Key, DMK) manuell in der eigenständigen master-Datenbank innerhalb der eigenständigen Verfügbarkeitsgruppe.

Datenbanken, die TDE verwenden, benötigen Zertifikate in der master-Datenbank, um den Datenbankverschlüsselungsschlüssel (Database Encryption Key, DEK) zu entschlüsseln. Ohne dieses Zertifikat kann SQL Server mit TDE verschlüsselte Datenbanken nicht entschlüsseln oder online schalten. In einer eigenständigen AG prüft SQL Server beide master Datenbanken für das DMK, die master Datenbank für die Instanz und die eigenständige master Datenbank innerhalb der eigenständigen AG, um die Datenbank zu entschlüsseln. Wenn das Zertifikat an keinem Speicherort gefunden wird, kann SQL Server die Datenbank nicht online schalten.

Informationen zum Übertragen des DMK aus der master-Datenbank der Instanz in die eigenständige master-Datenbank finden Sie im Artikel Verschieben einer TDE-geschützten Datenbank zu einer anderen SQL Server, in dem es hauptsächlich um die Phasen geht, in denen der DMK von einem alten auf einen neuen Server übertragen wird.

Anmerkung

Durch Verschlüsseln einer Datenbank in einer SQL Server-Instanz wird auch die tempdb Systemdatenbank verschlüsselt.

SSIS-Pakete und Wartungspläne

Die Verwendung von SSIS-Paketen, einschließlich Wartungsplänen, wird für eigenständige Verfügbarkeitsgruppen nicht unterstützt.

Nicht unterstützt

Derzeit werden die folgenden SQL Server-Features nicht mit einer eigenständigen AG unterstützt:

• SQL Server-Replikationen jeder Art (Transaktion, Merge, Momentaufnahme usw.).
• Protokollversand, in dem sich die Zieldatenbank in der eigenständigen AG befindet. Der Protokollversand mit der Quelldatenbank in der eigenständigen AG wird unterstützt.

DDL-Änderungen

Die einzigen DDL-Änderungen befinden sich im CREATE AVAILABILITY GROUP-Workflow . Es gibt eine WITH Klausel mit zwei Optionen:

<with_option_spec> ::=
CONTAINED [REUSE_SYSTEM_DATABASES | AUTOSEEDING_SYSTEM_DATABASES ]

ENTHALTEN

Dies gibt an, dass die zu erstellende AG eine eigenständige AG sein soll.

REUSE_SYSTEM_DATABASES

Die REUSE_SYSTEM_DATABASES Option ist nur für enthaltene AGs gültig und gibt an, dass die neu erstellte AG vorhandene enthaltene Systemdatenbanken für eine frühere enthaltene AG mit demselben Namen wiederverwenden soll. Wenn Sie z. B. eine eingeschlossene AG mit dem Namen MyContainedAG hatten und diese löschen und neu erstellen möchten, können Sie diese Option verwenden, um die Inhalte der ursprünglichen eingeschlossenen Systemdatenbanken wiederzuverwenden. Wenn Sie diese Option verwenden, geben Sie keine Systemdatenbanknamen an. SQL Server erkennt sie automatisch.

AUTOSEEDING_SYSTEMDATENBANKEN

Gilt für: SQL Server 2025 (17.x) Vorschau und höher

Wenn Sie beabsichtigen, Ihre enthaltene AG als Weiterleitung in einer verteilten Verfügbarkeitsgruppe zu verwenden, müssen Sie die AUTOSEEDING_SYSTEM_DATABASES Option verwenden, wenn Sie die enthaltene AG erstellen . Diese Option weist SQL Server an, das Erstellen seiner eigenen eigenständigen AG-Systemdatenbanken zu überspringen und stattdessen das Seeding der eigenständigen AG-Systemdatenbanken von der globalen primären Datenbank auszuführen.

DMV-Änderungen

Es gibt zwei Ergänzungen zu DMVs im Zusammenhang mit eigenständigen AGs:

• Der DMV sys.dm_exec_sessions verfügt über eine hinzugefügte Spalte: contained_availability_group_id
• Der Katalogansicht sys.availability_groups wurde eine Spalte hinzugefügt: is_contained

Zugehöriger Inhalt

• VERFÜGBARKEITSGRUPPE ERSTELLEN (Transact-SQL)