O que é um grupo de disponibilidade contido?

Aplica-se a: SQL Server 2022 (16.x)

Um grupo de disponibilidade contido é um grupo de disponibilidade Always On (AG) que suporta:

• gerenciando objetos de metadados (usuários, logons, permissões, trabalhos do SQL Agent e assim por diante) no nível AG, além do nível da instância.

• bases de dados especializadas contidas em sistemas dentro da AG.

Este artigo detalha as semelhanças, diferenças e funcionalidades dos AGs confinados.

Visão geral

Os AGs geralmente consistem em um ou mais bancos de dados de usuários destinados a operar como um grupo coordenado e que são replicados em algum número de 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 é movido como uma unidade para outro nó de réplica no AG. Todos os bancos de dados de usuários são mantidos sincronizados em todas as réplicas do AG, no modo síncrono ou assíncrono.

Isso funciona bem para aplicativos que interagem apenas com esse conjunto de bancos de dados de usuários, mas há desafios quando os aplicativos também dependem de objetos como usuários, logins, 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 forma suave e previsível, o administrador deve manualmente garantir 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 automática ou manualmente 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.

As AGs contidas alargam o conceito dos grupos de bases de dados que estão a ser replicadas para incluir partes relevantes das bases de dados master e msdb. Pense nisso como o contexto de execução para aplicativos que usam o AG contido. A ideia é que o ambiente AG contido inclua configurações que afetariam o aplicativo que depende delas. Como tal, o ambiente AG contido diz respeito a todos os bancos de dados com os quais o aplicativo interage, a autenticação que ele usa (logins, usuários, permissões), quaisquer trabalhos agendados que ele espera estar executando e outras definições de configuração que afetam o aplicativo.

Isso é diferente dos bancos de dados contidos, que usam um mecanismo diferente para as contas de usuário, armazenando as informações do usuário dentro do próprio banco de dados. Os bancos de dados contidos apenas replicam logons e usuários, e o escopo do login ou usuário replicado é limitado a esse único banco de dados (e suas réplicas).

Por outro lado, num AG contido, é possível criar usuários, logins, permissões e assim por diante, ao nível AG, e eles são automaticamente consistentes entre réplicas no AG, assim como consistentes entre bases de dados dentro desse AG contido. Isso evita que o administrador tenha que fazer essas alterações manualmente.

Alterações do SQL Server 2025

O SQL Server 2025 (17.x) introduz suporte a grupos de disponibilidade distribuídos para grupos de disponibilidade contidos.

Diferenças

Há algumas diferenças práticas a considerar ao trabalhar com Grupos de Disponibilidade contidos, tais como a criação de bases de dados de sistema contidas e forçar a conexão ao nível do Grupo de Disponibilidade contido, em vez de se conectar ao nível de instância.

Bases de dados do sistema contidas

Cada AG contido tem os seus próprios bancos de dados de sistema master e msdb, denominados após o nome do grupo de disponibilidade. Por exemplo, no AG MyContainedAGcontido, tem bancos de dados denominados MyContainedAG_master e MyContainedAG_msdb. Esses bancos de dados do sistema são automaticamente propagados para novas réplicas e as atualizações são replicadas para esses bancos de dados como qualquer outro banco de dados em um grupo de disponibilidade. Isso significa que, quando se adiciona um objeto, como um login ou uma tarefa do agente, enquanto está conectado ao AG contido, e este faz failover para outra instância, ao conectar-se novamente ao AG contido, ainda é possível ver as tarefas do agente e autenticar-se usando o login criado no AG contido.

Os bancos de dados do sistema num Grupo de Disponibilidade contido recém-criado não são cópias da instância onde o comando CREATE AVAILABILITY GROUP é executado. Inicialmente, são modelos vazios sem quaisquer 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ê criar usuários ou configurações locais em sua instância, eles não aparecerão automaticamente quando você criar os bancos de dados do sistema contidos e não ficarão visíveis quando você se conectar ao AG contido. Uma vez que o banco de dados de usuários tenha sido unido a um AG contido, ele se tornará imediatamente inacessível para esses usuários. Você precisa recriá-los manualmente nos bancos de dados do sistema contidos dentro do contexto do AG contido, conectando-se diretamente ao banco de dados ou usando o endpoint do listener. A exceção a isso é que todos os logins no papel de sysadmin na instância principal são copiados na nova base de dados específica master do AG durante a criação de um AG contido.

