Re: [oracle_br] Re: Modelagem visando Perfomance - Btree or Bitmap - Datas e seus problemas - Chiappa

2006-01-25 Por tôpico ESTUDO 
Chiappa, achei interessantissima a explicação, se possivel, gostaria de exemplo 
de configuração dos valores distintos no caso do A e B..

Obrigada

Cris

"vc o configura (params optimizer_nn, parãmetros de PGA, etc), passa a 
informação de quantos valores distintos e totais vc tem no índice e 
na tabela (estatísticas e histogramas)"

  - Original Message - 
  From: jlchiappa 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Thursday, January 05, 2006 4:41 PM
  Subject: [oracle_br] Re: Modelagem visando Perfomance - Btree or Bitmap - 
Datas e seus problemas


  --- Em oracle_br@yahoogrupos.com.br, Marcelo Cauduro <[EMAIL PROTECTED]> 
  escreveu
  >
  > Só mais uma coisa, vc disse :
  > 
  > "Já no outro caso
  > proposto, onde vc tem 20 mil e 80 mil, 20 mil representam 25% , pode
  > sim valer a pena um índice aí"
  > 
  > Status = 'A' 20 Mil registros
  > Status = 'B' 80 Mil registros
  > 
  > Valeria a pena somente se eu tivesse com objetivo em minha querie 
  buscar os
  > 25%, ou seja, o campo que representa esses 20 mil, no caso o 
  status 'A',
  > porque se eu quisesse buscar o campo com o status que tem 80 mil 
  registro,
  > no caso o 'B' não valeria a pena...
  > É isso mesmo ?

  Exato, se 'A' representa 25%. normalmente, via de regra, ainda vale a 
  pena os localizar via índice.

  > 
  > E se for isso mesmo... e eu estiver usando CBO... o otimizador 
  seria capaz (
  > se eu estiver colhendo as estatistica corretamente) de ver que com 
  um
  > determinado valor ( no caso o valor 'A' no Status) teria de ir 
  buscar o
  > valor pelo indice e com outro valor( no caso  o valor 'B')  teria 
  de fazer
  > um Full Scan ?

  ===>>> PRECISAMENTE  É exatamente pra isto que serve o CBO : se  
  vc o configura (params optimizer_nn, parãmetros de PGA, etc), passa a 
  informação de quantos valores distintos e totais vc tem no índice e 
  na tabela (estatísticas e histogramas), na esmagadora maioria das 
  vezes (tipo, 9 vezes em 10) , ele é totalmente capaz de checar se 
  vale a pena usar índice ou não, é isso sim.

  > 
  > E em RBO ? Ele iria por indice nas duas vezes ?

  Sendo índice comum, não-FBI, muito provavelmente sim :  o RBO é bem 
  burrinho, a lógica dele é : tenho um índice disponível , uso-o, ele é 
  totalmente incapaz de avaliar se o overhead natural dos índices vale 
  a pena ou não, se a leitura por "pedações" de uma vez que o full 
  table scan faz vale a pena ou não... Bem ruinzinho...

  []s

  Chiappa

  > 
  > On 1/5/06, Marcelo Cauduro <[EMAIL PROTECTED]> wrote:
  > >
  > > Impressionante...
  > >
  > > Muito obrigado
  > >
  > > On 1/5/06, jlchiappa <[EMAIL PROTECTED]> wrote:
  > > >
  > > >  É assim : índice, seja qual for, é extremamente útil pra 
  quando vc
  > > > quer recuperar relativamente ** POUCOS ** registros dentro do
  > > > universo maior da tabela. Isso porque buscar alguma coisa via 
  índice
  > > > significa : o banco recebe o valor-chave, procura no índice até 
  achar
  > > > esse valor, e nesse local do índice tem um rowid indicando onde
  > > > fisicamente em disco está o registro da tabela, que é 
  diretamente
  > > > acessado então.   Assim, se vc for recuperar (digamos) 1 
  registro via
  > > > índice, vc teve que acessar uns bloquinhos do índice (2 ou 3,
  > > > digamos) , aí achou o ROWID, aí acessou o bloco da tabela onde 
  está o
  > > > registro - certamente isso foi compensador, porque nesse caso o 
  full-
  > > > scan ia ler muito mais blocos. Se fossem digamos 5 ou 10 
  registros,
  > > > vc multiplicaria esse "overhead" do índice por 5 ou 10, tá 
  crescendo,
  > > > mas ainda certamente vale mais a pena ir por índice. PORÉM, 
  cfrme a
  > > > quntidade de registros a ler sobe mais e mais, esses bloquinhos
  > > > extras do índice pesam mais e mais, até chegar num ponto que 
  compensa
  > > > mais já se ler diretamente a tabela via table-scan, o que 
  inclusive
  > > > tem a vantagem de poder ser feito muito rapidamente, já que ao
  > > > contrário do índice, que é uma estrutura complexa (com 
  vários "tipos"
  > > > de blocos) uma tabela é só ler aos pedações, não há o 
  que "analisar"..
  > > > Aí vem a pergunta, que ponto é esse, onde começa a ser ruim 
  acesso
  > > > por índice  ?? Há grande discórdia entre os autores e 
  entendidos no
  > > > mundo Oracle, alguns falam que índice compensa só se vc for ler 
  até
  > > > 15% dos registros indexados, outros falam em 10% ou 20% ou 25%, 
  na
  > > > verdade há alguma variação natural, mas com certeza 50% tá bem 
  acima,
  > > > normalmente já começa  a valer a pena full-scan, então no teu 
  exemplo
  > > > de tabela com 100 mil, onde metade (50 mil) é = 'A' e a outra 
  metade
  > > > é 'B', certamente não deve valer a pena índice não. Já no outro 
  caso
  > > > proposto, onde vc tem 20 mil e 80 mil, 20 mil representam 25% , 
  pode
  > > > sim valer a pena um índice aí
  > > >
  > > > Quanto á b*tree ou bitmap, o ponto principal a favor do bitmap 
  é q

