Resposta direta: a capacidade do Fabric estoura (erro “capacity exceeded”) quando o consumo acumulado de CUs passa do limite contratado e o Fabric começa a atrasar ou rejeitar operações. Na maioria dos ambientes que analisamos, o problema está em poucas cargas mal configuradas. Corrigir essas cargas costuma resolver antes de qualquer aumento de capacidade.
Quando a capacidade do Fabric fica estourada, o sintoma chega primeiro ao negócio: relatório que não abre, atualização que falha de madrugada, mensagem pedindo para “tentar mais tarde”. Este guia explica o que acontece por trás do erro fabric capacity exceeded, como achar o responsável no Capacity Metrics App e quais correções testamos antes de recomendar uma capacidade maior.
Separamos ao longo do texto o que é regra oficial da Microsoft (com link) e o que é recomendação da beAnalytic a partir de projetos.
O que significa “capacity exceeded” e throttling no Fabric?
Throttling é a limitação automática que o Fabric aplica quando uma capacidade consome mais CU do que o SKU contratado permite: primeiro ele atrasa operações, depois rejeita. A capacidade se recupera sozinha quando o consumo excedente é “pago” pelos períodos ociosos seguintes.
Para entender quando isso acontece, é preciso conhecer dois mecanismos descritos na documentação oficial de throttling e smoothing:
- Bursting: uma operação pode usar temporariamente mais computação do que a capacidade tem, para terminar rápido.
- Smoothing: o Fabric distribui esse consumo ao longo do tempo. Operações interativas (como abrir um relatório) são suavizadas em 5 a 64 minutos. Operações em segundo plano (como atualizações e pipelines) são suavizadas em 24 horas.
O problema aparece quando o consumo futuro já comprometido fica grande demais. As fases oficiais são:
| Consumo futuro já comprometido | Fase | O que o usuário sente |
|---|---|---|
| Até 10 minutos | Proteção de excedente | Nada, tudo roda normalmente |
| De 10 a 60 minutos | Atraso interativo | Operações interativas esperam 20 segundos para começar |
| De 60 minutos a 24 horas | Rejeição interativa | Relatórios e consultas são recusados; cargas em segundo plano continuam |
| Acima de 24 horas | Rejeição em segundo plano | Tudo é recusado, inclusive atualizações |
Fonte: Microsoft Learn, atualizado em agosto de 2026.
A diferença que importa: atraso é incômodo, rejeição é incidente. Na rejeição em segundo plano, as atualizações param e os relatórios ficam desatualizados até a capacidade se recuperar.
Throttling faz perder dados?
Não. Operações que já estavam rodando quando o throttling começou vão até o fim. O que é rejeitado são as novas solicitações. A carga recusada precisa ser executada de novo, e o dado do dia pode chegar atrasado, mas nada já gravado se perde.
Como descobrir o que está consumindo a capacidade?
A resposta está no aplicativo Microsoft Fabric Capacity Metrics, instalado pelo administrador da capacidade. O roteiro que usamos:
- Abra a página Compute e veja o gráfico de Utilização. Picos acima da linha de 100% indicam excedente, mas excedente sozinho não significa throttling.
- Confira os gráficos de Throttling. Eles mostram se o consumo passou dos limites de 10 minutos, 60 minutos ou 24 horas.
- Veja a tabela System events. Ela registra quando a capacidade entrou e saiu do estado de sobrecarga.
- Faça drill through no ponto do pico. A página de timepoint lista as operações interativas e em segundo plano que mais consumiram naquele momento.
- Ordene por item e por usuário. Normalmente dois ou três itens respondem pela maior parte do consumo.
- Abra a aba Overages e alterne a escala entre 10 minutos, 60 minutos e 24 horas para ver o acúmulo e o tempo de recuperação (burndown).
Um aviso da própria Microsoft: lentidão muitas vezes vem do desenho do item. Se o Capacity Metrics não mostra throttling, o problema provavelmente está no modelo ou na consulta.
Quais são as causas mais comuns de capacidade estourada?
Em projetos da beAnalytic, sete causas explicam quase todos os casos:
- Atualizações em excesso. Modelos atualizados de hora em hora sem necessidade do negócio.
- Modelos importados muito grandes. Tabelas inteiras carregadas no modelo semântico, com colunas que ninguém usa.
- Notebooks Spark mal dimensionados. Sessões grandes para processar pouco dado, ou sessões que ficam abertas.
- Pipelines simultâneos. Todas as cargas agendadas para o mesmo horário.
- DAX pesado. Medidas com iteradores sobre tabelas grandes, recalculadas a cada clique.
- Falta de carga incremental. Recarregar cinco anos de histórico todos os dias.
- Desenvolvimento e produção na mesma capacidade. Um teste pesado derruba o relatório da diretoria.
| Sintoma | Causa provável | Correção |
|---|---|---|
| Rejeição de madrugada | Cargas completas e simultâneas | Carga incremental e escalonamento de horários |
| Relatório lento só em horário comercial | DAX pesado ou modelo grande | Otimizar medidas, remover colunas, agregações |
| Picos durante o dia sem relatório aberto | Notebooks e testes de desenvolvimento | Separar capacidade de desenvolvimento |
| Consumo alto e constante em segundo plano | Atualizações frequentes demais | Rever frequência com o negócio |
| Um workspace domina o consumo | Item sem governança | Limite de consumo por workspace |
Quais correções resolvem rápido?
A maioria das correções não exige capacidade maior. As que mais trazem resultado:
- Reagendar cargas. Espalhar pipelines e atualizações reduz picos de consumo interativo durante o expediente.
- Atualização incremental. Atualizar só os dados novos ou alterados. A organização em camadas da arquitetura medalhão com bronze, prata e ouro facilita esse desenho.
- Separar workspaces e capacidades. Desenvolvimento em uma capacidade menor, pausada fora do horário. Produção em outra.
- Proteção contra surtos (surge protection). Recurso oficial que rejeita novas operações em segundo plano antes que a capacidade entre em throttling profundo. Existe também um limite por workspace, ainda em preview, segundo a documentação de surge protection.
- Marcar workspaces críticos. O workspace da diretoria pode ser definido como Mission critical e fica fora das regras de surge protection por workspace.
- Alertas. Notificações por e-mail e banner avisam quando a capacidade se aproxima do throttling.
Para parar um throttling em andamento, a documentação oficial lista três saídas em capacidades F: aumentar o SKU temporariamente, pausar e retomar a capacidade (o consumo acumulado é cobrado na pausa e a capacidade volta zerada) ou habilitar o overage de capacidade, que custa três vezes a taxa normal.
Quando aumentar a capacidade é a resposta certa?
Aumentar a capacidade é a resposta certa quando o consumo alto é legítimo e constante. Os sinais que usamos para recomendar um SKU maior:
- O throttling se repete mesmo depois de otimizar as principais cargas.
- O consumo em segundo plano fica acima de 70% a 80% na maior parte do dia (recomendação beAnalytic).
- A empresa adicionou novas cargas de valor (novas áreas, novos dados) e o crescimento é estrutural.
- O custo do tempo do time tentando espremer a capacidade supera a diferença de preço.
Antes de aumentar, vale fazer a conta. No guia de preço do Microsoft Fabric de F2 a F64 mostramos quanto custa cada degrau no Brasil. Dobrar a capacidade dobra a conta de computação.
Caso ilustrativo: distribuidora que saiu da rejeição sem trocar de SKU
Cenário ilustrativo, montado a partir de situações comuns em projetos de dados. A empresa e os números são hipotéticos; as regras de throttling e os preços são os oficiais.
Contexto. Uma distribuidora de materiais elétricos roda o Fabric em uma F16 em Brazil South. Três manhãs por semana, os relatórios comerciais eram recusados entre 8h e 10h. A primeira proposta interna era subir para F32, o que custaria US$ 3.270 a mais por mês no pague pelo uso.
Diagnóstico no Capacity Metrics. Três itens respondiam por 77% do consumo em segundo plano:
| Item | Participação no consumo | Problema |
|---|---|---|
| Modelo semântico de vendas | 41% | Atualização completa de hora em hora |
| Notebook de desenvolvimento | 18% | Sessão Spark esquecida aberta na capacidade de produção |
| Quatro pipelines do ERP | 18% | Todos agendados para as 6h |
Correções. Atualização incremental no modelo de vendas, com frequência de 3 vezes ao dia combinada com o comercial. Capacidade F2 separada para desenvolvimento, pausada fora do horário. Pipelines escalonados entre 2h e 5h. Surge protection ativada com limite de rejeição em 75%.
Resultado em 30 dias.
| Indicador | Antes | Depois |
|---|---|---|
| Consumo em segundo plano (24h) | 95% | 52% |
| Eventos de rejeição interativa | 12 no mês | 0 |
| Capacidade de produção | F16 | F16 (mantida) |
| Custo adicional | US$ 409 (F2 de desenvolvimento, menos com pausa) |
O que esse cenário ensina: a proposta de dobrar a capacidade resolveria o sintoma por alguns meses. O diagnóstico resolveu a causa e custou uma fração do aumento.
Resumo para encaminhar à diretoria
- Problema: a capacidade do Fabric está estourando, com relatórios lentos ou recusados e atualizações falhando.
- Opções: otimizar as cargas que mais consomem ou contratar uma capacidade maior.
- Custo ou risco: aumentar o SKU dobra a conta de computação; o overage custa três vezes a taxa normal.
- Recomendação: diagnosticar no Capacity Metrics, corrigir as principais cargas e ativar surge protection antes de aumentar.
- Próximo passo: diagnóstico de consumo da capacidade com os dados reais do ambiente.
Perguntas frequentes sobre capacidade do Fabric estourada
O que é smoothing no Fabric?
É a distribuição do consumo de uma operação ao longo do tempo. Operações interativas são suavizadas em 5 a 64 minutos e operações em segundo plano em 24 horas, o que evita que picos curtos causem throttling.
O throttling faz perder dados?
Não. Operações que já estavam em execução terminam normalmente. Só novas solicitações são atrasadas ou recusadas e precisam ser executadas de novo.
Como ver o consumo de cada item?
No aplicativo Microsoft Fabric Capacity Metrics, pela página Compute e pelo drill through no ponto de pico, que lista o consumo por item, operação e usuário.
Separar desenvolvimento e produção ajuda?
Sim. Testes e notebooks de desenvolvimento deixam de competir com os relatórios de produção. A capacidade de desenvolvimento pode ser menor e pausada fora do horário.
Existe escalonamento automático da capacidade?
Capacidades F não têm autoscale como as antigas P. O aumento é feito manualmente pelo portal do Azure. Existem dois recursos opcionais: o overage de capacidade, que paga o excedente a três vezes a taxa normal, e o Autoscale Billing para Spark, que cobra cargas Spark à parte.
Sua capacidade Fabric está estourando? A beAnalytic é consultoria de dados e implementa e otimiza ambientes Fabric. Peça um diagnóstico de consumo da capacidade Fabric com a nossa consultoria de engenharia de dados, leia o que é o Microsoft Fabric e quando migrar do Power BI ou escreva para [email protected].
Daniel Luz
CEO da beAnalytic. Na liderança da empresa há mais de 6 anos, minha missão é transformar a forma como as organizações enxergam e utilizam dados para tomar decisões estratégicas. Ajudo empresas a destravar insights valiosos, impulsionar eficiência operacional e gerar impacto financeiro real, com uma equipe especializada em Business Intelligence, Engenharia de Dados e Machine Learning.
- Daniel Luz
- Daniel Luz
- Daniel Luz
- Daniel Luz
