Olá Chiappa, O objetivo é estudar, bem como entender o por quê de alguns fatos que ocorrem com o plano de execução escolhido, como por exemplo a mensagem de alguns dias que relatava FTS em tabela com milhões de registros e uma coluna com baixa seletividade e esta com índice. Fui no site indicado, li um monte de coisas.
O argumento usado para usar FTS é que determinados blocos seriam lidos mais de uma vez. Ora, isto depende de como os blocos de índices são construidos. Por exemplo, se num bloco de índice as entradas (no nível de blocos folhas de índice) as linhas possuirem somente a CHAVE + ROWID, sim, concordo pois, caso a entrada dos dados fosse feita de maneira aleatória, com esta quantidade de linhas e supondo que nem todos os blocos estariam em buffer o oracle acabaria tendo que fazer leituras físicas em blocos lidos anteriormente. Mas imagine agora que nas linhas tivessemos a CHAVE + BLOCK# + ROWID. Simplesmente ele entraria na parte superior da árvore (raiz), encontraria o ponteiro para o próximo nível da árvore (níveis intermediários), e assim sucessivamente até chegar ao primeiro bloco folha do índice. A partir deste ponto, bastaria ele percorrer horizontalmente a cadeia de blocos folha do índice e não mais passaria pelo mesmo bloco duas vezes pois, as informações estão ordenadas no índice. Aí alguém poderia falar: Poxa, mas colocar mais uma informação no bloco de índice, isto gastará muito disco, a árvore ficaria maior, etc. etc. etc. Lembro que antigamente, a cadeia de caracter de maior tamanho era de 255bytes; os computadore 386 nasceram com disco de 40MByte; memória grande era 4MByte, clock era 33MHz; o número de registros que um SGBD conseguia armazenar era muito menor que hoje etc. Se aumentaram a quantidade de disco, memória, tamanho do bloco lógico do SO, tamanho do arquivo físico do SO, tamanho do string, etc. etc. etc, por que não alteraram a arquitetura do bloco para ter concatenado a chave não só o rowid bem como o block#. Respostas possíveis: 1) O time está ganhando, não vamos alterar isto! 2) Vamos ter que alterar o kernel do SGBD, o custo disto é imenso! 3) Não havia pensado nisto! 4) O profissional que construiu esta parte do SGBD saiu da empresa e ninguém tem coragem de meter a mão; 5) Nunca ninguém pediu isto! 6) Etc. Concluíndo: Mr., tudo bem que eu tenho que me adaptar ao funcionamento do banco, inclusive acho isto correto pois, senão, quem sai perdendo sou eu mesmo. Mas cá pra nós, é muito básico. Chega a ser bizarro! Daí eu ficar desconfiando sempre do resultado quando trabalhava em modo CHOOSE. O plano escolhido, não bate inúmeras vezes com o que eu imaginava pois na minha cabeça a estrutura de dados utilizada era algo mais inteligente. Veja que tem uma mensagem a respeito de um índice do tipo BITMAP circulando no forum. Eu fiz um comentário ali. Gostaria de colocar a questão em debate, pois inúmeras vezes vi em um monte de visões, se não me engano na própria sys, instruções fazendo uma serie de operações usando BITAND, DECODE sobre um campo, ou seja, o kernel ainda continua no "tempo do onça" (nem sei o que é isto, tenho 48 anos e lembro que minha avó usava isto quando se referia a algo muito velho!). Estas instruções são usadas para se testar flags dentro de tabelas e/ou visões no dicionário, se não me engano. Lembro também que a MICO-SOFT re-escreveu seu kernerl, por que a Oracle NÃO? Não querendo ser rude, acho que eles só mudam a COR DA CASCA, mas o gosto é sempre de MAÇA (ou outra fruta qualquer). Fico por aqui, e agradeça a quem teve a paciência de aturar mais um e-mail e-n-o-r-m-e, mas é por causa do meu apelido (Fabão) Abraços, Fabão Fábio Martinho de Almeida Em 02/12/05, jlchiappa<[EMAIL PROTECTED]> escreveu: > Bom, antes de responder, só observo que conhecimento do tipo é ** bem > ** além do que se precisa pra administrar um banco - pra administrar > só se precisa entender que o bloco tem um header, um trailer, o > espaço no "meio" desses dois é o espaço útil, e esse espaço é > controlado pelo PCTFREE/PCTUSED, sabendo isso tá mais que bom pra > administrar... > Assim, imagino que o seu objetivo é enriquecimento de conhecimento, > com isso em mente a resposta : > > pra blocos de dados vc pode usar os textos : > > "A Close Look at Oracle8/8i Data Block Internals", de Dan Hotka > metalink Note:1061465.6 How To Determine The Block Header Size > metalink Note:10640.1 Extent and Block Space Calculation and Usage > in V7-V9 Databases > > > pra blocos de índices : > > "Geeky Internal Stuff: Block & Index Internals", de Dan Hotka > metalink Note:30405.1 How Btree Indexes Are Maintained > > ==> Para internals de índices, a dica principal, porém, é pesquisar > no site http://www.jlcomp.demon.co.uk/ , o autor tem uns textos ** > excelentes ** sobre formatos & estruturas de índices no bd Oracle. > > > Logicamente, itens internos do tipo ** mudam ** a cada versão, por > isso mesmo são absolutamente não-documentados, então pra vc confirmar > a informação na sua versão, e também pra estudar, vc ** VAI ** querer > fazer dumps dos seus blocos, no mesmo site acima indicado procurando > pela palavra-chave DUMP vc vai achar toda a informação necessária. > > ==> Os autores citados também escrevem frequentemente nos newsgroups > Oracle, é outra fonte de informação riquíssima. > > []s > > Chiappa > > > OBS : os papers acima citados eu peguei e li em sites especializados > em Oracle, mas como estou com acesso à internet restrito neste > momento, não pude fazer a pesquisa deles pra vc, mas até aí google é > seu amigo... > > > --- Em oracle_br@yahoogrupos.com.br, falmeida <[EMAIL PROTECTED]> escreveu > > Olá pessoal, > > > > Com objetivo de conhecer e estudar a implementação física da > estrutura > > de dados do Oracle, gostaria de saber se alguém tem, sabe onde tem > ou > > onde podemos encontrar uma documentação minuciosa da estrutura de > > blocos de dísco Oracle (preferencialmente 8i ou 9i). Seja de um > bloco > > de dados ou índice (dos mais variados tipos). Ou seja gostaria de > > saber como é o HEADER para cada tipo de bloco (DADOS, RAIZ, > > INTERMEDIÁRIO, FOLHA) e o conteúdo específico deles (como são > > armazenadas as informações bem como no caso dos índices os > ponteiros). > > > > Desde já agradeço, > > > > Fabão. > > -- > > Fábio Martinho de Almeida > > Niterói-RJ-Brasil > > > > > -------------------------------------------------------------------------------------------------------------------------- > 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 > > > > > > > > > -- Fábio Martinho de Almeida Niterói-RJ-Brasil -------------------------------------------------------------------------------------------------------------------------- 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