Re: [oracle_br] Re: Modelagem visando Perfomance - Btree or Bitmap - Datas e seus problemas

2006-01-25 Por tôpico ESTUDO 
Chiappa     (adoro seus ***)

Não sabia desse tipo de indice.
Obrigada pela dica.

Cris
  - Original Message - 
  From: jlchiappa 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Thursday, January 05, 2006 1:12 PM
  Subject: [oracle_br] Re: Modelagem visando Perfomance - Btree or Bitmap - 
Datas e seus problemas


  *** NENHUMA *** das duas opções, eu iria pra terceira, que é FBI 
  (Function-Based Index), tipo : teria o campo de flag como nullable, 
  escreveria uma função que me retornasse somente os (presumivelmente 
  poucos) caras que tem o campo preenchido, e faria um FBI com essa 
  função, aí só entrariam no índice os poucos registros com o flag 
  preenchido. Assim, se a tabela tem (digamos) 1 milhão d eregistros, e 
  num dado momento só há (digamos) mil registros com o campo de flag 
  preenchido, vc só teria mil registros no índice fbi, ficando portanto 
  ** muito ** menor que índice comum, e (o que é melhor) além de 
  pequeno só os caras que são realmente necessários estariam lá. Eu uso 
  bastante essa lógica aqui no cliente, obtive resultados EXCELENTES 
  com ela, coisa de fazer processo de 8 horas cair pra duas...

  []s

  Chiappa
  --- Em oracle_br@yahoogrupos.com.br, Marcelo Cauduro <[EMAIL PROTECTED]> 
  escreveu
  >
  > Pessoal,
  > 
  > Tenho uma tabela que recebe varias inserções e updates por dia.
  > Ela é uma tabela de referência para se saber o que já foi 
  processado em um
  > determinado arquivo
  > 
  > Ela entre outras, possui duas colunas, uma de "Data de Processo 1" 
  e outra
  > "Data de Processo 2", ambas do tipo Date.
  > Gravam-se nelas as datas em que cada um dos processo rodou. O 
  processo 1 na
  > tabela "Data de Processo 1" e o processo 2 na "Data de Processo 2".
  > O primeiro processo a rodar é o 1, afinal, o 2 roda se, e somente 
  se, o 1 ja
  > rodou.
  > 
  > Sendo assim , para identificar se já posso rodar o processo 2 
  (somente se o
  > 1 ja rodou ) , o que seria melhor:
  > 
  > -Criar um b-tree index na coluna "data de processo 1" e selecionar 
  tudo que
  > for nulo. Entretanto, Não acho essa uma boa alternativa porque , 
  pelo que
  > sei, o  indice b-tree não roda com valores nullos, certo ?
  > Então pensei em fazer a mesma coisa mas usando um indice bitmap, 
  mas pelo
  > que li, parece que o indice bitmap não deve ser usado em tabelas 
  com muitos
  > update
  > 
  > Outra opção:
  > -Criar coluna Estado que teria dois estados,
  > 1 para processo1 realizado e 2 para processo1 e 2 realizado,
  > Dai criaria um b-tree indice para ela e selecionaria tudo que 
  estiver com
  > valor 1
  > Se esse caso for bom, seria melhor nessa coluna um b-tree ou um 
  bitmap, e
  > por que ?
  > 
  > Muito Obrigado Pessoal.
  > 
  > 
  > [As partes desta mensagem que não continham texto foram removidas]
  >






  
--
  Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
  Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
  
--_
  Area de download do grupo - http://www.4shared.com/dir/101727/a4dcc423 


Yahoo! Grupos, um serviço oferecido por: 
  PUBLICIDADE

   


--
  Links do Yahoo! Grupos

a.. Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/oracle_br/
  
b.. Para sair deste grupo, envie um e-mail para:
[EMAIL PROTECTED]
  
c.. O uso que você faz do Yahoo! Grupos está sujeito aos Termos do Serviço 
do Yahoo!. 



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



--
Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--__
Moderador e Fundador: Dorian Anderson Soutto [EMAIL PROTECTED]
__ 
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: Modelagem visando Perfomance - Btree or Bitmap - Datas e seus problemas

2006-01-05 Por tôpico Marcelo Cauduro 
Muito Obrigado 

