Contained Availability Groups no SQL Server 2022/2025— Guia Prático Completo
O que é um Contained Availability Group?
O Contained Availability Group (Contained AG) é uma evolução do Always On Availability Groups introduzida no SQL Server 2022.
A principal diferença é simples:
👉 Um Availability Group tradicional replica apenas os bancos de dados do usuário.
👉 Já o Contained AG replica também componentes importantes da instância SQL Server, como:
- Logins
- Jobs do SQL Server Agent
- Permissões
- Usuários
- Parte do
master - Parte do
msdb
Na prática, isso resolve um dos maiores problemas históricos do Always On:
“O failover funcionou… mas os logins e os jobs não existem no servidor secundário.”
Com Contained AG isso passa a ser sincronizado automaticamente.
O problema do Availability Group tradicional
Imagine dois servidores:
SQLNODE1
SQLNODE2
Você cria um AG chamado:
AG_FINANCEIRO
Os bancos replicam normalmente.
Mas existe um problema clássico:
| Objeto | Replica automaticamente? |
|---|---|
| Banco de dados | ✅ Sim |
| Login | ❌ Não |
| SQL Agent Job | ❌ Não |
| Linked Server | ❌ Não |
| Permissões da instância | ❌ Não |
Resultado:
- Usuários órfãos
- Jobs quebrando após failover
- Necessidade de sincronizar logins manualmente
- Scripts extras de automação
- Mais complexidade operacional
O que muda com Contained AG?
Quando você cria um Contained AG, o SQL Server cria automaticamente bancos internos como:
MeuAG_master
MeuAG_msdb
Exemplo:
FinanceAG_master
FinanceAG_msdb
Esses bancos funcionam como bancos de sistema exclusivos daquele Availability Group.
Agora o AG possui seu próprio ambiente isolado.
Visualizando a arquitetura
Availability Group tradicional
INSTÂNCIA SQL
├── master
├── msdb
├── ERP
└── Financeiro
Somente os bancos do usuário participam da replicação.
Contained Availability Group
Contained AG
├── FinanceAG_master
├── FinanceAG_msdb
├── ERP
└── Financeiro
Agora o AG possui:
✅ Logins próprios
✅ Jobs próprios
✅ Configurações próprias
Tudo encapsulado.
Principais vantagens
1. Failover muito mais limpo
Após o failover:
✅ Logins continuam funcionando
✅ Jobs continuam funcionando
✅ Permissões permanecem válidas
✅ Aplicações reconectam com menos problemas
2. Menos scripts de sincronização
Antes era comum usar:
sp_help_revlogin- Scripts PowerShell
- Automação customizada
- Jobs de sincronização
Agora:
✅ O próprio AG faz isso automaticamente.
3. Ambiente mais portátil
Você consegue mover o AG entre servidores com muito menos dependências da instância SQL.
Isso melhora bastante cenários de:
- Disaster Recovery
- Migrações
- Ambientes híbridos
- Ambientes multi-datacenter
Pré-requisitos
Você precisa de:
- SQL Server 2022 ou superior
- Windows Failover Cluster
- Always On habilitado
- Banco em FULL Recovery Model
Exemplo prático completo
Passo 1 — Criar banco
CREATE DATABASE CAGDB2;
Passo 2 — Fazer backup
ALTER DATABASE CAGDB2 SET RECOVERY FULL;
BACKUP DATABASE CAGDB2 TO DISK = N'C:\backup\CAGDB2.bak' WITH INIT, COMPRESSION;
Passo 3 — Criar o Contained AG
CREATE AVAILABILITY GROUP [CAGDemo2] WITH (CONTAINED) FOR DATABASE [CAGDB2]
REPLICA ON N'DBSRV1' WITH ( ENDPOINT_URL = N'tcp://DBSRV1.companyx.com:5022',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = AUTOMATIC, SEEDING_MODE = AUTOMATIC ),
N'DBSRV2' WITH ( ENDPOINT_URL = N'tcp://DBSRV2.companyx.com:5022', AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = AUTOMATIC, SEEDING_MODE = AUTOMATIC );
O que acontece internamente?
O SQL cria automaticamente:
CAGDemo2_master
CAGDemo2_msdb
Esses bancos também participam da replicação.
Passo 4 — Connect to Secondary Replicas and join the AG
ALTER AVAILABILITY GROUP [CAGDemo2] JOIN;
ALTER AVAILABILITY GROUP [CAGDemo2] GRANT CREATE ANY DATABASE;
Passo 5 – Create Listener. Conect primary instance and run:
ALTER AVAILABILITY GROUP [CAGDemo2]
ADD LISTENER N’CAGDemoListener’
(
WITH IP
(
(N’192.168.1.171′, N’255.255.255.0′)
),
PORT = 1453
);
Check DNS
ping CAGDemoListener
Check Connection in ssms using CAGDemoListener,1453 or sqlcmd in DOS
sqlcmd -S CAGDemoListener,1453 -E -N -C
6. Como criar logins e jobs corretamente
Aqui está um detalhe MUITO importante.
Você NÃO deve conectar diretamente na instância SQL.
Você deve conectar:
✅ Pelo Listener
ou
✅ Por um banco pertencente ao AG
Exemplo correto de conexão
Server=CAGDemoListener,1453 ou
Database=CAGDemo2
Criando login dentro do Contained AG
CREATE LOGIN app_erp
WITH PASSWORD = 'SenhaForte123!';
GO
Esse login será replicado automaticamente entre os nós.
Criando um SQL Agent Job
USE msdb;
GO
EXEC sp_add_job
@job_name = 'Carga_Noturna';
GO
Esse job também será replicado.
Como testar failover
ALTER AVAILABILITY GROUP CAGDemo2 FAILOVER;
GO
Após o failover:
✅ Login continua existindo
✅ Job continua existindo
✅ Banco continua online
Diferença conceitual mais importante
AG tradicional
A instância SQL controla tudo
Contained AG
O próprio AG possui seu ambiente isolado
Como conectar corretamente na aplicação
ERRADO
Server=DBSRV1
Você estará fora do contexto do Contained AG.
CERTO
Server=CAGDemoListener,1453
Database=CAGDemo2
Assim sua aplicação entra no ambiente contido.
Limitações importantes
1. Replication não é suportada
Atualmente não suporta:
- Transactional Replication
- Merge Replication
- Snapshot Replication
2. Algumas ferramentas antigas podem apresentar problemas
A comunidade reporta incompatibilidades com:
- Database Mail
- Ferramentas legadas
- Sistemas de monitoramento antigos
- Procedures antigas
- Algumas automações customizadas
Problema comum: criação de banco via listener
Muita gente descobre isso somente em produção.
Para permitir criação de banco via listener:
EXEC sp_set_session_context
@key = N'allow_cag_create_db',
@value = 1;
GO
Exemplo de cenário real
Antes do Contained AG
Empresa possui:
- ERP
- Jobs automatizados
- Integrações
- Muitos logins
Quando ocorria failover:
❌ Usuários quebravam
❌ Jobs sumiam
❌ Aplicação falhava
❌ Equipe precisava sincronizar manualmente
Depois do Contained AG
Failover automático:
✅ Aplicação reconecta
✅ Logins continuam válidos
✅ Jobs permanecem ativos
✅ Menos intervenção manual
Quando usar Contained AG?
Cenários ideais
✅ Ambientes enterprise
✅ Alta disponibilidade crítica
✅ Muitos logins/jobs
✅ Disaster Recovery automatizado
✅ Ambientes complexos
Quando talvez NÃO valha a pena
❌ Ambientes muito simples
❌ Sistemas legados incompatíveis
❌ Uso intenso de replication
❌ SQL Server anterior ao 2022
Cuidados importantes
1. O Listener praticamente vira obrigatório
Evite conexões diretamente na instância.
2. Monitoramento precisa ser revisado
Ferramentas antigas podem não entender Contained AG corretamente.
3. Testes são obrigatórios
Sempre valide:
- failover
- jobs
- logins
- permissões
- aplicações
- integrações
Antes de colocar em produção.
Novidades do SQL Server 2025
O SQL Server 2025 trouxe suporte para:
✅ Distributed Availability Groups com Contained AG
Isso melhora cenários de replicação entre datacenters.
Arquitetura recomendada
APLICAÇÃO
↓
LISTENER
↓
Contained AG
↓
Réplicas SQL
Nunca conecte aplicações diretamente na instância.
Resumo final
Availability Group tradicional
Replica:
✅ Bancos
Não replica:
❌ Logins
❌ Jobs
❌ Configurações
Contained Availability Group
Replica:
✅ Bancos
✅ Logins
✅ Jobs
✅ Permissões
✅ Parte do master
✅ Parte do msdb
Vale a pena usar?
Minha visão prática
Contained AG provavelmente é o futuro do Always On.
Ele resolve um dos maiores problemas históricos do SQL Server HA/DR:
👉 Dependência excessiva da instância.
Para ambientes enterprise, ele reduz MUITO a complexidade operacional.
Mas ainda exige atenção em:
- aplicações legadas
- monitoramento
- automações antigas
- Database Mail
- ferramentas de terceiros
Referência oficial da Microsoft
Segue Principais Formações:
- Coloque comentário que gostaria de ter acesso aos cursos com desconto.
- AcademiaDBA. Formação Completa para DBA.
Aprenda SQL Server, Oracle, PostgreSQL, MySQL, Data Warehouse, ETL com SSIS/SSAS e Power BI em uma plataforma prática e focada na carreira, criada para ajudar você a se tornar um profissional confiante em banco de dados e dados.
1316 aulas e 412 horas de conteúdo original
Legendas: Portugues
https://formacaodba.academiadba.com/
1.1 DBAcademy. Master Databases.Build a Real Data Career.
Learn SQL Server, Oracle, PostgreSQL, MySQL, Data Warehousing, ETL with SSIS/SSAS, and Power BI in one practical, career-focused platform designed to help you become a confident database and data professional.
1316 class e 412 hours
Subtitles: English, Spain, France
https://dbacademy.academiadba.com/
Bons Estudos
Prof. Msc Sandro Servino
www.academiadba.com
Share this content:



Post Comment