You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/database-engine/availability-groups/windows/contained-availability-groups-overview.md
+14-11Lines changed: 14 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -57,28 +57,31 @@ Each contained AG has its own `master` and `msdb` system databases, named after
57
57
58
58
The system databases in a newly created contained AG aren't copies from the instance where the `CREATE AVAILABILITY GROUP` command is run. They are initially empty templates without any data. Immediately after creation, the admin accounts on the instance creating the contained AG are copied into the contained AG `master`. That way, the administrator can log into the contained AG and set up the rest of the configuration.
59
59
60
-
If you create local users or configurations in your instance, they don't automatically appear when you create your contained system databases, and they aren't visible when you connect to the contained AG. Once the user database has been joined to a contained AG, it will immediately become inaccessible to these users. You need to manually re-create them in the contained system databases within the context of the contained AG, by connecting directly to the database or by using the listener endpoint. The exception to this is that all of the logins in the sysadmin role in the parent instance are copied into the new AG specific `master` database.
60
+
If you create local users or configurations in your instance, they don't automatically appear when you create your contained system databases, and they aren't visible when you connect to the contained AG. Once the user database has been joined to a contained AG, it will immediately become inaccessible to these users. You need to manually re-create them in the contained system databases within the context of the contained AG, by connecting directly to the database or by using the listener endpoint. The exception to this is that all of the logins in the sysadmin role in the parent instance are copied into the new AG specific `master` database during creation of contained AG.
61
61
62
62
> [!NOTE]
63
63
> Because the `master` database is separate for each contained availability group, server-scope activities performed in the context of the contained AG are only persisted in the contained system database. This includes auditing. If you audit server level activity with SQL Server Auditing, you must create the same server audits within each contained AG.
64
64
65
-
#### Restore a contained system database
66
-
67
-
You can restore a contained system database using one of two different ways.
65
+
#### Initial Data synchronization
66
+
The contained system databases only support auto seeding as initial data synchronization way.
68
67
69
-
-**Restore a contained database using a secondary replica**:
68
+
In [!INCLUDE [sssql22-md](../../../includes/sssql22-md.md)] and earlier versions, contained availability groups must use automatic seeding during creation. When using the `CREATE AVAILABILITY GROUP` statement or the New Availability Group wizard in SQL Server Management Studio, only include user databases that support auto seeding. To add large databases using manual seeding (`JOIN ONLY`), wait until after the contained AG is created.
70
69
71
-
1. Restore the contained `master` and `msdb` database onto a server instance that hosts the secondary replica, using `RESTORE WITH NORECOVERY` for every restore operation. For more information, see [Prepare a secondary database for an Always On availability group](manually-prepare-a-secondary-database-for-an-availability-group-sql-server.md).
70
+
In [!INCLUDE [sssql25-md](../../../includes/sssql25-md.md)], contained system databases always use automatic seeding, even if the `CREATE AVAILABILITY GROUP` statement specifies manual seeding. You can set seeding mode to manual to create a contained AG, and later add user databases using synchronization methods other than auto seeding.
72
71
73
-
1. Join each contained database to the availability group. For more information, see [Join a secondary database to an Always On availability group](join-a-secondary-database-to-an-availability-group-sql-server.md).
72
+
#### Restore a contained system database
74
73
75
-
-**Restore a contained database by dropping the contained AG**:
74
+
To restore backups of contained system databases, follow these steps:
76
75
77
76
1. Drop the contained AG.
78
77
79
-
1. Restore the contained `master` and `msdb` database in each of the instances participating in the contained AG.
78
+
1. Restore the contained `master` and `msdb` databases on the original primary replica of the contained AG.
79
+
80
+
1. Drop the contained `master` and `msdb` database from secondary replicas.
81
+
82
+
1. On the primary replica, recreate the contained AG using the original name and nodes, with `WITH (CONTAINED, REUSE_SYSTEM_DATABASES)` and `SEEDING_MODE = AUTOMATIC` syntax.
80
83
81
-
1. Recreate the contained AG using original nodes and name, using `WITH (CONTAINED, REUSE_SYSTEM_DATABASES)` syntax.
84
+
When recreating a contained availability group, don't include contained system databases in the `CREATE AVAILABILITY GROUP` statement. [!INCLUDE [ssnoversion-md](../../../includes/ssnoversion-md.md)] detects them automatically when `REUSE_SYSTEM_DATABASES` is specified. In [!INCLUDE [sssql22-md](../../../includes/sssql22-md.md)] and earlier versions, include only small user databases that support automatic seeding. Add large databases separately after the contained AG is created, using `JOIN ONLY`.
82
85
83
86
### Contained availability group jobs
84
87
@@ -218,7 +221,7 @@ This specifies that the AG being created should be a contained AG.
218
221
219
222
#### REUSE_SYSTEM_DATABASES
220
223
221
-
The `REUSE_SYSTEM_DATABASES` option is only valid for contained AGs, and specifies that the newly created AG should reuse existing contained system databases for a previous contained AG of the same name. For example, if you had a contained AG with the name `MyContainedAG`, and wanted to drop and recreate it, you could use this option to reuse the contents of the original contained system databases.
224
+
The `REUSE_SYSTEM_DATABASES` option is only valid for contained AGs, and specifies that the newly created AG should reuse existing contained system databases for a previous contained AG of the same name. For example, if you had a contained AG with the name `MyContainedAG`, and wanted to drop and recreate it, you could use this option to reuse the contents of the original contained system databases. When using this option, don't specify system database names. SQL Server automatically detects them.
222
225
223
226
#### AUTOSEEDING_SYSTEM_DATABASES
224
227
Applies to: [!INCLUDE [sssql25-md](../../../includes/sssql25-md.md)] and later
Copy file name to clipboardExpand all lines: docs/relational-databases/resource-governor/resource-governor.md
+6-5Lines changed: 6 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ description: Learn about the SQL Server resource governor feature that limits th
4
4
author: WilliamDAssafMSFT
5
5
ms.author: wiassaf
6
6
ms.reviewer: dfurman
7
-
ms.date: 06/10/2025
7
+
ms.date: 06/23/2025
8
8
ms.service: sql
9
9
ms.subservice: performance
10
10
ms.topic: conceptual
@@ -44,16 +44,17 @@ Some of the usage scenarios supported by resource governor are:
44
44
- Isolate and limit runaway queries, or limit I/O resources for I/O intensive operations that can saturate the I/O subsystem and negatively impact other workloads.
45
45
- Add fine-grained resource tracking for resource usage chargebacks and provide predictable billing to the consumers of server resources.
46
46
47
-
## Resource governor limitations
48
-
49
-
Resource governor has the following limitations:
47
+
## Interoperability and limitations
50
48
49
+
- Resource governor can be used with Always On [availability groups](../../database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server.md) and [failover cluster instances](../../sql-server/failover-clusters/windows/always-on-failover-cluster-instances-sql-server.md). The following considerations apply:
50
+
- When used in [!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)], resource governor must be configured on each [!INCLUDE [ssNoVersion](../../includes/ssnoversion-md.md)] instance that hosts an availability group. Resource governor configuration doesn't propagate from the primary availability group replica to secondary replicas. We recommend that you use the same resource governor configuration for all [!INCLUDE [ssDEnoversion](../../includes/ssdenoversion-md.md)] instances hosting availability replicas. This ensures consistent behavior as availability group failovers occur.
51
+
- When used in [!INCLUDE [ssazuremi-md.md](../../includes/ssazuremi-md.md)], resource governor configuration propagates from the primary replica to all secondary replicas because the `master` database of the primary replica is replicated to all secondary replicas. This includes high availability and geo-replication secondaries. For more information, see [Resource governor](/azure/azure-sql/managed-instance/transact-sql-tsql-differences-sql-server#resource-governor).
52
+
- If you use contained availability groups, see [Interactions with other features](../../database-engine/availability-groups/windows/contained-availability-groups-overview.md#resource-governor) for more information.
51
53
- Resource management is limited to the [!INCLUDE[ssDEnoversion](../../includes/ssdenoversion-md.md)]. Resource governor can't be used for [!INCLUDE[ssASnoversion](../../includes/ssasnoversion-md.md)], [!INCLUDE[ssISnoversion](../../includes/ssisnoversion-md.md)], and [!INCLUDE[ssRSnoversion](../../includes/ssrsnoversion-md.md)].
52
54
- Resource governor does not provide workload monitoring or workload management across multiple [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] instances.
53
55
- Very short queries, such as queries in some OLTP workloads, might not use CPU long enough to apply CPU bandwidth controls. This might skew CPU usage statistics and limit the effectiveness of CPU resource governance.
54
56
- The ability to govern physical I/O applies only to user operations and not system tasks. System tasks perform transaction log, checkpoint, and lazy writer I/O. Resource governor governs user physical reads I/O but not write I/O performed by system tasks.
55
57
- You can't modify resource governance controls for the `internal` resource pool and workload group.
56
-
- If you use contained availability groups, see [Interactions with other features](../../database-engine/availability-groups/windows/contained-availability-groups-overview.md#resource-governor) for more information.
0 commit comments