Compartilhar via

Melhores práticas de vinculação de instância gerenciada: Instância Gerenciada de SQL do Azure

Aplica-se a:Instância Gerenciada de SQL do Azure

Este artigo descreve as práticas recomendadas ao usar o link da Instância Gerenciada para replicar dados entre a Instância Gerenciada de SQL do Azure e as instâncias do SQL Server hospedadas em qualquer lugar, fornecendo replicação de dados quase em tempo real entre as réplicas vinculadas.

Fazer backups do log regularmente

Se o SQL Server for o primário inicial, é importante fazer o primeiro backup de log no SQL Server após a conclusão do posicionamento inicial, quando o banco de dados não estiver mais no estado Restaurando... na Instância Gerenciada de SQL do Azure. Em seguida, faça backups de log de transações do SQL Server regularmente para manter um tamanho de arquivo de log de transações íntegro enquanto o SQL Server estiver na função primária.

O recurso de link replica dados usando a tecnologia de grupos de disponibilidade distribuídos com base em grupos de disponibilidade Always On. A replicação de dados com grupos de disponibilidade distribuídos baseia-se na replicação de registros de logs de transações. Nenhum registro de log de transações pode ser truncado do banco de dados na instância primária do SQL Server até que sejam replicados para o banco de dados na réplica secundária. Se a replicação do registro de log de transações estiver lenta ou bloqueada devido a problemas de conexão de rede, o arquivo de log continuará crescendo na instância primária. A velocidade de crescimento depende da intensidade da carga de trabalho e da velocidade da rede. Se houver interrupção de conexão de rede prolongada e uma carga de trabalho pesada na instância primária, o arquivo de log poderá usar todo o espaço de armazenamento disponível.

Fazer backups de log de transações de forma regular trunca o log de transações e minimiza o risco de ficar sem espaço na Instância do SQL Server primária devido ao crescimento do arquivo de registro. Nenhuma ação extra é necessária quando a Instância Gerenciada SQL é a principal, pois os backups de log já são feitos automaticamente. Fazendo backups de log regularmente no SQL Server primário, você torna seu banco de dados mais resiliente a eventos de crescimento de log não planejados. Considere o agendamento diário de tarefas de backup de log usando um trabalho do SQL Server Agent.

Você pode usar um script Transact-SQL (T-SQL) (Transact-SQL) para fazer backup do arquivo de log, como o exemplo fornecido nesta seção. Substitua os espaços reservados no script de exemplo pelo nome do seu banco de dados, o nome e o caminho do arquivo de backup e sua descrição.

Para fazer backup do seu log de transações, use o seguinte script T-SQL (Transact-SQL) de exemplo no SQL Server:

-- Execute on SQL Server
-- Take log backup
BACKUP LOG [<DatabaseName>]
TO DISK = N'<DiskPathandFileName>'
WITH NOFORMAT, NOINIT,
NAME = N'<Description>', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 1

Use o seguinte comando T-SQL (Transact-SQL) para verificar o espaço em log usado pelo banco de dados no SQL Server:

-- Execute on SQL Server
DBCC SQLPERF(LOGSPACE);

A saída da consulta é semelhante ao exemplo a seguir para o banco de dados de amostra tpcc:

Captura de tela com os resultados do comando mostrando o tamanho do arquivo de log e o espaço usado

Nesse exemplo, o banco de dados usou 76% do log disponível, com um tamanho de arquivo de log absoluto de aproximadamente 27 GB (27,971 MB). Os limites para ação variam com base na sua carga de trabalho. No exemplo anterior, o tamanho do log de transações e a porcentagem de uso do log geralmente são uma indicação de que você deve fazer um backup de log de transações para truncar o arquivo de log e liberar algum espaço, ou você deve fazer backups de log mais frequentes. Também pode ser uma indicação de que o truncamento do log de transações está sendo bloqueado por transações abertas. Para obter mais informações sobre como solucionar problemas de um log de transações no SQL Server, consulte Solucionar problemas de log de transações cheio (Erro 9002 do SQL Server). Para saber mais sobre a solução de problemas de log de transações na Instância Gerenciada de SQL do Azure, confira Solução de problemas de erros de log de transações com a Instância Gerenciada de SQL do Azure.

Observação

Ao participar de uma vinculação, os backups de log de transações automatizados e completos são obtidos da Instância Gerenciada de SQL, independentemente de ser ou não a réplica primária. Os backups diferenciais não são feitos, o que pode levar a tempos de restauração mais longos.

Corresponder capacidade de desempenho entre réplicas

Quando estiver usando o recurso de vinculação, é importante corresponder a capacidade de desempenho entre o SQL Server e a Instância Gerenciada de SQL para evitar problemas de desempenho se a réplica secundária não puder acompanhar a duplicação da réplica primária ou após o failover. A capacidade de desempenho inclui núcleos de CPU (ou vCores no Azure), memória e produtividade de E/S.

