sys.sp_get_table_health_metrics (Transact-SQL)

Aplica-se a:Endpoint de análise SQL no Microsoft Fabric

O sys.sp_get_table_health_metrics procedimento armazenado do sistema retorna métricas de saúde de armazenamento em nível de arquivo para uma tabela Lakehouse. O conjunto de resultados inclui distribuições de histogramas para tamanhos de arquivo, contagem de linhas e contagem de linhas excluídas, juntamente com detecção de anomalias que identifica condições comuns de armazenamento que degradam o desempenho das consultas.

Esse procedimento armazenado do sistema está disponível no endpoint de análise SQL para tabelas Lakehouse no Microsoft Fabric.

Syntax

sp_get_table_health_metrics [ @table_name = ] 'table_name'
[ ; ]

Arguments

[ @table_name = ] 'table_name'

O nome totalmente qualificado da tabela Lakehouse para analisar. Use o formato schema.table_name.

@table_name é nvarchar(256), sem padrão. Este parâmetro é obrigatório. O nome do esquema não é necessário se a tabela estiver no dbo esquema.

Valores do código de retorno

0 (êxito) ou um número diferente de zero (falha)

Conjunto de resultados

O sp_get_table_health_metrics conjunto de resultados é uma única linha.

Códigos potenciais de tipo de anomalia

A PotentialAnomalyType coluna retorna um dos seguintes códigos inteiros:

Interpretar os resultados

Se a PotentialAnomalyType coluna tiver um valor diferente de zero, o procedimento detectou uma anomalia na tabela. O procedimento armazenado analisa a tabela de destino e fornece um diagnóstico baseado em parâmetros ideais para o motor Fabric Data Warehouse. A PotentialAnomalyDescription coluna fornece uma descrição da anomalia detectada, mas talvez você precise de uma interpretação mais ampla dos resultados para melhor contexto.

Use as colunas do histograma para entender se o layout físico do arquivo da tabela está próximo da forma esperada para o desempenho de consultas do Data Warehouse. Uma tabela saudável geralmente tem a maioria dos arquivos nessa FileRowCount[1M,10M) faixa, com a contagem média de linhas próxima a 2 milhões de linhas por arquivo. Se a maioria dos arquivos estiver em caixas de menor número de linhas, como FileRowCount[1k,10k), FileRowCount[10k,100k), ou FileRowCount[100k,1M), a tabela pode conter muitos arquivos subdimensionados. Essa condição pode aumentar o planejamento de consultas e a sobrecarga de abertura de arquivos, pois o motor SQL precisa ler de muitos arquivos pequenos em vez de poucos arquivos maiores.

Para tamanho de arquivo, uma tabela saudável deve ter a maioria dos arquivos próxima da média alvo de 1,2 GB por arquivo. No histograma, os arquivos devem se concentrar em FileSize[1GiB,16GiB), com alguns arquivos em FileSize[64MiB,1GiB) dependendo dos padrões de ingestão e do tamanho da tabela. Se muitos arquivos aparecem em caixas menores, especialmente FileSize[1KiB,16KiB), FileSize[16KiB,256KiB), FileSize[256KiB,4MiB), ou FileSize[4MiB,64MiB), a tabela provavelmente tem um problema de arquivos pequenos e pode se beneficiar da compactação.

Arquivos muito grandes também podem reduzir o desempenho e a flexibilidade operacional. Se muitos arquivos aparecerem em FileSize[16GiB+), ou se o tamanho médio dos arquivos for maior que o alvo de 1,2 GB do warehouse, a tabela pode ter arquivos excessivamente grandes. Arquivos grandes podem reduzir o paralelismo porque há menos arquivos disponíveis para o trabalho de varredura distribuída, e podem tornar operações de manutenção, como reescritas ou compactação, mais caras. O melhor layout geralmente é uma distribuição balanceada em torno do tamanho do arquivo alvo, em vez de muitos arquivos pequenos ou um pequeno número de arquivos grandes.

Use as colunas de resumo para calcular médias em nível de tabela:

• Média de linhas por arquivo = PhysicalRowCount / FileCount
• Tamanho médio do arquivo = FileSizeInBytes / FileCount

Compare essas médias com as metas do Data Warehouse. Uma contagem média de linhas inferior a 2 milhões de linhas por arquivo, ou um tamanho médio de arquivo inferior a 1,2 GB, indica padrões de fragmentação ou ingestão que produzem arquivos pequenos demais para um processamento eficiente de consultas SQL. Executar OPTIMIZE pode compactar arquivos menores em arquivos maiores e melhorar a eficiência da varredura.

Métricas de linhas excluídas indicam se é necessária manutenção para remover linhas logicamente excluídas. Uma tabela saudável deve ter a maioria dos arquivos em FileDeletedRowCount[0], e DeletedRowCount deve ser baixa em relação a PhysicalRowCount. Se as linhas deletadas estiverem concentradas em bins mais altos, como FileDeletedRowCount[100k,1M), FileDeletedRowCount[1M,10M), ou FileDeletedRowCount[10M+), o motor SQL deve pular muitas linhas excluídas em tempo de leitura, o que pode reduzir o desempenho da consulta. Executar OPTIMIZE reescritas afeta arquivos e remove fisicamente linhas excluídas.

Permissões

O chamador deve ter pelo menos VIEW permissão DEFINITION na tabela de destino através do endpoint de análise SQL.

Observações

• O ponto de extremidade de análise do SQL é somente leitura. Você não pode rodar OPTIMIZE diretamente do endpoint de análise SQL. Use um caderno Spark, contexto Lakehouse ou um pipeline de dados Fabric para executar operações de manutenção. Para um tutorial, veja Tutorial: Otimize tabelas Lakehouse com base em checagens de saúde.
• O procedimento inspeciona apenas metadados em nível de arquivo. Não realiza análise em nível de grupo de linhas.
• Para tabelas sem arquivos de dados (tabelas vazias), o procedimento retorna um conjunto de resultados com todos os valores do histograma definidos como 0 e PotentialAnomalyType definidos como 0.

Examples

A. Verifique a saúde de uma única tabela

EXEC sys.sp_get_table_health_metrics @table_name = 'dbo.WebClickstreamEvents';

B. Use a sintaxe dos parâmetros posicionais

EXEC sys.sp_get_table_health_metrics 'sales.SalesOrderFacts';

Próxima etapa

Conteúdo relacionado

• Delta Lake OPTIMIZE
• Qual é o ponto de extremidade de análise SQL para um Lakehouse?