On 1/5/06, jlchiappa <[EMAIL PROTECTED]> wrote:
>
>  --- Em oracle_br@yahoogrupos.com.br, Marcelo Cauduro <[EMAIL PROTECTED]>
> escreveu
> >
> > Só mais uma coisa, vc disse :
> >
> > "Já no outro caso
> > proposto, onde vc tem 20 mil e 80 mil, 20 mil representam 25% , pode
> > sim valer a pena um índice aí"
> >
> > Status = 'A' 20 Mil registros
> > Status = 'B' 80 Mil registros
> >
> > Valeria a pena somente se eu tivesse com objetivo em minha querie
> buscar os
> > 25%, ou seja, o campo que representa esses 20 mil, no caso o
> status 'A',
> > porque se eu quisesse buscar o campo com o status que tem 80 mil
> registro,
> > no caso o 'B' não valeria a pena...
> > É isso mesmo ?
>
> Exato, se 'A' representa 25%. normalmente, via de regra, ainda vale a
> pena os localizar via índice.
>
> >
> > E se for isso mesmo... e eu estiver usando CBO... o otimizador
> seria capaz (
> > se eu estiver colhendo as estatistica corretamente) de ver que com
> um
> > determinado valor ( no caso o valor 'A' no Status) teria de ir
> buscar o
> > valor pelo indice e com outro valor( no caso  o valor 'B')  teria
> de fazer
> > um Full Scan ?
>
> ===>>> PRECISAMENTE  É exatamente pra isto que serve o CBO : se
> vc o configura (params optimizer_nn, parãmetros de PGA, etc), passa a
> informação de quantos valores distintos e totais vc tem no índice e
> na tabela (estatísticas e histogramas), na esmagadora maioria das
> vezes (tipo, 9 vezes em 10) , ele é totalmente capaz de checar se
> vale a pena usar índice ou não, é isso sim.
>
> >
> > E em RBO ? Ele iria por indice nas duas vezes ?
>
> Sendo índice comum, não-FBI, muito provavelmente sim :  o RBO é bem
> burrinho, a lógica dele é : tenho um índice disponível , uso-o, ele é
> totalmente incapaz de avaliar se o overhead natural dos índices vale
> a pena ou não, se a leitura por "pedações" de uma vez que o full
> table scan faz vale a pena ou não... Bem ruinzinho...
>
> []s
>
> Chiappa
>
> >
> > On 1/5/06, Marcelo Cauduro <[EMAIL PROTECTED]> wrote:
> > >
> > > Impressionante...
> > >
> > > Muito obrigado
> > >
> > > On 1/5/06, jlchiappa <[EMAIL PROTECTED]> wrote:
> > > >
> > > >  É assim : índice, seja qual for, é extremamente útil pra
> quando vc
> > > > quer recuperar relativamente ** POUCOS ** registros dentro do
> > > > universo maior da tabela. Isso porque buscar alguma coisa via
> índice
> > > > significa : o banco recebe o valor-chave, procura no índice até
> achar
> > > > esse valor, e nesse local do índice tem um rowid indicando onde
> > > > fisicamente em disco está o registro da tabela, que é
> diretamente
> > > > acessado então.   Assim, se vc for recuperar (digamos) 1
> registro via
> > > > índice, vc teve que acessar uns bloquinhos do índice (2 ou 3,
> > > > digamos) , aí achou o ROWID, aí acessou o bloco da tabela onde
> está o
> > > > registro - certamente isso foi compensador, porque nesse caso o
> full-
> > > > scan ia ler muito mais blocos. Se fossem digamos 5 ou 10
> registros,
> > > > vc multiplicaria esse "overhead" do índice por 5 ou 10, tá
> crescendo,
> > > > mas ainda certamente vale mais a pena ir por índice. PORÉM,
> cfrme a
> > > > quntidade de registros a ler sobe mais e mais, esses bloquinhos
> > > > extras do índice pesam mais e mais, até chegar num ponto que
> compensa
> > > > mais já se ler diretamente a tabela via table-scan, o que
> inclusive
> > > > tem a vantagem de poder ser feito muito rapidamente, já que ao
> > > > contrário do índice, que é uma estrutura complexa (com
> vários "tipos"
> > > > de blocos) uma tabela é só ler aos pedações, não há o
> que "analisar"..
> > > > Aí vem a pergunta, que ponto é esse, onde começa a ser ruim
> acesso
> > > > por índice  ?? Há grande discórdia entre os autores e
> entendidos no
> > > > mundo Oracle, alguns falam que índice compensa só se vc for ler
> até
> > > > 15% dos registros indexados, outros falam em 10% ou 20% ou 25%,
> na
> > > > verdade há alguma variação natural, mas com certeza 50% tá bem
> acima,
> > > > normalmente já começa  a valer a pena full-scan, então no teu
> exemplo
> > > > de tabela com 100 mil, onde metade (50 mil) é = 'A' e a outra
> metade
> > > > é 'B', certamente não deve valer a pena índice não. Já no outro
> caso
> > > > proposto, onde vc tem 20 mil e 80 mil, 20 mil representam 25% ,
> pode
> > > > sim valer a pena um índice aí
> > > >
> > > > Quanto á b*tree ou bitmap, o ponto principal a favor do bitmap
> é que
> > > > ele permite operações de "join" de índices, tipo usar um pedaço
> de
> > > > cada índice numa busca,  e coisas do tipo, o que o b*tree não,
> isso é
> > > > excelente pros casos de várias tabelas indexadas serem joineadas
> > > > frequentemente, e o ponto contra é que ele indexa os nulos E ,
> quando
> > > > ocorre DML na tabela (ie, INSERT, UPDATE, DELETE) o lock é no
> bitmap
> > > > inteiro, outras sessões que estiverem tentando usar esse índice
> > > > sofre. VEJA, não é que ** qualquer ** UPDATE/INSERT/DELETE
> derro

