Diagnóstico de solução de problemas de desempenho de hiperescala do SQL

Aplica-se a:Banco de Dados SQL do Azure

Para solucionar problemas de desempenho em um banco de dados de Hiperescala, as metodologias gerais de ajuste de desempenho de SQL são o ponto de partida de qualquer investigação de desempenho. No entanto, dada a arquitetura distribuída do Hyperscale, talvez seja necessário considerar dados adicionais de diagnóstico. Este artigo descreve dados de diagnóstico específicos de hiperescala.

Redução das esperas de taxa de logs

Cada banco de dados e pool elástico no Banco de Dados SQL do Azure gerencia a taxa de geração de logs por meio de governança de taxa de logs. O limite de taxa de log é exposto na coluna primary_max_log_rate em sys.dm_user_db_resource_governance.

Às vezes, a taxa de geração de log na réplica de computação primária deve ser reduzida para manter os SLAs (contratos de nível de serviço) de recuperabilidade. Por exemplo, isso pode acontecer quando um servidor de página ou outra réplica de computação está significativamente atrasado na aplicação de novos registros de log do serviço de logs. Se nenhum componente Hyperscale estiver atrasado, o mecanismo de governança da taxa de log permitirá que a taxa de geração de log atinja 150 MiB/s por banco de dados para hardware de série premium e otimizado para memória de série premium. Para hardware de série padrão, a taxa máxima de log é de 100 MiB/s por banco de dados. Para pools elásticos, a taxa máxima de log é de 150 MiB/s por pool para série premium e hardware otimizado para memória premium, e 125 MiB/s por pool para outros tipos de hardware.

Os seguintes tipos de espera aparecem em sys.dm_os_wait_stats quando a taxa de logs é reduzida:

Tipo de espera	Razão
`RBIO_RG_STORAGE`	Consumo de log atrasado por um servidor de página
`RBIO_RG_DESTAGE`	Consumo de logs atrasado devido ao armazenamento de log de longo prazo
`RBIO_RG_REPLICA`	Consumo de logs atrasado por uma réplica secundária de HA ou uma réplica nomeada
`RBIO_RG_GEOREPLICA`	Consumo de logs atrasado por uma réplica geográfica secundária
`RBIO_RG_DESTAGE`	Consumo de logs atrasado pelo serviço de logs
`RBIO_RG_LOCALDESTAGE`	Consumo de logs atrasado pelo serviço de logs
`RBIO_RG_STORAGE_CHECKPOINT`	Consumo de logs atrasado por um servidor de páginas devido à lentidão de um ponto de verificação do banco de dados
`RBIO_RG_MIGRATION_TARGET`	Atraso no consumo de log pelo banco de dados não hiperescala durante a migração reversa

A função de gerenciamento dinâmico (DMF) sys.dm_hs_database_log_rate() fornece mais detalhes para ajudá-lo a compreender, se houver, a redução da taxa de log. Por exemplo, ela pode informar qual réplica secundária específica está atrasada na aplicação de registros de log e o tamanho total do log de transações que ainda não foi aplicado.

Leituras de servidor de página

As réplicas de computação não armazenam em cache uma cópia completa do banco de dados localmente. Os dados locais para a réplica de computação são armazenados no pool de buffers (na memória) e no cache da RBPEX (extensão de pool de buffers resiliente) local que contém um subconjunto das páginas de dados acessadas com mais frequência. Esse cache SSD local é dimensionado proporcionalmente ao tamanho da computação. Cada servidor de página, por outro lado, tem um cache SSD completo para a parte do banco de dados que ele mantém.

Quando uma ES de leitura é emitida em uma réplica de computação, se os dados não existirem no pool de buffers ou no cache SSD local, a página no LSN (Número de Sequência de Log) solicitado será buscada do servidor de página correspondente. As leituras dos servidores de página são remotas e são mais lentas do que as leituras do cache SSD local. Ao solucionar problemas de desempenho relacionados a E/S, precisamos saber quantas E/S foram feitas por meio de leituras de servidor de página relativamente mais lentas.

Várias DMVs (exibições de gerenciamento dinâmico) e eventos estendidos têm colunas e campos que especificam o número de leituras remotas de um servidor de páginas, que podem ser comparadas com o total de leituras. O Repositório de Consultas também captura leituras de páginas no servidor nas estatísticas de runtime de consulta.

