Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Aplica-se a:
SQL Server 2022 (16.x)
Um grupo de disponibilidade contido é um grupo de disponibilidade (AG) Sempre Ativo que dá suporte a:
Gerenciamento de objetos de metadados (usuários, logons, permissões, trabalhos do SQL Agent etc.) no nível do AG, além do nível da instância.
bancos de dados do sistema independente especializados dentro do AG.
Este artigo detalha as semelhanças, as diferenças e as funcionalidades dos AGs contidos.
Visão geral
Os AGs geralmente são formados por um ou mais bancos de dados de usuário destinados a operar como um grupo coordenado que são replicados em alguns nós em um cluster. Quando há uma falha no nó ou na integridade do SQL Server no nó que hospeda a cópia primária, o grupo de bancos de dados se move como uma unidade para outro nó de réplica no AG. Todos os bancos de dados de usuário permanecem sincronizados em todas as réplicas do AG, no modo síncrono ou assíncrono.
Essa arquitetura funciona bem para aplicativos que interagem apenas com esse conjunto de bancos de dados de usuário. No entanto, surgem desafios quando os aplicativos também dependem de objetos como usuários, logons, permissões, trabalhos de agente e outros objetos armazenados em um dos bancos de dados do sistema (master ou msdb). Para garantir que os aplicativos funcionem de forma suave e previsível, o administrador deve garantir manualmente que qualquer alteração nesses objetos seja duplicada em todas as instâncias de réplica no AG. Se você adicionar uma nova instância ao AG, poderá inicializar automaticamente ou manualmente os bancos de dados em um processo simples. No entanto, você deve reconfigurar todas as personalizações do banco de dados do sistema na nova instância para corresponder às outras réplicas.
Os AGs independentes estendem o conceito do grupo de bancos de dados que está sendo replicado para incluir partes relevantes dos bancos de dados master e msdb. Considere-o como o contexto de execução para aplicativos que usam o AG contido. A ideia é que o ambiente AG contido inclua configurações que afetam o aplicativo que depende delas. Assim, o ambiente de AG contido diz respeito a todos os bancos de dados com os quais o aplicativo interage, a autenticação que ele usa (logons, usuários, permissões), todos os trabalhos agendados que ele espera que estejam em execução e outras configurações que afetam o aplicativo.
Esse conceito difere dos bancos de dados independentes, que usam um mecanismo diferente para as contas de usuário, armazenando as informações do usuário no próprio banco de dados. Os bancos de dados independentes replicam apenas logons e usuários, e o escopo do logon ou usuário replicado é limitado a esse banco de dados individual (e às respectivas réplicas).
Por outro lado, em um AG isolado, você cria usuários, logins, permissões e assim por diante, no nível do AG. Esses objetos são consistentes automaticamente entre réplicas no AG, bem como consistentes entre bancos de dados dentro do AG contido. Essa consistência salva o administrador de ter que fazer essas alterações manualmente.
Alterações do SQL Server 2025
O SQL Server 2025 (17.x) apresenta suporte de grupo de disponibilidade distribuído para grupos de disponibilidade independentes.
Diferenças
Quando você trabalha com AGs contidos, considere algumas diferenças práticas. Essas diferenças incluem a criação de bancos de dados do sistema contidos e forçar a conexão no nível de AG contido em vez de se conectar no nível da instância.
Bancos de dados do sistema independentes
Cada AG independente tem seus próprios master bancos de dados e msdb do sistema, com o nome do grupo de disponibilidade. Por exemplo, no AG MyContainedAGcontido, você tem bancos de dados nomeados MyContainedAG_master e MyContainedAG_msdb. Esses bancos de dados do sistema são propagados automaticamente para novas réplicas e as atualizações são replicadas para esses bancos de dados, assim como qualquer outro banco de dados em um grupo de disponibilidade. Quando você adiciona um objeto como um trabalho de logon ou agente enquanto está conectado ao AG contido, você ainda vê os trabalhos do agente e pode se autenticar usando o logon criado no AG contido quando o AG contido faz failover para outra instância.
Importante
Os AGs contidos são um mecanismo para manter as configurações de ambiente de execução consistentes entre as réplicas de um grupo de disponibilidade. Eles não representam um limite de segurança. Por exemplo, não há nenhum limite que impeça uma conexão com um AG contido de acessar bancos de dados fora do AG.
Os bancos de dados do sistema em um AG independente recém-criado não são cópias da instância em que você executa o CREATE AVAILABILITY GROUP comando. Inicialmente, são modelos vazios sem dados. Imediatamente após a criação, o processo copia as contas de administrador na instância para dentro do AG contido master. Dessa forma, o administrador pode entrar no AG contido e configurar o restante da configuração.
Se você tiver criado usuários locais ou configurações na instância, eles não serão exibidos automaticamente quando você criar os bancos de dados do sistema independentes e eles não ficarão visíveis quando você se conectar ao AG independente. Depois que o banco de dados do usuário ingressar em um AG independente, esses usuários perderão imediatamente o acesso. Você precisa recriá-las manualmente nos bancos de dados do sistema contidos no contexto do AG contido, conectando-se diretamente ao banco de dados ou usando o ponto de extremidade do ouvinte. A exceção a essa regra é que todos os logons na função sysadmin na instância pai são copiados para o novo banco de dados específico do AG master durante a criação do AG contido.
Nota
Como o master banco de dados é separado para cada grupo de disponibilidade contido, as atividades de escopo de servidor executadas no contexto do AG contido só persistem no banco de dados do sistema contido. Essa regra inclui auditoria. Se você auditar a atividade no nível do servidor com a Auditoria do SQL Server, deverá criar as mesmas auditorias de servidor em cada AG contido.
Sincronização inicial de dados
Os bancos de dados de sistema contidos dão suporte apenas ao semear automático como método inicial de sincronização de dados.
No SQL Server 2022 (16.x) e em versões anteriores, os grupos de disponibilidade contidos devem usar a semeadura automática durante a criação. Ao usar a instrução CREATE AVAILABILITY GROUP ou o assistente Novo Grupo de Disponibilidade no SQL Server Management Studio, inclua apenas bancos de dados de usuário que dão suporte à semeadura automática. Para adicionar bancos de dados grandes usando a propagação manual (JOIN ONLY), aguarde até que o AG contido seja criado.
No SQL Server 2025 (17.x), os bancos de dados do sistema contidos sempre usam semeadura automática, mesmo que a instrução CREATE AVAILABILITY GROUP especifique a semeadura manual. Você pode definir o modo de propagação como manual para criar um AG independente e, posteriormente, adicionar bancos de dados de usuário usando métodos de sincronização diferentes da propagação automática.
Restaurar um banco de dados de sistema contido
Para restaurar backups de bancos de dados de sistema contidos, siga as seguintes etapas:
Remover o AG contido.
Restaure os bancos de dados
masteremsdbindependentes na réplica primária original do AG independente.Remova os bancos de dados contidos
masteremsdbdas réplicas secundárias.Na réplica primária, recrie o AG independente com o nome e os nós originais, usando a sintaxe
WITH (CONTAINED, REUSE_SYSTEM_DATABASES)eSEEDING_MODE = AUTOMATIC.
Ao recriar um grupo de disponibilidade contido, não inclua bancos de dados do sistema contidos na instrução CREATE AVAILABILITY GROUP . O SQL Server detecta-os automaticamente quando você especifica REUSE_SYSTEM_DATABASES. No SQL Server 2022 (16.x) e versões anteriores, inclua apenas bancos de dados de usuário pequenos que dão suporte à propagação automática. Adicione bancos de dados grandes separadamente depois que o AG independente for criado, usando JOIN ONLY.
Trabalhos do grupo de disponibilidade contido
Trabalhos que pertencem a um grupo de disponibilidade contido são executados apenas na réplica primária. Eles não são executados em réplicas secundárias.
Conexão (ambiente independente)
É importante distinguir a diferença entre conectar-se à instância e conectar-se ao AG contido. A única maneira de acessar o ambiente do AG contido é conectar-se ao ouvinte de AG contido ou conectar-se a um banco de dados que esteja no AG contido.
"Persist Security Info=False;
User ID=MyUser;Password=*****;
Initial Catalog=MyContainedDatabase;
Server=MyServer;"
Onde MyContainedDatabase está um banco de dados dentro do AG contido com o qual você deseja interagir.
Você deve criar um ouvinte para que o AG contido use efetivamente um AG contido. Se você se conectar a uma das instâncias que hospedam o AG contido em vez de diretamente ao AG contido por meio do ouvinte, você estará no ambiente da instância, e não no AG contido.
Por exemplo, se o grupo de disponibilidade MyContainedAG estiver hospedado no servidor SERVER\MSSQLSERVER e, em vez de se conectar ao listener MyContainedAG_Listener, você se conectar à instância usando SERVER\MSSQLSERVER, estará no ambiente da instância e não no ambiente de MyContainedAG. Você está sujeito ao conteúdo (usuários, permissões, trabalhos e assim por diante) que são encontrados nos bancos de dados do sistema da instância. Para acessar o sumário encontrado nos bancos de dados do sistema contidos do AG contido, conecte-se ao ouvinte do AG contido (por exemplo, MyContainedAG_Listener). Quando você estiver conectado à instância por meio do ouvinte de AG contido, ao interagir com master, você será redirecionado para o banco de dados independente master (por exemplo, MyContainedAG_master).
Roteamento somente leitura e grupos de disponibilidade independentes
Se você configurar o roteamento somente leitura para redirecionar conexões com a intenção de leitura para uma réplica secundária (consulte Configurar o roteamento somente leitura para um grupo de disponibilidade Always On) e quiser se conectar usando um logon criado apenas no AG independente, haverá outras considerações:
- Você deve especificar um banco de dados que faça parte do AG contido na string de conexão.
- O usuário especificado na cadeia de conexão deve ter permissão para acessar os bancos de dados no AG contido.
Por exemplo, na seguinte cadeia de conexão, AdventureWorks é um banco de dados dentro do AG contido que tem MyContainedListener, e MyUser é um usuário definido no AG contido e em nenhuma das instâncias participantes:
"Persist Security Info=False;
User ID=MyUser;Password=*****;
Initial Catalog=AdventureWorks;
Server=MyContainedListener;
ApplicationIntent=ReadOnly"
Este exemplo conecta você ao secundário legível que faz parte da configuração de Roteamento ReadOnly e você está dentro do contexto do AG contido.
Diferenças entre conectar-se à instância e conectar-se ao grupo de disponibilidade contido
- Quando conectados a um AG contido, os usuários veem apenas os bancos de dados no AG contido, além de
tempdb. - No nível da instância, o AG
masteremsdbos nomes contidos são[contained AG]_master, e[contained AG]_msdb. Dentro do AG contido, seus nomes sãomasteremsdb. - A ID do banco de dados para o AG
mastercontido é1de dentro do AG contido, mas outra coisa quando conectada à instância. - Embora os usuários não vejam bancos de dados fora do AG
sys.databasescontido quando conectados em uma conexão ag contida, eles podem acessar esses bancos de dados por nome de três partes ou por meio doUSEcomando. - A configuração do servidor por meio de
sp_configurepode ser lida na conexão do AG contido, mas só pode ser gravada a partir do nível da instância. - A partir das conexões do AG contido, o administrador do sistema pode executar operações no nível da instância, como desligar o SQL Server.
- A maioria das operações no nível do banco de dados, no nível do ponto de extremidade ou no nível do AG só pode ser executada a partir de conexões de instância, não de conexões do AG contido.
Interações com outros recursos
Considere outros fatores ao usar determinados recursos com AGs contidos. No momento, alguns recursos não têm suporte.
Fazer backup
Os procedimentos para fazer backup de bancos de dados em um AG contido são os mesmos que qualquer procedimento de backup de banco de dados de usuário. Essa instrução é verdadeira tanto para os bancos de dados de usuário do AG contidos quanto para os bancos de dados do sistema do AG contidos.
Se você usar um local de backup local, os arquivos de backup serão colocados no servidor que executa o trabalho de backup. Isso significa que seus arquivos de backup podem estar em locais diferentes.
Se você usar um recurso de rede para o local de backup, todos os servidores que hospedam réplicas precisarão ter acesso a esse recurso.
Habilitar a criação ou restauração de banco de dados em sessões de grupo de disponibilidade contidas
Aplica-se a: SQL Server 2025 (17.x) CU 1 e versões posteriores.
No SQL Server 2025 (17.x) Atualização Cumulativa (UC) 1, você pode habilitar a criação e restauração do banco de dados diretamente dentro de uma sessão de grupo de disponibilidade contida, por meio do ouvinte do AG contido. Esse aprimoramento simplifica os fluxos de trabalho para os usuários atribuídos às funções apropriadas, permitindo operações perfeitas em ambientes de AG contidos.
Somente usuários com a função dbcreator podem criar bancos de dados em uma sessão de AG contida. Somente usuários com a função db_owner ou sysadmin podem restaurar bancos de dados.
O exemplo allow_cag_create_db seguir habilita o recurso para sua sessão, usando a chave sp_set_session_contex de contexto de sessão no procedimento armazenado. Para desabilitá-lo, defina @value como 0.
EXECUTE sp_set_session_context
@key = N'allow_cag_create_db',
@value = 1;
Grupos de disponibilidade distribuídos
Um grupo de disponibilidade distribuído é um tipo especial de grupo de disponibilidade que abrange dois grupos de disponibilidade subjacentes. Quando você configura um grupo de disponibilidade distribuído, as alterações que foram feitas no primário global (que é a réplica primária do seu primeiro AG) são replicadas para a réplica primária do seu segundo AG, conhecido como o encaminhador.
A partir do SQL Server 2025 (17.x), você pode configurar um grupo de disponibilidade distribuído entre dois AGs contidos. Como um AG independente depende de bancos de dados do sistema master e msdb independentes, para criar um grupo de disponibilidade distribuído, o segundo AG (encaminhador) deve ter o mesmo banco de dados do sistema AG independente que o primário global.
Se você pretende utilizar um AG contido como encaminhador em um grupo de disponibilidade distribuído, deverá criar o AG contido usando a cláusula AUTOSEEDING_SYSTEM_DATABASES para a opção WITH | CONTAINED da instrução CREATE AVAILABILITY GROUP. A cláusula AUTOSEEDING_SYSTEM_DATABASES orienta o SQL Server a não criar seus próprios bancos de dados de sistema de AG independentes, e, em vez disso, a propagar os bancos de dados de sistema independentes a partir do primário global.
Administrador de recursos
Aplica-se a: SQL Server 2022 (16.x) CU 18 e versões posteriores.
No SQL Server 2022 (16.x) antes da Atualização Cumulativa (CU) 18 e em versões mais antigas do SQL Server, não há suporte para configurar ou usar o governador de recursos em conexões de grupo de disponibilidade contidas.
No SQL Server 2022 (16.x) CU 18 e versões posteriores, se você configurar o Resource Governor em uma conexão de instância, o consumo de recursos em conexões de instância ou conexões de grupos de disponibilidade contidos será controlado conforme o esperado. Se você tentar configurar o administrador de recursos em uma conexão de grupo de disponibilidade contida, receberá um erro.
O administrador de recursos funciona no nível da instância do Mecanismo de Banco de Dados. A configuração do administrador de recursos no nível da instância não se propaga para réplicas de disponibilidade. Você deve configurar o administrador de recursos em cada instância que hospeda uma réplica de disponibilidade.
Dica
Você deve usar a mesma configuração de administrador de recursos para todas as instâncias do Mecanismo de Banco de Dados que hospedam réplicas de disponibilidade para garantir um comportamento consistente à medida que ocorrem failovers de grupo de disponibilidade.
Para obter mais informações, consulte o administrador de recursos e o tutorial: exemplos de configuração do administrador de recursos e práticas recomendadas.
Captura de dados de alterações
A CDC (captura de dados de alteração) é implementada como trabalhos do SQL Agent, portanto, o SQL Agent precisa estar em execução em todas as instâncias com réplicas no AG contido.
Para usar a captura de dados de alteração com um AG contido, conecte-se ao ouvinte do AG quando você configurar o CDC para que os metadados CDC sejam configurados usando os bancos de dados do sistema contidos.
Envio de logs
Você pode configurar o envio de logs se o banco de dados de origem estiver no AG contido. No entanto, não há suporte para um destino de envio de logs em um AG independente. Além disso, você precisa modificar o trabalho de envio de logs depois de configurar o CDC.
Para configurar o envio de logs com um AG independente, siga estas etapas:
- Conecte-se ao ouvinte de AG contido.
- Configure o envio de logs como faria normalmente.
- Depois de configurar o job de envio de logs, altere o job para se conectar ao listener do AG contido antes de fazer um backup.
TDE (Transparent Data Encryption)
Para usar a TDE (transparent Data Encryption) com bancos de dados em um AG independente, instale manualmente a DMK (Chave Mestra de Banco de Dados) no banco de dados master contido no AG contido.
Os bancos de dados que usam a TDE dependem de certificados no banco de dados master para descriptografar a DEK (chave de criptografia do banco de dados). Sem esse certificado, o SQL Server não consegue descriptografar bancos de dados criptografados com TDE nem os deixar online. Em um AG independente, o SQL Server verifica os dois master bancos de dados para o DMK, o master banco de dados da instância e o banco de dados contido master no AG contido para descriptografar o banco de dados. Se ele não conseguir encontrar o certificado em qualquer local, o SQL Server não poderá colocar o banco de dados online.
Para transferir o DMK do banco de dados da instância master para o banco de dados contido master, consulte Mover um banco de dados protegido por TDE para outro SQL Server, dando foco principalmente às partes em que o DMK é transferido do servidor antigo para o novo.
Nota
Criptografar qualquer banco de dados em uma instância do SQL Server também criptografa o banco de dados do tempdb sistema.
Pacotes do SSIS e planos de manutenção
Não há suporte para o uso de pacotes SSIS com grupos de disponibilidade contidos, incluindo planos de manutenção.
Sem suporte
Atualmente, os seguintes recursos do SQL Server não têm suporte em um AG contido:
- Replicação do SQL Server de qualquer tipo (transacional, mesclagem, instantâneo e assim por diante).
- Envio de logs em que o banco de dados de destino está no AG contido. Há suporte para o envio de logs com o banco de dados de origem no AG contido.
Suporte para DDL
No fluxo de trabalho CREATE AVAILABILITY GROUP, há uma cláusula WITH com várias opções:
<with_option_spec> ::=
CONTAINED [REUSE_SYSTEM_DATABASES | AUTOSEEDING_SYSTEM_DATABASES ]
CONTIDO
Essa opção especifica que o AG que você está criando é um AG contido.
REUTILIZAR_BASES_DE_DADOS_DO_SISTEMA
A REUSE_SYSTEM_DATABASES opção só é válida para AGs contidos. Ele especifica que o novo AG deve reutilizar bancos de dados do sistema independente existentes de um AG independente anterior com o mesmo nome. Por exemplo, se você tivesse um AG contido nomeado MyContainedAG e quisesse eliminá-lo e recriá-lo, você poderia usar essa opção para reutilizar o conteúdo dos bancos de dados do sistema contido original. Ao usar essa opção, não especifique os nomes do banco de dados do sistema. O SQL Server os detecta automaticamente.
AUTOSEEDING_SYSTEM_DATABASES
Aplica-se a: SQL Server 2025 (17.x) e versões posteriores.
Se você quiser usar o AG contido como encaminhador em um grupo de disponibilidade distribuído, deverá usar a opção AUTOSEEDING_SYSTEM_DATABASES ao criar o AG contido. Esta opção orienta o SQL Server a não criar seus próprios bancos de dados de sistema de AG independentes, e, em vez disso, a propagar os bancos de dados de sistema independentes a partir do primário global.
Suporte a objetos do sistema para grupos de disponibilidade contidos
Duas exibições do sistema incluem adições relacionadas a grupos de disponibilidade contidos:
- A visualização de gerenciamento dinâmico sys.dm_exec_sessions inclui uma coluna
contained_availability_group_id. - A exibição do catálogo sys.availability_groups inclui a coluna
is_contained.