AIOps TOTVS Presentation

1. Resumo Executivo

Servidor Analisado: SRVSEDE01706

Data da Análise: 13 de Março de 2026

Status Geral: OPERACIONAL COM RECOMENDAÇÕES

Diagnóstico: O servidor SQL Server está operacional e apresenta performance aceitável. No entanto, foram identificados pontos críticos na infraestrutura e configurações de banco de dados, que requerem atenção imediata para evitar degradação de performance.

2. Configuração do Servidor

Parâmetro	Valor	Status
Servidor	SRVSEDE01706	OK
RAM Total	131.071 MB (~128 GB)	OK
CPUs	16 cores (2 sockets, 8 cores cada)	OK
Max Server Memory	106.496 MB	AVISO
Tipo de VM	Hypervisor	OK
Uptime	346 horas (~14 dias)	OK

3. Análise de Performance do Servidor

3.1 Utilização de CPU

Análise de CPU

Observação: O gráfico mostra picos ocasionais de CPU atingindo 80-90%, mas com média mantida entre 30-40%. Isso é NORMAL para um ambiente de produção com cargas variáveis. A CPU não é o gargalo principal do ambiente, apesar de notarmos momentos que ocorrem saturação de cores. O pior momento de saturação de core observado, normalmente atinge picos de 02 cores, chegando a ficar 1 a 2 minutos saturados, mas são raros os momentos. Se considerarmos as melhorias recomendadas nesse documento, a tendencia é diminuir essas filas, e portanto nesse momento, não vejo necessidade de aumentar o numero de cores.

3.2 Memória do SQL Server

✓ Análise de Memória

O SQL Server está configurado para usar até 106.496 MB de RAM, e está utilizando aproximadamente 90% dessa alocação. Isso é NORMAL e ESPERADO para um servidor de banco de dados em produção. O SQL Server utiliza essa memória para:

Buffer Pool: cache de páginas de dados
Plan Cache: cache de planos de execução
Memory Grants: alocação para queries
Outras estruturas internas: estruturas de controle e metadados

⚠️ OBSERVAÇÃO IMPORTANTE: Atualmente, o ambiente apresenta um Page Life Expectancy (PLE) de aproximadamente 3.555 segundos (~59 minutos), o que é considerado um ótimo indicador de uso de memória. Esse valor demonstra que o SQL Server está conseguindo manter os dados em cache de forma eficiente, não havendo evidências de pressão significativa de memória no momento. Dessa forma, não há indícios de que a memória seja o principal gargalo do ambiente. Os pontos de atenção identificados estão mais relacionados à necessidade de manutenções estruturais, como atualização de estatísticas, reorganização/rebuild de índices e otimização de consultas, que serão detalhados ao longo deste relatório.

Recomendação: Como boa prática — especialmente em ambientes de alta concorrência como o ERP Protheus — recomenda-se configurar o SQL Server para utilizar até 128 GB de memória, mantendo ao menos 20 GB reservados para o Sistema Operacional. Caso haja disponibilidade para expansão, considerar o aumento da memória total do servidor para 160 GB pode trazer ganhos adicionais, principalmente na redução de I/O em disco, ao permitir que um volume ainda maior de dados e planos de execução permaneça em memória. No entanto, é importante destacar que esse ajuste deve ser tratado como otimização complementar, e não como solução para os principais gargalos atualmente observados no ambiente.

3.3 Page Life Expectancy (PLE)

Métrica	Valor	Classificação	Status
Page Life Instance	3.555 segundos	Bom (2501-3500s)	OK

✓ Análise: O Page Life Expectancy está em nível BOM, indicando que as páginas permanecem adequadamente em cache. O Buffer Pool está saudável e a pressão de memória é aceitável.

3.4 Análise de Infraestrutura (Disco)

Disco - Partição T (Dados)

Throughput: Picos ocasionais de até 1.200 MB/s, podendo ocorrer durante operações de backup. NORMAL

IOPS: Picos de até aproximadamente 20 mil IOPS. Na maior parte do tempo abaixo de 2 mil IOPS. NORMAL

Fila: Picos de até 268 operações na fila as 15:53Hs. Durou poucos minutos, e como não é regular, mostra que foi algo que consumiu de forma exagerada, se mostrando mais um problema de tuning no banco, do que problema de infra. AVISO - Os picos tem ocorrido principalmente quando em IOPS ultrapassa os 6 mil, e Throughput proximo a 400 MB.

Disco - Partição D

Throughput: Picos de até 1.100 MB/s. OK

