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: CLUSTERING FACTOR

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 14:58, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Bom, primero pergunto, quanto é 400KK - seria 400 mil milhares, ie, 400 
milhões ?? E segundo sorry, mas NÚMERO DE LINHAS não é significativo pra gente 
isoladamente - esse X de linhas representa QUANTOS BYTES/megabytes/gigabytes 
efetivamente ?? E terceiro ponto, como está a Média de linhas por bloco físico 
nessa tabela ?

 Mas de qquer maneira : a primeira coisa que TENHO que observar é que o CLUSTER 
FACTOR é relacionado com a localização Física dos dados indexados na tabela : 
Obviamente, não tem como Fisicamente a mesma tabela ter os dados ordenados pela 
coluna X ** e ** pela coluna Y ao mesmo tempo, então fique CIENTE que se vc 
alterar/melhorar o cluster factor da tabela em relação a um índice A, muito 
certamente vc vai PIORAR em relação a um índice B... Lógico 
  Julgando por esse nome de IN_ESTENTRADA_LOTEAPRES2 , me parece que esse Não É 
o único índice dessa tabela, então VEJA LÁ se mexendo no CF de um ídnice vc Não 
Estraga o de outro índice, usado por OUTRAs Consultas Legal ??
  
 Isso posto, aí sim a sua resposta... Primeiro teste, cfrme 
http://www.oracle.com/technetwork/issue-archive/2012/12-sep/o52asktom-1735913.html
 e 
https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:9524251800346726054
 (e os links deste último) demonstram sim, para vc alterar o CF é fisicamente 
recriar a tabela Tenta em primeiro lugar ao invés de TRUNCAR a tabela e 
reinserir os dados (o que vai reaproveitar o mesmo segmento MAS adicionando 
novos extents) criar uma NOVA tabela (chame de TAB_ORGANIZED) com os dados 
vindos da tabela em análise ordenados num CREATE TABLE AS SELECT e depois 
criando um índice , como mostrado no primeiro link... Pra ser mais seguro 
ainda, faça isso numa tablespace LMT com gerenciamento automático... 
==> SE esse teste não resultar em alteração nenhuma do CF a gente começa a 
suspeitar de algum atributo físico que esteja 'forçando' os dados a se espalhar 
por N blocos : talvez um registro lógico extenso ?? Montes e montes de colunas 
na tabela em questão ?? OBVIAMENTE, se os dados não couberem com mita folga 
dentro do bloco, algum tipo de row chaining/row migration vai ser quase certo, 
aí o CF vai pras picas...

[]s

  Chiappa  #yiv2246574670 #yiv2246574670 -- #yiv2246574670ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv2246574670 
