Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
gäller för: SQL Server 2022 (16.x)
En innesluten tillgänglighetsgrupp är en AlwaysOn-tillgänglighetsgrupp (AG) som stöder:
hantera metadataobjekt (användare, inloggningar, behörigheter, SQL Agent-jobb och så vidare) på ag-nivå utöver instansnivån.
specialiserade inneslutna systemdatabaser inom AG.
Den här artikeln beskriver likheterna, skillnaderna och funktionerna i inneslutna AG:er.
Överblick
AG:er består vanligtvis av en eller flera användardatabaser som är avsedda att fungera som en samordnad grupp och som replikeras på ett antal noder i ett kluster. När det uppstår ett fel i noden, eller i hälsotillståndet för SQL Server på noden som är värd för den primära kopian, flyttas databasgruppen som en enhet till en annan repliknod i AG. Alla användardatabaser hålls synkroniserade mellan alla repliker av tillgänglighetsgruppen (AG), antingen i synkront eller asynkront läge.
Detta fungerar bra för program som bara interagerar med den uppsättningen användardatabaser, men det finns utmaningar när program också förlitar sig på objekt som användare, inloggningar, behörigheter, agentjobb osv., som lagras i en av systemdatabaserna (master eller msdb). För att applikationerna ska fungera smidigt och förutsägbart måste administratören manuellt se till att alla ändringar av dessa objekt dupliceras över alla replikinstanser i AG:n. Om en ny instans tas med i tillgänglighetsgruppen kan databaserna automatiskt eller manuellt seedas i en enkel process, men sedan måste alla systemdatabasanpassningar konfigureras om på den nya instansen för att matcha de andra replikerna.
Inneslutna AG:er utökar begreppet databasgrupp som replikeras till att omfatta relevanta delar av master och msdb databaser. Tänk på det som körningskontexten för applikationer som använder den inneslutna AG. Tanken är att den inneslutna AG-miljön innehåller inställningar som skulle påverka applikationen som är beroende av dem. Därför gäller den inneslutna AG-miljön alla databaser som programmet interagerar med, den autentisering som används (inloggningar, användare, behörigheter), alla schemalagda uppgifter som förväntas köras och andra konfigurationsinställningar som påverkar programmet.
Detta skiljer sig från inneslutna databaser, som använder en annan mekanism för användarkontona och lagrar användarinformationen i själva databasen. Inneslutna databaser replikerar endast inloggningar och användare, och omfattningen för den replikerade inloggningen eller användaren är begränsad till den enskilda databasen (och dess repliker).
I en innesluten tillgänglighetsgrupp kan du skapa användare, inloggningar, behörigheter och så vidare på tillgänglighetsgruppens nivå, och de är automatiskt konsekventa mellan replikerna i tillgänglighetsgruppen samt mellan databaserna i den inneslutna tillgänglighetsgruppen. Detta sparar administratören från att behöva göra dessa ändringar manuellt.
SQL Server 2025-ändringar
Förhandsversionen av SQL Server 2025 (17.x) introducerar stöd för distribuerade tillgänglighetsgrupper för inneslutna tillgänglighetsgrupper.
Skillnader
Det finns några praktiska skillnader att tänka på när man arbetar med inneslutna tillgänglighetsgrupper (AG:er), såsom skapandet av inneslutna systemdatabaser och att tvinga fram anslutningen på nivån för den inneslutna tillgänglighetsgruppen i stället för på instansnivå.
Inneslutna systemdatabaser
Varje tillgänglighetsgrupp har sina egna master och msdb systemdatabaser, namngivna efter tillgänglighetsgruppens namn. I den i sammanhanget angivna AG MyContainedAG, har du till exempel databaser som heter MyContainedAG_master och MyContainedAG_msdb. Dessa systemdatabaser skickas automatiskt till nya repliker och uppdateringar replikeras till dessa databaser precis som andra databaser i en tillgänglighetsgrupp. Det innebär att när du lägger till ett objekt, till exempel ett inloggnings- eller agentjobb när du är ansluten till den inneslutna tillgänglighetsgruppen, och om den inneslutna tillgänglighetsgruppen växlar över till en annan instans, så kommer du fortfarande att kunna se agentjobben och logga in med inlogget som skapades i den inneslutna tillgänglighetsgruppen.
Viktig
Inneslutna AG:er är en mekanism för att hålla körningsmiljökonfigurationer konsekventa mellan replikerna i en tillgänglighetsgrupp. De representerar inte en säkerhetsgräns. Det finns ingen gräns som hindrar en anslutning till en innesluten tillgänglighetsgrupp från att komma åt databaser utanför tillgänglighetsgruppen, till exempel.
Systemdatabaserna i en nyligen skapad inneslutna AG är inte kopior från den instans där kommandot CREATE AVAILABILITY GROUP körs. De är initialt tomma mallar utan data. Omedelbart efter skapandet kopieras administratörskontona på den instans som skapar den inneslutna tillgänglighetsgruppen till den inneslutna tillgänglighetsgruppen master. På så sätt kan administratören logga in på den inneslutna tillgänglighetsgruppen och slutföra resten av konfigurationen.
Om du skapar lokala användare eller konfigurationer i din instans visas de inte automatiskt när du skapar dina inneslutna systemdatabaser och de visas inte när du ansluter till den inneslutna tillgänglighetsgruppen. När användardatabasen har anslutits till en avgränsad tillgänglighetsgrupp blir den omedelbart inte tillgänglig för dessa användare. Du måste manuellt återskapa dem i de avgränsade systemdatabaserna inom kontexten för den Inneslutna Tillgänglighetsgruppen, genom att ansluta direkt till databasen eller med hjälp av lyssnarens slutpunkt. Undantaget är att alla inloggningar i sysadmin-rollen i den överordnade instansen kopieras till den nya tillgänglighetsgruppens specifika databas master när den inneslutna tillgänglighetsgruppen skapas.
Not
Eftersom master-databasen är separat för varje innesluten tillgänglighetsgrupp, sparas aktiviteter med serveromfattande räckvidd som utförs i kontexten för den begränsade tillgänglighetsgruppen endast i den konfinerade systemdatabasen. Detta omfattar granskning. Om du granskar aktivitet på servernivå med SQL Server-granskning behöver du skapa motsvarande servergranskningar i varje inhägnad tillgänglighetsgrupp.
Inledande datasynkronisering
De inkluderade systemdatabaserna stöder endast automatisk seeding som inledande datasynkroniseringssätt.
I SQL Server 2022 (16.x) och tidigare versioner måste inneslutna tillgänglighetsgrupper använda automatisk seeding när de skapas. När du använder instruktionen CREATE AVAILABILITY GROUP eller guiden Ny tillgänglighetsgrupp i SQL Server Management Studio ska du bara inkludera användardatabaser som stöder automatisk seeding. Om du vill lägga till stora databaser med manuell seeding (JOIN ONLY) väntar du tills den inneslutna tillgänglighetsgruppen har skapats.
I förhandsversionen av SQL Server 2025 (17.x) använder inneslutna systemdatabaser alltid automatisk seeding, även om instruktionen CREATE AVAILABILITY GROUP anger manuell seeding. Du kan ange läge för seeding till manuellt för att skapa en begränsad tillgänglighetsgrupp och senare lägga till användarens databaser med andra synkroniseringsmetoder än automatisk seeding.
Återställa en innesluten systemdatabas
Följ dessa steg för att återställa säkerhetskopior av inneslutna systemdatabaser:
Släpp den inneslutna AG:n.
Återställ de innehållna
masterochmsdbdatabaserna på den ursprungliga primära replika av den innehållna AG.Ta bort den angivna
master- ochmsdb-databasen från de sekundära replikerna.På den primära repliken återskapar du den inneslutna tillgänglighetsgruppen med det ursprungliga namnet och noderna, med
WITH (CONTAINED, REUSE_SYSTEM_DATABASES)ochSEEDING_MODE = AUTOMATICsyntax.
När du återskapar en innesluten tillgänglighetsgrupp ska du inte ta med inneslutna systemdatabaser i -instruktionen CREATE AVAILABILITY GROUP . SQL Server identifierar dem automatiskt när REUSE_SYSTEM_DATABASES anges. I SQL Server 2022 (16.x) och tidigare versioner innehåller endast små användardatabaser som stöder automatisk seeding. Lägg till stora databaser separat efter att den inneslutna AG har skapats med JOIN ONLY.
Avgränsade tillgänglighetsgruppjobb
Jobb som tillhör en begränsad tillgänglighetsgrupp körs endast på den primära kopian. De körs inte på sekundära repliker.
Anslut (avgränsad miljö)
Det är viktigt att göra skillnad mellan att ansluta till instansen och att ansluta till den tillhörande AG. Det enda sättet att komma åt miljön för den inneslutna tillgänglighetsgruppen är att ansluta till den inneslutna tillgänglighetsgruppens lyssnare eller att ansluta till en databas som finns i den inneslutna tillgänglighetsgruppen.
"Persist Security Info=False;
User ID=MyUser;Password=*****;
Initial Catalog=MyContainedDatabase;
Server=MyServer;"
Där MyContainedDatabase är en databas inom den inneslutna tillgänglighetsgruppen som du vill interagera med.
Det innebär att du måste skapa en lyssnare för den inneslutna AG för att effektivt använda en innesluten AG. Om du ansluter till en av de instanserna som är värd för den inneslutna tillgänglighetsgruppen i stället för att direkt till den inneslutna tillgänglighetsgruppen via lyssnarenär du i miljön för instansen och inte den inneslutna tillgänglighetsgruppen.
Om tillgänglighetsgruppen till exempel MyContainedAG finns på servern SERVER\MSSQLSERVERoch i stället för att ansluta till lyssnaren MyContainedAG_Listeneransluter du till instansen med SERVER\MSSQLSERVER, är du i instansens miljö och inte i miljön för MyContainedAG. Det innebär att du omfattas av innehållet (användare, behörigheter, jobb osv.) som finns i systemdatabaserna i instansen. För att komma åt innehållet som finns i de inneslutna systemdatabaserna i den inneslutna tillgänglighetsgruppen ansluter du till den inneslutna tillgänglighetsgruppens lyssnare (MyContainedAG_Listener, till exempel) i stället. När du ansluter till instansen via lyssnaren för den begränsade tillgänglighetsgruppen och interagerar med master, blir du faktiskt omdirigerad till den begränsade master-databasen (till exempel MyContainedAG_master).
Endast läsbar routing och avgränsade tillgänglighetsgrupper
Om du konfigurerar skrivskyddad routning för att omdirigera anslutningar med läsintention till en sekundär replik (se Konfigurera skrivskyddad routning för en Always On-tillgänglighetsgrupp) och du vill ansluta med en inloggning som endast har skapats inom den inneslutna tillgänglighetsgruppen finns det några ytterligare överväganden:
- Du måste ange en databas som ingår i den bundna tillgänglighetsgruppen i anslutningssträngen
- Användaren som anges i anslutningssträngen måste ha behörighet för att komma åt databaserna i den inneslutna tillgänglighetsgruppen.
Till exempel i följande anslutningssträng, där AdventureWorks är en databas i den inneslutna tillgänglighetsgruppen som har MyContainedListener, och där MyUser är en användare som definierats i den inneslutna tillgänglighetsgruppen och ingen av de deltagande instanserna:
"Persist Security Info=False;
User ID=MyUser;Password=*****;
Initial Catalog=AdventureWorks;
Server=MyContainedListener;
ApplicationIntent=ReadOnly"
Den här anslutningssträngen gör att du ansluter till den läsbara sekundära replikan som är en del av ReadOnly Routing-konfigurationen, och du skulle vara inom kontexten för den avgränsade tillgänglighetsgruppen.
Skillnader mellan att ansluta till instansen och ansluta till den inneslutna tillgänglighetsgruppen
- När de är anslutna till en innesluten tillgänglighetsgrupp ser användarna bara databaser i den inneslutna tillgänglighetsgruppen, plus
tempdb. - På instansnivå är de innehållna AG-namnen
masterochmsdb,[contained AG]_masteroch[contained AG]_msdb. I det inneslutna AG är deras namnmasterochmsdb. - Databas-ID för den inneslutna AG:n
masterär1inifrån den inneslutna AG:n, men något annat när den är ansluten till instansen. - Även om användarna inte ser databaser utanför den inneslutna tillgänglighetsgruppen i
sys.databasesnär de är anslutna i en innesluten tillgänglighetsgruppsanslutning, kan de komma åt dessa databaser med tredelade namn eller via kommandotUSE. - Serverkonfiguration via
sp_configurekan läsas från den inneslutna AG-anslutningen, men kan endast skrivas på instansnivå. - Från inneslutna AG-anslutningar kan sysadmin utföra åtgärder på instansnivå, till exempel stänga av SQL Server.
- De flesta åtgärder på databasnivå, ändpunktsnivå eller tillgänglighetsgruppsnivå kan endast utföras från instansanslutningar, inte från kontrollerade tillgänglighetsgruppsanslutningar.
Interaktioner med andra funktioner
Det finns ytterligare saker att tänka på när du använder vissa funktioner med inneslutna AG:er, och det finns vissa funktioner som för närvarande inte stöds.
Säkerhetskopiera
Procedurer för att säkerhetskopiera databaser i en innesluten tillgänglighetsgrupp är desamma som alla säkerhetskopieringsprocedurer för användardatabaser. Detta gäller både för användardatabaserna och systemdatabaserna inom de inneslutna tillgänglighetsgrupperna (AG).
Om säkerhetskopieringsplatsen är lokal placeras säkerhetskopieringsfilerna på den server som kör säkerhetskopieringsjobbet. Det innebär att dina säkerhetskopieringsfiler kan finnas på olika platser.
Om säkerhetskopieringsplatsen finns på en nätverksresurs behöver alla servrar som är värdar för repliker åtkomst till den resursen.
Distribuerade tillgänglighetsgrupper
En distribuerad tillgänglighetsgrupp är en särskild typ av tillgänglighetsgrupp som omfattar två underliggande tillgänglighetsgrupper. När du konfigurerar en distribuerad tillgänglighetsgrupp replikeras ändringar som görs på den globala primärrepliken (som är den primära repliken för din första tillgänglighetsgrupp) till den primära repliken av den andra tillgänglighetsgruppen, som kallas vidarebefordraren.
Från och med förhandsversionen av SQL Server 2025 (17.x) kan du konfigurera en distribuerad tillgänglighetsgrupp mellan två inneslutna AG:er. Eftersom en innesluten tillgänglighetsgrupp förlitar sig på inneslutna master databaser och msdb systemdatabaser måste den andra tillgänglighetsgruppen (vidarebefordraren) ha samma innehållna tillgänglighetsgruppsdatabas som den globala primära.
Om du tänker använda en innesluten tillgänglighetsgrupp (AG) som vidarebefordrare i en distribuerad tillgänglighetsgrupp måste du skapa den inneslutna AG med hjälp av AUTOSEEDING_SYSTEM_DATABASES-klausulen för WITH | CONTAINED-alternativet i CREATE AVAILABILITY GROUP-instruktionen. Satsen AUTOSEEDING_SYSTEM_DATABASES instruerar SQL Server att hoppa över att skapa egna inneslutna AG-systemdatabaser och istället så de inneslutna AG-systemdatabaserna från den globala primära.
Resursguvernör
I SQL Server 2022 (16.x) före kumulativ uppdatering 18 och i äldre versioner av SQL Server stöds inte konfiguration eller användning av resource governor på inneslutna tillgänglighetsgruppanslutningar.
Från och med SQL Server 2022 (16.x) Kumulativ uppdatering 18, om du konfigurerar resursguvernör för en instansanslutning, styrs resursförbrukningen för antingen instansanslutningar eller inneslutna tillgänglighetsgruppanslutningar som förväntat. Om du försöker konfigurera resursguvernören för en innesluten tillgänglighetsgruppanslutning får du ett fel.
Resursguvernören fungerar på instansnivå för databasmotorn. Konfigurationen av resursguvernören på instansnivå överförs inte till tillgänglighetsrepliker. Du måste konfigurera resursguvernör för varje instans som är värd för en tillgänglighetsreplik.
Tips/Råd
Vi rekommenderar att du använder samma konfiguration av resursguvernören för alla databasmotorinstanser som är värdar för repliker i tillgänglighetsgrupper för att säkerställa konsekvent beteende när växlingar av tillgänglighetsgrupper inträffar.
Mer information finns i Konfigurationsexempel och metodtips för Resource Governor och Resource Governor.
Ändra datainsamling
Ändringsdatainsamling (CDC) implementeras som SQL Agent-jobb, så SQL-agenten måste köras på alla instanser med repliker i den innehållna AG:n.
Om du vill använda Change Data Capture med en tillgänglighetsgrupp med inneslutet läge, anslut till lyssnaren för tillgänglighetsgruppen när du konfigurerar CDC så att CDC-metadata konfigureras med hjälp av de inneslutna systemdatabaserna.
Loggöverföring
Loggleverans kan konfigureras om källdatabasen finns i en kontrollerad tillgänglighetsgrupp. Ett loggleveransmål stöds dock inte i en avgränsad tillgänglighetsgrupp. Dessutom finns det ett ytterligare steg för att ändra loggöverföringsarbetet efter att CDC har konfigurerats.
Följ dessa steg för att konfigurera loggöverföring med en innesluten tillgänglighetsgrupp (AG):
- Anslut till den begränsade AG-lyssnaren.
- Konfigurera loggöverföring som du normalt skulle göra.
- När loggleveransjobbet har konfigurerats ändrar du det för att ansluta till lyssnaren för den inneslutna tillgänglighetsgruppen (AG) innan du säkerhetskopierar.
Transparent datakryptering (TDE)
Om du vill använda transparent datakryptering (TDE) med databaser i en innesluten tillgänglighetsgrupp installerar du manuellt databashuvudnyckeln (DMK) till den inneslutna master databasen i den inneslutna tillgänglighetsgruppen.
Databaser som använder TDE förlitar sig på certifikat i master-databasen för att dekryptera databaskrypteringsnyckeln (DEK). Utan det certifikatet kan SQL Server inte dekryptera databaser som krypterats med TDE eller föra dem online. I en kontrollerad AG, kontrollerar SQL Server både master-databaserna för DMK, master-databasen för instansen och den inneslutna master-databasen inom den inneslutna AG:n för att dekryptera databasen. Om det inte kan hitta certifikatet på någon av platserna kan SQL Server inte ansluta databasen.
Om du vill överföra DMK:n från instansens master databas till den inneslutna master-databasen kan du läsa Flytta en TDE-skyddad databas till en annan SQL Server-, främst med fokus på de delar där DMK överförs från den gamla servern till den nya.
Not
Om du krypterar en databas på en SQL Server-instans krypteras även systemdatabasentempdb.
SSIS-paket och underhållsplaner &
Användning av SSIS-paket, inklusive underhållsplaner, stöds inte med inneslutna tillgänglighetsgrupper.
Stöds inte
För närvarande stöds inte följande SQL Server-funktioner i en innesluten tillgänglighetsgrupp:
- SQL Server-replikering av valfri typ (transaktionell, sammanslagning, ögonblicksbild och så vidare).
- Loggleverans där måldatabasen finns i den avgränsade tillgänglighetsgruppen. Loggleverans med källdatabasen i den inneslutna tillgänglighetsgruppen stöds.
DDL-ändringar
De enda DDL-ändringarna finns i arbetsflödet SKAPA TILLGÄNGLIGHETSGRUPP . Det finns en WITH sats med två alternativ:
<with_option_spec> ::=
CONTAINED [REUSE_SYSTEM_DATABASES | AUTOSEEDING_SYSTEM_DATABASES ]
INNEHÖLL
Detta anger att den ag som skapas ska vara en avgränsad ag.
REUSE_SYSTEM_DATABASES
Alternativet REUSE_SYSTEM_DATABASES är endast giltigt för inneslutna tillgänglighetsgrupper och anger att den nyligen skapade tillgänglighetsgruppen ska återanvända befintliga inneslutna systemdatabaser för en tidigare innesluten tillgänglighetsgrupp med samma namn. Om du till exempel hade en tillgänglighetsgrupp med begränsat omfång med namnet MyContainedAGoch ville ta bort och återskapa den, kan du använda det här alternativet för att återanvända innehållet i de ursprungliga systemdatabaserna som var inneslutna. Ange inte systemdatabasnamn när du använder det här alternativet. SQL Server identifierar dem automatiskt.
AUTOSEEDING_SYSTEM_DATABASES
Gäller för: SQL Server 2025 (17.x) Förhandsversion och senare
Om du tänker använda den inneslutna tillgänglighetsgruppen som vidarebefordrare i en distribuerad tillgänglighetsgrupp måste du använda AUTOSEEDING_SYSTEM_DATABASES alternativet när du skapar den inneslutna tillgänglighetsgruppen. Det här alternativet instruerar SQL Server att hoppa över skapandet av sina egna inneslutna AG-systemdatabaser och istället överföra de inneslutna AG-systemdatabaserna från den globala primära.
DMV-ändringar
Det finns två tillägg till DMV:er kopplade till avgränsade AG:er.
- DMV-
sys.dm_exec_sessionshar en tillagd kolumn:contained_availability_group_id - Katalogvyn
sys.availability_groupshar den tillagda kolumnen:is_contained