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 ein Fehler im Knoten oder im Zustand von SQL Server auf dem Knoten auftritt, auf dem die primäre Kopie gehostet wird, wird die Datenbankgruppe als Einheit zu einem anderen Replikatknoten in der AG verschoben. Alle Benutzerdatenbanken bleiben über alle Replikate der AG hinweg synchronisiert, entweder im synchronen oder asynchronen Modus.

Diese Architektur eignet sich gut für Anwendungen, die nur mit dieser Gruppe von Benutzerdatenbanken interagieren. Es treten jedoch Herausforderungen auf, wenn Anwendungen auch Objekte wie Benutzer, Anmeldungen, Berechtigungen, Agentaufträge und andere Objekte verwenden, die in einer der Systemdatenbanken gespeichert sind (master oder msdb). Um sicherzustellen, dass Anwendungen reibungslos und vorhersehbar funktionieren, muss der Administrator manuell sicherstellen, dass alle Änderungen an diesen Objekten in allen Replikatinstanzen in der AG dupliziert werden. Wenn Sie der AG eine neue Instanz hinzufügen, können Sie die Datenbanken automatisch oder manuell in einem einfachen Prozess seeden. Sie müssen jedoch alle Systemdatenbankanpassungen für die neue Instanz so konfigurieren, dass sie den anderen Replikaten 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. Die Idee besteht darin, dass die enthaltene AG-Umgebung Einstellungen enthält, die sich auf die Anwendung auswirken, die darauf angewiesen ist. 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.

Dieses Konzept unterscheidet sich von den enthaltenen Datenbanken, die einen anderen Mechanismus für die Benutzerkonten verwenden, indem die Benutzerinformationen in der Datenbank selbst gespeichert werden. 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 erstellen Sie in einer enthaltenen AG Benutzer, Anmeldungen, Berechtigungen usw. auf AG-Ebene. Diese Objekte werden automatisch über Replikate in der AG hinweg konsistent sowie über Datenbanken innerhalb der darin enthaltenen AG hinweg konsistent. Diese Konsistenz erspart dem Administrator, diese Änderungen manuell vornehmen zu müssen.

SQL Server 2025-Änderungen

SQL Server 2025 (17.x) führt die Unterstützung für verteilte Verfügbarkeitsgruppen für enthaltene Verfügbarkeitsgruppen ein.

Unterschiede

Wenn Sie mit eingeschlossenen AGs arbeiten, sollten Sie einige praktische Unterschiede beachten. Zu diesen Unterschieden gehören die Erstellung von enthaltenen Systemdatenbanken und das Erzwingen der Verbindung auf der ebene der enthaltenen AG anstelle der Verbindung auf Instanzebene.

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 bereitgestellt, und Aktualisierungen werden wie bei jeder anderen Datenbank in einer Verfügbarkeitsgruppe auf diese Datenbanken repliziert. Wenn Sie ein Objekt wie eine Anmeldung oder einen Agent-Job hinzufügen, während Sie mit der enthaltenen AG verbunden sind, sehen Sie weiterhin die Agent-Jobs und können sich mithilfe der in der enthaltenen AG erstellten Anmeldung authentifizieren, wenn die enthaltene AG auf eine andere Instanz umschaltet.

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. So gibt es beispielsweise keine Grenze, die eine Verbindung zu einer in der AG eingeschlossenen AG daran hindert, auf Datenbanken außerhalb der AG zuzugreifen.

Die Systemdatenbanken in einer neu erstellten enthaltenen AG sind keine Kopien aus der Instanz, in der Sie den CREATE AVAILABILITY GROUP Befehl ausführen. Sie sind anfänglich leere Vorlagen ohne Daten. Unmittelbar nach der Erstellung kopiert der Prozess die Administratorkonten von der Instanz, die die enthaltene AG erzeugt, in die enthaltene AG master. Auf diese Weise kann sich der Administrator bei der enthaltenen 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 enthaltenen AG beitritt, verlieren diese Benutzer sofort den Zugriff. 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 dieser Regel besteht darin, dass alle Anmeldungen in der Sysadmin-Rolle in der übergeordneten Instanz während der Erstellung der enthaltenen AG in die neue AG-spezifische master Datenbank kopiert werden.

