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 é 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=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]<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=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] > > > <[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 ------------------------------------------------------------------------------ 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
