É 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 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
