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 houver 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 será movido como uma unidade para outro nó de réplica no AG. Todos os bancos de dados de usuário permanecem em sincronia em todas as réplicas do AG, em modo síncrono ou assíncrono.
Isso funciona bem para aplicativos que interagem apenas com esse conjunto de bancos de dados de usuário, mas há desafios quando os aplicativos também dependem de objetos como usuários, logons, permissões, trabalhos de agente etc., que são armazenados em um dos bancos de dados do sistema (master ou msdb). Para que os aplicativos funcionem de maneira 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 uma nova instância for trazida para o AG, os bancos de dados poderão ser propagados de maneira automática ou manual em um processo simples, mas todas as personalizações do banco de dados do sistema deverão ser reconfiguradas 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 do AG contido inclua configurações que afetariam 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.
Isso é diferente 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).
Em contrapartida, em um AG contido, você pode criar usuários, logins, permissões e assim por diante no nível do AG, e eles são automaticamente consistentes entre as réplicas no AG, bem como consistentes entre os bancos de dados dentro desse AG contido. Com isso, o administrador não precisa 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
Há algumas diferenças práticas a serem consideradas ao trabalhar com AGs contidos, como a criação de bancos de dados do sistema contidos e a imposição da conexão no nível do AG contido, em vez de conectar-se 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 automaticamente replicados para novas réplicas, e as atualizações são aplicadas a esses bancos de dados, assim como a qualquer outro banco de dados em um grupo de disponibilidade. Isso significa que, quando você adiciona um objeto como um logon ou um trabalho de agente enquanto está conectado ao AG contido, quando o AG contido faz failover para outra instância, conectando-se ao AG contido, você ainda vê os trabalhos do agente e pode se autenticar usando o logon criado no AG contido.
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. Não há nenhum limite que mantenha uma conexão com um AG independente de acessar bancos de dados fora do AG, por exemplo.
Os bancos de dados do sistema em um AG independente recém-criado não são cópias da instância em que o CREATE AVAILABILITY GROUP comando é executado. Eles são modelos inicialmente vazios e sem dados. Imediatamente após a criação, as contas de administrador na instância que cria o AG contido são copiadas para o AG contido master. Dessa forma, o administrador pode fazer login 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. Uma vez que o banco de dados de usuários estiver associado a um AG independente, ele se tornará imediatamente inacessível para esses usuários. 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 isso é que todos os logins na função sysadmin da instância pai são copiados para o novo banco de dados master específico do AG durante a criação do AG independente.
Nota
Como o banco de dados master é separado para cada grupo de disponibilidade contido, as atividades de escopo de servidor executadas no contexto do grupo de disponibilidade contido são mantidas apenas no banco de dados do sistema contido. Isso 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 do sistema contidos dão suporte apenas à propagação automática como maneira 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), espere até que o AG independente 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 o banco de dados
masteremsdbindependentes das 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 REUSE_SYSTEM_DATABASES é especificado. 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;"
Em que MyContainedDatabase está um banco de dados dentro do AG contido com o qual você deseja interagir.
Isso significa que você deve criar um ouvinte para o AG contido para usar 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. Isso significa que você estará sujeito ao conteúdo (usuários, permissões, trabalhos etc.) dos 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 grupode disponibilidade Always On) e quiser se conectar usando um logon criado apenas no AG contido, há algumas considerações adicionais:
- Você deve especificar um banco de dados que faça parte do AG contido na cadeia 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 cadeia de conexão a seguir, em que AdventureWorks é um banco de dados no AG contido que tem MyContainedListener e em que 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"
Essa cadeia de conexão conectaria você à réplica secundária para leitura que faz parte da configuração de Roteamento Somente Leitura, e você estaria no 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
Há considerações adicionais ao usar determinados recursos com AGs independentes e há alguns recursos que atualmente não têm suporte.
Fazer backup
Os procedimentos para fazer backup de bancos de dados em um grupo de disponibilidade independente são iguais a todos os procedimentos de backup do banco de dados do usuário. Isso é verdadeiro para os bancos de dados de usuário do grupo de disponibilidade contido e os bancos de dados do sistema do grupo de disponibilidade contido.
Se a localização do backup for 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 o local de backup estiver em um recurso de rede, todos os servidores que hospedam réplicas precisarão ter acesso a esse recurso.
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
No SQL Server 2022 (16.x) antes da Atualização Cumulativa 18 e em versões mais antigas do SQL Server, não há suporte para configurar ou usar o administrador de recursos em conexões de grupo de disponibilidade contidas.
A partir da Atualização Cumulativa 18 do SQL Server 2022 (16.x), se você configurar o Resource Governor em uma conexão de instância, o consumo de recursos em conexões de instância ou em conexões de grupos de disponibilidade contidos será gerenciado conforme 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
Recomendamos que você use 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 Governador de Recursos e exemplos de configuração e práticas recomendadas do Governador de Recursos.
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
O envio de logs poderá ser configurado 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, há uma etapa extra para modificar a tarefa de envio de logs após a configuração da 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 que o trabalho de envio de logs for configurado, altere o trabalho para se conectar ao ouvinte de AG independente 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 localizar o certificado em nenhum dos locais, o SQL Server não conseguirá fazer com que o banco de dados fique online.
Para transferir a DMK do banco de dados master da instância para o banco de dados independente master, confira Mover um banco de dados protegido por TDE para outro SQL Server, focando principalmente as partes em que a DMK é transferida 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 SSIS e planos de manutenção
O uso de pacotes SSIS, incluindo planos de manutenção, não é suportado com grupos de disponibilidade contidos.
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.
alterações DDL
As únicas alterações de DDL estão no fluxo de trabalho CREATE AVAILABILITY GROUP. Há uma WITH cláusula com duas opções:
<with_option_spec> ::=
CONTAINED [REUSE_SYSTEM_DATABASES | AUTOSEEDING_SYSTEM_DATABASES ]
CONTIDO
Isso especifica que o AG que está sendo criado deve ser um AG independente.
REUTILIZAR_BASES_DE_DADOS_DO_SISTEMA
A REUSE_SYSTEM_DATABASES opção só é válida para AGs independentes e especifica que o AG recém-criado deve reutilizar bancos de dados do sistema independente existentes para um AG independente anterior com o mesmo nome. Por exemplo, se você tiver um grupo de disponibilidade contido com o nome MyContainedAG e quiser removê-lo e recriá-lo, poderá usar essa opção para reutilizar o conteúdo dos bancos de dados do sistema contidos originais. 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 posterior
Se você pretende 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.
Alterações de DMV
Há duas adições a DMVs relacionadas a AGs independentes:
- O DMV
sys.dm_exec_sessionstem uma coluna adicionada:contained_availability_group_id - A exibição de catálogo
sys.availability_groupstem a coluna adicionada:is_contained