IOPS: Picos de até 18.300 IOPS. OK

Fila: São raras as vezes que ocorrem. Maior pico foi as 10:04Hs, atingindo pouco mais de 1.400 operações. OK

🔴 Analise: Aparentemente o disco não esta ruim, ele esta sendo mau utilizado. São diversas leituras desnecessárias, Scans grandes, baixa eficiência de cache (mesmo com PLE bom) e acesso aleatório intenso na partição. Como resultado, o storage acaba respondendo de forma mais lenta, e o marcador de latência sobe. Podemos ver leituras relativamente grandes, com indicio de scan e não seek eficiênte. Mesmo que o resultado obtido da visão do SQL considere momentos de geração de backups, isso não é normal, sendo um sintoma de problema de workload/otimização. Situações que colaboram para esse resultado: Estatisticas desatualizadas, fragmentação alta, queries ineficientes e alto paralelismo.

4. Análise de Queries Ofensoras

4.1 Queries com Maior Consumo de CPU

As queries identificadas com maior consumo de CPU e tempo de execução, estão relacionadas a operações de atualização de timestamp e processamento de dados do ERP:

Query	Tabela	Tipo	Frequência	Impacto
`UPDATE SBZ010 SET S_T_A_M_P_ = GETUTCDATE()`	SBZ010	UPDATE	Milhares de execuções	MÉDIO
`UPDATE SE1010 SET S_T_A_M_P_ = GETUTCDATE()`	SE1010	UPDATE	Milhares de execuções	MÉDIO
`UPDATE SC7010 SET S_T_A_M_P_ = GETUTCDATE()`	SC7010	UPDATE	Milhares de execuções	MÉDIO

                    ⚠️ Observação: Essas queries normalmente indicam triggers automáticos de auditoria de atualização, padrão comum em sistemas ERP. Recomenda-se avaliar índices nas colunas R_E_C_N_O_, e o impacto de triggers para possíveis otimizações.
                

4.2 Queries com Execução Muito Longa

Uma sessão foi identificada executando há 2 dias e 23 horas, o que pode indicar:

Consultas de relatório pesadas
Cursores abertos por longo período
Processamento de integração