Re: [oracle_br] Re: Modelagem visando Perfomance - Btree or Bitmap - Datas e seus problemas

2006-01-05 Por tôpico Marcelo Cauduro 
Só mais uma coisa, vc disse :

"Já no outro caso
proposto, onde vc tem 20 mil e 80 mil, 20 mil representam 25% , pode
sim valer a pena um índice aí"

Status = 'A' 20 Mil registros
Status = 'B' 80 Mil registros

Valeria a pena somente se eu tivesse com objetivo em minha querie buscar os
25%, ou seja, o campo que representa esses 20 mil, no caso o status 'A',
porque se eu quisesse buscar o campo com o status que tem 80 mil registro,
no caso o 'B' não valeria a pena...
É isso mesmo ?

E se for isso mesmo... e eu estiver usando CBO... o otimizador seria capaz (
se eu estiver colhendo as estatistica corretamente) de ver que com um
determinado valor ( no caso o valor 'A' no Status) teria de ir buscar o
valor pelo indice e com outro valor( no caso  o valor 'B')  teria de fazer
um Full Scan ?

E em RBO ? Ele iria por indice nas duas vezes ?

On 1/5/06, Marcelo Cauduro <[EMAIL PROTECTED]> wrote:
>
> Impressionante...
>
> Muito obrigado
>
> On 1/5/06, jlchiappa <[EMAIL PROTECTED]> wrote:
> >
> >  É assim : índice, seja qual for, é extremamente útil pra quando vc
> > quer recuperar relativamente ** POUCOS ** registros dentro do
> > universo maior da tabela. Isso porque buscar alguma coisa via índice
> > significa : o banco recebe o valor-chave, procura no índice até achar
> > esse valor, e nesse local do índice tem um rowid indicando onde
> > fisicamente em disco está o registro da tabela, que é diretamente
> > acessado então.   Assim, se vc for recuperar (digamos) 1 registro via
> > índice, vc teve que acessar uns bloquinhos do índice (2 ou 3,
> > digamos) , aí achou o ROWID, aí acessou o bloco da tabela onde está o
> > registro - certamente isso foi compensador, porque nesse caso o full-
> > scan ia ler muito mais blocos. Se fossem digamos 5 ou 10 registros,
> > vc multiplicaria esse "overhead" do índice por 5 ou 10, tá crescendo,
> > mas ainda certamente vale mais a pena ir por índice. PORÉM, cfrme a
> > quntidade de registros a ler sobe mais e mais, esses bloquinhos
> > extras do índice pesam mais e mais, até chegar num ponto que compensa
> > mais já se ler diretamente a tabela via table-scan, o que inclusive
> > tem a vantagem de poder ser feito muito rapidamente, já que ao
> > contrário do índice, que é uma estrutura complexa (com vários "tipos"
> > de blocos) uma tabela é só ler aos pedações, não há o que "analisar"..
> > Aí vem a pergunta, que ponto é esse, onde começa a ser ruim acesso
> > por índice  ?? Há grande discórdia entre os autores e entendidos no
> > mundo Oracle, alguns falam que índice compensa só se vc for ler até
> > 15% dos registros indexados, outros falam em 10% ou 20% ou 25%, na
> > verdade há alguma variação natural, mas com certeza 50% tá bem acima,
> > normalmente já começa  a valer a pena full-scan, então no teu exemplo
> > de tabela com 100 mil, onde metade (50 mil) é = 'A' e a outra metade
> > é 'B', certamente não deve valer a pena índice não. Já no outro caso
> > proposto, onde vc tem 20 mil e 80 mil, 20 mil representam 25% , pode
> > sim valer a pena um índice aí
> >
> > Quanto á b*tree ou bitmap, o ponto principal a favor do bitmap é que
> > ele permite operações de "join" de índices, tipo usar um pedaço de
> > cada índice numa busca,  e coisas do tipo, o que o b*tree não, isso é
> > excelente pros casos de várias tabelas indexadas serem joineadas
> > frequentemente, e o ponto contra é que ele indexa os nulos E , quando
> > ocorre DML na tabela (ie, INSERT, UPDATE, DELETE) o lock é no bitmap
> > inteiro, outras sessões que estiverem tentando usar esse índice
> > sofre. VEJA, não é que ** qualquer ** UPDATE/INSERT/DELETE derrote a
> > idéia de bitmap, o problema aqui é a frequência (quntidade) e o fato
> > de houverem ou não outras sessões querendo usar ao mesmo tempo.
> >
> > []s
> >
> > Chiappa
> >
> > --- Em oracle_br@yahoogrupos.com.br, Marcelo Cauduro <[EMAIL PROTECTED]>
> > escreveu
> > >
> > > Muito Obrigado... Ótima explanação
> > >
> > > fica apenas uma dúvida aparente o FBI é uma das melhores
> > alternativas em
> > > alguns casos mas fico com uma dúvida persistente..
> > >
> > > Tenho uma tabela com 100.000 registros
> > > tenho um campo de status com dois status apenas, 'A' de ativo e 'I'
> > de
> > > inativo...
> > >
> > > supondo que cada um tenha 50 mil registros cada... teria diferenca
> > ter um
> > > indice nessa coluna ?
> > > E supondo outra situacao, se uma tiver 2 registro e a outra
> > 8, teria
> > > diferenca o indice ?
> > > Seria melhor ser Btree ou Bitmap ?
> > >
> > >
> > > Muito Obrigado
> > >
> > >
> > >
> > > On 1/5/06, jlchiappa <[EMAIL PROTECTED]> wrote:
> > > >
> > > >  Seguinte, dá uma olhada no exemplinho que acabei de mandar pra
> > outra
> > > > pergunta, que tá completinho (eu o fiz em 9i, mas funcionaria
> > > > perfeitamente no 8i versão 8.1.7.x, é onde eu o usava no começo do
> > > > ano passado, antes de migrar o meu sistema pra 9i) - e lógico, lá
> > no
> > > > exemplinho o outro colega queria usar FBI

