[oracle_br] Re: Consulta muito lenta!!

[jlchia...@yahoo.com.br [oracle_br]]

Blz ? Vamos por partes aí : primeiro, antes de tudo, tecnicamente falando *** 
Não é verdade *** que vc não consegue mudar o texto de um SQL (para injetar um 
hint, para mudar cláusulas no WHERE, mudar tabelas no FROM, enfim, re-escrever 
o SQL) sem ter acesso ao fonte da Aplicação : minha Apresentação no dba brasil 
1.0 (veja em 
http://www.dbabr.com.br/blog/wp-content/uploads/2016/03/SQL-Factoring.pdf) foi 
EXATAMENTE SOBRE ISSO, no caso usando a DBMS_ADVANCED_REWRITE, mas também falei 
de passagem sobre outras menos invasivas como views, sinônimos, etc... ok ? 
CONHEÇA as capacidades mas ANALISE A VIABILIDADE antes de usar...
 Mas só porque vc PODE fazer não quer dizer que vc DEVA okdoc ? Em especial 
quando falamos de SAP, que é uma aplicação TREMENDAMENTE FECHADA, onde nem 
sequer usar a tool de backup nativa do banco eles te deixam.... Sendo assim, 
NECESSARIAMENTE tudo o que vou falar tem que ser feito com CONCORDÂNCIA DO 
SUPORTE DA SAP, sim sim ?? Então se não abriu Chamado lá, ABRA!!!
 
 Bom, para vc começar uma análise visando tuning (E EM ESPECIAL para um SQL que 
usa & abusa de binds como parece ser esse aí!!) o Passo Inicial é vc obter um 
PLANO DE EXECUÇÃO EXTENDIDO, que mostre as colunas A-ROWs e E-ROWs, pra vc 
poder Validar se as estatísticas usadas estão razoáveis : veja 
https://blogs.oracle.com/optimizer/how-do-i-know-if-the-cardinality-estimates-in-a-plan-are-accurate
 ....
 
 Outra Possibilidade é que vc tenha BIND VARIABLE PEEKING acontecendo aí e o 
Otimizador está usando estatísticas para um determinado valor peeked numa 
execução anterior que não é de frequência comum, OU mesmo que o banco esteja 
criando Múltiplos cursores child por causa dos binds : veja 
http://optimizermagic.blogspot.com.br/2007/12/why-are-there-more-cursors-in-11g-for.html
 e 
http://kerryosborne.oracle-guy.com/2009/03/bind-variable-peeking-drives-me-nuts/
 como refs... INCLUSIVE, a entrada 
https://blogs.sap.com/2013/06/13/oracle-db-optimizer-part-vi-effects-of-disabled-bind-variable-peeking-adaptive-cursor-sharing-and-cardinality-feedback-on-the-cbo-in-sap-environments/
 num blog da SAP mesmo já Alerta para essa Possibilidade, e PERCEBA que essa 
entrada mesmo do blog USA TAMBÉM as colunas A-ROWs e E-ROWs do Plano de 
Execução Extendido para Diagnóstico, sim sim ?? veja lá...
 
 Uma outra possibilidade que vc pode Perseguir é a possibilidade que o Plano de 
Execução em si esteja o melhor possível para as condições exigidas MAS 
fisicamente na hora de executar o plano o banco tá demorando muito - seja 
porque Outros SQLs tão consumindo muita banda de rede, I/O e/o CPU não deixando 
poder de hardware pro banco executar esse seu, seja porque tá com montes de 
whitespace nos segmentos em questão, ou seja qual for WAITs/locks/latches tão 
envolvidos... Faça um TRACE 10046 level máximo de uma sessão executando esse 
SQL em questão...
 
 E finalmente : vc Não Só deve repassar para o Suporte da SAP o tracle, o Plano 
Extendido e as suas conclusões da análise MAS também TEM que validar com eles 
esses PROFILES DE SQL, SQL patches e etc  que alguém (eles mesmos ?? você ??) 
criou, pois vi nos planos as linhas :
 
 ----
   - SQL profile coe_ag6zapv5kypgx_1159570678 used for this statement
   - SQL patch "suggest_support_sap" used for this statement
 
 []s
 
   Chiappa
   
  OBS : para fins de Análise, já que vc Identificou o SQL, nada Impede que vc, 
no seu banco de TESTE mas que tenha um volume Razoável de dados, experimentar 
HINTs, criar outros índices,  alterar o SQL para que faça acesso à chave 
COMPLETA do índice (e não à chave parcial, que deduzo estar acontecendo por 
causa dos "INDEX RANGE SCAN" e "INDEX SKIP SCAN" que vi)... QUalquer informação 
que vc obtenha nesses testes Repasse pro Suporte SAP...