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
