Análise Statspack 2

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!

[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.

[portilho]

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:

Código: Selecionar todos

SELECT SQL_TEXT FROM V$SQL WHERE SQL_TEXT LIKE 'SELECT COUNT(*) FROM ( select os.numero_os, os.cod_os_agenda, os.seguradora, os.franquia, os%';


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.