Sincronização inicial de dados

Os bancos de dados do sistema contidos suportam apenas a propagação automática como forma inicial de sincronização de dados.

No SQL Server 2022 (16.x) e versões anteriores, os grupos de disponibilidade contidos devem usar a sementeira automática durante a criação. Ao usar a CREATE AVAILABILITY GROUP instrução ou o assistente para Novo Grupo de Disponibilidade no SQL Server Management Studio, inclua apenas bancos de dados de usuários que ofereçam suporte à propagação 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), as bases de dados do sistema contidas usam sempre replicação automática, ainda que a CREATE AVAILABILITY GROUP declaração especifique replicação manual. Você pode definir o modo de propagação como manual para criar um AG contido 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 do sistema contido

Para restaurar backups de bancos de dados contidos do sistema, execute estas etapas:

1. Solte o AG contido.

2. Restaure os bancos de dados contidos master e msdb na réplica primária original do AG contido.

3. Remova as bases de dados contidas nas réplicas secundárias master e msdb.

4. Na réplica primária, recrie o AG contido utilizando o nome e os nós originais, com a sintaxe WITH (CONTAINED, REUSE_SYSTEM_DATABASES) e SEEDING_MODE = AUTOMATIC.

Ao recriar um grupo de disponibilidade contido, não inclua bancos de dados contidos do sistema na CREATE AVAILABILITY GROUP instrução. O SQL Server os deteta automaticamente quando REUSE_SYSTEM_DATABASES é especificado. No SQL Server 2022 (16.x) e versões anteriores, inclua apenas bancos de dados de usuários pequenos que ofereçam suporte à propagação automática. Adicione bancos de dados grandes separadamente depois que o AG contido for criado, usando JOIN ONLY.

Trabalhos de grupos de disponibilidade contida

Os 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.

Conectar (ambiente fechado)

É importante distinguir a diferença entre conectar-se à instância e conectar-se ao AG contido. A única maneira de aceder ao ambiente do AG contido é conectar-se ao listener do AG contido ou conectar-se a uma base de dados que está no AG contido.

"Persist Security Info=False;
User ID=MyUser;Password=*****;
Initial Catalog=MyContainedDatabase;
Server=MyServer;"

Onde MyContainedDatabase é um banco de dados dentro do AG contido com o qual você deseja interagir.

Isso significa que é necessário criar um ouvinte para o AG contido, a fim de utilizar eficazmente um AG contido. Se se ligar a uma das instâncias que hospedam o AG contido em vez de diretamente ao AG contido através do 'listener', estará no ambiente da instância e não no AG contido.

Por exemplo, se o grupo de disponibilidade MyContainedAG está hospedado no servidor SERVER\MSSQLSERVERe, em vez de se conectar ao listener MyContainedAG_Listener, se conectar à instância usando SERVER\MSSQLSERVER, estará no ambiente da instância e não no ambiente de MyContainedAG. Isso significa que você está sujeito aos conteúdos (usuários, permissões, trabalhos, etc.) encontrados nos bancos de dados do sistema da instância. Para aceder ao conteúdo encontrado nas bases de dados do sistema de um AG contido, ligue-se ao listener do AG contido (por exemplo,MyContainedAG_Listener). Quando o utilizador está conectado à instância através do agente AG contido e interage com master, é redirecionado para o banco de dados master contido (por exemplo, MyContainedAG_master).

Roteamento de só leitura e grupos de disponibilidade contidos

Se configurar o roteamento de leitura apenas para redirecionar conexões com intenção de leitura para uma réplica secundária (consulte Configurar o roteamento de leitura apenas para um grupo de disponibilidade Always On) e quiser conectar-se usando um login criado apenas no próprio AG, há algumas considerações adicionais:

• Você deve especificar um banco de dados que faça parte do AG incluído na string de conexão.
• O utilizador especificado na cadeia de conexão deve ter permissão para acessar os bancos de dados nos AG contidos.

Por exemplo, na seguinte cadeia de ligação, onde AdventureWorks é uma base de dados dentro do AG contido que tem MyContainedListenere onde MyUser é um utilizador 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ê ao secundário legível que faz parte da configuração de Roteamento Somente Leitura e você estaria 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 só veem bancos de dados no AG contido e tempdb.
• Ao nível da instância, os nomes dos AG contidos master e msdb são [contained AG]_mastere [contained AG]_msdb. Dentro do AG contido, seus nomes são master e msdb.
• O ID do banco de dados para o AG contido master é 1 quando visto de dentro do próprio AG contido, mas algo diferente ao se conectar à instância.
• Embora os usuários não vejam bancos de dados fora do AG contido em sys.databases quando conectados em uma conexão AG contida, eles podem acessar esses bancos de dados por nome de três partes ou por meio do comando USE.
• A configuração do servidor através do sp_configure pode ser lida a partir da conexão AG contida, mas só pode ser gravada a partir do nível da instância.
• A partir de conexões AG contidas, o sysadmin é capaz de executar operações no nível da instância, como desligar o SQL Server.
• A maioria das operações ao nível de banco de dados, ponto de extremidade ou nível AG só pode ser executada a partir de conexões de instância, e não de conexões AG contidas.

Interações com outros recursos

Há considerações adicionais ao usar certas funcionalidades com AGs contidos, e há algumas funcionalidades que atualmente não são suportadas.

Fazer uma cópia de segurança

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. Isso é verdade tanto para os bancos de dados de usuários AG contidos quanto para os bancos de dados contidos do sistema AG.

Se o local de 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 acessar esse recurso.

Grupos de disponibilidade distribuídos

Um grupo de disponibilidade distribuída é um tipo especial de grupo de disponibilidade que abrange dois grupos de disponibilidade subjacentes. Quando se configura um grupo de disponibilidade distribuído, as alterações feitas no primário global (que é a réplica primária do primeiro AG) são replicadas para a réplica primária do segundo AG, conhecido como reenviador.

A partir do SQL Server 2025 (17.x), pode configurar um grupo de disponibilidade distribuído entre dois AGs contidos. Como um AG contido depende de bancos de dados contidos master e msdb do sistema, para criar um grupo de disponibilidade distribuída, o segundo AG (encaminhador) deve ter o mesmo banco de dados do sistema AG contido que o primário global.

Caso pretenda usar um AG contido como o remetente em um grupo de disponibilidade distribuído, deve-se criar o AG contido utilizando a cláusula AUTOSEEDING_SYSTEM_DATABASES para a opção WITH | CONTAINED da instrução CREATE AVAILABILITY GROUP. A cláusula AUTOSEEDING_SYSTEM_DATABASES instrui o SQL Server a não criar os bancos de dados contidos do sistema AG por conta própria e, em vez disso, a provisionar esses bancos de dados 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 administrador de recursos em uma conexão de instância, o consumo de recursos em conexões de instância ou conexões de grupo de disponibilidade contidas será regido 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 disponíveis. Você deve configurar o administrador de recursos em cada instância que hospeda uma réplica de disponibilidade.

Para obter mais informações, consulte Governador de Recursos e Exemplos de configuração e práticas recomendadas do Governador de Recursos.

Alterar a captura de dados

A captura de dados de alteração (CDC) é implementada como tarefas do SQL Agent, portanto, o SQL Agent precisa estar em execução em todas as instâncias com réplicas na AG contida.

Para usar a captura de dados de alteração com um AG contido, conecte-se ao listener do AG ao configurar o CDC, para que os metadados do CDC sejam configurados usando os bancos de dados do sistema contidos.

