Existe a possibilidade de o oracle server dar um "bypass" no buffer cache ?
o trecho abaixo eu retirei dos docs do curso de tunning do 9i: "EVALUATING THE CACHE HIT RATIO Do not continue increasing DB_BLOCK_BUFFERS if the last increase made on significant difference in the cache hit ratio.This may be because of the way that you area accessing your data, or there may be other operations that do not even use the buffer pool.For example, the Oracle Server bypass the buffer cache for sorting an parallel reads" --- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <[EMAIL PROTECTED]> escreveu > > Os "blocks em cache" vc quis dizer, né ? Sim , com certeza : > > "==> Na verdade o bd Oracle vai até um pouco mais além, não > importando > > > como foram lidos, não só blocos de dados, mas TAMBÉM blocos > > > temporários , de índices, de undo, etc, etc, etc, vão também pro > > > cache... > > > > " > > isso inclui Parallel Queries, sim... > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, "fabiobat2002" <[EMAIL PROTECTED]> > escreveu > > > > > > Obrigado novamente chiappa > > > > Agora as instrucoes FULL SCAN em paralelo tb jogam os caches em > buffer > > primeiro ou nao? > > > > > > > > > > --- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <[EMAIL PROTECTED]> > escreveu > > > > > > Claro que ficam sim, colega, é bico de mostrar : > > > > > > ==> primeiro tiro o que tiver no cache de blocos : > > > > > > [EMAIL PROTECTED]:SQL>alter tablespace orausers offline; > > > > > > Tablespace alterado. > > > > > > [EMAIL PROTECTED]:SQL>alter tablespace orausers online; > > > > > > Tablespace alterado. > > > > > > ==> agora vou fazer dois full-scans consecutivos : > > > > > > [EMAIL PROTECTED]:SQL>select * from big_table; > > > > > > 1225 linhas selecionadas. > > > > > > > > > Plano de Execução > > > ---------------------------------------------------------- > > > 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=4 Card=1225 > > > Bytes=101675) > > > 1 0 TABLE ACCESS (FULL) OF 'BIG_TABLE' (Cost=4 Card=1225 > > > Bytes=101675) > > > > > > > > > Estatística > > > ---------------------------------------------------------- > > > 275 recursive calls > > > 0 db block gets > > > 160 consistent gets > > > 38 physical reads > > > 72 redo size > > > 67114 bytes sent via SQL*Net to client > > > 843 bytes received via SQL*Net from client > > > 83 SQL*Net roundtrips to/from client > > > 0 sorts (memory) > > > 0 sorts (disk) > > > 1225 rows processed > > > > > > ==> veja acima que como não tinha NADA dessa tabela no cache, fiz > > > diversos I/Os físicos (não foi TUDO I/O físico, veja q obtive > alguns > > > consistent gets pois vários, X registros cabem dentro dum bloco > > > Oracle, aí ler esses X registros tive 1 I/O físico recuperando o > > > bloco mas depois daí foi só X-1 acessos lógicos ao bloco). Vou > fazer > > > de novo : > > > > > > [EMAIL PROTECTED]:SQL>select * from big_table; > > > > > > 1225 linhas selecionadas. > > > > > > > > > Plano de Execução > > > ---------------------------------------------------------- > > > 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=4 Card=1225 > > > Bytes=101675) > > > 1 0 TABLE ACCESS (FULL) OF 'BIG_TABLE' (Cost=4 Card=1225 > > > Bytes=101675) > > > > > > > > > Estatística > > > ---------------------------------------------------------- > > > 0 recursive calls > > > 0 db block gets > > > 120 consistent gets > > > 0 physical reads > > > 0 redo size > > > 67114 bytes sent via SQL*Net to client > > > 843 bytes received via SQL*Net from client > > > 83 SQL*Net roundtrips to/from client > > > 0 sorts (memory) > > > 0 sorts (disk) > > > 1225 rows processed > > > > > > ==> taí, diminuídos (na verdade neste caso de bd calmo e > tranquilo > > > ZERADOS) os I/Os físicos, portanto HOUVE SIM aproveitamento do > cache > > > de blocos , apesar de terem sido lidos lá na primeira vez por > > > multiblock, que é o que o full scan usa, se o param estiver > ativo : > > > > > > [EMAIL PROTECTED]:SQL>show parameters multiblock > > > > > > NAME TYPE VALUE > > > ------------------------------------ ----------- --------------- > > > db_file_multiblock_read_count integer 36 > > > [EMAIL PROTECTED]:SQL> > > > > > > ==> Na verdade o bd Oracle vai até um pouco mais além, não > improtando > > > como foram lidos, não só blocos de dados, mas TAMBÉM blocos > > > temporários , de índices, de undo, etc, etc, etc, vão também pro > > > cache... > > > > > > []s > > > > > > Chiappa > > > --- Em oracle_br@yahoogrupos.com.br, "fabiobat2002" > <[EMAIL PROTECTED]> > > > escreveu > > > > > > > > Eu sei que este parametro e responsavel pela leitura sequencial > no > > > > disco qdo uma instrucao com FULL SCAN e solicitada. > > > > Minha duvida e a seguinte, estes blocos sao colocados no > > > cache_buffer > > > > ou nao ? > > > > > > > > Obrigado > > > > > > > > > > -------------------------------------------------------------------------------------------------------------------------- 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/ --------------------------------------------------------------------------------------------------------------------------__________________________________________________________________ Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine __________________________________________________________________ O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o link do mesmo para evitar trafego(pedidos) desnecessário. 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