Re: [oracle_br] Re: Modelagem visando Perfomance - Btree or Bitmap - Datas e seus problemas

2006-01-05 Por tôpico Marcelo Cauduro 
Impressionante...

Muito obrigado

On 1/5/06, jlchiappa <[EMAIL PROTECTED]> wrote:
>
>  É assim : índice, seja qual for, é extremamente útil pra quando vc
> quer recuperar relativamente ** POUCOS ** registros dentro do
> universo maior da tabela. Isso porque buscar alguma coisa via índice
> significa : o banco recebe o valor-chave, procura no índice até achar
> esse valor, e nesse local do índice tem um rowid indicando onde
> fisicamente em disco está o registro da tabela, que é diretamente
> acessado então.   Assim, se vc for recuperar (digamos) 1 registro via
> índice, vc teve que acessar uns bloquinhos do índice (2 ou 3,
> digamos) , aí achou o ROWID, aí acessou o bloco da tabela onde está o
> registro - certamente isso foi compensador, porque nesse caso o full-
> scan ia ler muito mais blocos. Se fossem digamos 5 ou 10 registros,
> vc multiplicaria esse "overhead" do índice por 5 ou 10, tá crescendo,
> mas ainda certamente vale mais a pena ir por índice. PORÉM, cfrme a
> quntidade de registros a ler sobe mais e mais, esses bloquinhos
> extras do índice pesam mais e mais, até chegar num ponto que compensa
> mais já se ler diretamente a tabela via table-scan, o que inclusive
> tem a vantagem de poder ser feito muito rapidamente, já que ao
> contrário do índice, que é uma estrutura complexa (com vários "tipos"
> de blocos) uma tabela é só ler aos pedações, não há o que "analisar"..
> Aí vem a pergunta, que ponto é esse, onde começa a ser ruim acesso
> por índice  ?? Há grande discórdia entre os autores e entendidos no
> mundo Oracle, alguns falam que índice compensa só se vc for ler até
> 15% dos registros indexados, outros falam em 10% ou 20% ou 25%, na
> verdade há alguma variação natural, mas com certeza 50% tá bem acima,
> normalmente já começa  a valer a pena full-scan, então no teu exemplo
> de tabela com 100 mil, onde metade (50 mil) é = 'A' e a outra metade
> é 'B', certamente não deve valer a pena índice não. Já no outro caso
> proposto, onde vc tem 20 mil e 80 mil, 20 mil representam 25% , pode
> sim valer a pena um índice aí
>
> Quanto á b*tree ou bitmap, o ponto principal a favor do bitmap é que
> ele permite operações de "join" de índices, tipo usar um pedaço de
> cada índice numa busca,  e coisas do tipo, o que o b*tree não, isso é
> excelente pros casos de várias tabelas indexadas serem joineadas
> frequentemente, e o ponto contra é que ele indexa os nulos E , quando
> ocorre DML na tabela (ie, INSERT, UPDATE, DELETE) o lock é no bitmap
> inteiro, outras sessões que estiverem tentando usar esse índice
> sofre. VEJA, não é que ** qualquer ** UPDATE/INSERT/DELETE derrote a
> idéia de bitmap, o problema aqui é a frequência (quntidade) e o fato
> de houverem ou não outras sessões querendo usar ao mesmo tempo.
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br, Marcelo Cauduro <[EMAIL PROTECTED]>
> escreveu
> >
> > Muito Obrigado... Ótima explanação
> >
> > fica apenas uma dúvida aparente o FBI é uma das melhores
> alternativas em
> > alguns casos mas fico com uma dúvida persistente..
> >
> > Tenho uma tabela com 100.000 registros
> > tenho um campo de status com dois status apenas, 'A' de ativo e 'I'
> de
> > inativo...
> >
> > supondo que cada um tenha 50 mil registros cada... teria diferenca
> ter um
> > indice nessa coluna ?
> > E supondo outra situacao, se uma tiver 2 registro e a outra
> 8, teria
> > diferenca o indice ?
> > Seria melhor ser Btree ou Bitmap ?
> >
> >
> > Muito Obrigado
> >
> >
> >
> > On 1/5/06, jlchiappa <[EMAIL PROTECTED]> wrote:
> > >
> > >  Seguinte, dá uma olhada no exemplinho que acabei de mandar pra
> outra
> > > pergunta, que tá completinho (eu o fiz em 9i, mas funcionaria
> > > perfeitamente no 8i versão 8.1.7.x, é onde eu o usava no começo do
> > > ano passado, antes de migrar o meu sistema pra 9i) - e lógico, lá
> no
> > > exemplinho o outro colega queria usar FBI em otimização de ROLE,
> > > então eu (urgh!!) meti hints no SELECT, vc em tendo um sistema
> > > civilizado, escrito em CBO (deve ser, já que vc está desenvolvendo
> > > agora) logicamente não precisa dessa coisarada...
> > >
> > > O conceito que vc tinha está não errado, mas incompleto : é assim,
> > > em todo e qualquer índice b*tree (seja FBI, seja índice
> > > b*tree "comum"), realmente ** NÂO É ** todos os registros que
> entram
> > > no índice, e sim APENAS os registros onde a chave não é nula,
> chaves
> > > nulas nunca, nunca entram no índice b*tree), o truque que estou
> > > usando portanto depende desse conceito, SE uma função retornar um
> > > nulo e a função é o que está sendo indexado, nulls não entram no
> > > índice, o índice ficou portanto só com os regs q me interessam.
> > >
> > > []s
> > >
> > >   Chiappa
> > > --- Em oracle_br@yahoogrupos.com.br, Marcelo Cauduro
> <[EMAIL PROTECTED]>
> > > escreveu
> > > >
> > > > Além disso, só mais uma coisa, você mencionou em criar um FBI
> para
> > > apenas os
> > > > que tem o valor preenchido...
> > >

