[oracle_br] Re: BITMAP CONVERSION (TO ROWIDS)
Phael, veja : absolutamente *** não é *** o uso em si de bitmap copnversion em si que é o bug, mas sim o uso dele EM DETRIMENTO DE um plano melhor disponível, então o que vc tem que fazer é pegar uma dessas queries que estão fazendo isso e TESTAR COM OUTRO PLANO, se não der dif de performance absolutamente NÃO É BUG, o CBO estará no caso fazendo a coisa certa , confere ?? Um meio simples de se fazer esse teste é meter um _btree_bitmap_plans alterado pra false via ALTER SESSION (iirc esse param é alterável por sessão) e ver qual plano que é gerado, se for melhor SIM, vc pode estar caindo num bug, SE for indiferente simplesmente largue mão, o CBO está correto se isso acontecer []s Chiappa === Participe do ENPO - Encontro de Profissionais Oracle 2006 ! Informações e inscrições em www.enpo-br.org José Laurindo Chiappa, Palestrante ENPO-2006 === --- Em oracle_br@yahoogrupos.com.br, Phael [EMAIL PROTECTED] escreveu Gente, Tenho algumas consultas no banco que estão utilizando a conversão de rowids para bitmap. Sei que isso é uma escolha do CBO mas pesquisando no metalink vi que isso parece ser um BUG... e umas das sugestões é colocar esse parametro: _b_tree_bitmap_plans=FALSE Minha pergunta é... Alguém ja passou por isso? A solução seria essa mesmo? Como a empresa é 24/7 fica complicado aplicar um patch ... mas se for o caso sabem me dizer se o patch 9.2.0.8 soluciona esse problema??? Oracle9i Enterprise Edition Release 9.2.0.5.0 Red Had AS 3.0 Phael [As partes desta mensagem que não continham texto foram removidas] Vem aí: ENPO-BR 2006 - Encontro Nacional de Profissionais Oracle VISITE: http://www.enpo-br.org/ - Dia 11/11 Vagas Limitadas Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine -- Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -- O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: WWW.ORACLEBR.COM.BR Links do Yahoo! Grupos * Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ * Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] * O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
Re: [oracle_br] Re: BITMAP CONVERSION (TO ROWIDS)
Chiappa, Ja tinha feito o teste que vc sugeriu, na verdade a principio nem estava conseguindo dar um alter session porque esse problema era em uma aplicação dai fiz um trace e peguei o select e testei com o parametro _btree_bitmap_plans=false... blz... ficou bem melhor demorava 2min .. passou para 30seg. Dai criei uma trigger after logon que seta a sessão desse usuario resolveu!!! mas eu gostaria de saber se tem algum impacto em mudar pro banco inteiro? colocar no init esse parametro... e reestart na instancia isso afetaria o uso de index do tipo bitmap ?? Outra pergunta... isso seria um BUG mesmo?? sera que o patch 9.2.0.8 resolve?? https://metalink.oracle.com/metalink/plsql/f?p=200:27:2549418528396169552p27_id,p27_show_header,p27_show_help:643600.999,1,1 Phael - Original Message - From: jlchiappa To: oracle_br@yahoogrupos.com.br Sent: Friday, October 20, 2006 1:29 PM Subject: [oracle_br] Re: BITMAP CONVERSION (TO ROWIDS) Phael, veja : absolutamente *** não é *** o uso em si de bitmap copnversion em si que é o bug, mas sim o uso dele EM DETRIMENTO DE um plano melhor disponível, então o que vc tem que fazer é pegar uma dessas queries que estão fazendo isso e TESTAR COM OUTRO PLANO, se não der dif de performance absolutamente NÃO É BUG, o CBO estará no caso fazendo a coisa certa , confere ?? Um meio simples de se fazer esse teste é meter um _btree_bitmap_plans alterado pra false via ALTER SESSION (iirc esse param é alterável por sessão) e ver qual plano que é gerado, se for melhor SIM, vc pode estar caindo num bug, SE for indiferente simplesmente largue mão, o CBO está correto se isso acontecer []s Chiappa === Participe do ENPO - Encontro de Profissionais Oracle 2006 ! Informações e inscrições em www.enpo-br.org José Laurindo Chiappa, Palestrante ENPO-2006 === --- Em oracle_br@yahoogrupos.com.br, Phael [EMAIL PROTECTED] escreveu Gente, Tenho algumas consultas no banco que estão utilizando a conversão de rowids para bitmap. Sei que isso é uma escolha do CBO mas pesquisando no metalink vi que isso parece ser um BUG... e umas das sugestões é colocar esse parametro: _b_tree_bitmap_plans=FALSE Minha pergunta é... Alguém ja passou por isso? A solução seria essa mesmo? Como a empresa é 24/7 fica complicado aplicar um patch ... mas se for o caso sabem me dizer se o patch 9.2.0.8 soluciona esse problema??? Oracle9i Enterprise Edition Release 9.2.0.5.0 Red Had AS 3.0 Phael [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas] Vem aí: ENPO-BR 2006 - Encontro Nacional de Profissionais Oracle VISITE: http://www.enpo-br.org/ - Dia 11/11 Vagas Limitadas Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine -- Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -- O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: WWW.ORACLEBR.COM.BR Links do Yahoo! Grupos * Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ * Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] * O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
[oracle_br] Re: BITMAP CONVERSION (TO ROWIDS)
** Lógico ** que há um benefício, senão a Oracle não teria mudado...
Na verdade a função do parâmetro é permitir que planos normalmente só
disponíveis para bitmap indexes passem a estar disponíveis também pra
índices btree, abrindo NOVAS possibilidades na execução de SQLs. Mas
é claro, nada vem de graça, isso implica em MAIS consumo de CPU pra
fazer as conversões, mais espaço temporário pras conversões se os
índices forem grandes, enfim, mais consumo de modo geral. A Oracle
avaliou que , num banco bem-tunado, SEM gargalos de CPU, com
tablespaces LMT, com TEMP rápida (ie, de tamanho adequado. LMT, e
com true tempfiles), com áreas de bitmap (ie, bitmap_merge_area_size
e create_bitmap_area_size) razoáveis, onde NÂO haja desperdício de
CPU devido à parse constante, etc, esse acréscimo não seria tão
significativo, e realmente, em muitos casos isso é assim : no maior
banco que gerencio no cliente atual (um DW com cerca de 5 Tb de
dados) , quando migramos do 8i para 9.2.0.5 não alteramos o parâmetro
(na verdade nenhum dos parãmetros _ ), e foi ok, e está rodando há
mais de 6 meses sem problemas.
CASO realmente vc queira mudar isso, em banco Produção é **
IMPERATIVO ** que vc tenha a bênção e o OK do Suporte, já que
parâmetros _ são OCULTOS, em produção vc só os muda com aprovação do
Suporte Oracle, se vc quer que o banco continue sendo Suportado.
Pra se consultar esses parâmetros, o SHOW PARAMETERS do sqlplus não
funciona, já que são ocultos, vc teria que usar um script do tipo :
set linesize 132
column name format a42
column value format a30
select
x.ksppinm name,
y.kspftctxvl value,
y.kspftctxdf isdefault,
decode(bitand
(y.kspftctxvf,7),1,'MODIFIED',4,'SYSTEM_MOD','FALSE') ismod,
decode(bitand(y.kspftctxvf,2),2,'TRUE','FALSE') isadj
from
sys.x_$ksppi x,
sys.x_$ksppcv2 y
where
x.ksppinm like lower('%PARAM_NAME_LIKE%') and
x.inst_id = userenv('Instance') and
y.inst_id = userenv('Instance') and
x.indx+1 = y.kspftctxpn
order by
translate(x.ksppinm, ' _', ' ')
/
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, Phael [EMAIL PROTECTED] escreveu
Bom dia a todos,
Fiz uma migração de dados de um banco para outro(msm versão 9.2.0.5
só q plataforma diferente AIX p/ Linux)
e notei que algumas querys q levavam questão de segundo para serem
executadas demoravam muito mais no
novo ambiente e fazendo um tuning nessas querys descobri que CBO
fazia bitmap conversion from/to rowids.
Procurando no metalink.
Sugestão seria que o parametro _b_tree_bitmap_plans está com TRUE
e deve ser FALSE.
Em versões anteriores ao 9 já era FALSE. porque a Oracle deixou
como TRUE na nova versão(9 e 10g?
existe algum beneficio ?
Como são muitas as querys que estão usando BITMAP CONVERSION vou
ter que mudar para FALSE esse
parametro!!!
A solução seria essa mesma??
COMO EU VEJO O VALOR QUE ESSE PARAMETRO ESTA SETADO NO BANCO???
Phael
[As partes desta mensagem que não continham texto foram removidas]
__
Histórico: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
Falar com os Moderadores:([EMAIL PROTECTED])
Dorian Anderson Soutto - Fernanda Damous - Alisson Aguiar
__
Links do Yahoo! Grupos
* Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/oracle_br/
* Para sair deste grupo, envie um e-mail para:
[EMAIL PROTECTED]
* O uso que você faz do Yahoo! Grupos está sujeito aos:
http://br.yahoo.com/info/utos.html
Re: [oracle_br] Re: BITMAP CONVERSION (TO ROWIDS)
Quero ver como esse parametro esta setado na base antiga pois
se estiver como TRUE o problema pode ser outro.
O estranho é que somente algumas consulta há essa conversão
e quando eu dou
alter session set _b_tree_bitmap_plans=FALSE
A consulta restorna em segundos.
Esse problema pode também estar associado a conversão de caracteres na
migração???
Todas os parametros da v$nls_parameter estão iguais nas duas bases.
Foi usado um simples exp/imp.
Não estou conseguindo entender porque o plano de execução dessas consultas
estão assim.
Tanto com usuario SYSTEM como SYS
SQL select
2 x.ksppinm name,
3 y.kspftctxvl value,
4 y.kspftctxdf isdefault,
5 decode(bitand
6 (y.kspftctxvf,7),1,'MODIFIED',4,'SYSTEM_MOD','FALSE') ismod,
7 decode(bitand(y.kspftctxvf,2),2,'TRUE','FALSE') isadj
8 from
9 sys.x_$ksppi x,
10 sys.x_$ksppcv2 y
11 where
12 x.ksppinm like lower('%PARAM_NAME_LIKE%') and
13 x.inst_id = userenv('Instance') and
14 y.inst_id = userenv('Instance') and
15 x.indx+1 = y.kspftctxpn
16 order by
17 translate(x.ksppinm, ' _', ' ')
18
SQL /
Enter value for param_name_like: tree
old 12:x.ksppinm like lower('%PARAM_NAME_LIKE%') and
new 12:x.ksppinm like lower('%tree%') and
sys.x_$ksppcv2 y
*
ERROR at line 10:
ORA-00942: table or view does not exist
Phael
- Original Message -
From: jlchiappa [EMAIL PROTECTED]
To: oracle_br@yahoogrupos.com.br
Sent: Monday, July 25, 2005 9:46 AM
Subject: [oracle_br] Re: BITMAP CONVERSION (TO ROWIDS)
** Lógico ** que há um benefício, senão a Oracle não teria mudado...
Na verdade a função do parâmetro é permitir que planos normalmente só
disponíveis para bitmap indexes passem a estar disponíveis também pra
índices btree, abrindo NOVAS possibilidades na execução de SQLs. Mas
é claro, nada vem de graça, isso implica em MAIS consumo de CPU pra
fazer as conversões, mais espaço temporário pras conversões se os
índices forem grandes, enfim, mais consumo de modo geral. A Oracle
avaliou que , num banco bem-tunado, SEM gargalos de CPU, com
tablespaces LMT, com TEMP rápida (ie, de tamanho adequado. LMT, e
com true tempfiles), com áreas de bitmap (ie, bitmap_merge_area_size
e create_bitmap_area_size) razoáveis, onde NÂO haja desperdício de
CPU devido à parse constante, etc, esse acréscimo não seria tão
significativo, e realmente, em muitos casos isso é assim : no maior
banco que gerencio no cliente atual (um DW com cerca de 5 Tb de
dados) , quando migramos do 8i para 9.2.0.5 não alteramos o parâmetro
(na verdade nenhum dos parãmetros _ ), e foi ok, e está rodando há
mais de 6 meses sem problemas.
CASO realmente vc queira mudar isso, em banco Produção é **
IMPERATIVO ** que vc tenha a bênção e o OK do Suporte, já que
parâmetros _ são OCULTOS, em produção vc só os muda com aprovação do
Suporte Oracle, se vc quer que o banco continue sendo Suportado.
Pra se consultar esses parâmetros, o SHOW PARAMETERS do sqlplus não
funciona, já que são ocultos, vc teria que usar um script do tipo :
set linesize 132
column name format a42
column value format a30
select
x.ksppinm name,
y.kspftctxvl value,
y.kspftctxdf isdefault,
decode(bitand
(y.kspftctxvf,7),1,'MODIFIED',4,'SYSTEM_MOD','FALSE') ismod,
decode(bitand(y.kspftctxvf,2),2,'TRUE','FALSE') isadj
from
sys.x_$ksppi x,
sys.x_$ksppcv2 y
where
x.ksppinm like lower('%PARAM_NAME_LIKE%') and
x.inst_id = userenv('Instance') and
y.inst_id = userenv('Instance') and
x.indx+1 = y.kspftctxpn
order by
translate(x.ksppinm, ' _', ' ')
/
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, Phael [EMAIL PROTECTED] escreveu
Bom dia a todos,
Fiz uma migração de dados de um banco para outro(msm versão 9.2.0.5
só q plataforma diferente AIX p/ Linux)
e notei que algumas querys q levavam questão de segundo para serem
executadas demoravam muito mais no
novo ambiente e fazendo um tuning nessas querys descobri que CBO
fazia bitmap conversion from/to rowids.
Procurando no metalink.
Sugestão seria que o parametro _b_tree_bitmap_plans está com TRUE
e deve ser FALSE.
Em versões anteriores ao 9 já era FALSE. porque a Oracle deixou
como TRUE na nova versão(9 e 10g?
existe algum beneficio ?
Como são muitas as querys que estão usando BITMAP CONVERSION vou
ter que mudar para FALSE esse
parametro!!!
A solução seria essa mesma??
COMO EU VEJO O VALOR QUE ESSE PARAMETRO ESTA SETADO NO BANCO???
Phael
[As partes desta mensagem que não continham texto foram removidas]
__
Histórico: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
Falar com os Moderadores:([EMAIL PROTECTED])
Dorian Anderson Soutto - Fernanda Damous - Alisson Aguiar
__
Links do Yahoo! Grupos
[oracle_br] Re: BITMAP CONVERSION (TO ROWIDS)
respostas pra cada item :
--- Em oracle_br@yahoogrupos.com.br, Phael [EMAIL PROTECTED] escreveu
Quero ver como esse parametro esta setado na base antiga pois
se estiver como TRUE o problema pode ser outro.
OK, mas como eu disse esse cara implica em manipular bitmaps, ** não
** deixe de ver como estão os params de bitmap, e fazer as checagens
gerais (ie, tablespaces LMT corretamente criadas com uniform size,
objetos corretamente colocados nas tablespaces (sem initials
absurdos, por exemplo), banco de modo geral bem em performance,
CPU/rede/IO absolutamente sem gargalos...
Esse problema pode também estar associado a conversão de caracteres
na
migração???
Creio que não tem nada a ver characterset com isso.
Tanto com usuario SYSTEM como SYS
SQL select
2 x.ksppinm name,
3 y.kspftctxvl value,
4 y.kspftctxdf isdefault,
5 decode(bitand
6 (y.kspftctxvf,7),1,'MODIFIED',4,'SYSTEM_MOD','FALSE') ismod,
7 decode(bitand(y.kspftctxvf,2),2,'TRUE','FALSE') isadj
8 from
9 sys.x_$ksppi x,
10 sys.x_$ksppcv2 y
11 where
12 x.ksppinm like lower('%PARAM_NAME_LIKE%') and
13 x.inst_id = userenv('Instance') and
14 y.inst_id = userenv('Instance') and
15 x.indx+1 = y.kspftctxpn
16 order by
17 translate(x.ksppinm, ' _', ' ')
18
SQL /
Enter value for param_name_like: tree
old 12:x.ksppinm like lower('%PARAM_NAME_LIKE%') and
new 12:x.ksppinm like lower('%tree%') and
sys.x_$ksppcv2 y
*
ERROR at line 10:
ORA-00942: table or view does not exist
use X$ ao invés de X_$, então, e conectado como SYS (ou crie as views
x_$ e dê os privs pro system, se preferir).
[]s
Chiappa
__
Histórico: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
Falar com os Moderadores:([EMAIL PROTECTED])
Dorian Anderson Soutto - Fernanda Damous - Alisson Aguiar
__
Links do Yahoo! Grupos
* Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/oracle_br/
* Para sair deste grupo, envie um e-mail para:
[EMAIL PROTECTED]
* O uso que você faz do Yahoo! Grupos está sujeito aos:
http://br.yahoo.com/info/utos.html