As colunas para leituras do servidor de página de relatório estão disponíveis em DMVs de execução e exibições de catálogo:
Os campos de leitura do servidor de página estão presentes nos seguintes eventos estendidos:
- sql_statement_completed
- sp_statement_completed
- sql_batch_completed
- rpc_completed
- scan_stopped
- query_store_begin_persist_runtime_stat
- query_store_execution_runtime_info
ActualPageServerReads / ActualPageServerReadAheads atributos estão presentes no XML do plano de consulta para planos que incluem estatísticas de tempo de execução. Por exemplo:
```
<RunTimeCountersPerThread Thread="8" ActualRows="90466461" [...] ActualPageServerReads="0" ActualPageServerReadAheads="5687297" ActualLobPageServerReads="0" ActualLobPageServerReadAheads="0" />
```
Dica

Para exibir esses atributos na janela de propriedades do plano de consulta, é necessário o SSMS (SQL Server Management Studio) 18.3 ou posterior.

Estatísticas de arquivo virtual e contabilização de E/S

No Banco de Dados SQL do Azure, o sys.dm_io_virtual_file_stats() DMF é uma maneira de monitorar estatísticas de E/S do banco de dados, como IOPS, taxa de transferência e latência. As características de E/S na Hiperescala são diferentes devido à arquitetura distribuída . Nesta seção, nos concentramos na leitura e gravação de E/S, conforme visto nesta DMF.

Para Hiperescala, os dados relevantes são os seguintes sys.dm_io_virtual_file_stats().

As linhas em que o database_id valor corresponde ao valor retornado pela função DB_ID e em que o file_id valor é diferente de 2 correspondem aos servidores de página. Normalmente, cada linha corresponde a um servidor de página. No entanto, para arquivos maiores, vários servidores de página são usados.
- A linha com file_id 2 corresponde ao log de transações.
As linhas em que o valor na database_id coluna é 0 correspondem ao cache SSD local na réplica de computação.

Uso do cache SSD local

Como o cache SSD local existe na mesma réplica de computação em que o mecanismo de banco de dados está processando consultas, as operações de E/S nesse cache são mais rápidas do que E/S em servidores de página. Em um banco de dados Hiperscale ou pool elástico, sys.dm_io_virtual_file_stats() tem linhas especiais informando estatísticas de E/S para o cache local SSD. Essas linhas têm o valor de 0 na coluna database_id. Por exemplo, a consulta a seguir retorna as estatísticas de E/S do cache SSD local desde a inicialização do banco de dados.

SELECT *
FROM sys.dm_io_virtual_file_stats(0, NULL);

Uma razão das leituras agregadas dos arquivos de cache do SSD local para as leituras agregadas de todos os outros arquivos de dados é a taxa de acerto do cache SSD local. Essa métrica é fornecida pelos contadores de desempenho RBPEX cache hit ratio e RBPEX cache hit ratio base, disponíveis na DMV sys.dm_os_performance_counters.

Leituras de dados

Quando as leituras são emitidas pelo mecanismo de banco de dados em uma réplica de computação, elas podem ser atendidas pelo cache SSD local, por servidores de páginas ou por uma combinação dos dois, caso estejam lendo várias páginas.
Quando a réplica de computação lê algumas páginas de um arquivo de dados específico (por exemplo, o arquivo com file_id 1), se esses dados residem apenas no cache SSD local, toda a E/S para essa leitura é contabilizada contra os arquivos de cache SSD locais, onde database_id é 0. Se uma parte desses dados estiver no cache SSD local e outra parte nos servidores de página, a E/S será contabilizada parcialmente para os arquivos do cache SSD local e parcialmente para os arquivos de dados correspondentes aos servidores de página.
Quando uma réplica de computação solicita uma página em um LSN específico de um servidor de página, se o servidor de página ainda não tiver acessado o LSN solicitado, a leitura na réplica de computação aguardará até que o servidor de páginas seja atualizado antes que a página seja retornada. Para qualquer leitura de um servidor de página na réplica de computação, você verá um PAGEIOLATCH_* tipo de espera se ele estiver aguardando essa E/S. Em hiperescala, esse tempo de espera inclui o tempo para acompanhar a página solicitada no servidor de página para o LSN necessário e o tempo necessário para transferir a página do servidor de página para a réplica de computação.
Leituras grandes, como read-ahead, geralmente são feitas usando leituras de scatter-gather. Isso permite ler até 4 MB como uma só operação de ES de leitura. No entanto, quando os dados que estão sendo lidos estão no cache SSD local, essas leituras são contabilizados como várias leituras individuais de 8 KB, já que o pool de buffers e o cache SSD local sempre usam páginas de 8 KB. Como resultado, o número de ESs de leitura vistos no cache SSD local pode ser maior do que o número real de ESs executadas pelo mecanismo.

