Re: [oracle_br] Re: Consulta muito lenta!!
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: Assunto: [oracle_br] Consulta muito lenta!!
O problema ja foi resolvido Emerson, conforme escrevi no primeiro topico, a
view seria inviavel.
Em Terça-feira, 19 de Dezembro de 2017 16:01, "Emerson Moreira Rocha
tkz...@yahoo.com.br [oracle_br]" escreveu:
Não dá pra fazer uma mview atualizável?
Enviado do Yahoo Mail no Android
Em sex, 15 15e dez 15e 2017 às 10:57, Rafael Mendonca raffaell.t...@yahoo.com
[oracle_br]&It;oracle_br@yahoogrupos.com.br> escreveu: 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?
#yiv3378312260 #yiv3378312260 -- #yiv3378312260ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv3378312260
#yiv3378312260ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv3378312260
#yiv3378312260ygrp-mkp #yiv3378312260hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv3378312260 #yiv3378312260ygrp-mkp #yiv3378312260ads
{margin-bottom:10px;}#yiv3378312260 #yiv3378312260ygrp-mkp .yiv3378312260ad
{padding:0 0;}#yiv3378312260 #yiv3378312260ygrp-mkp .yiv3378312260ad p
{margin:0;}#yiv3378312260 #yiv3378312260ygrp-mkp .yiv3378312260ad a
{color:#ff;text-decoration:none;}#yiv3378312260 #yiv3378312260ygrp-sponsor
#yiv3378312260ygrp-lc {font-family:Arial;}#yiv3378312260
#yiv3378312260ygrp-sponsor #yiv3378312260ygrp-lc #yiv3378312260hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv3378312260
#yiv3378312260ygrp-sponsor #yiv3378312260ygrp-lc .yiv3378312260ad
{margin-bottom:10px;padding:0 0;}#yiv3378312260 #yiv3378312260actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv3378312260
#yiv3378312260activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv3378312260
#yiv3378312260activity span {font-weight:700;}#yiv3378312260
#yiv3378312260activity span:first-child
{text-transform:uppercase;}#yiv3378312260 #yiv3378312260activity span a
{color:#5085b6;text-decoration:none;}#yiv3378312260 #yiv3378312260activity span
span {color:#ff7900;}#yiv3378312260 #yiv3378312260activity span
.yiv3378312260underline {text-decoration:underline;}#yiv3378312260
.yiv3378312260attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv3378312260 .yiv3378312260attach div a
{text-decoration:none;}#yiv3378312260 .yiv3378312260attach img
{border:none;padding-right:5px;}#yiv3378312260 .yiv3378312260attach label
{display:block;margin-bottom:5px;}#yiv3378312260 .yiv3378312260attach label a
{text-decoration:none;}#yiv3378312260 blockquote {margin:0 0 0
4px;}#yiv3378312260 .yiv3378312260bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv3378312260
.yiv3378312260bold a {text-decoration:none;}#yiv3378312260 dd.yiv3378312260last
p a {font-family:Verdana;font-weight:700;}#yiv3378312260 dd.yiv3378312260last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv3378312260
dd.yiv3378312260last p span.yiv3378312260yshortcuts
{margin-right:0;}#yiv3378312260 div.yiv3378312260attach-table div div a
{text-decoration:none;}#yiv3378312260 div.yiv3378312260attach-table
{width:400px;}#yiv3378312260 div.yiv3378312260file-title a, #yiv3378312260
div.yiv3378312260file-title a:active, #yiv3378312260
div.yiv3378312260file-title a:hover, #yiv3378312260 div.yiv3378312260file-title
a:visited {text-decoration:none
Assunto: [oracle_br] Consulta muito lenta!!
Não dá pra fazer uma mview atualizável?
Enviado do Yahoo Mail no Android
Em sex, 15 15e dez 15e 2017 às 10:57, Rafael Mendonca raffaell.t...@yahoo.com
[oracle_br]&It;oracle_br@yahoogrupos.com.br> escreveu:
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?
#yiv6344813816 #yiv6344813816 -- #yiv6344813816ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv6344813816
#yiv6344813816ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv6344813816
#yiv6344813816ygrp-mkp #yiv6344813816hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv6344813816 #yiv6344813816ygrp-mkp #yiv6344813816ads
{margin-bottom:10px;}#yiv6344813816 #yiv6344813816ygrp-mkp .yiv6344813816ad
{padding:0 0;}#yiv6344813816 #yiv6344813816ygrp-mkp .yiv6344813816ad p
{margin:0;}#yiv6344813816 #yiv6344813816ygrp-mkp .yiv6344813816ad a
{color:#ff;text-decoration:none;}#yiv6344813816 #yiv6344813816ygrp-sponsor
#yiv6344813816ygrp-lc {font-family:Arial;}#yiv6344813816
#yiv6344813816ygrp-sponsor #yiv6344813816ygrp-lc #yiv6344813816hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv6344813816
#yiv6344813816ygrp-sponsor #yiv6344813816ygrp-lc .yiv6344813816ad
{margin-bottom:10px;padding:0 0;}#yiv6344813816 #yiv6344813816actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv6344813816
#yiv6344813816activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv6344813816
#yiv6344813816activity span {font-weight:700;}#yiv6344813816
#yiv6344813816activity span:first-child
{text-transform:uppercase;}#yiv6344813816 #yiv6344813816activity span a
{color:#5085b6;text-decoration:none;}#yiv6344813816 #yiv6344813816activity span
span {color:#ff7900;}#yiv6344813816 #yiv6344813816activity span
.yiv6344813816underline {text-decoration:underline;}#yiv6344813816
.yiv6344813816attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv6344813816 .yiv6344813816attach div a
{text-decoration:none;}#yiv6344813816 .yiv6344813816attach img
{border:none;padding-right:5px;}#yiv6344813816 .yiv6344813816attach label
{display:block;margin-bottom:5px;}#yiv6344813816 .yiv6344813816attach label a
{text-decoration:none;}#yiv6344813816 blockquote {margin:0 0 0
4px;}#yiv6344813816 .yiv6344813816bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv6344813816
.yiv6344813816bold a {text-decoration:none;}#yiv6344813816 dd.yiv6344813816last
p a {font-family:Verdana;font-weight:700;}#yiv6344813816 dd.yiv6344813816last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv6344813816
dd.yiv6344813816last p span.yiv6344813816yshortcuts
{margin-right:0;}#yiv6344813816 div.yiv6344813816attach-table div div a
{text-decoration:none;}#yiv6344813816 div.yiv6344813816attach-table
{width:400px;}#yiv6344813816 div.yiv6344813816file-title a, #yiv6344813816
div.yiv6344813816file-title a:active, #yiv6344813816
div.yiv6344813816file-title a:hover, #yiv6344813816 div.yiv6344813816file-title
a:visited {text-decoration:none;}#yiv6344813816 div.yiv6344813816photo-title a,
#yiv6344813816 div.yiv6344813816photo-title a:active, #yiv6344813816
div.yiv6344813816photo-title a:hover, #yiv6344813816
div.yiv6344813816photo-title a:visited {text-decoration
Re: [oracle_br] Re: Consulta muito lenta!!
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 span
span {color:#ff7900;}#yiv2
Re: [oracle_br] Re: CLUSTERING FACTOR
Sim, as coisas vão ficando mais claras pra mim. Obrigada pela indicação do livro Oracle SQL High-Performance, vou atrás hoje mesmo. Obrigada pelos esclarecimentos, fizeram diferença pra minha visão do problema. Abss, De: oracle_br@yahoogrupos.com.br em nome de jlchia...@yahoo.com.br [oracle_br] Enviado: terça-feira, 19 de dezembro de 2017 06:37 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Re: CLUSTERING FACTOR Sim : inclusive, clustering factor *** NÂO TEM NADA A VER *** com redução de I/O per se : ele é simplesmente um indicador, uma referência se os dados dentro do índice estão bastante 'espalhados' por múltiplos blocos ou não, e é usado como fator de DESEMPATE para o Otimizador escolher quando houver mais de um índice possível... E Imagino que vc ENTENDEU quando eu disse que o CF é uma medida de organização da tabela, se fisicamente a tabela está organizada mais coerentemente com a coluna X , não tem ao mesmo tempo como ela Também estar organizada fisicamente pela coluna Y ao mesmo tempoNÃO EXISTE isso de 'melhorar o clustering factor para a query' , o CF é PARA A TABELA COMO UM TODO, okdoc Então SIM, eu Recomendo que vc parte pras opções de Tuning de SQL : via de regra tuning de SQL é muuito mais simples e mito mais Efetivo, vc consegue resultados melhores de uma maneira mais simples... O passo inicial para tuning de SQL é obter Conhecimento sobre os índices E as tabelas envolvidas na query (o que inclui a razão / regra de negócio que te leva a sub-queries, por exemplo), TEM que saber os volumes estimados para cada acesso via cada índice E tem que conhecer os métodos de JOIn (ie, HASH JOIN, NESTED LOOPs, SORT_mERGE, etc) para poder avaliar o Plano de Execução que o Otimizador vai te dar e validar se ele está o mais otimizado possível ou não... Por exemplo, pegando o exemplo em www.oracle..com/technetwork/database/bi-datawarehousing/twp-explain-the-explain-plan-052011-393674.pdf o Otimizador escolher fazer um HASH JOIN, ie, ler na íntegra as tabelas envolvidas criando uma tabela temporária em memória ordenada e então filtrar os dados por essas tabelas temporárias - isso é RADICALMENTE DIFERENTE de NESTED LOOP, onde ele vai lendo os dados linha a linha e para cada linha lida o RDBMS procura nas outrs tabelas pra ver se tem um valor correspondente Qual o melhor/mais correto ? DEPENDE dessas infos que citei Na minha experiência pessoal, a fonte que melhor explicou esses diferentes métodos de JOIN foi o livro "Oracle SQL High-Performance Tuning", de Guy Harrison , Recomendo que vc o leia... O passo inicial do método para Tuning de SQL que recomendo portanto é : COM o conhecimento teórico da metodologia do Otimizador de SQL presente E conhecendo também volumes e distribuição de dados nas tabelas e índices envolvidas, obtenha o Plano de Execução extendido (ie, que inclui qtdades estimadas versus qtdades efetivamente obtidas) cfrme https://blogs.oracle.com/optimizer/how-do-i-know-if-the-cardinality-estimates-in-a-plan-are-accurate Com isso aí vc vai analisar se o índice e o método de JOIN tão apropriados ou se vc acredita que outro seria mais efetivo, se as Estatísticas que guiam as Estimativas do RDBMS tão apropriadas, é por aí []s Chiappa
Re: [oracle_br] Re: Consulta muito lenta!!
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!!
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
#yiv5858779180photos div div {border:1px solid
#66;min-height:62px;overflow:hidden;width:62px
[oracle_br] Re: CLUSTERING FACTOR
Sim : inclusive, clustering factor *** NÂO TEM NADA A VER *** com redução de I/O per se : ele é simplesmente um indicador, uma referência se os dados dentro do índice estão bastante 'espalhados' por múltiplos blocos ou não, e é usado como fator de DESEMPATE para o Otimizador escolher quando houver mais de um índice possível... E Imagino que vc ENTENDEU quando eu disse que o CF é uma medida de organização da tabela, se fisicamente a tabela está organizada mais coerentemente com a coluna X , não tem ao mesmo tempo como ela Também estar organizada fisicamente pela coluna Y ao mesmo tempoNÃO EXISTE isso de 'melhorar o clustering factor para a query' , o CF é PARA A TABELA COMO UM TODO, okdoc Então SIM, eu Recomendo que vc parte pras opções de Tuning de SQL : via de regra tuning de SQL é muuito mais simples e mito mais Efetivo, vc consegue resultados melhores de uma maneira mais simples... O passo inicial para tuning de SQL é obter Conhecimento sobre os índices E as tabelas envolvidas na query (o que inclui a razão / regra de negócio que te leva a sub-queries, por exemplo), TEM que saber os volumes estimados para cada acesso via cada índice E tem que conhecer os métodos de JOIn (ie, HASH JOIN, NESTED LOOPs, SORT_mERGE, etc) para poder avaliar o Plano de Execução que o Otimizador vai te dar e validar se ele está o mais otimizado possível ou não... Por exemplo, pegando o exemplo em www.oracle.com/technetwork/database/bi-datawarehousing/twp-explain-the-explain-plan-052011-393674.pdf o Otimizador escolher fazer um HASH JOIN, ie, ler na íntegra as tabelas envolvidas criando uma tabela temporária em memória ordenada e então filtrar os dados por essas tabelas temporárias - isso é RADICALMENTE DIFERENTE de NESTED LOOP, onde ele vai lendo os dados linha a linha e para cada linha lida o RDBMS procura nas outrs tabelas pra ver se tem um valor correspondente Qual o melhor/mais correto ? DEPENDE dessas infos que citei Na minha experiência pessoal, a fonte que melhor explicou esses diferentes métodos de JOIN foi o livro "Oracle SQL High-Performance Tuning", de Guy Harrison , Recomendo que vc o leia... O passo inicial do método para Tuning de SQL que recomendo portanto é : COM o conhecimento teórico da metodologia do Otimizador de SQL presente E conhecendo também volumes e distribuição de dados nas tabelas e índices envolvidas, obtenha o Plano de Execução extendido (ie, que inclui qtdades estimadas versus qtdades efetivamente obtidas) cfrme https://blogs.oracle.com/optimizer/how-do-i-know-if-the-cardinality-estimates-in-a-plan-are-accurate Com isso aí vc vai analisar se o índice e o método de JOIN tão apropriados ou se vc acredita que outro seria mais efetivo, se as Estatísticas que guiam as Estimativas do RDBMS tão apropriadas, é por aí []s Chiappa
Re: [oracle_br] Re: Consulta muito lenta!!
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
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv4409151850
#yiv4409151850reco-category {font-size