Re: [oracle_br] Re: Modelagem visando Perfomance - Btree or Bitmap - Datas e seus problemas

2006-01-05 Por tôpico Marcelo Cauduro 
Muito Obrigado... Ótima explanação

fica apenas uma dúvida aparente o FBI é uma das melhores alternativas em
alguns casos mas fico com uma dúvida persistente..

Tenho uma tabela com 100.000 registros
tenho um campo de status com dois status apenas, 'A' de ativo e 'I' de
inativo...

supondo que cada um tenha 50 mil registros cada... teria diferenca ter um
indice nessa coluna ?
E supondo outra situacao, se uma tiver 2 registro e a outra 8, teria
diferenca o indice ?
Seria melhor ser Btree ou Bitmap ?


Muito Obrigado



On 1/5/06, jlchiappa <[EMAIL PROTECTED]> wrote:
>
>  Seguinte, dá uma olhada no exemplinho que acabei de mandar pra outra
> pergunta, que tá completinho (eu o fiz em 9i, mas funcionaria
> perfeitamente no 8i versão 8.1.7.x, é onde eu o usava no começo do
> ano passado, antes de migrar o meu sistema pra 9i) - e lógico, lá no
> exemplinho o outro colega queria usar FBI em otimização de ROLE,
> então eu (urgh!!) meti hints no SELECT, vc em tendo um sistema
> civilizado, escrito em CBO (deve ser, já que vc está desenvolvendo
> agora) logicamente não precisa dessa coisarada...
>
> O conceito que vc tinha está não errado, mas incompleto : é assim,
> em todo e qualquer índice b*tree (seja FBI, seja índice
> b*tree "comum"), realmente ** NÂO É ** todos os registros que entram
> no índice, e sim APENAS os registros onde a chave não é nula, chaves
> nulas nunca, nunca entram no índice b*tree), o truque que estou
> usando portanto depende desse conceito, SE uma função retornar um
> nulo e a função é o que está sendo indexado, nulls não entram no
> índice, o índice ficou portanto só com os regs q me interessam.
>
> []s
>
>   Chiappa
> --- Em oracle_br@yahoogrupos.com.br, Marcelo Cauduro <[EMAIL PROTECTED]>
> escreveu
> >
> > Além disso, só mais uma coisa, você mencionou em criar um FBI para
> apenas os
> > que tem o valor preenchido...
> >
> > mas como ?
> >
> > seria um:
> >
> > create index X on TABELA ( ? )
> >
> > mas que função ? como ele restringiria ?
> >
> > pois sempre pensei que no indice FBI eu teria todos os valoles...
> iguais aos
> > outros indices ... mas eles teriam em epscial o tratamento dado
> pela funcao,
> > por exemplo ,se eu quisesse um indice com data truncadas, ele
> guardaria o
> > row id e data truncada.de "Todos" os valores...
> > mas pelo que você disse é possivel deixar o FBI somente com os
> registros
> > necessários ao meu objetivo  como ?
> >
> > On 1/5/06, Marcelo Cauduro <[EMAIL PROTECTED]> wrote:
> > >
> > > Muito Obrigado Chiappa,ótima alteranativa, .
> > >
> > > mas supondo que meu Oracle seja 8i... teria outra alternativa a
> FBI ?
> > >
> > > On 1/5/06, jlchiappa <[EMAIL PROTECTED] > wrote:
> > > >
> > > >  *** NENHUMA *** das duas opções, eu iria pra terceira, que é
> FBI
> > > > (Function-Based Index), tipo : teria o campo de flag como
> nullable,
> > > > escreveria uma função que me retornasse somente os
> (presumivelmente
> > > > poucos) caras que tem o campo preenchido, e faria um FBI com
> essa
> > > > função, aí só entrariam no índice os poucos registros com o flag
> > > > preenchido. Assim, se a tabela tem (digamos) 1 milhão d
> eregistros, e
> > > > num dado momento só há (digamos) mil registros com o campo de
> flag
> > > > preenchido, vc só teria mil registros no índice fbi, ficando
> portanto
> > > > ** muito ** menor que índice comum, e (o que é melhor) além de
> > > > pequeno só os caras que são realmente necessários estariam lá.
> Eu uso
> > > > bastante essa lógica aqui no cliente, obtive resultados
> EXCELENTES
> > > > com ela, coisa de fazer processo de 8 horas cair pra duas...
> > > >
> > > > []s
> > > >
> > > > Chiappa
> > > > --- Em oracle_br@yahoogrupos.com.br, Marcelo Cauduro
> <[EMAIL PROTECTED]>
> > > > escreveu
> > > > >
> > > > > Pessoal,
> > > > >
> > > > > Tenho uma tabela que recebe varias inserções e updates por
> dia.
> > > > > Ela é uma tabela de referência para se saber o que já foi
> > > > processado em um
> > > > > determinado arquivo
> > > > >
> > > > > Ela entre outras, possui duas colunas, uma de "Data de
> Processo 1"
> > > > e outra
> > > > > "Data de Processo 2", ambas do tipo Date.
> > > > > Gravam-se nelas as datas em que cada um dos processo rodou. O
> > > > processo 1 na
> > > > > tabela "Data de Processo 1" e o processo 2 na "Data de
> Processo 2".
> > > > > O primeiro processo a rodar é o 1, afinal, o 2 roda se, e
> somente
> > > > se, o 1 ja
> > > > > rodou.
> > > > >
> > > > > Sendo assim , para identificar se já posso rodar o processo 2
> > > > (somente se o
> > > > > 1 ja rodou ) , o que seria melhor:
> > > > >
> > > > > -Criar um b-tree index na coluna "data de processo 1" e
> selecionar
> > > > tudo que
> > > > > for nulo. Entretanto, Não acho essa uma boa alternativa
> porque ,
> > > > pelo que
> > > > > sei, o  indice b-tree não roda com valores nullos, certo ?
> > > > > Então pensei em fazer a mesma coisa mas usando um indice
> bitmap,
> > > > mas pelo
> > > > > que li,

