Um dos principais benefícios das ofertas de Plataforma como Serviço (PaaS) hospedadas pelo Microsoft Azure é a minimização considerável da sobrecarga de gerenciamento. Esse princípio também se aplica ao Banco de Dados do Azure SQL, que elimina a necessidade de administrar e manter o hardware subjacente, o sistema operacional e a plataforma de gerenciamento de banco de dados. No entanto, essa abordagem de “mãos livres” não implica que você deva abrir mão completamente da supervisão de seus recursos de banco de dados.

Neste artigo, apresentaremos diferentes métodos que permitem monitorar o desempenho e as características de seus bancos de dados PaaS, garantindo que eles se comportem de maneira que corresponda às suas expectativas. Além disso, você pode usar os dados monitorados para otimizar a escalabilidade e o dimensionamento de sua implantação, garantindo que as demandas de suas aplicações dependentes de banco de dados sejam atendidas adequadamente, mas com um custo mínimo.

Ao implantar um novo Banco de Dados SQL, além de designar o datacenter regional que fornecerá seus serviços de computação e armazenamento, você também precisa escolher sua camada de preços, que pode ser definida como Básica, Padrão ou Premium. Sua escolha determina o desempenho geral, o tamanho máximo, a variedade de capacidades de recuperação, bem como o preço. O desempenho é medido na forma de Unidades de Desempenho do Banco de Dados (ou simplesmente DTUs), que representam a capacidade relativa das camadas individuais e refletem seu poder de processamento, memória e características de throughput.

Além disso, cada camada de preços é caracterizada por sua taxa de transação de referência (número de transações por hora que medem o throughput real do nível de desempenho correspondente, conforme produzido pelo Benchmark do Banco de Dados do Azure SQL simulando cargas de trabalho de processamento de transações online), número máximo de threads de trabalho, número máximo de sessões, tamanho máximo do banco de dados, bem como previsibilidade (indicando consistência no tempo de resposta).

Depois que o banco de dados é provisionado, você poderá coletar várias métricas que devem fornecer uma compreensão básica de seu estado atual e garantir que ele corresponda ao nível de desempenho esperado associado à camada de preços selecionada. O método mais direto para alcançar esse objetivo envolve o uso do Portal de Gerenciamento do Azure ou do Portal de Visualização.

Por padrão, ambos os portais acompanham a contagem de Deadlocks, a quantidade de armazenamento (identificando o tamanho total do banco de dados), bem como o número de Conexões Bem-sucedidas e Falhas (por acaso, o portal de visualização também inclui automaticamente a porcentagem de DTU). Para monitorar os níveis de utilização do banco de dados, você também pode adicionar, no mínimo, a porcentagem de CPU, a porcentagem de E/S de Dados e a porcentagem de E/S de Log.

Para cada métrica, a página de Monitoramento no portal de gerenciamento e as lentes ou blades correspondentes no portal de visualização fornecem estatísticas numéricas e seus equivalentes baseados em gráficos, ilustrando os valores atuais (em intervalos de uma hora), médios, mínimos e máximos, bem como (quando apropriado) valores totais. Além disso, você também tem a opção de estender o monitoramento para tentativas de conexão que foram Bloqueadas pelo Firewall ou Conexões Limitadas, bem como visualizar qualquer uma das estatísticas listadas acima nas últimas horas, hoje, na última semana ou em um intervalo de tempo personalizado.

Para qualquer uma das métricas que você decidiu monitorar, você pode definir um alerta (clicando em Adicionar Regra na barra de comandos do portal de gerenciamento completo ou Adicionar Alerta no portal de visualização) que será acionado quando essa métrica ultrapassar um limite arbitrariamente escolhido dentro de um dos quatro intervalos de janela de avaliação predefinidos (o portal de gerenciamento completo é limitado aos últimos 15 minutos, 30 minutos, 45 minutos ou uma hora, mas o portal de visualização oferece mais flexibilidade, com intervalos variando de 5 minutos a 24 horas). Isso será refletido por um alerta aparecendo na página de Alerta dentro do nó Serviços de Gerenciamento do portal de gerenciamento e na lente Regras de Alerta da blade de banco de dados correspondente no portal de visualização. Os alertas podem ser encaminhados automaticamente para uma caixa de correio designada (incluindo as caixas de correio do Administrador de Serviço e dos co-administradores da assinatura subjacente).

Se sua intenção é gerenciar e visualizar dados de monitoramento sem recorrer aos portais de acesso, você pode implementar a funcionalidade equivalente aproveitando duas construções existentes do Banco de Dados SQL:

A visão de catálogo sys.resource_stats no banco de dados master da instância lógica do SQL Server onde seu banco de dados de usuário reside. A visão expõe várias estatísticas de desempenho (incluindo usage_in_seconds, storage_in_megabytes, avg_cpu_cores_used, avg_physical_read_iops, avg_physical_write_iops, active_memory_used_kb, active_session_count, active_worker_count, avg_cpu_percent, avg_physical_data_read_percent e avg_log_write_percent) agregadas em intervalos de cinco minutos para cada banco de dados hospedado pela mesma instância lógica do SQL Server (da qual o banco de dados master faz parte). Devido ao atraso inerente à coleta e ao cálculo de estatísticas agregadas, esse método é tipicamente empregado para obter dados de monitoramento ao longo de períodos estendidos de tempo com o objetivo de analisar tendências de desempenho de longo prazo (os dados são preservados por 14 dias).

Por exemplo, o seguinte T-SQL permitiria que você visualizasse as estatísticas agregadas para um banco de dados chamado db1 nos últimos sete dias (observe que você precisa estar conectado ao banco de dados master para executá-lo com sucesso):

SELECT * 
FROM sys.resource_stats
WHERE database_name = 'db1' AND
	start_time > DATEADD(day, -7, GETDATE())
ORDER BY start_time DESC;

A visão de gerenciamento dinâmico sys.dm_db_resource_stats no Banco de Dados SQL de destino. A visão expõe um subconjunto de estatísticas de desempenho, incluindo avg_cpu_percent, avg_data_io_percent, avg_log_write_percent e avg_memory_usage_percent calculados em intervalos de quinze segundos, portanto, é mais adequada para cenários em que a análise de desempenho precisa ser realizada em tempo quase real (os dados são preservados por uma hora).

Se essas porcentagens permanecerem próximas de 100% de utilização, você deve considerar a melhoria do desempenho por meio de escalonamento, dimensionamento ou otimização do design do banco de dados. O seguinte T-SQL permitiria que você visualizasse as estatísticas mais recentes no banco de dados atual:

SELECT * FROM sys.dm_db_resource_stats ORDER BY end_time DESC;

É importante observar que a funcionalidade fornecida pelas visões de gerenciamento dinâmico vai além dos recursos de monitoramento disponíveis nos portais de gerenciamento. Em particular, você pode aproveitá-la para obter informações adicionais sobre o banco de dados e seus objetos, suas conexões, bem como consultas e planos de consulta individuais.

A primeira dessas capacidades é facilitada pela visão sys.dm_db_partition_stats, que permite calcular tanto o tamanho do banco de dados quanto seus objetos individuais executando as duas consultas a seguir:

SELECT SUM(reserved_page_count)*8.0/1024
FROM sys.dm_db_partition_stats; 
GO
SELECT sys.objects.name, SUM(reserved_page_count) * 8.0 / 1024
FROM sys.dm_db_partition_stats, sys.objects 
WHERE sys.dm_db_partition_stats.object_id = sys.objects.object_id 
GROUP BY sys.objects.name; 
GO

Da mesma forma, você pode consultar a visão de gerenciamento dinâmico sys.dm_exec_sessions e sys.dm_exec_connections relacionada à execução para conexões de banco de dados ativas, o que permite identificar valores de login_name, host_name, session_id ou cpu_time associados a cada uma delas:

SELECT *
FROM
      sys.dm_exec_sessions s
      INNER JOIN sys.dm_exec_connections e
      ON s.session_id = e.session_id
GO

Se sua intenção é monitorar o desempenho dos planos de consulta e identificar consultas de longa duração, você pode aproveitar a visão de gerenciamento dinâmico sys.dm_exec_query_stats.

Para implantações maiores do Banco de Dados SQL que complementam seu ambiente do SQL Server local em cenários híbridos, você pode considerar soluções de nível empresarial, como o System Center Operations Manager (SCOM) com o Management Pack para Azure. O management pack depende das APIs REST do Azure para coletar informações de instrumentação sobre uma variedade de tipos de recursos em nuvem, incluindo o Banco de Dados SQL. Com o SCOM, você pode contar com monitores de saúde e desempenho padrão incorporados ao management pack ou definir os seus próprios que aproveitam as visões de gerenciamento dinâmico descritas anteriormente. Apresentaremos essa configuração com mais detalhes em um de nossos próximos artigos.

Veja todos os artigos de Marcin Policht