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

2017-12-19 Por tôpico Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
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]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

Assunto: [oracle_br] Consulta muito lenta!!

2017-12-19 Por tôpico Emerson Moreira Rocha tkz...@yahoo.com.br [oracle_br] 
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]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

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]" <oracle_br@yahoogrupos.com.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]" <oracle_br@yahoogrupos.com.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<http://www.mufalani.com.br/>


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



De: <oracle_br@yahoogrupos.com.br> em nome de "Luis Freitas 
lfreita...@yahoo.com [oracle_br]" <oracle_br@yahoogrupos.com.br>
Responder para: "oracle_br@yahoogrupos.com.br" <oracle_br@yahoogrupos.com.br>
Data: sexta-feira, 15 de dezembro de 2017 12:09
Para: "oracle_br@yahoogrupos.com.br" <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]" <oracle_br@yahoogrupos.com.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 re

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]" <oracle_br@yahoogrupos.com.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<http://www.mufalani.com.br/>


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



De: <oracle_br@yahoogrupos.com.br> em nome de "Luis Freitas 
lfreita...@yahoo.com [oracle_br]" <oracle_br@yahoogrupos.com.br>
Responder para: "oracle_br@yahoogrupos.com.br" <oracle_br@yahoogrupos.com.br>
Data: sexta-feira, 15 de dezembro de 2017 12:09
Para: "oracle_br@yahoogrupos.com.br" <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]" <oracle_br@yahoogrupos.com.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

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<http://www.mufalani.com.br/>


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



De: <oracle_br@yahoogrupos.com.br> em nome de "Luis Freitas 
lfreita...@yahoo.com [oracle_br]" <oracle_br@yahoogrupos.com.br>
Responder para: "oracle_br@yahoogrupos.com.br" <oracle_br@yahoogrupos.com.br>
Data: sexta-feira, 15 de dezembro de 2017 12:09
Para: "oracle_br@yahoogrupos.com.br" <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]" <oracle_br@yahoogrupos.com.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?