Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
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 saúde do SQL Server no nó que hospeda a cópia primária, o grupo de bases de dados move-se como unidade para outro nó réplica no AG. Todas as bases de dados dos utilizadores mantêm-se sincronizadas em todas as réplicas do AG, seja em modo síncrono ou assíncrono.
Esta arquitetura funciona bem para aplicações que interagem apenas com esse conjunto de bases de dados de utilizador. No entanto, surgem desafios quando as aplicações também dependem de objetos como utilizadores, logins, permissões, trabalhos de agente e outros objetos armazenados numa das bases de dados do sistema (master ou msdb). Para garantir que as aplicações funcionam de forma fluida e previsível, o administrador deve garantir manualmente que qualquer alteração a estes objetos é duplicada em todas as instâncias de réplica no AG. Caso adicione uma nova instância ao AG, pode inicializar automaticamente ou manualmente as bases de dados de forma simples. No entanto, deve reconfigurar todas as personalizações da base de dados do sistema na nova instância para corresponderem à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 afetam a aplicação que delas depende. 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.
Este conceito difere das bases de dados contidas, que utilizam um mecanismo diferente para as contas de utilizador, armazenando a informação do utilizador dentro da própria base 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).
Em contraste, numa AG contida, cria-se utilizadores, logins, permissões, e assim por diante, ao nível da AG. Estes objetos são automaticamente consistentes entre réplicas no AG, bem como consistentes entre bases de dados dentro do AG contido. Esta consistência poupa ao administrador de ter de fazer estas 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
Quando trabalhar com AGs contidos, considere algumas diferenças práticas. Estas diferenças incluem a criação de bases de dados do sistema contidas e a forçação da ligação ao nível do AG contido em vez de se ligar ao nível da 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. Estas bases de dados do sistema são automaticamente semeadas para novas réplicas, e as atualizações replicam-se para estas bases de dados tal como qualquer outra base de dados num grupo de disponibilidade. Quando adiciona um objeto, como um login ou um trabalho do agente, enquanto está ligado ao AG contido, continua a ver os trabalhos do agente e pode autenticar-se usando o login criado no AG contido quando o AG contido realiza um failover para outra instância.
Importante
Os agrupamentos de disponibilidade contidos são um mecanismo para assegurar consistência nas configurações do ambiente de execução nas réplicas de um grupo de disponibilidade. Eles não representam um limite de segurança. Por exemplo, não existe nenhum limite que impeça uma ligação a um AG restrito de aceder a bases de dados fora do AG.
As bases de dados do sistema num AG contido recém-criado não são cópias da instância onde executas o CREATE AVAILABILITY GROUP comando. Inicialmente, são modelos vazios sem qualquer informação. Imediatamente após a criação, o processo copia as contas de administrador da instância que cria o AG contido para dentro do AG contido master. Desta forma, o administrador pode iniciar sessão no AG contido e configurar o resto 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. Assim que a base de dados de utilizadores se junta a um AG contido, estes utilizadores perdem imediatamente o acesso. 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 esta regra é que todos os logins no papel de sysadmin na instância principal são copiados para a nova base de dados específica master do AG durante a criação do AG contido.
Observação
Como a master base de dados é separada para cada grupo de disponibilidade contido, as actividades de nível de servidor realizadas no contexto do grupo de disponibilidade contido só persistem na base de dados do sistema contida. Esta regra inclui auditorias. Se auditas a atividade ao nível do servidor com a Auditoria do SQL Server, deves criar as mesmas auditorias de servidor em cada Grupo de Disponibilidade contido.
Sincronização inicial de dados
As bases de dados de sistema contidas suportam apenas a semeadura automática como método 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 instrução CREATE AVAILABILITY GROUP ou o assistente New Availability Group no SQL Server Management Studio, inclua apenas as bases de dados dos utilizadores que suportem inicialização automática. Para adicionar grandes bases de dados usando seed manual (JOIN ONLY), espere 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. Pode definir o modo de seeding como manual para criar um AG contido e, posteriormente, adicionar bases de dados do utilizador, utilizando métodos de sincronização diferentes do seeding automático.
Restaurar um banco de dados do sistema contido
Para restaurar backups de bancos de dados contidos do sistema, execute estas etapas:
Solte o AG contido.
Restaure os bancos de dados contidos
masteremsdbna réplica primária original do AG contido.Remover as bases de dados
masteremsdbdas réplicas secundárias.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)eSEEDING_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 deteta-os automaticamente quando especifica REUSE_SYSTEM_DATABASES. 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. Não funcionam 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 é uma base de dados dentro do AG contido com a qual queres interagir.
Deve criar um listener para o AG contido para que ele possa ser usado de forma eficaz. 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. Estás sujeito ao conteúdo (utilizadores, permissões, trabalhos, etc.) que se encontram nas bases 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 encaminhamento de leitura exclusiva para redirecionar ligações destinadas à leitura para uma réplica secundária (veja Configurar o encaminhamento de leitura exclusiva para um grupo de disponibilidade Always On) e quiser ligar usando um login criado exclusivamente no AG contido, existem considerações adicionais a ter em conta:
- Deve especificar uma base de dados que faça parte do AG contido na cadeia de ligaçã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 cadeia de ligação seguinte, AdventureWorks é uma base de dados dentro do AG contido com MyContainedListener, e MyUser é um utilizador definido no AG contido e não em nenhuma das instâncias participantes:
"Persist Security Info=False;
User ID=MyUser;Password=*****;
Initial Catalog=AdventureWorks;
Server=MyContainedListener;
ApplicationIntent=ReadOnly"
Este exemplo liga-o ao secundário legível que faz parte da configuração de Roteamento Só de Leitura, e 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 só veem bancos de dados no AG contido e
tempdb. - Ao nível da instância, os nomes dos AG contidos
masteremsdbsão[contained AG]_mastere[contained AG]_msdb. Dentro do AG contido, seus nomes sãomasteremsdb. - O ID do banco de dados para o AG contido
masteré1quando 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.databasesquando conectados em uma conexão AG contida, eles podem acessar esses bancos de dados por nome de três partes ou por meio do comandoUSE. - A configuração do servidor através do
sp_configurepode 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
Considere outros fatores ao usar certas funcionalidades com AGs contidos. Algumas funcionalidades estão atualmente sem suporte.
Fazer uma cópia de segurança
Os procedimentos para fazer backup de bases de dados numa AG contida são os mesmos de qualquer procedimento de backup de base de dados de utilizador. Esta afirmação é verdadeira tanto para as bases de dados AG de utilizadores como para as bases de dados AG de sistema.
Se usares um local de backup local, os ficheiros de backup são colocados no servidor que executa o trabalho de backup. Isto significa que os teus ficheiros de backup podem estar em locais diferentes.
Se usares um recurso de rede como local de backup, todos os servidores que alojam réplicas precisam de acesso a esse recurso.
Permitir a criação ou restauração de bases 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) Cumulative Update (CU) 1, pode ativar a criação e restauração da base de dados diretamente dentro de uma sessão de grupo de disponibilidade contida, através do listener AG contido. Esta melhoria simplifica os fluxos de trabalho para os utilizadores atribuídos às funções apropriadas, permitindo operações fluidas dentro de ambientes AG contidos.
Apenas utilizadores com o papel dbcreator podem criar bases de dados numa sessão AG contida. Só utilizadores com o papel de db_owner ou administrador de sistemas podem restaurar bases de dados.
O exemplo seguinte ativa a funcionalidade para a sua sessão, usando a chave allow_cag_create_db de contexto da sessão no sp_set_session_contex procedimento armazenado. Para o desativar, defina @value para 0.
EXECUTE sp_set_session_context
@key = N'allow_cag_create_db',
@value = 1;
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
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, configurar ou usar o governador de recursos em conexões de grupos de disponibilidade contidos não é suportado.
No SQL Server 2022 (16.x) CU 18 e versões posteriores, se configurar o governador de recursos numa ligação de instância, o consumo de recursos em ligações de instância ou em ligações de grupos de disponibilidade contidos é gerido 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 disponíveis. Você deve configurar o administrador de recursos em cada instância que hospeda uma réplica de disponibilidade.
Sugestão
Deve usar a mesma configuração de governador de recursos para todas as instâncias do Motor de Base de Dados que alojam réplicas de disponibilidade, de modo a garantir um comportamento consistente à medida que ocorrem failovers de grupos de disponibilidade.
Para mais informações, consulte Governador de Recursos e Tutorial: Exemplos de configuração de governadores de recursos e melhores práticas.
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
Podes configurar o envio de registos de transações, se a base de dados de origem estiver no Grupo de Disponibilidade contido. No entanto, um destino de envio de logs não é suportado num AG contido. Além disso, precisas de modificar o trabalho de envio de registos depois de configurares o CDC.
Para configurar o envio de logs com um AG contido, siga estas etapas:
- Conecte-se ao ouvinte AG contido.
- Configure envio de logs como faria normalmente.
- Depois de configurar o trabalho de envio de logs, altere o trabalho para se ligar 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 encontrar o certificado em nenhum dos locais, o SQL Server não consegue colocar a base de dados online.
Para transferir o DMK da base de dados master da instância para a base de dados contida master, consulte Mover uma base de dados protegida por TDE para um outro SQL Server, com especial atenção às seções que tratam da transferência do DMK do servidor antigo para o novo.
Observação
A criptografia de qualquer banco de dados em uma instância do SQL Server também criptografa o banco de dados do tempdb sistema.
Pacotes e planos de manutenção do SSIS
O uso de pacotes SSIS, incluindo planos de manutenção, não é suportado por 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.
Suporte DDL
No fluxo de trabalho do CREATE AVAILABILITY GROUP, existe uma cláusula WITH com várias opções:
<with_option_spec> ::=
CONTAINED [REUSE_SYSTEM_DATABASES | AUTOSEEDING_SYSTEM_DATABASES ]
CONTIDO
Esta opção especifica que o AG que estás a criar é um AG contido.
REUTILIZAR_BANCOS_DE_DADOS_DO_SISTEMA
A REUSE_SYSTEM_DATABASES opção só é válida para Grupos de Disponibilidade (AGs) contidos. Especifica que o novo AG deve reutilizar as bases de dados do sistema de contenção de um AG anteriormente contido com o mesmo nome. Por exemplo, se tivesse um AG contido chamado MyContainedAG, e quisesse eliminá-lo e recriá-lo, poderia usar esta opção para reutilizar o conteúdo das bases de dados do sistema contido originais. Quando usar esta opção, não especifique nomes de bases 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.
Se quiser usar o seu AG contido como encaminhador num grupo de disponibilidade distribuída, deve usar a AUTOSEEDING_SYSTEM_DATABASES opção 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.
Suporte a objetos do sistema para grupos de disponibilidade contida
Duas vistas de sistema incluem adições relacionadas com grupos de disponibilidade contidos:
- A sys.dm_exec_sessions vista de gestão dinâmica inclui uma
contained_availability_group_idcoluna. - A vista de catálogo sys.availability_groups inclui a coluna
is_contained.