Re: [oracle_br] Re: Consulta muito lenta!!

2017-12-19 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Então  : comparando o plano original com o novo plano obtido pelo profile, ok 
até mudou o método de acesso mas a Diferença de cardinalidade ao se usar esse 
tal índice  BKPF~0 é ** brutal **, é muita coisa mesmo - assim se esse índice 
Já Existia, o fato de ele não ter sido usado indica que vc deve ter um problema 
Sério de coleta de estatísticas aí... Talvez o tamanho da amostra seja pequeno 
demais, talvez esteja faltando histogramas, talvez a frequência de coleta não 
esteja ótima... Alguma coisa de errada não está certa nesse ambiente...
  Já que cfrme sabemos o SAP não deixa vc mudar nada no banco sozinho,  imho vc 
tem informação MAIS QUE SUFICIENTE pra demandar com o pessoal do SAP 
esclarecimentos e análise de alteração no procedimento de coleta de 
estatísticas
  
  []s
  
Chiappa

Re: [oracle_br] Re: Consulta muito lenta!!

2017-12-19 Por tôpico Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
Esse indice FAGLFLEXA~2 eu fiz rebuild, mas nao adiantou de absolutamente nada. 
O restante nao foi alterado, nem indice criado nem dropado.
Algumas das informacoes do SQLT:
DBMS_STATS SYSTEM STATISTICS Single-block read time of 1.138 milliseconds seems 
too small.Index coalesce candidate. (para quase todos os indices dos segmentos 
envolvidos aparece esse advisor)Index with fluctuating BLEVELSample size of 
1593658 rows may be too small for column with histogram. Sample percent used 
was:0.10%. (Essa mensagem tb aparece para todas as colunas da tabela FAGLFLEXA)
A coleta de estatística é feita pelo sistema SAP.
 

Em Terça-feira, 19 de Dezembro de 2017 15:08, "jlchia...@yahoo.com..br 
[oracle_br]"  escreveu:
 

     Ok que o vc contornou seu 'problema', mas alguma coisa muito esquisita 
estava acontecendo aí : no plano original vc tinha (elimino a coluna do ID e do 
tempo só para caber melhor aqui no post) :


| Operation | Name    | Rows  | Bytes |TempSpc| Cost 
(%CPU)|

| SELECT STATEMENT  | |   |   |   | 54953 
(100)|
|  FILTER   | |   |   |   | 
   |
|   HASH JOIN   | |  1280K|   398M|   277M| 54952   
(1)|
|    TABLE ACCESS BY INDEX ROWID| FAGLFLEXA   |  1280K|   262M|   |  8463   
(1)|
| INDEX RANGE SCAN  | FAGLFLEXA~2 |   398K|   |   |   440   
(1)|
|    TABLE ACCESS BY INDEX ROWID| BKPF    |  2499K|   264M|   | 18178   
(1)|
| INDEX SKIP SCAN   | BKPF~BUT    |  2499K|   |   |  2599   
(2)|



E a nova versão :


-
| Operation  | Name    | Rows  | Bytes | Cost (%CPU)|
-
| SELECT STATEMENT   | |   |   |    11 (100)|
|  FILTER    | |   |   |    |
|   NESTED LOOPS | |   |   |    |
|    NESTED LOOPS    | |    31 | 10075 |    10   (0)|
| TABLE ACCESS BY INDEX ROWID| FAGLFLEXA   |    31 |  6634 | 1   (0)|
|  INDEX RANGE SCAN  | FAGLFLEXA~2 |    10 |   | 1   (0)|
| INDEX UNIQUE SCAN  | BKPF~0  | 1 |   | 0   (0)|
|    TABLE ACCESS BY INDEX ROWID | BKPF    | 1 |   111 | 0   (0)|
-


==> Perceba que as qtdades de linhas envolvidas passaram de coisa de milhão pra 
coisa de dezenas de linhas : vc já tinha disponível esse índice BKPF ? Vc 
recriou (tirando ou adicionando colunas, talvez ?) esse índice FAGLFLEXA~2 ? 
COMO É que o Otimizador errou por uma margem tão larga, estimando no plano 
original que o hash join iria criar (E provavelmente CRIOU, dado o consumo de 
temp space!!) tabela hash de vários milhões E agora no novo plano não chega nem 
perto ?? Será que as Estatísticas estavam assim tão defasadas ??? Ou como eu 
disse vc mudou as regras do jogo, criando um novo índice e/ou alterando os que 
existiam ??

[]s

  Chiappa  #yiv2597863981 #yiv2597863981 -- #yiv2597863981ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv2597863981 
