Compartilhar via

Melhores práticas com o recurso de link para a Instância Gerenciada de SQL do Azure

  • Artigo

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

Saiba mais sobre práticas recomendadas para o uso do recurso de link para Instância Gerenciada de SQL do Azure. O recurso de link para uma Instância Gerenciada de SQL do Azure conecta seus Servidores SQL hospedados em qualquer lugar à Instância Gerenciada de SQL, fornecendo replicação de dados quase em tempo real para a nuvem.

Observação

Algumas funcionalidades do link estão em disponibilidade geral, enquanto outras estão atualmente em versão prévia. Examine os pré-requisitos para saber mais.

Fazer backups do log regularmente

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.

Para minimizar o risco de ficar sem espaço na instância primária do SQL Server devido ao crescimento do arquivo de log, certifique-se de fazer backups de log do banco de dados regularmente no SQL Server quando ele for o primário. 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. O primeiro backup de log do banco de dados deve ser feito somente após a conclusão da propagação inicial para a Instância Gerenciada de SQL (ou seja, a réplica do banco de dados na Instância Gerenciada de SQL não está mais no estado “Restaurando”). Considere o agendamento de tarefas de backup diário do 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.

Rotação de certificados

É possível que o certificado usado para proteger o ponto de extremidade de espelhamento de banco de dados expire, o que pode causar a degradação do link. 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.

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