O objetivo principal de um Contained Availability Group de bancos de dados de usuários, conhecido como Grupo de Disponibilidade (AG), é garantir alta disponibilidade e replicação de dados.

Em um AG, esses bancos de dados são replicados em vários nós de um cluster. No caso de uma falha de nó ou de um problema de integridade com a cópia primária do SQL Server em um nó, todo o grupo de bancos de dados é transferido perfeitamente para outro nó de réplica dentro do AG.

Isso garante que todos os bancos de dados de usuários permaneçam sincronizados em todas as réplicas, seja no modo síncrono ou assíncrono.

Ao lidar com aplicativos que interagem apenas com um conjunto específico de bancos de dados de usuários, há uma integração perfeita. No entanto, surgem complicações quando esses aplicativos também dependem de objetos como usuários, logins, permissões e trabalhos de agente, que são armazenados nos bancos de dados do sistema master ou msdb.

Para garantir uma funcionalidade suave e previsível, os administradores devem replicar manualmente quaisquer alterações feitas nesses objetos em todas as instâncias de réplica no Grupo de Disponibilidade (AG).

Embora o processo de propagação automática ou manual dos bancos de dados em uma nova instância dentro do AG seja simples, é necessário reconfigurar todas as personalizações do banco de dados do sistema na nova instância para alinhá-las com as outras réplicas.

Expandindo a noção de replicação de um grupo de bancos de dados, o conceito agora abrange segmentos significativos dos bancos de dados master e msdb. Considere como a estrutura operacional para aplicativos que utilizam o AG contido.

A essência reside no fato de que o ambiente AG contido abrange configurações que têm impacto no comportamento da aplicação.

Conseqüentemente, o ambiente AG contido abrange todos os bancos de dados com os quais o aplicativo interage, incluindo protocolos de autenticação (logins, usuários, permissões), trabalhos agendados que deveriam estar em execução e outras definições de configuração que influenciam diretamente o aplicativo.

Ao contrário dos bancos de dados independentes, que empregam um método alternativo para gerenciar contas de usuários, armazenando os dados do usuário no banco de dados, o mecanismo utilizado aqui é distinto. Os bancos de dados contidos apenas duplicam logins e usuários, e a extensão do login ou usuário duplicado é confinada exclusivamente a esse banco de dados específico (bem como às suas réplicas).

Por outro lado, dentro de um AG confinado, os administradores têm a capacidade de estabelecer usuários, logins, permissões e elementos semelhantes no nível do AG. Esses ajustes são sincronizados automaticamente entre as réplicas do AG, bem como mantidos de forma consistente nos bancos de dados do AG confinado. Isso elimina a necessidade de intervenção manual do administrador para implementar essas modificações.

Cada grupo de disponibilidade (AG) contido possui seu próprio conjunto de bancos de dados do sistema, especificamente os bancos de dados master e msdb, que recebem o nome do próprio AG. Para fornecer um exemplo, se tivermos um AG contido chamado “MeuAG”, também teremos bancos de dados chamados “MeuAG_master” e “MeuAG_msdb”.

Esses bancos de dados do sistema são replicados automaticamente para novas réplicas e quaisquer atualizações feitas neles também são replicadas, assim como qualquer outro banco de dados dentro de um AG.

Isso significa que se você adicionar um objeto, como um login ou um trabalho de agente, enquanto estiver conectado ao AG contido, você ainda poderá ver esses trabalhos de agente e autenticar usando o login, mesmo se o AG contido fizer failover para outra instância