Envio de logs

O envio de logs pode ser configurado se o banco de dados de origem estiver no AG contido. No entanto, um destino de envio de logs não é suportado num AG contido. Além disso, há uma etapa extra para modificar o trabalho de envio de logs após a configuração do CDC.

Para configurar o envio de logs com um AG contido, siga estas etapas:

1. Conecte-se ao ouvinte AG contido.
2. Configure envio de logs como faria normalmente.
3. Depois que o trabalho de envio de logs for configurado, altere-o para se conectar ao ouvinte AG contido antes de fazer um backup.

Criptografia de dados transparente (TDE)

Para usar a criptografia de dados transparente (TDE) com bases de dados num AG contido, instale manualmente a chave mestra do banco de dados (DMK) na base de dados contida master dentro do AG contido.

Os bancos de dados que usam TDE dependem de certificados no banco de dados master para descriptografar a DEK (Chave de Criptografia de Banco de Dados). Sem esse certificado, o SQL Server não pode descriptografar bancos de dados criptografados com TDE ou colocá-los online. Em um AG contido, o SQL Server verifica os bancos de dados master para o DMK, o banco de dados master para a instância e o banco de dados master contido dentro do AG contido para descriptografar o banco de dados. Se não conseguir localizar o certificado em nenhum dos locais, o SQL Server não conseguirá colocar o banco de dados online.

Para transferir o DMK do banco de dados master da instância para o banco de dados master contido, consulte Mover um banco de dados protegido por TDE para outro SQL Server, concentrando-se principalmente nas partes em que o DMK é transferido do servidor antigo para o novo.

Pacotes SSIS &, planos de manutenção

O uso de pacotes SSIS, incluindo planos de manutenção, não é suportado com grupos de disponibilidade contidos.

Não suportado

Atualmente, os seguintes recursos do SQL Server não são suportados com um AG contido:

• Replicação do SQL Server de qualquer tipo (transacional, fusão, instantâneo, etc.).
• Envio de logs onde o banco de dados de destino está no AG contido. O envio de logs com o banco de dados de origem no AG contido é suportado.

Alterações de DDL

As únicas alterações de DDL estão no fluxo de trabalho CREATE AVAILABILITY GROUP . Existe uma WITH cláusula com duas opções:

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

CONTIDO

Isto especifica que a AG que está a ser criada deve ser uma AG contida.

REUTILIZAR_BANCOS_DE_DADOS_DO_SISTEMA

A opção REUSE_SYSTEM_DATABASES só é válida para AGs contidas e especifica que a AG recém-criada deve reutilizar as bases de dados de sistema contidas existentes de uma AG contida anterior que tinha o mesmo nome. Por exemplo, se tivesses um AG contido com o nome MyContainedAGe quisesses removê-lo e recriá-lo, poderias usar esta opção para reutilizar o conteúdo dos bancos de dados originalmente contidos no sistema. Ao usar essa opção, não especifique nomes de bancos de dados do sistema. O SQL Server os deteta automaticamente.

SISTEMAS_DE_AUTOSEMENTEAMENTO_BASES_DE_DADOS

Aplica-se a: SQL Server 2025 (17.x) e versões posteriores

Caso pretenda usar o seu AG contido como encaminhador em um grupo de disponibilidade distribuída, deve utilizar a opção AUTOSEEDING_SYSTEM_DATABASES ao criar o AG contido. Esta opção instrui o SQL Server a ignorar a criação das suas próprias bases de dados de sistema AG contidas e, em vez disso, provisionar as bases de dados de sistema AG contidas a partir do primário global.

Alterações no Departamento de Veículos Motorizados

Existem duas novidades nos DMVs relacionadas aos grupos de disponibilidade contidos:

• O DMV sys.dm_exec_sessions teve uma coluna adicionada: contained_availability_group_id
• A visualização do catálogo sys.availability_groups tem a coluna adicionada: is_contained

Conteúdo relacionado

• CRIAR GRUPO DE DISPONIBILIDADE (Transact-SQL)