Re: [oracle_br] Re: Modelagem visando Perfomance - Btree or Bitmap - Datas e seus problemas

2006-01-05 Por tôpico Marcelo Cauduro 
Além disso, só mais uma coisa, você mencionou em criar um FBI para apenas os
que tem o valor preenchido...

mas como ?

seria um:

create index X on TABELA ( ? )

mas que função ? como ele restringiria ?

pois sempre pensei que no indice FBI eu teria todos os valoles... iguais aos
outros indices ... mas eles teriam em epscial o tratamento dado pela funcao,
por exemplo ,se eu quisesse um indice com data truncadas, ele guardaria o
row id e data truncada.de "Todos" os valores...
mas pelo que você disse é possivel deixar o FBI somente com os registros
necessários ao meu objetivo  como ?

On 1/5/06, Marcelo Cauduro <[EMAIL PROTECTED]> wrote:
>
> Muito Obrigado Chiappa,ótima alteranativa, .
>
> mas supondo que meu Oracle seja 8i... teria outra alternativa a FBI ?
>
> On 1/5/06, jlchiappa <[EMAIL PROTECTED] > wrote:
> >
> >  *** NENHUMA *** das duas opções, eu iria pra terceira, que é FBI
> > (Function-Based Index), tipo : teria o campo de flag como nullable,
> > escreveria uma função que me retornasse somente os (presumivelmente
> > poucos) caras que tem o campo preenchido, e faria um FBI com essa
> > função, aí só entrariam no índice os poucos registros com o flag
> > preenchido. Assim, se a tabela tem (digamos) 1 milhão d eregistros, e
> > num dado momento só há (digamos) mil registros com o campo de flag
> > preenchido, vc só teria mil registros no índice fbi, ficando portanto
> > ** muito ** menor que índice comum, e (o que é melhor) além de
> > pequeno só os caras que são realmente necessários estariam lá. Eu uso
> > bastante essa lógica aqui no cliente, obtive resultados EXCELENTES
> > com ela, coisa de fazer processo de 8 horas cair pra duas...
> >
> > []s
> >
> > Chiappa
> > --- Em oracle_br@yahoogrupos.com.br, Marcelo Cauduro <[EMAIL PROTECTED]>
> > escreveu
> > >
> > > Pessoal,
> > >
> > > Tenho uma tabela que recebe varias inserções e updates por dia.
> > > Ela é uma tabela de referência para se saber o que já foi
> > processado em um
> > > determinado arquivo
> > >
> > > Ela entre outras, possui duas colunas, uma de "Data de Processo 1"
> > e outra
> > > "Data de Processo 2", ambas do tipo Date.
> > > Gravam-se nelas as datas em que cada um dos processo rodou. O
> > processo 1 na
> > > tabela "Data de Processo 1" e o processo 2 na "Data de Processo 2".
> > > O primeiro processo a rodar é o 1, afinal, o 2 roda se, e somente
> > se, o 1 ja
> > > rodou.
> > >
> > > Sendo assim , para identificar se já posso rodar o processo 2
> > (somente se o
> > > 1 ja rodou ) , o que seria melhor:
> > >
> > > -Criar um b-tree index na coluna "data de processo 1" e selecionar
> > tudo que
> > > for nulo. Entretanto, Não acho essa uma boa alternativa porque ,
> > pelo que
> > > sei, o  indice b-tree não roda com valores nullos, certo ?
> > > Então pensei em fazer a mesma coisa mas usando um indice bitmap,
> > mas pelo
> > > que li, parece que o indice bitmap não deve ser usado em tabelas
> > com muitos
> > > update
> > >
> > > Outra opção:
> > > -Criar coluna Estado que teria dois estados,
> > > 1 para processo1 realizado e 2 para processo1 e 2 realizado,
> > > Dai criaria um b-tree indice para ela e selecionaria tudo que
> > estiver com
> > > valor 1
> > > Se esse caso for bom, seria melhor nessa coluna um b-tree ou um
> > bitmap, e
> > > por que ?
> > >
> > > Muito Obrigado Pessoal.
> > >
> > >
> > > [As partes desta mensagem que não continham texto foram removidas]
> > >
> >
> >
> >
> >
> >
> >
> > --
> > Atenção! As mensagens deste grupo são de acesso público e de inteira
> > responsabilidade de seus remetentes.
> > Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
> >
> > --_
> > Area de download do grupo - http://www.4shared.com/dir/101727/a4dcc423
> >
> >
> >  *Yahoo! Grupos, um serviço oferecido por:*  PUBLICIDADE
> >
> > 
> > --
> > *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]
> ><[EMAIL PROTECTED]>
> >
> >- O uso que você faz do Yahoo! Grupos está sujeito aos Termos do
> >Serviço do Yahoo! .
> >
> >
>


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