Você pode verificar o desempenho da duplicação com o tamanho da fila de restauração na réplica secundária. O tamanho da fila de restauração indica o número de registros de log que estão aguardando para serem refeitos na réplica secundária. Um tamanho de fila de restauração consistentemente alto indica que a réplica secundária não consegue acompanhar a réplica primária. Você pode verificar o tamanho da fila de restauração das seguintes maneiras:

Se o tamanho da fila de restauração for consistentemente alto, considere aumentar os recursos na réplica secundária.

Rotação de certificados

Talvez seja necessário renovar manualmente o certificado usado para proteger o endpoint de espelhamento de banco de dados no SQL Server. Como o certificado usado para proteger o ponto de extremidade de espelhamento de banco de dados na Instância Gerenciada de SQL é gerenciado pelo serviço e renovado automaticamente, você não precisa renová-lo manualmente.

SQL Server

É possível que o certificado usado para proteger o ponto de extremidade de espelhamento de banco de dados no SQL Server expire, o que pode levar à degradação da conexão. Para evitar esse problema, faça a rotação do certificado antes que ele expire.

Use o seguinte comando T-SQL (Transact-SQL) para verificar a data de expiração do certificado atual:

-- Run on SQL Server
USE MASTER
GO
SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK'

Se o certificado estiver prestes a expirar ou já tiver expirado, você poderá criar um novo certificado e alterar o ponto de extremidade existente para substituir o certificado atual.

Depois que o ponto de extremidade estiver configurado para usar o novo certificado, você poderá descartar o certificado expirado.

Instância Gerenciada de SQL

O certificado de ponto de extremidade de espelhamento de banco de dados na Instância Gerenciada de SQL é automaticamente girado periodicamente. Não é necessário monitorar a data de expiração do certificado do endpoint de espelhamento de banco de dados na Instância Gerenciada de SQL, desde que você possa validar com êxito a cadeia de certificação no SQL Server.

Validar a cadeia de certificados no SQL Server

Observação

A cadeia de certificados deve ser validada periodicamente para links existentes ou para solucionar problemas com um link degradado. Ignore esta seção se você estiver configurando um novo link ou tiver concluído recentemente as etapas nas seções Obter a chave pública do certificado da Instância Gerenciada de SQL e importá-la para o SQL Server e importar chaves de autoridade de certificação raiz confiáveis do Azure para o SQL Server.

Problemas com a cadeia de certificados podem prejudicar o link. Para evitar esse problema, valide a cadeia de certificados no SQL Server regularmente.

Os seguintes cenários podem causar problemas com a cadeia de certificados no SQL Server:

  • Rotação agendada de certificados na Instância Gerenciada de SQL.
  • Alterações não intencionais ou acidentais nos certificados no SQL Server, como remover ou alterar o certificado usado para proteger o endpoint (ponto de extremidade) de espelhamento de banco de dados (database mirroring).

Primeiro, determine o certificate_id certificado de ponto de extremidade MI importado substituindo o valor <ManagedInstanceFQDN> e, em seguida, executando a seguinte consulta no SQL Server:

-- Run on SQL Server 
USE master 
SELECT name, subject, certificate_id, start_date, expiry_date 
FROM sys.certificates 
WHERE issuer_name LIKE '%Microsoft Corporation%' AND name = '<ManagedInstanceFQDN>' 
GO

Em seguida, valide o certificado substituindo o valor de <certificate_id> do resultado da consulta anterior e executando a seguinte consulta no SQL Server:

-- Run on SQL Server 
USE master
EXEC sp_validate_certificate_ca_chain <certificate_id> 
GO

Uma resposta Commands completed successfully. Completion time: ... indica que o certificado de ponto de extremidade de MI foi validado com êxito.

Importante

O procedimento sp_validate_certificate_ca_chain armazenado depende dos serviços do sistema operacional host para executar a validação do certificado, o que pode envolver uma verificação de revogação de certificado online. Se o sistema operacional do host não estiver configurado para acessar a Internet, a execução falhará mesmo que a cadeia de certificados seja válida.

Se você encontrar um erro, a mitigação mais confiável será restaurar a cadeia de certificados descartando primeiro todos os certificados criados em seções Obter a chave pública do certificado da Instância Gerenciada de SQL e importá-la para o SQL Server e importar chaves de autoridade de certificação raiz confiáveis do Azure para o SQL Server e, em seguida, reimportá-los novamente.

Adicionar sinalizadores de rastreamento na inicialização

No SQL Server, há dois sinalizadores de rastreamento (-T1800 e -T9567) que, quando adicionados como parâmetros de inicialização, podem otimizar o desempenho da replicação de dados por meio do link. Consulte Habilitar sinalizadores de rastreamento de inicialização para saber mais.

Conteúdo relacionado

Para usar o link:

Para saber mais sobre o link:

Para outros cenários de replicação e migração, considere:

  • Last updated on