#yiv2597863981ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv2597863981 
#yiv2597863981ygrp-mkp #yiv2597863981hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv2597863981 #yiv2597863981ygrp-mkp #yiv2597863981ads 
{margin-bottom:10px;}#yiv2597863981 #yiv2597863981ygrp-mkp .yiv2597863981ad 
{padding:0 0;}#yiv2597863981 #yiv2597863981ygrp-mkp .yiv2597863981ad p 
{margin:0;}#yiv2597863981 #yiv2597863981ygrp-mkp .yiv2597863981ad a 
{color:#ff;text-decoration:none;}#yiv2597863981 #yiv2597863981ygrp-sponsor 
#yiv2597863981ygrp-lc {font-family:Arial;}#yiv2597863981 
#yiv2597863981ygrp-sponsor #yiv2597863981ygrp-lc #yiv2597863981hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv2597863981 
#yiv2597863981ygrp-sponsor #yiv2597863981ygrp-lc .yiv2597863981ad 
{margin-bottom:10px;padding:0 0;}#yiv2597863981 #yiv2597863981actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv2597863981 
#yiv2597863981activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv2597863981
 #yiv2597863981activity span {font-weight:700;}#yiv2597863981 
#yiv2597863981activity span:first-child 
{text-transform:uppercase;}#yiv2597863981 #yiv2597863981activity span a 
{color:#5085b6;text-decoration:none;}#yiv2597863981 #yiv2597863981activity

Re: [oracle_br] Re: Consulta muito lenta!!

2017-12-19 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Ok que o vc contornou seu 'problema', mas alguma coisa muito esquisita estava 
acontecendo aí : no plano original vc tinha (elimino a coluna do ID e do tempo 
só para caber melhor aqui no post) :


| Operation | Name| Rows  | Bytes |TempSpc| Cost 
(%CPU)|

| SELECT STATEMENT  | |   |   |   | 54953 
(100)|
|  FILTER   | |   |   |   | 
   |
|   HASH JOIN   | |  1280K|   398M|   277M| 54952   
(1)|
|TABLE ACCESS BY INDEX ROWID| FAGLFLEXA   |  1280K|   262M|   |  8463   
(1)|
| INDEX RANGE SCAN  | FAGLFLEXA~2 |   398K|   |   |   440   
(1)|
|TABLE ACCESS BY INDEX ROWID| BKPF|  2499K|   264M|   | 18178   
(1)|
| INDEX SKIP SCAN   | BKPF~BUT|  2499K|   |   |  2599   
(2)|



E a nova versão :


-
| Operation  | Name| Rows  | Bytes | Cost (%CPU)|
-
| SELECT STATEMENT   | |   |   |11 (100)|
|  FILTER| |   |   ||
|   NESTED LOOPS | |   |   ||
|NESTED LOOPS| |31 | 10075 |10   (0)|
| TABLE ACCESS BY INDEX ROWID| FAGLFLEXA   |31 |  6634 | 1   (0)|
|  INDEX RANGE SCAN  | FAGLFLEXA~2 |10 |   | 1   (0)|
| INDEX UNIQUE SCAN  | BKPF~0  | 1 |   | 0   (0)|
|TABLE ACCESS BY INDEX ROWID | BKPF| 1 |   111 | 0   (0)|
-


==> Perceba que as qtdades de linhas envolvidas passaram de coisa de milhão pra 
coisa de dezenas de linhas : vc já tinha disponível esse índice BKPF ? Vc 
recriou (tirando ou adicionando colunas, talvez ?) esse índice FAGLFLEXA~2 ? 
COMO É que o Otimizador errou por uma margem tão larga, estimando no plano 
original que o hash join iria criar (E provavelmente CRIOU, dado o consumo de 
temp space!!) tabela hash de vários milhões E agora no novo plano não chega nem 
perto ?? Será que as Estatísticas estavam assim tão defasadas ??? Ou como eu 
disse vc mudou as regras do jogo, criando um novo índice e/ou alterando os que 
existiam ??

[]s

  Chiappa

Re: [oracle_br] Re: Consulta muito lenta!!

2017-12-19 Por tôpico Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
Luis, segue o novo plano gerado abaixo:

http://textuploader.com/dcjxh
 

Em Terça-feira, 19 de Dezembro de 2017 10:11, "Luis Freitas 
lfreita...@yahoo.com [oracle_br]"  escreveu:
 

     Ola Rafael,
    Você pode postar o plano de execução novo?
Atc,Luis Freitas 

On Monday, December 18, 2017 3:33 PM, "Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br]"  wrote:
 

     PEssoal, o problema foi resolvido.
A solução na qual tomei como base foi a extração do relatório SQLT pelo sqlid 
da consulta. E no SQLT existia a recomendação para criação de um sqlprofile, 
que o ganho seria de 99%, após a criação do sql_profile abaixo
execute dbms_sqltune.accept_sql_profile(task_name => 
'sqlt_s47584_mem',task_owner => 'SYS', replace => TRUE);

A query que rodava em 16 minutos, passou a rodar em 3 segundos.
Valeu pessoal, obrigado a todos. 

Em Sexta-feira, 15 de Dezembro de 2017 19:43, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Bom, pelo prompt de SQL> eu estou SUPONDO que vc optou por criar no 
sqlplus as bind variables todas necessárias e executar o SQL via sqlplus mesmo 
né ? Bom, DEVERIA FUNCIONAR certinho mas pra teste já que é assim mete o hint 
de gather_statistics mesmo no texto que vc entra entrando no sqlplus... Se 
ainda assim não mostrar o A-ROWs E o E-ROWs já repassa essa info pro Suporte 
SAP, é um sinal indicador que alguma coisa tá MUITO diferente nesse banco

[]s

  Chiappa
   

 

 #yiv5858779180 #yiv5858779180 -- #yiv5858779180ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv5858779180 
#yiv5858779180ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv5858779180 
#yiv5858779180ygrp-mkp #yiv5858779180hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv5858779180 #yiv5858779180ygrp-mkp #yiv5858779180ads 
{margin-bottom:10px;}#yiv5858779180 #yiv5858779180ygrp-mkp ..yiv5858779180ad 
{padding:0 0;}#yiv5858779180 #yiv5858779180ygrp-mkp .yiv5858779180ad p 
{margin:0;}#yiv5858779180 #yiv5858779180ygrp-mkp .yiv5858779180ad a 
{color:#ff;text-decoration:none;}#yiv5858779180 #yiv5858779180ygrp-sponsor 
#yiv5858779180ygrp-lc {font-family:Arial;}#yiv5858779180 
#yiv5858779180ygrp-sponsor #yiv5858779180ygrp-lc #yiv5858779180hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv5858779180 
#yiv5858779180ygrp-sponsor #yiv5858779180ygrp-lc .yiv5858779180ad 
{margin-bottom:10px;padding:0 0;}#yiv5858779180 #yiv5858779180actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv5858779180 
#yiv5858779180activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv5858779180
 #yiv5858779180activity span {font-weight:700;}#yiv5858779180 
#yiv5858779180activity span:first-child 
{text-transform:uppercase;}#yiv5858779180 #yiv5858779180activity span a 
{color:#5085b6;text-decoration:none;}#yiv5858779180 #yiv5858779180activity span 
span {color:#ff7900;}#yiv5858779180 #yiv5858779180activity span 
.yiv5858779180underline {text-decoration:underline;}#yiv5858779180 
.yiv5858779180attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv5858779180 .yiv5858779180attach div a 
{text-decoration:none;}#yiv5858779180 .yiv5858779180attach img 
{border:none;padding-right:5px;}#yiv5858779180 .yiv5858779180attach label 
{display:block;margin-bottom:5px;}#yiv5858779180 .yiv5858779180attach label a 
{text-decoration:none;}#yiv5858779180 blockquote {margin:0 0 0 
4px;}#yiv5858779180 .yiv5858779180bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv5858779180 
.yiv5858779180bold a {text-decoration:none;}#yiv5858779180 dd.yiv5858779180last 
p a {font-family:Verdana;font-weight:700;}#yiv5858779180 dd.yiv5858779180last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv5858779180 
dd.yiv5858779180last p span.yiv5858779180yshortcuts 
{margin-right:0;}#yiv5858779180 div.yiv5858779180attach-table div div a 
{text-decoration:none;}#yiv5858779180 div.yiv5858779180attach-table 
{width:400px;}#yiv5858779180 div.yiv5858779180file-title a, #yiv5858779180 
div.yiv5858779180file-title a:active, #yiv5858779180 
div.yiv5858779180file-title a:hover, #yiv5858779180 div.yiv5858779180file-title 
a:visited {text-decoration:none;}#yiv5858779180 div.yiv5858779180photo-title a, 
#yiv5858779180 div.yiv5858779180photo-title a:active, #yiv5858779180 
div.yiv5858779180photo-title a:hover, #yiv5858779180 
div.yiv5858779180photo-title a:visited {text-decoration:none;}#yiv5858779180 
div#yiv5858779180ygrp-mlmsg #yiv5858779180ygrp-msg p a 
span.yiv5858779180yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv5858779180 
.yiv5858779180green {color:#628c2a;}#yiv5858779180 .yiv5858779180MsoNormal 
{margin:0 0 0 0;}#yiv5858779180 o {font-size:0;}#yiv5858779180 
#yiv5858779180photos div {float:left;width:72px;}#yiv5858779180

Re: [oracle_br] Re: Consulta muito lenta!!

2017-12-19 Por tôpico Luis Freitas lfreita...@yahoo.com [oracle_br] 
Ola Rafael,
    Você pode postar o plano de execução novo?
Atc,Luis Freitas 

On Monday, December 18, 2017 3:33 PM, "Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br]"  wrote:
 

     PEssoal, o problema foi resolvido.
A solução na qual tomei como base foi a extração do relatório SQLT pelo sqlid 
da consulta. E no SQLT existia a recomendação para criação de um sqlprofile, 
que o ganho seria de 99%, após a criação do sql_profile abaixo
execute dbms_sqltune.accept_sql_profile(task_name => 
'sqlt_s47584_mem',task_owner => 'SYS', replace => TRUE);

A query que rodava em 16 minutos, passou a rodar em 3 segundos.
Valeu pessoal, obrigado a todos. 

Em Sexta-feira, 15 de Dezembro de 2017 19:43, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Bom, pelo prompt de SQL> eu estou SUPONDO que vc optou por criar no 
sqlplus as bind variables todas necessárias e executar o SQL via sqlplus mesmo 
né ? Bom, DEVERIA FUNCIONAR certinho mas pra teste já que é assim mete o hint 
de gather_statistics mesmo no texto que vc entra entrando no sqlplus... Se 
ainda assim não mostrar o A-ROWs E o E-ROWs já repassa essa info pro Suporte 
SAP, é um sinal indicador que alguma coisa tá MUITO diferente nesse banco

[]s

  Chiappa
   

 #yiv4409151850 #yiv4409151850 -- #yiv4409151850ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv4409151850 
#yiv4409151850ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv4409151850 
#yiv4409151850ygrp-mkp #yiv4409151850hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv4409151850 #yiv4409151850ygrp-mkp #yiv4409151850ads 
{margin-bottom:10px;}#yiv4409151850 #yiv4409151850ygrp-mkp ..yiv4409151850ad 
{padding:0 0;}#yiv4409151850 #yiv4409151850ygrp-mkp .yiv4409151850ad p 
{margin:0;}#yiv4409151850 #yiv4409151850ygrp-mkp .yiv4409151850ad a 
{color:#ff;text-decoration:none;}#yiv4409151850 #yiv4409151850ygrp-sponsor 
#yiv4409151850ygrp-lc {font-family:Arial;}#yiv4409151850 
#yiv4409151850ygrp-sponsor #yiv4409151850ygrp-lc #yiv4409151850hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv4409151850 
#yiv4409151850ygrp-sponsor #yiv4409151850ygrp-lc .yiv4409151850ad 
{margin-bottom:10px;padding:0 0;}#yiv4409151850 #yiv4409151850actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv4409151850 
#yiv4409151850activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv4409151850
 #yiv4409151850activity span {font-weight:700;}#yiv4409151850 
#yiv4409151850activity span:first-child 
{text-transform:uppercase;}#yiv4409151850 #yiv4409151850activity span a 
{color:#5085b6;text-decoration:none;}#yiv4409151850 #yiv4409151850activity span 
span {color:#ff7900;}#yiv4409151850 #yiv4409151850activity span 
.yiv4409151850underline {text-decoration:underline;}#yiv4409151850 
.yiv4409151850attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv4409151850 .yiv4409151850attach div a 
{text-decoration:none;}#yiv4409151850 .yiv4409151850attach img 
{border:none;padding-right:5px;}#yiv4409151850 .yiv4409151850attach label 
{display:block;margin-bottom:5px;}#yiv4409151850 .yiv4409151850attach label a 
{text-decoration:none;}#yiv4409151850 blockquote {margin:0 0 0 
4px;}#yiv4409151850 .yiv4409151850bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv4409151850 
.yiv4409151850bold a {text-decoration:none;}#yiv4409151850 dd.yiv4409151850last 
p a {font-family:Verdana;font-weight:700;}#yiv4409151850 dd.yiv4409151850last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv4409151850 
dd.yiv4409151850last p span.yiv4409151850yshortcuts 
{margin-right:0;}#yiv4409151850 div.yiv4409151850attach-table div div a 
{text-decoration:none;}#yiv4409151850 div.yiv4409151850attach-table 
{width:400px;}#yiv4409151850 div.yiv4409151850file-title a, #yiv4409151850 
div.yiv4409151850file-title a:active, #yiv4409151850 
div.yiv4409151850file-title a:hover, #yiv4409151850 div.yiv4409151850file-title 
a:visited {text-decoration:none;}#yiv4409151850 div.yiv4409151850photo-title a, 
#yiv4409151850 div.yiv4409151850photo-title a:active, #yiv4409151850 
div.yiv4409151850photo-title a:hover, #yiv4409151850 
div.yiv4409151850photo-title a:visited {text-decoration:none;}#yiv4409151850 
div#yiv4409151850ygrp-mlmsg #yiv4409151850ygrp-msg p a 
span.yiv4409151850yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv4409151850 
.yiv4409151850green {color:#628c2a;}#yiv4409151850 .yiv4409151850MsoNormal 
{margin:0 0 0 0;}#yiv4409151850 o {font-size:0;}#yiv4409151850 
#yiv4409151850photos div {float:left;width:72px;}#yiv4409151850 
#yiv4409151850photos div div {border:1px solid 
#66;min-height:62px;overflow:hidden;width:62px;}#yiv4409151850 
#yiv4409151850photos div label

Re: [oracle_br] Re: Consulta muito lenta!!

2017-12-18 Por tôpico Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
PEssoal, o problema foi resolvido.
A solução na qual tomei como base foi a extração do relatório SQLT pelo sqlid 
da consulta. E no SQLT existia a recomendação para criação de um sqlprofile, 
que o ganho seria de 99%, após a criação do sql_profile abaixo
execute dbms_sqltune.accept_sql_profile(task_name => 
'sqlt_s47584_mem',task_owner => 'SYS', replace => TRUE);

A query que rodava em 16 minutos, passou a rodar em 3 segundos.
Valeu pessoal, obrigado a todos. 

Em Sexta-feira, 15 de Dezembro de 2017 19:43, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Bom, pelo prompt de SQL> eu estou SUPONDO que vc optou por criar no 
sqlplus as bind variables todas necessárias e executar o SQL via sqlplus mesmo 
né ? Bom, DEVERIA FUNCIONAR certinho mas pra teste já que é assim mete o hint 
de gather_statistics mesmo no texto que vc entra entrando no sqlplus... Se 
ainda assim não mostrar o A-ROWs E o E-ROWs já repassa essa info pro Suporte 
SAP, é um sinal indicador que alguma coisa tá MUITO diferente nesse banco

[]s

  Chiappa
   #yiv4332546053 #yiv4332546053 -- #yiv4332546053ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv4332546053 
#yiv4332546053ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv4332546053 
#yiv4332546053ygrp-mkp #yiv4332546053hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv4332546053 #yiv4332546053ygrp-mkp #yiv4332546053ads 
{margin-bottom:10px;}#yiv4332546053 #yiv4332546053ygrp-mkp .yiv4332546053ad 
{padding:0 0;}#yiv4332546053 #yiv4332546053ygrp-mkp .yiv4332546053ad p 
{margin:0;}#yiv4332546053 #yiv4332546053ygrp-mkp .yiv4332546053ad a 
{color:#ff;text-decoration:none;}#yiv4332546053 #yiv4332546053ygrp-sponsor 
#yiv4332546053ygrp-lc {font-family:Arial;}#yiv4332546053 
#yiv4332546053ygrp-sponsor #yiv4332546053ygrp-lc #yiv4332546053hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv4332546053 
#yiv4332546053ygrp-sponsor #yiv4332546053ygrp-lc .yiv4332546053ad 
{margin-bottom:10px;padding:0 0;}#yiv4332546053 #yiv4332546053actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv4332546053 
#yiv4332546053activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv4332546053
 #yiv4332546053activity span {font-weight:700;}#yiv4332546053 
#yiv4332546053activity span:first-child 
{text-transform:uppercase;}#yiv4332546053 #yiv4332546053activity span a 
{color:#5085b6;text-decoration:none;}#yiv4332546053 #yiv4332546053activity span 
span {color:#ff7900;}#yiv4332546053 #yiv4332546053activity span 
.yiv4332546053underline {text-decoration:underline;}#yiv4332546053 
.yiv4332546053attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv4332546053 .yiv4332546053attach div a 
{text-decoration:none;}#yiv4332546053 .yiv4332546053attach img 
{border:none;padding-right:5px;}#yiv4332546053 .yiv4332546053attach label 
{display:block;margin-bottom:5px;}#yiv4332546053 .yiv4332546053attach label a 
{text-decoration:none;}#yiv4332546053 blockquote {margin:0 0 0 
4px;}#yiv4332546053 .yiv4332546053bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv4332546053 
.yiv4332546053bold a {text-decoration:none;}#yiv4332546053 dd.yiv4332546053last 
p a {font-family:Verdana;font-weight:700;}#yiv4332546053 dd.yiv4332546053last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv4332546053 
dd.yiv4332546053last p span.yiv4332546053yshortcuts 
{margin-right:0;}#yiv4332546053 div.yiv4332546053attach-table div div a 
{text-decoration:none;}#yiv4332546053 div.yiv4332546053attach-table 
{width:400px;}#yiv4332546053 div.yiv4332546053file-title a, #yiv4332546053 
div.yiv4332546053file-title a:active, #yiv4332546053 
div.yiv4332546053file-title a:hover, #yiv4332546053 div.yiv4332546053file-title 
a:visited {text-decoration:none;}#yiv4332546053 div.yiv4332546053photo-title a, 
#yiv4332546053 div.yiv4332546053photo-title a:active, #yiv4332546053 
div.yiv4332546053photo-title a:hover, #yiv4332546053 
div.yiv4332546053photo-title a:visited {text-decoration:none;}#yiv4332546053 
div#yiv4332546053ygrp-mlmsg #yiv4332546053ygrp-msg p a 
span.yiv4332546053yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv4332546053 
.yiv4332546053green {color:#628c2a;}#yiv4332546053 .yiv4332546053MsoNormal 
{margin:0 0 0 0;}#yiv4332546053 o {font-size:0;}#yiv4332546053 
#yiv4332546053photos div {float:left;width:72px;}#yiv4332546053 
#yiv4332546053photos div div {border:1px solid 
#66;min-height:62px;overflow:hidden;width:62px;}#yiv4332546053 
#yiv4332546053photos div label 
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv4332546053
 #yiv4332546053reco-category {font-size:77%;}#yiv4332546053 
#yiv4332546053reco-desc {font-size:77%;}#yiv4332546053 .yiv4332546053replbq 
{margin:4px;}#yiv4332546053 #yiv4332546053ygrp-actbar div

Re: [oracle_br] Re: Consulta muito lenta!!

2017-12-15 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Bom, pelo prompt de SQL> eu estou SUPONDO que vc optou por criar no sqlplus as 
bind variables todas necessárias e executar o SQL via sqlplus mesmo né ? Bom, 
DEVERIA FUNCIONAR certinho mas pra teste já que é assim mete o hint de 
gather_statistics mesmo no texto que vc entra entrando no sqlplus... Se ainda 
assim não mostrar o A-ROWs E o E-ROWs já repassa essa info pro Suporte SAP, é 
um sinal indicador que alguma coisa tá MUITO diferente nesse banco

[]s

  Chiappa

Re: [oracle_br] Re: Consulta muito lenta!!

2017-12-15 Por tôpico Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
Exatamente pessoal, estou de acordo com voces. O chamado com a SAP ja esta 
aberto, e so alteramos algo com a autorizacao da SAP.
Chiappa, realizei o que vc me pediu, mas nao obtive sucesso, o plano de 
execucao soh me mostra o E-rows.
Alterei o parametro a nivel de sessao.
Note-   - Warning: basic plan statistics not available. These are only 
collected when:       * hint 'gather_plan_statistics' is used for the statement 
or       * parameter 'statistics_level' is set to 'ALL', at session or system 
level

51 rows selected.
SQL> show parameter statistics_level
NAME                                 TYPE        
VALUE --- 
--statistics_level                     string      
ALL
 

Em Sexta-feira, 15 de Dezembro de 2017 16:20, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Verdade verdadeiríssima, por isso na minha resposta frisei bem :

"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!!!
 "

Eu fiquei o ano passado dando Suporte em banco de dados Oracle numa Consultoria 
especializada em SAP e tools de Report/DW/Bi baseadas no SAP, então fiquei 
sabendo quem o quão fechada e exigente ela é  Sem a menor dúvida, falou em 
SAP antes de mais nada abrir Chamado, E pra qualquer coisa que for fazer, pedir 
Anuência deles

[]s

  Chiappa  #yiv9629188119 #yiv9629188119 -- #yiv9629188119ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9629188119 
#yiv9629188119ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9629188119 
#yiv9629188119ygrp-mkp #yiv9629188119hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv9629188119 #yiv9629188119ygrp-mkp #yiv9629188119ads 
{margin-bottom:10px;}#yiv9629188119 #yiv9629188119ygrp-mkp .yiv9629188119ad 
{padding:0 0;}#yiv9629188119 #yiv9629188119ygrp-mkp .yiv9629188119ad p 
{margin:0;}#yiv9629188119 #yiv9629188119ygrp-mkp .yiv9629188119ad a 
{color:#ff;text-decoration:none;}#yiv9629188119 #yiv9629188119ygrp-sponsor 
#yiv9629188119ygrp-lc {font-family:Arial;}#yiv9629188119 
#yiv9629188119ygrp-sponsor #yiv9629188119ygrp-lc #yiv9629188119hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9629188119 
#yiv9629188119ygrp-sponsor #yiv9629188119ygrp-lc .yiv9629188119ad 
{margin-bottom:10px;padding:0 0;}#yiv9629188119 #yiv9629188119actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9629188119 
#yiv9629188119activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9629188119
 #yiv9629188119activity span {font-weight:700;}#yiv9629188119 
#yiv9629188119activity span:first-child 
{text-transform:uppercase;}#yiv9629188119 #yiv9629188119activity span a 
{color:#5085b6;text-decoration:none;}#yiv9629188119 #yiv9629188119activity span 
span {color:#ff7900;}#yiv9629188119 #yiv9629188119activity span 
.yiv9629188119underline {text-decoration:underline;}#yiv9629188119 
.yiv9629188119attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv9629188119 .yiv9629188119attach div a 
{text-decoration:none;}#yiv9629188119 .yiv9629188119attach img 
{border:none;padding-right:5px;}#yiv9629188119 .yiv9629188119attach label 
{display:block;margin-bottom:5px;}#yiv9629188119 .yiv9629188119attach label a 
{text-decoration:none;}#yiv9629188119 blockquote {margin:0 0 0 
4px;}#yiv9629188119 .yiv9629188119bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv9629188119 
.yiv9629188119bold a {text-decoration:none;}#yiv9629188119 dd.yiv9629188119last 
p a {font-family:Verdana;font-weight:700;}#yiv9629188119 dd.yiv9629188119last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv9629188119 
dd.yiv9629188119last p span.yiv9629188119yshortcuts 
{margin-right:0;}#yiv9629188119 div.yiv9629188119attach-table div div a 
{text-decoration:none;}#yiv9629188119 div.yiv9629188119attach-table 
{width:400px;}#yiv9629188119 div.yiv9629188119file-title a, #yiv9629188119 
div.yiv9629188119file-title a:active, #yiv9629188119 
div.yiv9629188119file-title a:hover, #yiv9629188119 div.yiv9629188119file-title 
a:visited {text-decoration:none;}#yiv9629188119 div.yiv9629188119photo-title a, 
#yiv9629188119 div.yiv9629188119photo-title a:active, #yiv9629188119 
div.yiv9629188119photo-title a:hover, #yiv9629188119 
div.yiv9629188119photo-title a:visited {text-decoration:none;}#yiv9629188119 
div#yiv9629188119ygrp-mlmsg #yiv9629188119ygrp-msg p a 
span.yiv9629188119yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv9629188119 
.yiv9629188119green {color:#628c2a;}#yiv9629188119

Re: [oracle_br] Re: Consulta muito lenta!!

2017-12-15 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Verdade verdadeiríssima, por isso na minha resposta frisei bem :

"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!!!
 "

Eu fiquei o ano passado dando Suporte em banco de dados Oracle numa Consultoria 
especializada em SAP e tools de Report/DW/Bi baseadas no SAP, então fiquei 
sabendo quem o quão fechada e exigente ela é  Sem a menor dúvida, falou em 
SAP antes de mais nada abrir Chamado, E pra qualquer coisa que for fazer, pedir 
Anuência deles

[]s

  Chiappa

Re: [oracle_br] Re: Consulta muito lenta!!

2017-12-15 Por tôpico Juliano Ribeiro julianonoiz...@yahoo.com.br [oracle_br] 
Boa tarde a todos,

​Gostaria apenas de complementar com um experiência que já tive com a SAP.​


O pessoal passou varias dicas boas, para tratar o seu caso/situação,
entendo que na vontade de melhorar e/ou resolver acabamos fazendo essas
"alternativas", que muitas vezes são "pontuais", "temporárias" e por fim
acabem sendo definitivas.
Mas recomendo fortemente consultar a SAP antes de exe​cutar qualquer
procedimento no ambiente, digo isso porque geralmente eles se
​eximem ​de suportar ambientes decorrentes de alterações não autorizadas
​ ou de acordo com recomendações deles​
.
Isso vem em contrato, já tomei chicotadas na vida por causa disso, por
melhor que seja a intensão de melhorar, você pode acabar de prejudicando
futuramente.
​ Porque quando da "cagada" qualquer coisa é justificativa.​


E
​m nenhum momento estou te dizendo o que fazer, apenas queria ajudar,
compartilhando uma má experiência que ja vivi com ambiente SAP.
​
Abraços.

Att.

*Juliano Ribeiro*
http://br.linkedin.com/in/supernoi


Em 15 de dezembro de 2017 15:08, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
>
> Sim, exatamente o que sugeri na minha Obs lá pro colega : fora de prod
> testar hints, alter sessions mexendo em params do CBO, profiles, e tudo o
> mais
>
> []s
>
> Chiappa
>
> ---Em oracle_br@yahoogrupos.com.br,  escreveu:
>
> olá, boa tarde!
>
> você poderia testar o hint /*+ use_nl()*/ e ve se o resuldato melhora?
>
> se o resultado for satisfatorio, você pode aplicar esse plano para a sua
> query, com a criação de uma profile.
>
> Att,
>
>
> Em Sexta-feira, 15 de Dezembro de 2017 14:28, "jlchia...@yahoo.com.br
> [oracle_br]"  escreveu:
>
>
>
> 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

Re: [oracle_br] Re: Consulta muito lenta!!

2017-12-15 Por tôpico jlchia...@yahoo.com.br [oracle_br] 

 Sim, exatamente o que sugeri na minha Obs lá pro colega : fora de prod testar 
hints, alter sessions mexendo em params do CBO, profiles, e tudo o mais
 

 []s
 

 Chiappa
 

 ---Em oracle_br@yahoogrupos.com.br,  escreveu:

 olá, boa tarde!
 

 você poderia testar o hint /*+ use_nl()*/ e ve se o resuldato melhora?
 

 se o resultado for satisfatorio, você pode aplicar esse plano para a sua 
query, com a criação de uma profile.
 

 
 Att,
 


 Em Sexta-feira, 15 de Dezembro de 2017 14:28, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:

 

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

Re: [oracle_br] Re: Consulta muito lenta!!

2017-12-15 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Usa a opção de criar BIND VARIABLEs da tua tool cliente (no SQLPLUS seria 
VARIABLE, por exemplo) e cria todos os BINDs necessários e bota os valores 
neles , ou AINDA MELHOR, se for possível vc alterar apenas uma sessão na 
aplicação pra executar com o parâmetro de STATISTICS_LEVEL para all (via ALTER 
SESSION SET STATISTICS_LEVEL=ALL numa trigger de logon que dispara só pra 
sessão/usuário/serviço/seja o que for que vc está usando pra testes, talvez) vc 
faz isso : esse parâmetro STATISTICS_LEVEL pode ser setado a nível de sessão ou 
de banco, e faz o mesmo que o HINt de GATHER STATISTICS...

[]s

  Chiappa

Re: [oracle_br] Re: Consulta muito lenta!!

2017-12-15 Por tôpico Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
Chiappa, a recomendacao foi da SAP, irei checar todas essas informacoes 
passadas por voces, no fim do dia darei um retorno aqui.
Em relacao ao plano extendido com SELECT /*+ GATHER_PLAN_STATISTICS */como eu 
vou executar com as variaveis bind? Com variavel bind o select me retorna o 
erro informando que nao reconhece aquele valor obviamente.


SP2-0552: Bind variable "A4" not declared.
 

Em Sexta-feira, 15 de Dezembro de 2017 14:28, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     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...  #yiv8130852198 
#yiv8130852198 -- #yiv8130852198ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv8130852198 
#yiv8130852198ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv8130852198 
#yiv8130852198ygrp-mkp #yiv8130852198hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv8130852198 #yiv8130852198ygrp-mkp #yiv8130852198ads 
{margin-bottom:10px;}#yiv8130852198 #yiv8130852198ygrp-mkp .yiv8130852198ad 
{padding:0 0;}#yiv8130852198 #yiv8130852198ygrp-mkp .yiv8130852198ad p 
{margin:0;}#yiv8130852198 #yiv8130852198ygrp-mkp .yiv8130852198ad a 
{color:#ff;text-decoration:none;}#yiv8130852198 #yiv8130852198ygrp-sponsor

Re: [oracle_br] Re: Consulta muito lenta!!

2017-12-15 Por tôpico Junior Cesar juniorcesa...@yahoo.com.br [oracle_br] 
olá, boa tarde!
você poderia testar o hint /*+ use_nl()*/ e ve se o resuldato melhora?
se o resultado for satisfatorio, você pode aplicar esse plano para a sua query, 
com a criação de uma profile.
Att, 

Em Sexta-feira, 15 de Dezembro de 2017 14:28, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     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...  #yiv5259282637 
#yiv5259282637 -- #yiv5259282637ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv5259282637 
#yiv5259282637ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv5259282637 
#yiv5259282637ygrp-mkp #yiv5259282637hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv5259282637 #yiv5259282637ygrp-mkp #yiv5259282637ads 
{margin-bottom:10px;}#yiv5259282637 #yiv5259282637ygrp-mkp .yiv5259282637ad 
{padding:0 0;}#yiv5259282637 #yiv5259282637ygrp-mkp .yiv5259282637ad p 
{margin:0;}#yiv5259282637 #yiv5259282637ygrp-mkp .yiv5259282637ad a 
{color:#ff;text-decoration:none;}#yiv5259282637 #yiv5259282637ygrp-sponsor 
#yiv5259282637ygrp-lc {font-family:Arial;}#yiv5259282637 
#yiv5259282637ygrp-sponsor #yiv5259282637ygrp-lc #yiv5259282637hd {margin:10px