🔴 Recomendação: Investigar queries com execução muito longa utilizando sys.dm_exec_requests e sys.dm_exec_query_stats. Considerar implementar timeouts ou limites de execução para queries de longa duração. Segue a query: SELECT CASE WHEN SC7.C7_FILIAL != SC7.C7_FISCORI THEN SC7.C7_FISCORI ELSE '' END FILIALDEST, CASE WHEN SC7.C7_FILIAL != SC7.C7_FISCORI THEN COALESCE(STUFF((SELECT DISTINCT (', ' + A2.C1_NUM) FROM SC7010 A1 (NOLOCK) INNER JOIN SC1010 A2 ON (Continuação avalie o relatório do banco de dados, em Visão em Tempo Real (DB))

4.3 Wait Types Identificados

Wait Type	Percentual	Causa	Ação Recomendada
ASYNC_NETWORK_IO	43%	Cliente lento consumindo resultados	Revisar queries retornando grandes volumes
CXPACKET	Relevante	Waits de paralelismo	Ajustar MAXDOP e Cost Threshold

5. Problemas Identificados e Recomendações Críticas

5.1 Configurações de Paralelismo (ALTA PRIORIDADE)

🔴 Problema Identificado:

MAXDOP = 0 (padrão inadequado)
Cost Threshold for Parallelism = 5 (muito baixo)

Impacto: Com cost threshold = 5, praticamente qualquer query usa paralelismo, causando excesso de threads e waits de paralelismo.

Recomendação:

EXEC sp_configure 'cost threshold for parallelism', 25;
RECONFIGURE;
EXEC sp_configure 'max degree of parallelism', 8;
RECONFIGURE;

Benefício: Menos contenção de CPU, menos waits de paralelismo, planos de execução mais eficientes.

5.2 Versão do SQL Server (ALTA PRIORIDADE)

🔴 Problema Identificado:

Ambiente está em SQL Server 2016 SP2 GDR (versão antiga)

Impacto: Muitas melhorias de performance nas versões mais novas não estão disponíveis.

Recomendação: Migrar para SQL Server 2019 ou SQL Server 2022

Benefícios:

Melhor paralelismo
Melhor cardinality estimator
Adaptive query processing
Memory grant feedback

5.3 Latencia e Filas de Disco na Partição T e D (Dados e TempDB)

                    ⚠️ Aviso: As latencias e filas de disco está atingindo alguns picos que precisam ser acompanhados. Após as devidas manutenções, deve occorre analise do ambiente, de forma a verificccar se numeros relatados no SQL, ainda continuam elevados em latencia e fila nessas partições.
                

Impacto: Pode causar latência na aplicação em operações de I/O, e afetar a responsividade do banco de dados durante picos de carga.

Recomendação: Monitorar continuamente. Se ultrapassar 50 operações consistentemente, considerar upgrade de disco ou otimização de backup.

5.4 Plano de Energia

                    ⚠️ Aviso: O servidor está configurado com "Plano Equilibrado" quando o recomendado para servidores de banco de dados é "Alto Desempenho".
                

Recomendação: Alterar o plano de energia para "Alto Desempenho" para garantir máxima performance.

5.5 Investigar Waits de Rede (ASYNC_NETWORK_IO)

                    ⚠️ Aviso: Um dos principais wait identificado foi ASYNC_NETWORK_IO (43%), indicando que o SQL terminou de produzir resultados mas o cliente demora para consumir os dados.
                

Possíveis Causas:

Consultas retornando muitos registros
Aplicação lendo resultados lentamente
Problemas de rede
Consultas usadas como relatórios pesados

Recomendação: Avaliar queries retornando grandes volumes, consultas sem paginação, uso de SELECT * e consultas usadas por relatórios do ERP. Esse tipo de wait é comum em ambientes ERP e requer análise para tuning. Uma consideração aqui é melhorar os planos de manutenções, realizando Rebuild, Reorg e atualização de estatísticas de forma mais regular, de preferência semanalmente.

6. Recomendações Prioritárias

Prioridade	Ação	Impacto	Timeline
🔴 ALTA	Ajustar Cost Threshold for Parallelism (20) e MAXDOP (8)	Alto	Imediato
🔴 ALTA	Atualizar SQL Server para 2019 ou 2022	Alto	1-2 semanas
🔴 ALTA	Alterar Plano de Energia para Alto Desempenho	Médio	Imediato
🔴 ALTA	Rebuild e Reorg Semanal	Alto	Semanal
🔴 ALTA	Atualização de estatisticas	Alto	Semanal
🟡 MÉDIA	Aumentar Max Server Memory para 128.000 MB quando possivel, aumentando a memória do servidor para 160 GB pelo menos.	Médio	1-2 dias
🟡 MÉDIA	Monitorar continuamente a Latência e Fila de Disco (Partição T e D)	Alto	Contínuo
🟡 MÉDIA	Revisar queries com ASYNC_NETWORK_IO	Médio	1 semana
🟡 MÉDIA	Revisar queries com execução muito longa	Médio	1 semana
🟢 BAIXA	Revisar triggers de atualização (SBZ010, SE1010, SC7010)	Baixo	2 semanas

7. Pontos Positivos do Ambiente

✓ Boas Notícias:

✔ Backups estão em dia
✔ Nenhum deadlock detectado
✔ Nenhum bloqueio ativo
✔ CPU com raros momentos de saturação
✔ Page Life Expectancy em nível BOM
✔ Uptime estável

Conclusão: O gargalo principal não é CPU e sim queries, rede e configurações de paralelismo. Com as otimizações recomendadas, espera-se melhoria significativa de performance.

8. Conclusão

Diagnóstico Final: O servidor SRVSEDE01706 está operacional e apresenta performance aceitável. O Page Life Expectancy está saudável, indicando boa gestão de memória. A infraestrutura está dentro dos limites aceitáveis, porém próxima aos limites críticos em alguns pontos.

Pontos Positivos:

✓ Page Life Expectancy em nível BOM
✓ CPU com utilização controlada
✓ Memória adequadamente distribuída
✓ Uptime estável
✓ Backups em dia

Pontos de Atenção:

⚠️ Configurações de paralelismo inadequadas
⚠️ Versão do SQL Server desatualizada
⚠️ Fila de disco deve ser constantemente acompanhada
⚠️ Rebuild, Reorg e atualização de estatística devem ocorrer de forma semanal
⚠️ Plano de energia não otimizado
⚠️ Waits de rede (ASYNC_NETWORK_IO) relevantes

Próximos Passos: Implementar as recomendações prioritárias listadas acima, especialmente as de ALTA prioridade (ajustar paralelismo, atualizar SQL Server, alterar plano de energia, Rebuild e Reorg Semanal, assim como a atualização de estatísticas). Manter monitoramento contínuo da fila de disco e investigar queries com ASYNC_NETWORK_IO.