Fórum Nerv Informática Ltda.

Olá Portilho,

Estou com dúvida de como resolver um problema de desempenho que analisei em um relatório Statspack (relatório anexo).

Não percebi nenhum problema generalizado no cabeçalho.

Partindo para a Time Model.

Time Model System Stats DB/Inst: APOLLO/APOLLO Snaps: 5032-5033
-> Ordered by % of DB time desc, Statistic name

Statistic Time (s) % DB time
----------------------------------- -------------------- ---------
DB CPU 3,049.4 80.0
sql execute elapsed time 1,965.4 51.6
parse time elapsed 1,089.5 28.6
hard parse elapsed time 1,013.8 26.6

Esses dois itens em destaque que são o motivo da minha dúvida, porque juntos são metade do tempo total.

Do tempo de sql execute elapsed time 80% é DBCPU. Sobrou muito pouco para analisar em waits.

Nos SQL order by CPU também não encontrei nada de exagerado.

Minhas dúvidas são:
O que seriam esses itens?
Porque acontecem?
Como resolver?

Abraços, Portilho!

Oi.
Seu problema é compilação. Evidências:
- DB CPU alto, sendo que boa parte é Parse.
- Shared Pool com 10GB, enquanto o Buffer Cache está com 14GB.
- Em "OS Statistics", SYS_TIME relativamente alto em relação ao USER_TIME.

Procure o(s) SQL(s) sem Binds:
http://nervinformatica.com.br/blog/inde ... sem-binds/

Ou se não puder corrigir eles, veja se pode alterar o CURSOR_SHARING para FORCE.

Boa tarde Portilho,

Conforme sugeriu entrei no link do Blog e rodei o select. Peguei dois resultados de exemplo, que são:

8818 SELECT COUNT(*) FROM ( select os.numero_os, os.cod_os_agenda, os.seguradora, os.franquia, os.
franquia_servico, os.franquia_manual, abs(os.numero_os) as abs_osnum, os.cod_empresa,

14685 SELECT 1 FROM ADIANTAMENTO A, TIPO_ADIANTAMENTO T, EMPRESAS EM WHERE A.TIPO_ADIANTAMENTO = T.TIPO_ADIANTAMENTO AND A.COD_EMPRESA = EM.COD_EMPRESA AND T.NATUREZA = 'E' AND A.DATA_BAIXA IS NULL A

Só pra ver se entendi: Esses dois trechos de SQL rodaram respectivamente 8818 e 14685 vezes?

Com relação ao parâmetro que passou (cursor_sharing=force), eu alterei e fiz o teste. O ambiente melhorou muito depois disso. O tempo gasto com execução de SQL aumentou muito e o tamanho da Shared Pool diminuiu drasticamente, embora o DB CPU tenha aumentado também.

Anexei um relatório Statpack para você poder ver a diferença no mesmo período.

Ainda vou continuar tentando corrigir os SQLs sem bind com a software house, pois sei que o cursor_sharing ajuda, mas não resolve, e ainda tem alguns efeitos colaterais.

Muito obrigado pela ajuda de sempre.

Abraços.

Só pra ver se entendi: Esses dois trechos de SQL rodaram respectivamente 8818 e 14685 vezes?
Sim.

Para pegar a falta de Bind em flagrante:


Comparando os Statspack:
- A Shared Pool estava em 10,432M, e passou a utilizar 2,944M;
- O "sql execute elapsed time" (o tempo produtivo do banco) foi de 51.6% para 94.1%;
- O "parse time elapsed" foi de 28.6% para 3.3%.

Realmente, o correto, o mais escalável é utilizar Binds nos SQLs altamente repetitivos, e e não o CURSOR_SHARING = FORCE.