Algum tempo atrás, um cliente solicitou minha ajuda para analisar um ambiente Oracle Database Standard Edition 19c, que estava apresentando lentidão em diversos momentos do dia há algumas semanas.
Iniciei a análise verificando o consumo de CPU e os eventos de espera das sessões dos usuários. Durante a investigação, identifiquei os eventos resmgr:cpu quantum e cpu run queue, com load abaixo de 20 no momento da lentidão.
Esses eventos indicam que as sessões dos usuários estão aguardando por CPU. Se este banco de dados fosse Oracle EE, eu verificaria se algum Resource Manager estava habilitado, limitando o consumo de CPU. Para entender melhor a situação, verifiquei a quantidade de CPUs disponíveis no servidor e se o parâmetro CPU_COUNT havia sido modificado.
[root@srv01 ~]# lscpu | egrep 'Model name|Socket|Thread|NUMA|CPU\(s\)'
CPU(s): 32
On-line CPU(s) list: 0-31
Thread(s) per core: 1
Socket(s): 2
NUMA node(s): 1
Model name: Intel(R) Xeon(R) Gold 6326 CPU @ 2.90GHz
NUMA node0 CPU(s): 0-31Connected to:
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.24.0.0.0
SQL> SHOW PARAMETER CPU_COUNT;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
cpu_count integer 32Ao verificar essas informações, constatei que a quantidade de CPUs no sistema operacional correspondia àquela configurada no CPU_COUNT. Após essa verificação, gerei um relatório do Statspack para analisar a saúde do banco de dados.
Ao analisar os top 5 eventos de espera, ficou claro que o principal evento de espera era o cpu quantum, e que 55,2% da CPU estava ociosa.
Para obter dados mais consistentes, coletei os gráficos de consumo de CPU do SAR e os anexei ao relatório. O uso médio de CPU permaneceu abaixo de 50%, conforme indicado pelo relatório do SAR.
Verifiquei se a CPU estava aguardando devido a problemas de I/O, e os eventos de espera estavam baixos, conforme indicado pelo relatório do SAR.
Se o uso de CPU no Statspack mostrava 55,02% de ociosidade, por que as sessões dos usuários estavam sendo enfileiradas devido à falta de recursos de CPU, gerando os eventos resmgr:cpu quantum e cpu run queue? Para profissionais iniciantes, é importante lembrar que a Oracle Standard Edition, a partir da versão 12c, tem um limite de 16 threads. Mesmo que o servidor do cliente tenha 32 threads disponíveis, o Oracle Database usará apenas as 16 threads limitadas pela edição.
Resumindo a situação deste cliente, o servidor começou a apresentar problemas de baixa performance após a migração de Oracle Database 11g SE para Oracle Database 19c SE. Na versão 11g, não havia o limite de uso de CPU pelo banco de dados, o que explica a diferença de comportamento.
É fundamental planejar e coletar dados com um histórico amplo do workload do cliente antes de propor uma migração de versões. Neste caso, identifiquei as principais consultas que utilizam CPU para melhorar a performance, mas o cliente foi notificado de que, para atender ao workload específico da sua empresa, será necessário um upgrade para a edição Enterprise.
Após alguns meses, o cliente migrou do Oracle Database SE para EE.Referências:
https://www.oracle.com/a/ocom/docs/database-licensing-070584.pdf