1. Visão Geral do Ambiente
Servidor: SRVSEDE01621
Banco de Dados: CORPORERM (ERP TOTVS)
Versão SQL Server: SQL Server 2019 (150)
Data da Análise: 31/03/2026
2. Análise de Consumo de CPU e Memória
Padrão de Consumo de CPU Identificado
A análise dos gráficos de CPU revela um padrão característico de picos "agulha". O consumo de CPU atinge valores elevados (entre 86% e 92%) em momentos específicos, sendo o processo sqlservr.exe o principal ofensor. No entanto, o SQL Server libera rapidamente esse consumo no minuto seguinte, indicando que não há saturação sustentada, mas sim operações pontuais intensivas.
O consumo médio de CPU permanece em torno de 35-40%, o que é considerado saudável. A saturação (linha roxa nos gráficos) é mínima e esporádica. A evolução ao longo do dia mostra múltiplos picos distribuídos, sem padrão de degradação progressiva, indicando que o servidor está controlando bem a carga.
Conclusão: O servidor não está subdimensionado em termos de CPU. Os picos são transitórios e esperados para um ERP em produção. O foco deve ser na otimização de queries e configurações.
Análise de Memória
O Buffer Pool apresenta-se saudável, com o Page Life Expectancy (PLE) em 4316s, o que indica uma boa retenção de páginas em memória. No entanto, observou-se que o banco CustomizacoesSGE ocupa 24% da memória RAM. Este é um valor considerável para um banco secundário, e sugere a ocorrência de varreduras completas (Scans) em tabelas grandes customizadas, o que requer melhoria.
3. Configuração da Instância e Infraestrutura
| Parâmetro | Valor Atual | Status | Observação |
|---|---|---|---|
| Plano de Energia (Windows) | Equilibrado (Balanced) | CRÍTICO | Causa latência na resposta da CPU a picos de carga. Deve ser alterado para "Alto Desempenho". |
| Max Server Memory | 57 GB (Total: 80 GB) | OK | Configuração aceitável, deixando memória suficiente para o SO. |
| Min Server Memory | 0 MB | CRÍTICO | Risco de o Windows "paginar" a memória do SQL. Recomenda-se definir para 32 GB. |
| Compatibility Level (CORPORERM) | 120 (SQL 2014) | ATENÇÃO | A instância é 2019 (150). O banco não está aproveitando melhorias como o Intelligent Query Processing. É importante homologar a alteração, pois pode afetar rotinas. |
4. Saúde do Banco de Dados (CORPORERM)
- Estatísticas Desativadas: As opções
AUTO_UPDATE_STATISTICSeAUTO_CREATE_STATISTICSestão configuradas como OFF. Isso é crítico, pois estatísticas desatualizadas forçam o SQL Server a escolher planos de execução ruins. - Fragmentação de Índices: Tabelas vitais como
STURMACOMPL,FBOLETOHISTORICOeSHABILITACAOALUNOapresentam fragmentação superior a 90%, degradando o desempenho de leitura. - Backup do Banco Master: O banco
masternão recebe backup desde 21/12/2025, representando um sério risco de desastre.
5. Análise de Queries e Waits
5.1 Queries Ofensoras
| Query / Procedure | Problema Identificado | Impacto |
|---|---|---|
| Top 1 CPU/Duração ( SMATRICULA, SFREQUENCIA, SPLANOAULA) |
Extremamente agressiva. No relatório de 1h, teve Avg CPU de 10s por execução. Com 533 execuções, gerou mais de 5.300s de carga de CPU. | ALTO |
| Consultas de Portal ( ProfessorDisciplineClassServer, ProfessorClassReportServer) |
Aparecem repetidamente no topo. O uso de NOLOCK é comum no RM, mas a complexidade dos JOINs sem índices ideais gera alto volume de Logical Reads. | ALTO |
ZSPGERASOLUCAOINTEGRADORA |
Consumiu 381s de CPU em uma única execução e realizou 152 milhões de leituras lógicas. Utiliza UNION ALL com funções de tabela (FN_SOLUCAOINTEGRADORA) não-inline, que são conhecidamente lentas. Gerou I/O e Latência: Apresentou PAGEIOLATCH_SH e IO_COMPLETION no SPID 1802, indicando espera por leitura em disco. | ALTO |
| Revisão de Customizações ( DBO.ZSCAE_HORAALUNO) |
Consumiu quase 200s de CPU em apenas 2 execuções. Realiza múltiplos UNION ALL com subqueries complexas. Pode ser otimizada com tabelas temporárias ou variáveis de tabela. | MÉDIO |
GIMAGEM |
O comando SELECT * processou aproximadamente 320 GB de dados em uma única execução, demorando 940s (15,6 min). Deve-se evitar o tráfego de blobs/binários sem filtros rígidos. |
MÉDIO |
5.2 Wait Types e Locks
| Wait Type / Lock | Causa / Processo | Ação Recomendada |
|---|---|---|
| PAGEIOLATCH_SH / IO_COMPLETION | Gargalo de leitura em disco (SPID 1802) causado pela query ZSPGERASOLUCAOINTEGRADORA. |
Otimizar queries com alto volume de leitura lógica. |
| ASYNC_NETWORK_IO | SPID 2606 (SSIS/Catraca) rodando com DOP 8. Indica que o SQL enviou os dados e está esperando a aplicação (ou rede) processar. | Investigar rotinas que fazem uso de paralelismo, é um ótimo caminho para cada vez mais gastar menos com infra, performando a operação em busca de um ambiente estável. |
| Locks de Intenção (IX) | Processo de fechamento/movimentação (ZSIRETORNO) segurando diversos locks em tabelas acadêmicas (SMATRICULA, SNOTAETAPA). Se o volume aumentar, pode gerar bloqueios em cascata. |
Revisar transações; considerar isolamento READ_COMMITTED_SNAPSHOT. |
6. Recomendações Prioritárias
| Prioridade | Ação | Impacto | Timeline |
|---|---|---|---|
| 🔴 ALTA | Alterar Plano de Energia do Windows para "Alto Desempenho" | Alto | Imediato |
| 🔴 ALTA | Habilitar AUTO_UPDATE_STATISTICS e AUTO_CREATE_STATISTICS no banco CORPORERM |
Alto | Imediato |
| 🔴 ALTA | Definir Min Server Memory para 32 GB |
Médio | Imediato |
| 🔴 ALTA | Executar backup imediato do banco master |
Alto | Imediato |
| 🔴 ALTA | Criar índices estratégicos sugeridos (Impacto > 90%): - STURMADISC: (ATIVA, CODCOLIGADA, CODFILIAL, CODTIPOCURSO) INCLUDE (CODDISC, CODTURMA, IDPERLET...)- SLOGCAMPUS: (CODCOLIGADA, RA)- SCOORDENADOR
|
Alto | Imediato (Janela) |
| 🟡 MÉDIA | Agendar REBUILD de índices (especialmente STURMACOMPL, FBOLETOHISTORICO e SHABILITACAOALUNO) |
Alto | 1-2 dias |
| 🟡 MÉDIA | Revisar e otimizar a query ZSPGERASOLUCAOINTEGRADORA e DBO.ZSCAE_HORAALUNO |
Alto | 1-2 dias |
| 🟢 BAIXA | Avaliar a atualização do Compatibility Level de 120 para 150 para ganhar performance nativa de motor (Requer homologação). | Médio | 1-2 semanas |
7. Pontos Positivos do Ambiente
- ✔ O servidor não está subdimensionado em CPU; os picos são transitórios.
- ✔ A memória máxima (Max Server Memory) está adequadamente configurada.
- ✔ O Buffer Pool está saudável (PLE em 4316s).
- ✔ O uptime do servidor é estável.
- ✔ O padrão de carga é bem distribuído ao longo do dia, sem degradação progressiva.
Conclusão: O hardware atual suporta a carga. Com as otimizações de software e queries recomendadas, espera-se uma melhoria de 20-30% no desempenho geral, e redução no consumo de CPU durante operações críticas.
8. Conclusão
Diagnóstico Final: O servidor SRVSEDE01621 está operacional e funcional, mas apresenta oportunidades significativas de otimização. O padrão de picos "agulha" de CPU é normal e esperado para um ERP, não indicando subdimensionamento de hardware.
Gargalos Principais:
- ⚠️ Configurações de software inadequadas (plano de energia, estatísticas desativadas, memória mínima zerada).
- ⚠️ Fragmentação severa de índices (>90% em tabelas críticas) e ausência de índices estratégicos (STURMADISC, SLOGCAMPUS).
- ⚠️ Queries não otimizadas (Top 1 CPU, Consultas de Portal, ZSPGERASOLUCAOINTEGRADORA) gerando volume massivo de leituras lógicas e consumo de CPU.
- ⚠️ Consumo elevado de memória (24%) pelo banco CustomizacoesSGE.
Próximos Passos: Implementar as recomendações prioritárias listadas acima, com foco imediato na alteração do plano de energia, ativação da atualização automática de estatísticas, configuração da memória mínima e criação dos índices estratégicos. Em seguida, atuar na desfragmentação de índices e otimização das queries ofensoras.