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!
Análise Statspack 2
Re: Análise Statspack 2
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.
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.
Re: Análise Statspack 2
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.
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.
- Attachments
-
- report_2.zip
- (28.66 KiB) Downloaded 346 times
Re: Análise Statspack 2
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.
Sim.
Para pegar a falta de Bind em flagrante:
Code: Select all
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.