Anmerkung

Da die master Datenbank für jede enthaltene Verfügbarkeitsgruppe getrennt ist, werden serverbezogene Aktivitäten, die im Kontext der enthaltenen AG durchgeführt werden, nur in der enthaltenen Systemdatenbank gespeichert. Diese Regel umfasst 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.

Synchronisierung der ursprünglichen Daten

Die enthaltenen Systemdatenbanken unterstützen nur das automatische Seeding als erste Datensynchronisierungsmethode.

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 der manuellen Seeding (JOIN ONLY) hinzuzufügen, warten Sie, bis die enthaltene AG erstellt wurde.

In SQL Server 2025 (17.x) verwenden enthaltene Systemdatenbanken immer automatische Seeding, auch wenn die CREATE AVAILABILITY GROUP Anweisung manuelle Seeding angibt. Sie können den Seedingmodus manuell festlegen, um eine enthaltene AG zu erstellen und später Benutzerdatenbanken hinzuzufügen, indem Sie andere Synchronisierungsmethoden als automatisches Seeding verwenden.

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. Legen Sie die enthaltenen master und msdb Datenbanken aus sekundären Replikaten ab.

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 Sie angeben REUSE_SYSTEM_DATABASES. 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;"

Dabei MyContainedDatabase handelt es sich um eine Datenbank innerhalb der enthaltenen AG, mit der Sie interagieren möchten.

Sie müssen einen Listener für die enthaltene AG erstellen, um eine enthaltene 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. Sie unterliegen den Inhalten (Benutzer, Berechtigungen, Aufträge usw.), die sich in den Systemdatenbanken der Instanz befinden. 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 enthaltenen AG erstellt wird, gibt es weitere Überlegungen:

• Sie müssen eine Datenbank angeben, die Teil der enthaltenen 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.

In der folgenden Verbindungszeichenfolge ist `AdventureWorks` beispielsweise eine Datenbank innerhalb der enthaltenen AG, die `MyContainedListener` hat, und `MyUser` ist ein Benutzer, der in der enthaltenen AG und in keiner der teilnehmenden Instanzen definiert ist.

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

In diesem Beispiel wird eine Verbindung mit der lesbaren sekundären Komponente hergestellt, die Teil der ReadOnly Routing-Konfiguration ist, und Sie befinden sich im Kontext der enthaltenen 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

Berücksichtigen Sie andere Faktoren bei der Verwendung bestimmter Features mit enthaltenen AGs. Einige Features werden derzeit nicht unterstützt.

Sichern

Die Verfahren zum Sichern von Datenbanken in einer enthaltenen AG sind identisch mit allen Sicherungsprozeduren der Benutzerdatenbank. Diese Aussage gilt sowohl für die enthaltenen AG-Benutzerdatenbanken als auch für die darin enthaltenen AG-Systemdatenbanken.

Wenn Sie einen lokalen Sicherungsspeicherort verwenden, werden die Sicherungsdateien auf dem Server platziert, auf dem der Sicherungsauftrag ausgeführt wird. Dies bedeutet, dass sich Ihre Sicherungsdateien möglicherweise an unterschiedlichen Speicherorten befinden.

Wenn Sie eine Netzwerkressource für den Sicherungsspeicherort verwenden, benötigen alle Server, die Replikate hosten, Zugriff auf diese Ressource.

Aktivieren der Datenbankerstellung oder Wiederherstellung in enthaltenen Verfügbarkeitsgruppensitzungen

Gilt für: SQL Server 2025 (17.x) CU 1 und höhere Versionen.

In SQL Server 2025 (17.x) Kumulatives Update (CU) 1 können Sie die Datenbankerstellung und Wiederherstellung direkt in einer enthaltenen Verfügbarkeitsgruppensitzung über den enthaltenen AG-Listener aktivieren. Durch diese Verbesserung werden Workflows für Benutzer optimiert, denen die entsprechenden Rollen zugewiesen wurden, sodass nahtlose Vorgänge in enthaltenen AG-Umgebungen möglich sind.

