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 20000 registro e a outra
> > 80000, 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, 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
> > > > > > >
> > > > > > >
> > > >
> > <http://br.rd.yahoo.com/SIG=12fhsm0ri/M=387526.7663462.8550203.1588051
> > >
> > > /D=brclubs/S=2137114689:HM/Y=BR/EXP=1136481349/A=3215516/R=2/SIG=16e
> > 56
> > > > adpd/*http://landingstrip.dell.com/landingstrip/ls.asp?
> > > >
> > CID=10029&LID=288321&DGC=BA&DGStor=DHS&DGSite=Yahoo&Conum=BR&DURL=http
> > > > ://www1.la.dell.com/content/products/category.aspx/desktops?c%
> > 3Dbr%
> > > > 26l%3Dpt%26s%3Ddhs>
> > > > > > > ------------------------------
> > > > > > > *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]
> > > > subject=Unsubscribe>
> > > > > > >
> > > > > > >    - O uso que você faz do Yahoo! Grupos está sujeito aos
> > > > Termos do
> > > > > > >    Serviço do Yahoo! <http://br.yahoo.com/info/utos.html>.
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > [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
> > > >
> > <http://br.rd.yahoo.com/SIG=12ff3ia4s/M=387526.7663462.8550203.1588051
> > /D=brclubs/S=2137114689:HM/Y=BR/EXP=1136486447/A=3215516/R=2/SIG=16e56
> > adpd/*http://landingstrip.dell.com/landingstrip/ls.asp?
> > CID=10029&LID=288321&DGC=BA&DGStor=DHS&DGSite=Yahoo&Conum=BR&DURL=http
> > ://www1.la.dell.com/content/products/category.aspx/desktops?c%3Dbr%
> > 26l%3Dpt%26s%3Ddhs>
> > > > ------------------------------
> > > > *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]<oracle_br-
> > [EMAIL PROTECTED]>
> > > >
> > > >    - O uso que você faz do Yahoo! Grupos está sujeito aos Termos
> > do
> > > >    Serviço do Yahoo! <http://br.yahoo.com/info/utos.html>.
> > > >
> > > >
> > >
> > >
> > > [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
> >
> > <http://br.rd.yahoo.com/SIG=12f887nc8/M=387526.7663462.8550203.1588051/D=brclubs/S=2137114689:HM/Y=BR/EXP=1136490552/A=3215516/R=2/SIG=16e56adpd/*http://landingstrip.dell.com/landingstrip/ls.asp?CID=10029&LID=288321&DGC=BA&DGStor=DHS&DGSite=Yahoo&Conum=BR&DURL=http://www1.la.dell.com/content/products/category.aspx/desktops?c%3Dbr%26l%3Dpt%26s%3Ddhs>
> > ------------------------------
> > *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! <http://br.yahoo.com/info/utos.html>.
> >
> >
>


[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

 



Responder a