Gravações de dados

A réplica primária de computação não escreve diretamente nos servidores de página. Em vez disso, os registros de log do serviço de log são reproduzidos nos servidores de página correspondentes.
As gravações na réplica de computação são feitas predominantemente no cache SSD local (database_id 0). Para gravações maiores que 8 KB, ou seja, aquelas realizadas usando a operação de escrita por coleta, cada operação de gravação é dividida em várias escritas individuais de 8 KB no cache SSD local, uma vez que tanto o pool de buffers quanto o cache SSD local sempre utilizam páginas de 8 KB. Como resultado, o número de ESs de gravação vistos no cache SSD local pode ser maior do que o número real de ESs executadas pelo mecanismo.
Arquivos de dados diferentes de database_id 0 que correspondem aos servidores de página também podem mostrar gravações. Na Hiperescala, essas gravações são simuladas, pois as réplicas de computação nunca gravam diretamente em servidores de páginas. As estatísticas de E/S são contabilizadas conforme ocorrem na réplica de computação. Os IOPS, a taxa de transferência e a latência vistas em uma réplica de computação para arquivos de dados, exceto database_id 0, não reflete as estatísticas reais de E/S das gravações que ocorrem em servidores de página.

Gravações de log

Na réplica de computação primária, as gravações de log são contabilizadas em sys.dm_io_virtual_file_stats() em file_id 2.
Ao contrário dos grupos de disponibilidade, quando uma transação é confirmada na réplica de computação primária, os registros de log não são protegidos na réplica secundária. Na Hiperescala, o log é consolidado no serviço de log e aplicado às réplicas secundárias de maneira assíncrona. Como as gravações de log não ocorrem de fato em réplicas secundárias, qualquer contabilização de E/S de log em sys.dm_io_virtual_file_stats() nas réplicas secundárias não deve ser usada como estatísticas de E/S do log de transações.

E/S de dados nas estatísticas de utilização de recursos

Em um banco de dados não Hiperescala, IOPS de leitura e gravação combinadas em arquivos de dados relativos ao limite de E/S de dados de governança de recursos, são relatados nas exibições sys.dm_db_resource_stats e sys.resource_stats, na coluna avg_data_io_percent. As DMVs correspondentes para pools elásticos são sys.dm_elastic_pool_resource_stats e sys.elastic_pool_resource_stats. Os mesmos valores são informados como as métricas do Azure Monitor de Percentagem de ES de Dados para bancos de dados e pools elásticos.

No banco de dados hiperescalar, essas colunas e métricas informam a utilização de E/S de dados em comparação com o limite de armazenamento de SSD local apenas na réplica de computação, incluindo E/S no cache SSD local e no banco de dados tempdb. Um valor de 100% nessa coluna indica que a governança de recursos está limitando o IOPS de armazenamento local. Se isso estiver correlacionado a um problema de desempenho, ajuste a carga de trabalho para gerar menos ES ou aumente o tamanho da computação para aumentar o limitemáximo de IOPS de Dados da governança de recursos. Para governança de recursos de leituras e gravações de cache SSD local, o sistema conta operações de entrada/saída individuais de 8 KB (IOs), em vez de operações de entrada/saída maiores (IOs) que podem ser emitidas pelo mecanismo de banco de dados.

A I/O de dados em servidores de página não é relatada nas visualizações de utilização de recursos ou por meio das métricas do Azure Monitor, mas é relatada no sys.dm_io_virtual_file_stats(), conforme descrito anteriormente.

Comentários

Esta página foi útil?

Last updated on 2025-11-05