Nur Benutzer mit der Dbcreator-Rolle können Datenbanken in einer enthaltenen AG-Sitzung erstellen. Nur Benutzer mit der rolle db_owner oder sysadmin können Datenbanken wiederherstellen.

Im folgenden Beispiel wird das Feature für Ihre Sitzung mithilfe des Sitzungskontextschlüssels allow_cag_create_db in der sp_set_session_contex gespeicherten Prozedur aktiviert. Um ihn zu deaktivieren, setzen Sie @value auf 0.

EXECUTE sp_set_session_context
    @key = N'allow_cag_create_db',
    @value = 1;

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) 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

Gilt für: SQL Server 2022 (16.x) CU 18 und höher.

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

Wenn Sie in SQL Server 2022 (16.x) CU 18 und neueren Versionen die Ressourcenkontrolle für eine Instanzverbindung konfigurieren, wird der Ressourcenverbrauch für Instanzenverbindungen oder enthaltene Verfügbarkeitsgruppenverbindungen wie erwartet 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

Sie sollten dieselbe Ressourcenkontrolle-Konfiguration für alle Datenbankmodulinstanzen verwenden, die Verfügbarkeitsreplikate hosten, um ein konsistentes Verhalten zu gewährleisten, wenn Verfügbarkeitsgruppenfailover auftreten.

Weitere Informationen finden Sie unter Ressourcengouverneur und Lernprogramm: Konfigurationsbeispiele für 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

Sie können den Protokollversand konfigurieren, wenn sich die Quelldatenbank in der enthaltenen Verfügbarkeitsgruppe (AG) befindet. Ein Protokollversandziel wird jedoch nicht innerhalb einer eigenständigen AG unterstützt. Darüber hinaus müssen Sie den Protokollversandauftrag ändern, nachdem Sie CDC konfiguriert haben.

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. Nachdem Sie den Protokollversandauftrag konfiguriert haben, ändern Sie den Auftrag, um eine Verbindung mit dem enthaltenen 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 beiden Speicherorten nicht gefunden werden kann, kann SQL Server die Datenbank nicht online übertragen.

Informationen zum Übertragen des DMK aus der master Datenbank der Instanz in die enthaltene master Datenbank finden Sie unter Verschieben einer TDE-geschützten Datenbank auf einen anderen SQL Server, in erster Linie auf die Teile, in denen der DMK vom alten Server auf den neuen ü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 nicht für eingeschlossene Verfügbarkeitsgruppen 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-Unterstützung

Im WORKFLOW CREATE AVAILABILITY GROUP gibt es eine WITH Klausel mit mehreren Optionen:

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

ENTHALTEN

Diese Option gibt an, dass es sich bei der von Ihnen erstellten AG um eine enthaltene AG handelt.

REUSE_SYSTEM_DATABASES

Die REUSE_SYSTEM_DATABASES Option ist nur für enthaltene AGs gültig. Es wird angegeben, dass die neue eingeschlossene AG vorhandene eingeschlossene Systemdatenbanken einer früheren eingeschlossenen AG mit demselben Namen wiederverwenden soll. Wenn Sie beispielsweise eine enthaltene AG mit dem Namen MyContainedAG hatten und sie ablegen und neu erstellen wollten, könnten Sie diese Option verwenden, um den Inhalt der ursprünglichen enthaltenen 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) und neuere Versionen.

Wenn Sie Ihre enthaltene AG als Weiterleitung in einer verteilten Verfügbarkeitsgruppe verwenden möchten, 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.

Systemobjektunterstützung für enthaltene Verfügbarkeitsgruppen

Zwei Systemansichten umfassen Ergänzungen im Zusammenhang mit enthaltenen Verfügbarkeitsgruppen:

• Die sys.dm_exec_sessions dynamische Verwaltungsansicht enthält eine contained_availability_group_id Spalte.
• Die sys.availability_groups Katalogansicht enthält die is_contained Spalte.

Zugehöriger Inhalt

• VERFÜGBARKEITSGRUPPE ERSTELLEN (Transact-SQL)