Re: [oracle_br] Re: Modelagem visando Perfomance - Btree or Bitmap - Datas e seus problemas

2006-01-05 Por tôpico Marcelo Cauduro 
Muito Obrigado Chiappa,ótima alteranativa, .

mas supondo que meu Oracle seja 8i... teria outra alternativa a FBI ?

On 1/5/06, jlchiappa <[EMAIL PROTECTED]> wrote:
>
>  *** NENHUMA *** das duas opções, eu iria pra terceira, que é FBI
> (Function-Based Index), tipo : teria o campo de flag como nullable,
> escreveria uma função que me retornasse somente os (presumivelmente
> poucos) caras que tem o campo preenchido, e faria um FBI com essa
> função, aí só entrariam no índice os poucos registros com o flag
> preenchido. Assim, se a tabela tem (digamos) 1 milhão d eregistros, e
> num dado momento só há (digamos) mil registros com o campo de flag
> preenchido, vc só teria mil registros no índice fbi, ficando portanto
> ** muito ** menor que índice comum, e (o que é melhor) além de
> pequeno só os caras que são realmente necessários estariam lá. Eu uso
> bastante essa lógica aqui no cliente, obtive resultados EXCELENTES
> com ela, coisa de fazer processo de 8 horas cair pra duas...
>
> []s
>
> Chiappa
> --- Em oracle_br@yahoogrupos.com.br, Marcelo Cauduro <[EMAIL PROTECTED]>
> escreveu
> >
> > Pessoal,
> >
> > Tenho uma tabela que recebe varias inserções e updates por dia.
> > Ela é uma tabela de referência para se saber o que já foi
> processado em um
> > determinado arquivo
> >
> > Ela entre outras, possui duas colunas, uma de "Data de Processo 1"
> e outra
> > "Data de Processo 2", ambas do tipo Date.
> > Gravam-se nelas as datas em que cada um dos processo rodou. O
> processo 1 na
> > tabela "Data de Processo 1" e o processo 2 na "Data de Processo 2".
> > O primeiro processo a rodar é o 1, afinal, o 2 roda se, e somente
> se, o 1 ja
> > rodou.
> >
> > Sendo assim , para identificar se já posso rodar o processo 2
> (somente se o
> > 1 ja rodou ) , o que seria melhor:
> >
> > -Criar um b-tree index na coluna "data de processo 1" e selecionar
> tudo que
> > for nulo. Entretanto, Não acho essa uma boa alternativa porque ,
> pelo que
> > sei, o  indice b-tree não roda com valores nullos, certo ?
> > Então pensei em fazer a mesma coisa mas usando um indice bitmap,
> mas pelo
> > que li, parece que o indice bitmap não deve ser usado em tabelas
> com muitos
> > update
> >
> > Outra opção:
> > -Criar coluna Estado que teria dois estados,
> > 1 para processo1 realizado e 2 para processo1 e 2 realizado,
> > Dai criaria um b-tree indice para ela e selecionaria tudo que
> estiver com
> > valor 1
> > Se esse caso for bom, seria melhor nessa coluna um b-tree ou um
> bitmap, e
> > por que ?
> >
> > Muito Obrigado Pessoal.
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>
>
>
>
>
>
> --
> Atenção! As mensagens deste grupo são de acesso público e de inteira
> responsabilidade de seus remetentes.
> Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
>
> --_
> Area de download do grupo - http://www.4shared.com/dir/101727/a4dcc423
>
>
>  *Yahoo! Grupos, um serviço oferecido por:*  PUBLICIDADE
> 
> --
> *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]<[EMAIL PROTECTED]>
>
>- O uso que você faz do Yahoo! Grupos está sujeito aos Termos do
>Serviço do Yahoo! .
>
>


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



--
Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--_
Area de download do grupo - http://www.4shared.com/dir/101727/a4dcc423  
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