#yiv2246574670ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv2246574670 
#yiv2246574670ygrp-mkp #yiv2246574670hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv2246574670 #yiv2246574670ygrp-mkp #yiv2246574670ads 
{margin-bottom:10px;}#yiv2246574670 #yiv2246574670ygrp-mkp .yiv2246574670ad 
{padding:0 0;}#yiv2246574670 #yiv2246574670ygrp-mkp .yiv2246574670ad p 
{margin:0;}#yiv2246574670 #yiv2246574670ygrp-mkp .yiv2246574670ad a 
{color:#ff;text-decoration:none;}#yiv2246574670 #yiv2246574670ygrp-sponsor 
#yiv2246574670ygrp-lc {font-family:Arial;}#yiv2246574670 
#yiv2246574670ygrp-sponsor #yiv2246574670ygrp-lc #yiv2246574670hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv2246574670 
#yiv2246574670ygrp-sponsor #yiv2246574670ygrp-lc .yiv2246574670ad 
{margin-bottom:10px;padding:0 0;}#yiv2246574670 #yiv2246574670actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv2246574670 
#yiv2246574670activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv2246574670
 #yiv2246574670activity span {font-weight:700;}#yiv2246574670 
#yiv2246574670activity span:first-child 
{text-transform:uppercase;}#yiv2246574670 #yiv2246574670activity span a 
{color:#5085b6;text-decoration:none;}#yiv2246574670 #yiv2246574670activity span 
span {color:#ff7900;}#yiv2246574670 #yiv2246574670activity span 
.yiv2246574670underline {text-decoration:underline;}#yiv2246574670 
.yiv2246574670attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv2246574670 .yiv2246574670attach div a 
{text-decoration:none;}#yiv2246574670 .yiv2246574670attach img

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

[oracle_br] Re: CLUSTERING FACTOR

2017-12-15 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Bom, primero pergunto, quanto é 400KK - seria 400 mil milhares, ie, 400 milhões 
?? E segundo sorry, mas NÚMERO DE LINHAS não é significativo pra gente 
isoladamente - esse X de linhas representa QUANTOS BYTES/megabytes/gigabytes 
efetivamente ?? E terceiro ponto, como está a Média de linhas por bloco físico 
nessa tabela ?

 Mas de qquer maneira : a primeira coisa que TENHO que observar é que o CLUSTER 
FACTOR é relacionado com a localização Física dos dados indexados na tabela : 
Obviamente, não tem como Fisicamente a mesma tabela ter os dados ordenados pela 
coluna X ** e ** pela coluna Y ao mesmo tempo, então fique CIENTE que se vc 
alterar/melhorar o cluster factor da tabela em relação a um índice A, muito 
certamente vc vai PIORAR em relação a um índice B... Lógico 
  Julgando por esse nome de IN_ESTENTRADA_LOTEAPRES2 , me parece que esse Não É 
o único índice dessa tabela, então VEJA LÁ se mexendo no CF de um ídnice vc Não 
Estraga o de outro índice, usado por OUTRAs Consultas Legal ??
  
 Isso posto, aí sim a sua resposta... Primeiro teste, cfrme 
http://www.oracle.com/technetwork/issue-archive/2012/12-sep/o52asktom-1735913.html
 e 
https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:9524251800346726054
 (e os links deste último) demonstram sim, para vc alterar o CF é fisicamente 
recriar a tabela Tenta em primeiro lugar ao invés de TRUNCAR a tabela e 
reinserir os dados (o que vai reaproveitar o mesmo segmento MAS adicionando 
novos extents) criar uma NOVA tabela (chame de TAB_ORGANIZED) com os dados 
vindos da tabela em análise ordenados num CREATE TABLE AS SELECT e depois 
criando um índice , como mostrado no primeiro link... Pra ser mais seguro 
ainda, faça isso numa tablespace LMT com gerenciamento automático... 
==> SE esse teste não resultar em alteração nenhuma do CF a gente começa a 
suspeitar de algum atributo físico que esteja 'forçando' os dados a se espalhar 
por N blocos : talvez um registro lógico extenso ?? Montes e montes de colunas 
na tabela em questão ?? OBVIAMENTE, se os dados não couberem com mita folga 
dentro do bloco, algum tipo de row chaining/row migration vai ser quase certo, 
aí o CF vai pras picas...

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

[oracle_br] Re: Consulta muito lenta!!

2017-12-15 Por tôpico 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...

Re: [oracle_br] CLUSTERING FACTOR

2017-12-15 Por tôpico Luis Freitas lfreita...@yahoo.com [oracle_br] 
   Esse "CLUSTERING_FACTOR" também não conhecia :-). Não caiu na prova do OCP, 
rs.
http://www.oracle.com/technetwork/issue-archive/2012/12-sep/o52asktom-1735913.html

   "In short, the index clustering factor is a measure of how many I/Os the 
database would perform if it were to read every row in that table via the index 
in index order. If the rows of a table on disk are sorted in about the same 
order as the index keys, the database will perform a minimum number of I/Os on 
the table to read the entire table via the index."
    Então, se você recriar a tabela ordenando ela pela chave do índice, em vez 
do campo de data, deve melhorar essa estatística. Mas eu só faria isso se 
realmente esse índice for muito importante para as suas queries.
Atc,Luis Freitas 

On Friday, December 15, 2017 12:59 PM, "ydisco...@hotmail.com [oracle_br]" 
 wrote:
 

     Olá, Pessoal!

Tenho uma TABELA de 400KK rows que está com o INDICE com o CLUSTERING FACTOR 
muito alto. ocasionando alto I/O na TABELA. 
Quanto mais próximo ao número de blocos da tabela oCLUSTERING FACTOR estiver, 
maior será a efetividade do index, pois menos I/Osserão necessários para 
acessar os dados. Caso esteja mais próximo do número delinhas da tabela, 
provavelmente este index não será de muita serventia durantea execução de 
nossas queries em muitas situações.
Quais são as maneiras de diminuir o CF?

1. Rebuild do índice, não diminuiu.
2. Passei os dados para outra tabela e trunquei a original, passei os dados 
novamente para a tabela original com a query abaixo, e posteriormente fiz o 
Rebuild. Sem sucesso para diminuir o CF. 3. Alguem tem alguma outra forma?
DECLARE  CURSOR c1 IS  SELECT *FROM dbsngpc.tb_estoque_entrada ORDER BY 
co_seq_estoque_entrada;    TYPE fetch_array IS TABLE OF C1%ROWTYPE;  cur1 
fetch_array;  BEGIN  OPEN c1;  LOOP    EXIT  WHEN c1%notfound;    FETCH c1 bulk 
collect INTO cur1 limit5;        forall i IN 1..CUR1.count  INSERT 
/*+APPEND NOLOGGING */ INTO precise.tb_estoque_entrada2VALUES cur1(i); 
COMMIT;   END LOOP;  CLOSE c1;  COMMIT; END;/

INFO:TABELA exec 
dbms_stats.gather_table_stats('PRECISE','TB_ESTOQUE_ENTRADA2',cascade=>TRUE, 
estimate_percent=>100, method_opt=>'FOR ALL COLUMNSSIZE AUTO', 
granularity=>'ALL', degree=>24);    
SELECTsegment_name,blocks,extents,bytes/(1024*1024*1024) AS GB FROM 
dba_segmentsWHERE segment_name='TB_ESTOQUE_ENTRADA2';    
|  SEGMENT_NAME  |  SEGMENT_TYPE  |  BLOCKS  |  EXTENTS  |  GB  |  ROWS  |
|  TB_ESTOQUE_ENTRADA2      
|  TABLE   |  5.438.208  |  850  |  41,49  |  414.612.027  |

  
INDICEExec dbms_stats.gather_index_stats('DBSNGPC','IN_ESTENTRADA_LOTEAPRES');  
 SELECTsegment_name,segment_type,blocks,extents,bytes/(1024*1024*1024) AS GB 
FROMdba_segments WHERE segment_name='IN_ESTENTRADA_LOTEAPRES2';  
|  SEGMENT_NAME  |  SEGMENT_TYPE  |  BLOCKS  |  EXTENTS  |  GB  |
|  IN_ESTENTRADA_LOTEAPRES2 
     |  INDEX     |  1.363.712  |  363  |  10,40  |

  SELECTindex_name,clustering_factor,num_rows FROM dba_indexes 
WHEREindex_name='IN_ESTENTRADA_LOTEAPRES2';  
|  INDEX_NAME  |  CLUSTERING_FACTOR  |  NUM_ROWS  |
|  IN_ESTENTRADA_LOTEAPRES2 
     |  390.699178  |  414.612.027  |

  
Grata,


  #yiv1032351243 #yiv1032351243 -- #yiv1032351243ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv1032351243 
#yiv1032351243ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv1032351243 
#yiv1032351243ygrp-mkp #yiv1032351243hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv1032351243 #yiv1032351243ygrp-mkp #yiv1032351243ads 
{margin-bottom:10px;}#yiv1032351243 #yiv1032351243ygrp-mkp .yiv1032351243ad 
{padding:0 0;}#yiv1032351243 #yiv1032351243ygrp-mkp .yiv1032351243ad p 
{margin:0;}#yiv1032351243 #yiv1032351243ygrp-mkp .yiv1032351243ad a 
{color:#ff;text-decoration:none;}#yiv1032351243 #yiv1032351243ygrp-sponsor 
#yiv1032351243ygrp-lc {font-family:Arial;}#yiv1032351243 
#yiv1032351243ygrp-sponsor #yiv1032351243ygrp-lc #yiv1032351243hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv1032351243 
#yiv1032351243ygrp-sponsor #yiv1032351243ygrp-lc .yiv1032351243ad 
{margin-bottom:10px;padding:0 0;}#yiv1032351243 #yiv1032351243actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv1032351243 
#yiv1032351243activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv1032351243
 #yiv1032351243activity span {font-weight:700;}#yiv1032351243 
#yiv1032351243activity span:first-child 
{text-transform:uppercase;}#yiv1032351243 #yiv1032351243activity span a 
{color:#5085b6;text-decoration:none;}#yiv1032351243 #yiv1032351243activity span 
span {color:#ff7900;}#yiv1032351243 #yiv1032351243activity span 
.yiv1032351243underline {text-decoration:underline;}#yiv1032351243

Re: [oracle_br] Consulta muito lenta!!

2017-12-15 Por tôpico Luis Freitas lfreita...@yahoo.com [oracle_br] 
Rafael,
   Não conhecia esse recurso do "SQL Patch", costumo usar o "SQL Plan 
Management", dbms_spm.alter_sql_plan_baseline.
   Quantos registros retornam efetivamente na consulta? Algumas dezenas ou 
milhares?
    Outra opção que talvez tenha um efeito grande é gerar histogramas nos 
campos de maior e menor cardinalidade, para que o Oracle possa escolher o plano 
com mais informações.
Atc,Luis Freitas     

On Friday, December 15, 2017 12:36 PM, "Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br]"  wrote:
 

     Obrigado pelo rapido retorno pessoal.
Mulafani - sempre me ajudando... obrigado, porem esse caso de criar indice 
bitmap em ambiente OLTP e principalmente em tabelas extremamentes utilizadas em 
operacoes DML, essa opcao infelizmente nao vem ao caso.

Luis Freitas, criei 2 sql patches para forcar o Oracle a realizar nested loops 
ao inves de hash join porem sem sucesso, segue o codigo abaixo:

obs: repare que no final do plano de execucao, aparece: SQL patch 
"suggest_support_sap" used for this statement
Segue codigo:

http://textuploader.com/dc9sm


Tambem tentei criar um sql patch com paralelismo, mas a mesma nao utilizou, 
irei verificar os outros pontos, testarei e trarei para voces sem seguida.

 

Em Sexta-feira, 15 de Dezembro de 2017 12:23, "Rodrigo Mufalani 
rodr...@mufalani.com.br [oracle_br]"  escreveu:
 

     Bom dia,

 Uma coisa que talvez o teu ambiente tenha de sobra, e já que está usando EE, 
pense em usar DOP (PARALLEL) para essas tabelas assim a consulta vai rodar mais 
rápido.

 Dá uma lida no manual 
https://docs.oracle.com/cd/E11882_01/server.112/e25554/indexes.htm#sthref120

CREATE BITMAP INDEX sales_cust_gender_bjix
ON sales(customers.cust_gender)
FROM sales, customers
WHERE sales.cust_id = customers.cust_id
LOCAL NOLOGGING COMPUTE STATISTICS;
 OBS.: Lembrando que bitmap índexes tem que ser usados com muito cuidado, por 
conta de locks e que o paralelismo pode usar todos os recursos, verifique, 
monte um cenário de testes antes de aplicar isso em prod. OK?

Atenciosamente,
[RED]

Rodrigo Mufalani - Dir. Técnico
rodr...@mufalani.com.br
+55 21 988 994 817

Mufalani
+55 21 3193 0326
Rua Almirante Grenfall, 405, Bloco 3, Sala 310
Centro Empresarial Washington Luiz
Duque de Caxias - RJ
CEP 25085-009
www.mufalani.com.br


[id:image002.png@01D2F4C6.8E6B3BE0]



De:  em nome de "Luis Freitas 
lfreita...@yahoo.com [oracle_br]" 
Responder para: "oracle_br@yahoogrupos.com.br" 
Data: sexta-feira, 15 de dezembro de 2017 12:09
Para: "oracle_br@yahoogrupos.com.br" 
Assunto: Re: [oracle_br] Consulta muito lenta!!


Rafael,

 Difícil sugerir alguma coisa só com o plano de execução, sem saber a 
cardinalidade campos usados na query.

 O tempo maior do plano está aparecendo como CPU, e está proximo do tempo que 
você reportou, algumas coisas que poderiam ser tentadas:

- Forçar o uso de algum índice no campo RACCT, que é o numero da conta. Se 
houver uma cardinalidade grande nesse campo, pode reduzir muito o tempo de 
execução.

- Forçar um full scan na FAGLFLEXA, o que deve mudar o perfil da query de CPU 
para disco.

- Forçar um join por "nested loops", em vez de "hash". Também deve mudar o 
perfil de CPU para disco.

 Outra coisa que pode ser tentada é ativar o paralelismo na FAGLFLEXA, o que 
irá distribuir a execução da query em mais processos. Poderia ser feito por 
"sql plan management" para não ativar direto na tabela.

Atc,
Luis Freitas




On Friday, December 15, 2017 10:57 AM, "Rafael Mendonca raffaell.t...@yahoo.com 
[oracle_br]"  wrote:


Senhores, bom dia.

Preciso de uma grande ajuda dos especialistas.

Ambiente single instance, file system, EE 11.2.0.3
Options: diagnostic and tuning pack, in memory, advanced compression, 
partitioning


Possuo uma query do sistema SAP (standard SAP), ou seja, nao existe alternativa 
para mudança estrutural da consulta, nem por hint na consulta, nem nada, por 
ser standard. O que é possível fazer é tudo a nível de banco de dados, como 
criação de sql patch, rewrite etc...

Pois bem, vamos aos detalhes:

A consulta envolve 2 tabelas e 2 índices, cada um com seus respectivos tamanhos 
abaixo:

tabela x1: 400GB
tabela x2:160GB
Indice tab x1: 140GB
Indice tab x2: 2GB

Duracao da consulta: 16 minutos

OBS: Os segmentos envoldios nao possuem PARTICIONAMENTO ou COMPRESSAO.

COnsulta abaixo:

http://textuploader.com/dcreu


Plano de execucao abaixo (SELECT * FROM table(dbms_xplan.display_cursor)):

http://textuploader.com/dcre7



Alternativas 1:

A criacao de uma Mview para a consulta em questao, porem o SAP nao pode 
direcionar o relatorio para a MVIew, entao pensei na rewrite para forcar ao ler 
o sqlid utilizar Mview, porem se as mview nao estiver totalmente atualizada com 
as tabelas envolvidas a

[oracle_br] CLUSTERING FACTOR

2017-12-15 Por tôpico ydisco...@hotmail.com [oracle_br] 
Olá, Pessoal!

 Tenho uma TABELA de 400KK rows que está com o INDICE com o CLUSTERING FACTOR 
muito alto. ocasionando alto I/O na TABELA. 
 

 Quanto mais próximo ao número de blocos da tabela o CLUSTERING FACTOR estiver, 
maior será a efetividade do index, pois menos I/Os serão necessários para 
acessar os dados. Caso esteja mais próximo do número de linhas da tabela, 
provavelmente este index não será de muita serventia durante a execução de 
nossas queries em muitas situações.
 

 Quais são as maneiras de diminuir o CF?

1. Rebuild do índice, não diminuiu.
2. Passei os dados para outra tabela e trunquei a original, passei os dados 
novamente para a tabela original com a query abaixo, e posteriormente fiz o 
Rebuild. Sem sucesso para diminuir o CF. 
 3. Alguem tem alguma outra forma?
 

 DECLARE
   CURSOR c1 IS
  
 SELECT * FROM dbsngpc.tb_estoque_entrada ORDER BY co_seq_estoque_entrada;
   
   TYPE fetch_array IS TABLE OF C1%ROWTYPE;
   cur1 fetch_array;
   
 BEGIN
   OPEN c1;
   LOOP
 EXIT
   WHEN c1%notfound;
 FETCH c1 bulk collect INTO cur1 limit 5;
 
 forall i IN 1..CUR1.count
  
 INSERT /*+ APPEND NOLOGGING */ INTO precise.tb_estoque_entrada2 VALUES cur1(i);
  
 COMMIT;
  
   END LOOP;
   CLOSE c1;
   COMMIT;
  END;
 
 /
 


 

 INFO:
 TABELA
 exec dbms_stats.gather_table_stats('PRECISE','TB_ESTOQUE_ENTRADA2', 
cascade=>TRUE, estimate_percent=>100, method_opt=>'FOR ALL COLUMNS SIZE AUTO', 
granularity=>'ALL', degree=>24);
  
 SELECT segment_name,blocks,extents,bytes/(1024*1024*1024) AS GB FROM 
dba_segments WHERE segment_name='TB_ESTOQUE_ENTRADA2';
  
 SEGMENT_NAME
 SEGMENT_TYPE
 BLOCKS
 EXTENTS
 GB
 ROWS
 TB_ESTOQUE_ENTRADA2
 TABLE 
 5.438.208
 850
 41,49
 414.612.027
  
 

 INDICE
 Exec dbms_stats.gather_index_stats('DBSNGPC','IN_ESTENTRADA_LOTEAPRES'); 
  
 SELECT segment_name,segment_type,blocks,extents,bytes/(1024*1024*1024) AS GB 
FROM dba_segments WHERE segment_name='IN_ESTENTRADA_LOTEAPRES2';
  
 SEGMENT_NAME
 SEGMENT_TYPE
 BLOCKS
 EXTENTS
 GB
 IN_ESTENTRADA_LOTEAPRES2   
 
 INDEX   
 1.363.712
 363
 10,40
  
 SELECT index_name,clustering_factor,num_rows FROM dba_indexes WHERE 
index_name='IN_ESTENTRADA_LOTEAPRES2';
  
 INDEX_NAME
 CLUSTERING_FACTOR
 NUM_ROWS
 IN_ESTENTRADA_LOTEAPRES2   
 
 390.699178
 414.612.027
 
  
 


 Grata,

Re: [oracle_br] Consulta muito lenta!!

2017-12-15 Por tôpico Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
Obrigado pelo rapido retorno pessoal.
Mulafani - sempre me ajudando... obrigado, porem esse caso de criar indice 
bitmap em ambiente OLTP e principalmente em tabelas extremamentes utilizadas em 
operacoes DML, essa opcao infelizmente nao vem ao caso.

Luis Freitas, criei 2 sql patches para forcar o Oracle a realizar nested loops 
ao inves de hash join porem sem sucesso, segue o codigo abaixo:

obs: repare que no final do plano de execucao, aparece: SQL patch 
"suggest_support_sap" used for this statement
Segue codigo:

http://textuploader.com/dc9sm


Tambem tentei criar um sql patch com paralelismo, mas a mesma nao utilizou, 
irei verificar os outros pontos, testarei e trarei para voces sem seguida.

 

Em Sexta-feira, 15 de Dezembro de 2017 12:23, "Rodrigo Mufalani 
rodr...@mufalani.com.br [oracle_br]"  escreveu:
 

     Bom dia,

 Uma coisa que talvez o teu ambiente tenha de sobra, e já que está usando EE, 
pense em usar DOP (PARALLEL) para essas tabelas assim a consulta vai rodar mais 
rápido.

 Dá uma lida no manual 
https://docs.oracle.com/cd/E11882_01/server.112/e25554/indexes.htm#sthref120

CREATE BITMAP INDEX sales_cust_gender_bjix
ON sales(customers.cust_gender)
FROM sales, customers
WHERE sales.cust_id = customers.cust_id
LOCAL NOLOGGING COMPUTE STATISTICS;
 OBS.: Lembrando que bitmap índexes tem que ser usados com muito cuidado, por 
conta de locks e que o paralelismo pode usar todos os recursos, verifique, 
monte um cenário de testes antes de aplicar isso em prod. OK?

Atenciosamente,
[RED]

Rodrigo Mufalani - Dir. Técnico
rodr...@mufalani.com.br
+55 21 988 994 817

Mufalani
+55 21 3193 0326
Rua Almirante Grenfall, 405, Bloco 3, Sala 310
Centro Empresarial Washington Luiz
Duque de Caxias - RJ
CEP 25085-009
www.mufalani.com.br


[id:image002.png@01D2F4C6.8E6B3BE0]



De:  em nome de "Luis Freitas 
lfreita...@yahoo.com [oracle_br]" 
Responder para: "oracle_br@yahoogrupos.com.br" 
Data: sexta-feira, 15 de dezembro de 2017 12:09
Para: "oracle_br@yahoogrupos.com.br" 
Assunto: Re: [oracle_br] Consulta muito lenta!!


Rafael,

 Difícil sugerir alguma coisa só com o plano de execução, sem saber a 
cardinalidade campos usados na query.

 O tempo maior do plano está aparecendo como CPU, e está proximo do tempo que 
você reportou, algumas coisas que poderiam ser tentadas:

- Forçar o uso de algum índice no campo RACCT, que é o numero da conta. Se 
houver uma cardinalidade grande nesse campo, pode reduzir muito o tempo de 
execução.

- Forçar um full scan na FAGLFLEXA, o que deve mudar o perfil da query de CPU 
para disco.

- Forçar um join por "nested loops", em vez de "hash". Também deve mudar o 
perfil de CPU para disco.

 Outra coisa que pode ser tentada é ativar o paralelismo na FAGLFLEXA, o que 
irá distribuir a execução da query em mais processos. Poderia ser feito por 
"sql plan management" para não ativar direto na tabela.

Atc,
Luis Freitas




On Friday, December 15, 2017 10:57 AM, "Rafael Mendonca raffaell.t...@yahoo.com 
[oracle_br]"  wrote:


Senhores, bom dia.

Preciso de uma grande ajuda dos especialistas.

Ambiente single instance, file system, EE 11.2.0.3
Options: diagnostic and tuning pack, in memory, advanced compression, 
partitioning


Possuo uma query do sistema SAP (standard SAP), ou seja, nao existe alternativa 
para mudança estrutural da consulta, nem por hint na consulta, nem nada, por 
ser standard. O que é possível fazer é tudo a nível de banco de dados, como 
criação de sql patch, rewrite etc...

Pois bem, vamos aos detalhes:

A consulta envolve 2 tabelas e 2 índices, cada um com seus respectivos tamanhos 
abaixo:

tabela x1: 400GB
tabela x2:160GB
Indice tab x1: 140GB
Indice tab x2: 2GB

Duracao da consulta: 16 minutos

OBS: Os segmentos envoldios nao possuem PARTICIONAMENTO ou COMPRESSAO.

COnsulta abaixo:

http://textuploader.com/dcreu


Plano de execucao abaixo (SELECT * FROM table(dbms_xplan.display_cursor)):

http://textuploader.com/dcre7



Alternativas 1:

A criacao de uma Mview para a consulta em questao, porem o SAP nao pode 
direcionar o relatorio para a MVIew, entao pensei na rewrite para forcar ao ler 
o sqlid utilizar Mview, porem se as mview nao estiver totalmente atualizada com 
as tabelas envolvidas a Mview nao sera lida, ou seja, a tabela em questao 
possui 2 bilhoes de registros, eh alterada o tempo inteiro, ou seja, sem chance.

Alternativa 2: realizar um compression OLTP nas tabelas envolvidas, o que 
acham? Problema sera a carga de DML nessas tabelas, me preocupo com a lentidao 
dos inserts, updates e deletes.

Alternativa 3: Particionamento. Porem precisamos de uma solucao rapida, ira 
entrar um processo de auditoria e nao temos tempo para essa implementacao.

Alguem pode ajudar nessa dificil missao?




[As partes desta mensagem que não

Re: [oracle_br] Consulta muito lenta!!

2017-12-15 Por tôpico Rodrigo Mufalani rodr...@mufalani.com.br [oracle_br] 
Bom dia,

  Uma coisa que talvez o teu ambiente tenha de sobra, e já que está usando EE, 
pense em usar DOP (PARALLEL) para essas tabelas assim a consulta vai rodar mais 
rápido.

   Dá uma lida no manual 
https://docs.oracle.com/cd/E11882_01/server.112/e25554/indexes.htm#sthref120

CREATE BITMAP INDEX sales_cust_gender_bjix
ON sales(customers.cust_gender)
FROM sales, customers
WHERE sales.cust_id = customers.cust_id
LOCAL NOLOGGING COMPUTE STATISTICS;
  OBS.: Lembrando que bitmap índexes tem que ser usados com muito cuidado, por 
conta de locks e que o paralelismo pode usar todos os recursos, verifique, 
monte um cenário de testes antes de aplicar isso em prod. OK?

Atenciosamente,
[RED]

Rodrigo Mufalani -  Dir. Técnico
rodr...@mufalani.com.br
+55 21 988 994 817

Mufalani
+55 21 3193 0326
Rua Almirante Grenfall, 405, Bloco 3, Sala 310
Centro Empresarial Washington Luiz
Duque de Caxias - RJ
CEP 25085-009
www.mufalani.com.br


[id:image002.png@01D2F4C6.8E6B3BE0]



De:  em nome de "Luis Freitas 
lfreita...@yahoo.com [oracle_br]" 
Responder para: "oracle_br@yahoogrupos.com.br" 
Data: sexta-feira, 15 de dezembro de 2017 12:09
Para: "oracle_br@yahoogrupos.com.br" 
Assunto: Re: [oracle_br] Consulta muito lenta!!


Rafael,

 Difícil sugerir alguma coisa só com o plano de execução, sem saber a 
cardinalidade campos usados na query.

 O tempo maior do plano está aparecendo como CPU, e está proximo do tempo 
que você reportou, algumas coisas que poderiam ser tentadas:

- Forçar o uso de algum índice no campo RACCT, que é o numero da conta. Se 
houver uma cardinalidade grande nesse campo, pode reduzir muito o tempo de 
execução.

- Forçar um full scan na FAGLFLEXA, o que deve mudar o perfil da query de CPU 
para disco.

- Forçar um join por "nested loops", em vez de "hash". Também deve mudar o 
perfil de CPU para disco.

Outra coisa que pode ser tentada é ativar o paralelismo na FAGLFLEXA, o que 
irá distribuir a execução da query em mais processos. Poderia ser feito por 
"sql plan management" para não ativar direto na tabela.

Atc,
Luis Freitas




On Friday, December 15, 2017 10:57 AM, "Rafael Mendonca raffaell.t...@yahoo.com 
[oracle_br]"  wrote:


Senhores, bom dia.

Preciso de uma grande ajuda dos especialistas.

Ambiente single instance, file system, EE 11.2.0.3
Options: diagnostic and tuning pack, in memory, advanced compression, 
partitioning


Possuo uma query do sistema SAP (standard SAP), ou seja, nao existe alternativa 
para mudança estrutural da consulta, nem por hint na consulta, nem nada, por 
ser standard. O que é possível fazer é tudo a nível de banco de dados, como 
criação de sql patch, rewrite etc...

Pois bem, vamos aos detalhes:

A consulta envolve 2 tabelas e 2 índices, cada um com seus respectivos tamanhos 
abaixo:

tabela x1: 400GB
tabela x2:160GB
Indice tab x1: 140GB
Indice tab x2: 2GB

Duracao da consulta: 16 minutos

OBS: Os segmentos envoldios nao possuem PARTICIONAMENTO ou COMPRESSAO.

COnsulta abaixo:

http://textuploader.com/dcreu


Plano de execucao abaixo (SELECT * FROM table(dbms_xplan.display_cursor)):

http://textuploader.com/dcre7



Alternativas 1:

A criacao de uma Mview para a consulta em questao, porem o SAP nao pode 
direcionar o relatorio para a MVIew, entao pensei na rewrite para forcar ao ler 
o sqlid utilizar Mview, porem se as mview nao estiver totalmente atualizada com 
as tabelas envolvidas a Mview nao sera lida, ou seja, a tabela em questao 
possui 2 bilhoes de registros, eh alterada o tempo inteiro, ou seja, sem chance.

Alternativa 2: realizar um compression OLTP nas tabelas envolvidas, o que 
acham? Problema sera a carga de DML nessas tabelas, me preocupo com a lentidao 
dos inserts, updates e deletes.

Alternativa 3: Particionamento. Porem precisamos de uma solucao rapida, ira 
entrar um processo de auditoria e nao temos tempo para essa implementacao.

Alguem pode ajudar nessa dificil missao?





[As partes desta mensagem que não continham texto foram removidas]

Re: [oracle_br] Consulta muito lenta!!

2017-12-15 Por tôpico Luis Freitas lfreita...@yahoo.com [oracle_br] 
Rafael,
     Difícil sugerir alguma coisa só com o plano de execução, sem saber a 
cardinalidade campos usados na query.
     O tempo maior do plano está aparecendo como CPU, e está proximo do tempo 
que você reportou, algumas coisas que poderiam ser tentadas:
- Forçar o uso de algum índice no campo RACCT, que é o numero da conta. Se 
houver uma cardinalidade grande nesse campo, pode reduzir muito o tempo de 
execução.
- Forçar um full scan na FAGLFLEXA, o que deve mudar o perfil da query de CPU 
para disco.
- Forçar um join por "nested loops", em vez de "hash". Também deve mudar o 
perfil de CPU para disco.
    Outra coisa que pode ser tentada é ativar o paralelismo na FAGLFLEXA, o que 
irá distribuir a execução da query em mais processos. Poderia ser feito por 
"sql plan management" para não ativar direto na tabela.
Atc,Luis Freitas


   

 On Friday, December 15, 2017 10:57 AM, "Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br]"  wrote:
 

     Senhores, bom dia.
Preciso de uma grande ajuda dos especialistas.
Ambiente single instance, file system, EE 11.2.0.3Options: diagnostic and 
tuning pack, in memory, advanced compression, partitioning

Possuo uma query do sistema SAP (standard SAP), ou seja, nao existe alternativa 
para mudança estrutural da consulta, nem por hint na consulta, nem nada, por 
ser standard. O que é possível fazer é tudo a nível de banco de dados, como 
criação de sql patch, rewrite etc...
Pois bem, vamos aos detalhes:
A consulta envolve 2 tabelas e 2 índices, cada um com seus respectivos tamanhos 
abaixo:
tabela x1: 400GBtabela x2:160GBIndice tab x1: 140GBIndice tab x2: 2GB
Duracao da consulta: 16 minutos
OBS: Os segmentos envoldios nao possuem PARTICIONAMENTO ou COMPRESSAO.
COnsulta abaixo:
http://textuploader.com/dcreu


Plano de execucao abaixo (SELECT * FROM table(dbms_xplan.display_cursor)):

http://textuploader.com/dcre7



Alternativas 1:
A criacao de uma Mview para a consulta em questao, porem o SAP nao pode 
direcionar o relatorio para a MVIew, entao pensei na rewrite para forcar ao ler 
o sqlid utilizar Mview, porem se as mview nao estiver totalmente atualizada com 
as tabelas envolvidas a Mview nao sera lida, ou seja, a tabela em questao 
possui 2 bilhoes de registros, eh alterada o tempo inteiro, ou seja, sem chance.
Alternativa 2: realizar um compression OLTP nas tabelas envolvidas, o que 
acham? Problema sera a carga de DML nessas tabelas, me preocupo com a lentidao 
dos inserts, updates e deletes.
Alternativa 3: Particionamento. Porem precisamos de uma solucao rapida, ira 
entrar um processo de auditoria e nao temos tempo para essa implementacao.
Alguem pode ajudar nessa dificil missao?
  #yiv8578936269 -- #yiv8578936269ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv8578936269 
#yiv8578936269ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv8578936269 
#yiv8578936269ygrp-mkp #yiv8578936269hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv8578936269 #yiv8578936269ygrp-mkp #yiv8578936269ads 
{margin-bottom:10px;}#yiv8578936269 #yiv8578936269ygrp-mkp .yiv8578936269ad 
{padding:0 0;}#yiv8578936269 #yiv8578936269ygrp-mkp .yiv8578936269ad p 
{margin:0;}#yiv8578936269 #yiv8578936269ygrp-mkp .yiv8578936269ad a 
{color:#ff;text-decoration:none;}#yiv8578936269 #yiv8578936269ygrp-sponsor 
#yiv8578936269ygrp-lc {font-family:Arial;}#yiv8578936269 
#yiv8578936269ygrp-sponsor #yiv8578936269ygrp-lc #yiv8578936269hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv8578936269 
#yiv8578936269ygrp-sponsor #yiv8578936269ygrp-lc .yiv8578936269ad 
{margin-bottom:10px;padding:0 0;}#yiv8578936269 #yiv8578936269actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv8578936269 
#yiv8578936269activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv8578936269
 #yiv8578936269activity span {font-weight:700;}#yiv8578936269 
#yiv8578936269activity span:first-child 
{text-transform:uppercase;}#yiv8578936269 #yiv8578936269activity span a 
{color:#5085b6;text-decoration:none;}#yiv8578936269 #yiv8578936269activity span 
span {color:#ff7900;}#yiv8578936269 #yiv8578936269activity span 
.yiv8578936269underline {text-decoration:underline;}#yiv8578936269 
.yiv8578936269attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv8578936269 .yiv8578936269attach div a 
{text-decoration:none;}#yiv8578936269 .yiv8578936269attach img 
{border:none;padding-right:5px;}#yiv8578936269 .yiv8578936269attach label 
{display:block;margin-bottom:5px;}#yiv8578936269 .yiv8578936269attach label a 
{text-decoration:none;}#yiv8578936269 blockquote {margin:0 0 0 
4px;}#yiv8578936269 .yiv8578936269bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv8578936269 
.yiv8578936269bold a {text-decoration:none;}#yiv8578936269 dd.yiv8578936269last 
p a {font-family:Verdana;font-weight:700;}#yiv8578936269

[oracle_br] Consulta muito lenta!!

2017-12-15 Por tôpico Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
Senhores, bom dia.
Preciso de uma grande ajuda dos especialistas.
Ambiente single instance, file system, EE 11.2.0.3Options: diagnostic and 
tuning pack, in memory, advanced compression, partitioning

Possuo uma query do sistema SAP (standard SAP), ou seja, nao existe alternativa 
para mudança estrutural da consulta, nem por hint na consulta, nem nada, por 
ser standard. O que é possível fazer é tudo a nível de banco de dados, como 
criação de sql patch, rewrite etc...
Pois bem, vamos aos detalhes:
A consulta envolve 2 tabelas e 2 índices, cada um com seus respectivos tamanhos 
abaixo:
tabela x1: 400GBtabela x2:160GBIndice tab x1: 140GBIndice tab x2: 2GB
Duracao da consulta: 16 minutos
OBS: Os segmentos envoldios nao possuem PARTICIONAMENTO ou COMPRESSAO.
COnsulta abaixo:
http://textuploader.com/dcreu


Plano de execucao abaixo (SELECT * FROM table(dbms_xplan.display_cursor)):

http://textuploader.com/dcre7



Alternativas 1:
A criacao de uma Mview para a consulta em questao, porem o SAP nao pode 
direcionar o relatorio para a MVIew, entao pensei na rewrite para forcar ao ler 
o sqlid utilizar Mview, porem se as mview nao estiver totalmente atualizada com 
as tabelas envolvidas a Mview nao sera lida, ou seja, a tabela em questao 
possui 2 bilhoes de registros, eh alterada o tempo inteiro, ou seja, sem chance.
Alternativa 2: realizar um compression OLTP nas tabelas envolvidas, o que 
acham? Problema sera a carga de DML nessas tabelas, me preocupo com a lentidao 
dos inserts, updates e deletes.
Alternativa 3: Particionamento. Porem precisamos de uma solucao rapida, ira 
entrar um processo de auditoria e nao temos tempo para essa implementacao.
Alguem pode ajudar nessa dificil missao?

Re: [oracle_br] Re: AJuda script shell

2017-12-15 Por tôpico Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
Obrigado Angelo, isso mesmo.k, com ajuda dos amigos acima, consegui fazer 
esse RTA :) 

Em Quinta-feira, 14 de Dezembro de 2017 11:40, "angelo 
angelolis...@gmail.com [oracle_br]"  escreveu:
 

     Esse seu workaround..   isso também poderia ser chamado de "RTA - Recurso 
Tecnico Alternativo"  um nome mais pomposo para a gambi,  afinal fica feio 
falar pro cliente que fez uma "gambiarra"...   Kkkk
mas as vezes a gente tem que lançar mão dessas tecnicas mesmo.. Ta lembrando o 
caso do outro thread do problema que tava rolando com o Nagios, que o colega 
estava reclamando que de vez em quando travava o banco.

O que nos conforta é que é tudo nessa vida é codigo,  e código sempre tem bug.. 

tomara que a Oracle responda isso rapido, se é que o problema está lá, siga com 
sua pesquisa enquanto isso




2017-12-12 18:20 GMT-02:00 Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
:

     Chiappa, no ponto 1 eu concordo com tudo que voce disse. Isso eh um 
workaround vulgo gambiarra para poder sanar o problema do cliente enquanto nao 
se descobri a causa raiz, um chamado com a Oracle ja foi aberto para suporte.
Em relacao ao item 2 a minha consulta funciona sim, esse pid eh o mesmo pid do 
SO, tanto que ela existe na v$process, e nao na v$session. Tanto que funcionou!
Essa questao do alter system disconnect session eu vou testar tambem, obrigado 
pela dica.  

Em Terça-feira, 12 de Dezembro de 2017 14:25, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Bom, antes de responder algumas obs importantes :

1. absolutamente NÃO É NORMAL que vc tenha que ficar matando sessão manualmente 
: necessariamente ALGUMA COISA está causando a sessão ficar 'pendurada' , e vc 
DEVERIA MESMO encontrar e solucionar esse 'alguma coisa'... Há muitas 
possibilidades, que vão desde falha na infra de rede fazendo a comunicação com 
o banco ser perdida, até bugs em middleware, ou mesmo aplicação porquinha que 
sai criando conexões novas sem desativar anteriores, coisas assim Em ALGUNS 
CASOS inclusive pode ser possível como work-around vc solicitar que o banco 
mesmo elimine sessões inativas por x minutos aplicando o DCD e um profile de 
máximo de conexão, mas normalmente o mais correto é encontrar a Causa raiz 
antes de tudo...

2. SE vc for obrigado a por qquer motivo matar a sessão, a sessão normalmente 
fica com status de KILLED apenas se vc usou (incorretamente, imho) o KILL 
SESSIOn ao invés do DISCONNECT SESSION, via de regra muito mais efetivo : 
http://www.fabioprado.net/ 2014/05/matando-sessoes-no- oracle-database.html é 
uma das refs pra ele

3. Tudo que vou falar na resposta é baseado em conexões DEDICADAS e 
PERMANENTES, e criadas quando a sessão pede conexão : EVIDENTEMENTE não se 
aplica se a sua app está usando qualquer tipo de POOLS DE CONEXÃO, ou se seu 
banco tá usando MTS/SHARED SESSIONs

Isso posto, a resposta : como eu não uso quase nunca KILL SESSION não tenho 
aqui um ambiente a testar, mas de acordo com a nota metalink "How To Find The 
Process Identifier (pid, spid) After The Corresponding Session Is Killed?" (Doc 
ID 387077.1) é possível que o ponteiro em memória do processo que atendia à 
sessão não fique mais registrado na coluna PADDR da V$SESSION, pois o processo 
de eliminação já começou no banco mas não chegou ainda a ser solicitada remoção 
no SO (seja qual for o motivo - banco intensamente concorrente, rollback sendo 
executado ainda, o que for)... Veja lá se é esse o seu caso, SE FOR ISSO 
obviamente teu JOIN :

SELECT  p.spid
    FROM v$session s,
 v$process p
   WHERE s.paddr   = p.addr
   
NÂO VAI FUNCIONAR, sim sim ?? Se for isso aplique um dos work-arounds indicados 
para encontrar o SPID (system pid, o id da task no Sistema Operacional) na 
V$PROCESS a partir da linha da V$SESSION que está com STATUS de KILLED, 
provavelmente (já que seu banco é 11g) deve ser :

select spid from v$process where addr=(select creator_addr from v$session where 
STATUS='KILLED');

Ou alguma variação muito próxima

Aí a segunda parte da resposta : uma vez que vc conseguiu uma query que extraia 
os SPIDs vc TANTO pode escrever um shell script que acione o sqlplus  via 
script e retorne o valor de cada SPID desejado QUANTO pode fazer o contrário, 
ie, dentro do sqlplus gerar um shell script com os comandos necessários - sim, 
um shell script NADA MAIS É do que um arquivo-texto, é Bico gerar um 
arquivo-texto com o output de uma query no sqlplus... Seria algo mais ou menos 
tipo :

==> vc tem um script sqlplus chamado gera_kills.sql contendo :

set term off feedback off verify off pages 0 lines 500 trimspool on head off
spool /tmp/kill_sessions.sh
select 'kill -9 ' || spid from v$process where addr=(select creator_addr from 
v$session where STATUS='KILLED')
/
select 'exit' || chr(10) from dual
/
spool off
exit


Aí teu shell script principal seria tipo :

#!/bin/sh
sqlplus