[oracle_br] Re: Valor máximo do MULTIBLOCK_READ
O impacto, se houver, vai ser localizado(ie, ALGUMAS queries em CBO
podem dar preferência maior pra scans), e em sendo banco 9i é tão
fácil mudar o parãmetro online se o problema ocorrer (via ALTER
SYSTEM), que sem duvida eu diria já ir pro maior valor, e só se vc
notar probs baixar. Lógico, vc NÃO vai fazer isso exatamente no dia
do fechamento, vai agendar isso pruma hora mais tranquila, pra poder
testar os SQLs antes, mas é isso, ok ?
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, "Sebastião Carlos Santos"
<[EMAIL PROTECTED]> escreveu
>
> Ok, vou estar providenciando contato com o pessoal do suporte,
entretanto,
> qual seria o valor que eu deveria colocar no
db_file_multiblock_read_count?
> 64 ou 128? Seria mais prudente por hora definir este parâmetro como
> 64 avaliar o impacto ou não e depois quem sabe subir para 128?
>
> Obrigado.
>
> Em 18/04/06, jlchiappa <[EMAIL PROTECTED]> escreveu:
>
> > Sim, pelo lado do banco eu recomendaria vc subir o valor do
param, **
> > MAS ** já que vc usa aplicação de terceiros, como sempre, antes de
> > qquer alteração, PEDIR PERMISSÃO pro Suporte deles, se eles
falarem
> > que não tem problema, então blz.
> >
> > []s
> >
> > Chiappa
> >
> > --- Em oracle_br@yahoogrupos.com.br, "Sebastião Carlos Santos"
> > <[EMAIL PROTECTED]> escreveu
> > >
> > > *
> > >
> > > SQL> select name, value from v$parameter where name in
> > > ('db_block_size','db_file_multiblock_read_count');
> > > NAME
> > VALUE
> > >
> > >
> >
> > > db_block_size
> > 8192
> > > db_file_multiblock_read_count 16
> > >
> > > Após executar os testes descritos no seu e-mail anterior obtive
os
> > seguintes
> > > valores:
> > >
> > > grep -i 'db file' psfin8_ora_355252.trc
> > > WAIT #1: nam='db file sequential read' ela= 5336 p1=1 p2=313
p3=1
> > > WAIT #3: nam='db file sequential read' ela= 8529 p1=1 p2=4918
p3=1
> > > WAIT #3: nam='db file sequential read' ela= 2516 p1=1 p2=54326
p3=1
> > > WAIT #3: nam='db file sequential read' ela= 6682 p1=1 p2=4972
p3=1
> > > WAIT #3: nam='db file sequential read' ela= 12328 p1=1 p2=4295
p3=1
> > > WAIT #3: nam='db file sequential read' ela= 9131 p1=1 p2=4317
p3=1
> > > WAIT #3: nam='db file sequential read' ela= 5739 p1=1 p2=1605
p3=1
> > > WAIT #3: nam='db file sequential read' ela= 7856 p1=1 p2=104635
p3=1
> > > WAIT #4: nam='db file sequential read' ela= 2527 p1=1 p2=104864
p3=1
> > > WAIT #4: nam='db file sequential read' ela= 18867 p1=1 p2=121433
> > p3=1
> > > WAIT #7: nam='db file sequential read' ela= 11802 p1=1 p2=82723
p3=1
> > > WAIT #8: nam='db file sequential read' ela= 6497 p1=1 p2=84778
p3=1
> > > WAIT #2: nam='db file scattered read' ela= 34147 p1=68 p2=10
p3=128
> > > WAIT #2: nam='db file scattered read' ela= 26809 p1=68 p2=138
p3=128
> > > WAIT #2: nam='db file scattered read' ela= 26647 p1=68 p2=266
p3=128
> > > WAIT #2: nam='db file scattered read' ela= 137280 p1=68 p2=394
> > p3=128*
> > > Banco -> Oracle9i Enterprise Edition Release 9.2.0.7.0 - 64bit
> > Production
> > > S.O -> AIX 5.2
> > > Base Produção People Soft
> > >
> > > Seria interessante aumentar o valor de
> > db_file_multiblock_read_count para 64
> > > ou até 128.
> > >
> > > Obrigado.
> > >
> > >
> > > [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/
> >
> > --
__
> >
> > 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
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> [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/
--__
Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.b
Re: [oracle_br] Re: Valor máximo do MULTIBLOCK_READ
Ok, vou estar providenciando contato com o pessoal do suporte, entretanto,
qual seria o valor que eu deveria colocar no db_file_multiblock_read_count?
64 ou 128? Seria mais prudente por hora definir este parâmetro como
64 avaliar o impacto ou não e depois quem sabe subir para 128?
Obrigado.
Em 18/04/06, jlchiappa <[EMAIL PROTECTED]> escreveu:
> Sim, pelo lado do banco eu recomendaria vc subir o valor do param, **
> MAS ** já que vc usa aplicação de terceiros, como sempre, antes de
> qquer alteração, PEDIR PERMISSÃO pro Suporte deles, se eles falarem
> que não tem problema, então blz.
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br, "Sebastião Carlos Santos"
> <[EMAIL PROTECTED]> escreveu
> >
> > *
> >
> > SQL> select name, value from v$parameter where name in
> > ('db_block_size','db_file_multiblock_read_count');
> > NAME
> VALUE
> >
> >
>
> > db_block_size
> 8192
> > db_file_multiblock_read_count 16
> >
> > Após executar os testes descritos no seu e-mail anterior obtive os
> seguintes
> > valores:
> >
> > grep -i 'db file' psfin8_ora_355252.trc
> > WAIT #1: nam='db file sequential read' ela= 5336 p1=1 p2=313 p3=1
> > WAIT #3: nam='db file sequential read' ela= 8529 p1=1 p2=4918 p3=1
> > WAIT #3: nam='db file sequential read' ela= 2516 p1=1 p2=54326 p3=1
> > WAIT #3: nam='db file sequential read' ela= 6682 p1=1 p2=4972 p3=1
> > WAIT #3: nam='db file sequential read' ela= 12328 p1=1 p2=4295 p3=1
> > WAIT #3: nam='db file sequential read' ela= 9131 p1=1 p2=4317 p3=1
> > WAIT #3: nam='db file sequential read' ela= 5739 p1=1 p2=1605 p3=1
> > WAIT #3: nam='db file sequential read' ela= 7856 p1=1 p2=104635 p3=1
> > WAIT #4: nam='db file sequential read' ela= 2527 p1=1 p2=104864 p3=1
> > WAIT #4: nam='db file sequential read' ela= 18867 p1=1 p2=121433
> p3=1
> > WAIT #7: nam='db file sequential read' ela= 11802 p1=1 p2=82723 p3=1
> > WAIT #8: nam='db file sequential read' ela= 6497 p1=1 p2=84778 p3=1
> > WAIT #2: nam='db file scattered read' ela= 34147 p1=68 p2=10 p3=128
> > WAIT #2: nam='db file scattered read' ela= 26809 p1=68 p2=138 p3=128
> > WAIT #2: nam='db file scattered read' ela= 26647 p1=68 p2=266 p3=128
> > WAIT #2: nam='db file scattered read' ela= 137280 p1=68 p2=394
> p3=128*
> > Banco -> Oracle9i Enterprise Edition Release 9.2.0.7.0 - 64bit
> Production
> > S.O -> AIX 5.2
> > Base Produção People Soft
> >
> > Seria interessante aumentar o valor de
> db_file_multiblock_read_count para 64
> > ou até 128.
> >
> > Obrigado.
> >
> >
> > [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/
>
> --__
>
> 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
>
>
>
>
>
>
>
>
[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/
--__
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
[oracle_br] Re: Valor máximo do MULTIBLOCK_READ
Sim, pelo lado do banco eu recomendaria vc subir o valor do param, **
MAS ** já que vc usa aplicação de terceiros, como sempre, antes de
qquer alteração, PEDIR PERMISSÃO pro Suporte deles, se eles falarem
que não tem problema, então blz.
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, "Sebastião Carlos Santos"
<[EMAIL PROTECTED]> escreveu
>
> *
>
> SQL> select name, value from v$parameter where name in
> ('db_block_size','db_file_multiblock_read_count');
> NAME
VALUE
>
>
> db_block_size
8192
> db_file_multiblock_read_count 16
>
> Após executar os testes descritos no seu e-mail anterior obtive os
seguintes
> valores:
>
> grep -i 'db file' psfin8_ora_355252.trc
> WAIT #1: nam='db file sequential read' ela= 5336 p1=1 p2=313 p3=1
> WAIT #3: nam='db file sequential read' ela= 8529 p1=1 p2=4918 p3=1
> WAIT #3: nam='db file sequential read' ela= 2516 p1=1 p2=54326 p3=1
> WAIT #3: nam='db file sequential read' ela= 6682 p1=1 p2=4972 p3=1
> WAIT #3: nam='db file sequential read' ela= 12328 p1=1 p2=4295 p3=1
> WAIT #3: nam='db file sequential read' ela= 9131 p1=1 p2=4317 p3=1
> WAIT #3: nam='db file sequential read' ela= 5739 p1=1 p2=1605 p3=1
> WAIT #3: nam='db file sequential read' ela= 7856 p1=1 p2=104635 p3=1
> WAIT #4: nam='db file sequential read' ela= 2527 p1=1 p2=104864 p3=1
> WAIT #4: nam='db file sequential read' ela= 18867 p1=1 p2=121433
p3=1
> WAIT #7: nam='db file sequential read' ela= 11802 p1=1 p2=82723 p3=1
> WAIT #8: nam='db file sequential read' ela= 6497 p1=1 p2=84778 p3=1
> WAIT #2: nam='db file scattered read' ela= 34147 p1=68 p2=10 p3=128
> WAIT #2: nam='db file scattered read' ela= 26809 p1=68 p2=138 p3=128
> WAIT #2: nam='db file scattered read' ela= 26647 p1=68 p2=266 p3=128
> WAIT #2: nam='db file scattered read' ela= 137280 p1=68 p2=394
p3=128*
> Banco -> Oracle9i Enterprise Edition Release 9.2.0.7.0 - 64bit
Production
> S.O -> AIX 5.2
> Base Produção People Soft
>
> Seria interessante aumentar o valor de
db_file_multiblock_read_count para 64
> ou até 128.
>
> Obrigado.
>
>
> [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/
--__
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
Re: [oracle_br] Re: Valor máximo do MULTIBLOCK_READ
*
SQL> select name, value from v$parameter where name in
('db_block_size','db_file_multiblock_read_count');
NAME VALUE
db_block_size8192
db_file_multiblock_read_count 16
Após executar os testes descritos no seu e-mail anterior obtive os seguintes
valores:
grep -i 'db file' psfin8_ora_355252.trc
WAIT #1: nam='db file sequential read' ela= 5336 p1=1 p2=313 p3=1
WAIT #3: nam='db file sequential read' ela= 8529 p1=1 p2=4918 p3=1
WAIT #3: nam='db file sequential read' ela= 2516 p1=1 p2=54326 p3=1
WAIT #3: nam='db file sequential read' ela= 6682 p1=1 p2=4972 p3=1
WAIT #3: nam='db file sequential read' ela= 12328 p1=1 p2=4295 p3=1
WAIT #3: nam='db file sequential read' ela= 9131 p1=1 p2=4317 p3=1
WAIT #3: nam='db file sequential read' ela= 5739 p1=1 p2=1605 p3=1
WAIT #3: nam='db file sequential read' ela= 7856 p1=1 p2=104635 p3=1
WAIT #4: nam='db file sequential read' ela= 2527 p1=1 p2=104864 p3=1
WAIT #4: nam='db file sequential read' ela= 18867 p1=1 p2=121433 p3=1
WAIT #7: nam='db file sequential read' ela= 11802 p1=1 p2=82723 p3=1
WAIT #8: nam='db file sequential read' ela= 6497 p1=1 p2=84778 p3=1
WAIT #2: nam='db file scattered read' ela= 34147 p1=68 p2=10 p3=128
WAIT #2: nam='db file scattered read' ela= 26809 p1=68 p2=138 p3=128
WAIT #2: nam='db file scattered read' ela= 26647 p1=68 p2=266 p3=128
WAIT #2: nam='db file scattered read' ela= 137280 p1=68 p2=394 p3=128*
Banco -> Oracle9i Enterprise Edition Release 9.2.0.7.0 - 64bit Production
S.O -> AIX 5.2
Base Produção People Soft
Seria interessante aumentar o valor de db_file_multiblock_read_count para 64
ou até 128.
Obrigado.
[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/
--__
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
[oracle_br] Re: Valor máximo do MULTIBLOCK_READ
Sim, ele fala do MAXPHYS como eu fiz na msg, lembra que SE vc timer timed_statistics ativada vc vai ter uma medida do TEMPO gasto pro I/O (em cima disso é outra verificação do hardware e SO), e lembra a questão do tamanho dos extents, que influi DIRETAMENTE na performance de scans, como eu tinha dito na minha apresentação de 2004 da ENPO - quando chegar em casa eu posto ela no yousendit pra ficar disponível pra quem se interessar, e aviso o grupo. []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Anderson Haertel Rodrigues <[EMAIL PROTECTED]> escreveu > > Vou "appendar" este link que certa vez me tirou > algumas dúvidas em relação ao parâmetro citado: > > http://asktom.oracle.com/pls/ask/f? p=4950:8:12175793637147510511::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERI A:10015427038722 > > Anderson Haertel Rodrigues > Administrador de Banco de Dados - DBA > Florianópolis/SC > > --- jlchiappa <[EMAIL PROTECTED]> escreveu: > > > Marcelo, esse p3 ** não é ** nem em bytes nem em > > kbytes , é em > > BLOCOS, é a qtdade máxima de BLOCOS que o bd pôde > > ler no seu hardware > > e SO (36 BLOCOS no meu caso, que já q meu banco usa > > blocos de 8 Kb > > representam 36 x 8Kb = 256 Kb de I/O máximo), e o > > parâmetro de > > multiread é em BLOCOS também, então a recomendação é > > uma vez > > descoberta a quantidade máxima de blocos vc sete o > > parâmetro pra essa > > qtdade e, SE o CBo passar a optar por full table > > scan em demasia, > > ajuste isso com os params optimizer_nn, normalmente > > resolve, é isso. > > Notar , como eu disse em outra msg, que num SO > > moderno e hardware > > moderno, normalmente o limite é próximo de 1 Mb de > > I/O máximo, mas > > devido à restrições de filesystem e quetais, um > > pouco menos (digamos > > 1/3 ou 1/4 desse 1 Mb) é aceitável, SE nos seus > > testes vc só > > conseguir muito menos que isso, coloque em suspeita > > a config de > > kernel, de SO, de hardware, algo não vai bem. > > > > []s > > > > Chiappa > > > > --- Em oracle_br@yahoogrupos.com.br, "Marcelo > > Cauduro" > > <[EMAIL PROTECTED]> escreveu > > > > > > Nesse caso > > > WAIT #3: nam='db file scattered read' ela= 27789 > > p1=24 p2=10 p3=36 > > > Qual seria então o valor ideal ja que o I/o maximo > > é 36kb ? > > > > > > > > > On 4/18/06, jlchiappa <[EMAIL PROTECTED]> wrote: > > > > > > > > Desconheço bugs pra isso, dá uma checada no > > metalink pra sua > > versão > > > > mas acho que não vai ter não, é uma > > funcionalidade bem antiga do > > db. > > > > O impacto que vc poderá ter é que o CBO vai > > "pensar" que o full > > table > > > > scan ficou "mais barato", pode ser que em algum > > SQL ele passe a > > dar > > > > preferência pra full table scan, mas isso vc > > corrige com os > > params de > > > > optimizer_nn, principalmente o > > optimizer_index_cost_adj (fazendo o > > > > índice ficar "mais barato" vc deverá ver muito > > menos table scans), > > > > teste aí seus princiopais SQLs antes de mudar em > > produção > > > > > > > > > > > > []s > > > > > > > > Chiappa > > > > --- Em oracle_br@yahoogrupos.com.br, Thiago > > Lazzarotto > > > > <[EMAIL PROTECTED]> escreveu > > > > > > > > > > Fiz o teste aqui e o valor máximo que obtive > > foi 128 mesmo > > > > colocando o > > > > > parametro para 512 por exemplo... > > > > > > > > > > Acho que vou ter um grande ganho já que hj o > > meu valor é 8. > > > > > > > > > > Existe algum problema em aumentar esse valor? > > > > > Pode haver algum outro tipo de impacto > > negativo na performance? > > > > > Algum bug conhecido? > > > > > > > > > > Obrigado. > > > > > > > > > > jlchiappa escreveu: > > > > > > > > > > > Thiago, não achei a msg que enviei > > originalmente, mas talvez > > tenha > > > > > > havido erro/omissão de minha parte, segue > > exemplo completo > > > > (chiappa é > > > > > > o usuário dba, e scott é o usuário "comum") > > : > > > > > > > > > > > > [EMAIL PROTECTED]:SQL>create tablespace TS_EXT_10 > > > > > > datafile > > '/u2/oradata/COBPROD/data01/ts_ext_10_01.dbf' size > > 100M > > > > > > 2 extent management local uniform size > > 10m nologging; > > > > > > > > > > > > Tablespace criado. > > > > > > > > > > > > [EMAIL PROTECTED]:SQL>alter user scott quota > > unlimited on TS_EXT_10; > > > > > > > > > > > > Usuário alterado. > > > > > > > > > > > > scott:SQL>create table TAB_TESTE tablespace > > TS_EXT_10 as > > (select * > > > > > > from all_objects); > > > > > > > > > > > > Tabela criada. > > > > > > > > > > > > scott:SQL>BEGIN > > > > > > 2 for i in 1..200 loop > > > > > > 3 insert into TAB_TESTE (select * > > from all_objects); > > > > > > 4 commit; > > > > > > 5 end loop; > > > > > > 6* END; > > > > > > / > > > > > > scott:SQL> commit; > > > > > > > > > > > > scott:SQL> alter session set > > db_file_multiblock_read_count=128; > > > > > > > > > > > > Sessão alterada. > > > > > > > > > > > > [EMAIL PROTECTED]:SQL>select sid, serial# from > > v$session where > > > > >
[oracle_br] Re: Valor máximo do MULTIBLOCK_READ
Marcelo, esse p3 ** não é ** nem em bytes nem em kbytes , é em BLOCOS, é a qtdade máxima de BLOCOS que o bd pôde ler no seu hardware e SO (36 BLOCOS no meu caso, que já q meu banco usa blocos de 8 Kb representam 36 x 8Kb = 256 Kb de I/O máximo), e o parâmetro de multiread é em BLOCOS também, então a recomendação é uma vez descoberta a quantidade máxima de blocos vc sete o parâmetro pra essa qtdade e, SE o CBo passar a optar por full table scan em demasia, ajuste isso com os params optimizer_nn, normalmente resolve, é isso. Notar , como eu disse em outra msg, que num SO moderno e hardware moderno, normalmente o limite é próximo de 1 Mb de I/O máximo, mas devido à restrições de filesystem e quetais, um pouco menos (digamos 1/3 ou 1/4 desse 1 Mb) é aceitável, SE nos seus testes vc só conseguir muito menos que isso, coloque em suspeita a config de kernel, de SO, de hardware, algo não vai bem. []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "Marcelo Cauduro" <[EMAIL PROTECTED]> escreveu > > Nesse caso > WAIT #3: nam='db file scattered read' ela= 27789 p1=24 p2=10 p3=36 > Qual seria então o valor ideal ja que o I/o maximo é 36kb ? > > > On 4/18/06, jlchiappa <[EMAIL PROTECTED]> wrote: > > > > Desconheço bugs pra isso, dá uma checada no metalink pra sua versão > > mas acho que não vai ter não, é uma funcionalidade bem antiga do db. > > O impacto que vc poderá ter é que o CBO vai "pensar" que o full table > > scan ficou "mais barato", pode ser que em algum SQL ele passe a dar > > preferência pra full table scan, mas isso vc corrige com os params de > > optimizer_nn, principalmente o optimizer_index_cost_adj (fazendo o > > índice ficar "mais barato" vc deverá ver muito menos table scans), > > teste aí seus princiopais SQLs antes de mudar em produção > > > > > > []s > > > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, Thiago Lazzarotto > > <[EMAIL PROTECTED]> escreveu > > > > > > Fiz o teste aqui e o valor máximo que obtive foi 128 mesmo > > colocando o > > > parametro para 512 por exemplo... > > > > > > Acho que vou ter um grande ganho já que hj o meu valor é 8. > > > > > > Existe algum problema em aumentar esse valor? > > > Pode haver algum outro tipo de impacto negativo na performance? > > > Algum bug conhecido? > > > > > > Obrigado. > > > > > > jlchiappa escreveu: > > > > > > > Thiago, não achei a msg que enviei originalmente, mas talvez tenha > > > > havido erro/omissão de minha parte, segue exemplo completo > > (chiappa é > > > > o usuário dba, e scott é o usuário "comum") : > > > > > > > > [EMAIL PROTECTED]:SQL>create tablespace TS_EXT_10 > > > > datafile '/u2/oradata/COBPROD/data01/ts_ext_10_01.dbf' size 100M > > > > 2 extent management local uniform size 10m nologging; > > > > > > > > Tablespace criado. > > > > > > > > [EMAIL PROTECTED]:SQL>alter user scott quota unlimited on TS_EXT_10; > > > > > > > > Usuário alterado. > > > > > > > > scott:SQL>create table TAB_TESTE tablespace TS_EXT_10 as (select * > > > > from all_objects); > > > > > > > > Tabela criada. > > > > > > > > scott:SQL>BEGIN > > > > 2 for i in 1..200 loop > > > > 3 insert into TAB_TESTE (select * from all_objects); > > > > 4 commit; > > > > 5 end loop; > > > > 6* END; > > > > / > > > > scott:SQL> commit; > > > > > > > > scott:SQL> alter session set db_file_multiblock_read_count=128; > > > > > > > > Sessão alterada. > > > > > > > > [EMAIL PROTECTED]:SQL>select sid, serial# from v$session where > > > > username='SCOTT'; > > > > > > > > SID SERIAL# > > > > --- > > > > 625266 > > > > > > > > 1 linha selecionada. > > > > > > > > [EMAIL PROTECTED]:SQL>exec sys.dbms_system.set_ev(62, 5266, 10046, > > 12, ''); > > > > > > > > Procedimento PL/SQL concluído com sucesso. > > > > > > > > scott:SQL> select /*+ FULL */ * FROM TAB_TESTE; > > > > > > > > scott:SQL> exit > > > > > > > > olhar dentro do arquivo .trc gerado : > > > > > > > > sid=PRD:/u1/app/oracle/admin/PRD/udump>grep -i 'db file' > > > > prd_ora_26020.trc > > > > > > > > WAIT #3: nam='db file scattered read' ela= 27789 p1=24 p2=10 p3=36 > > > > > > > > Note que o evento de table scan se chama 'db file scattered > > read', e > > > > não 'sequential', como está na msg. Caso vc não saia de 8 blocos > > no > > > > multiblock read reproduzindo o exemplo acima, duas possibilidades > > aí : > > > > > > > > a) na maioria dos unix há um parâmetro (MAXPHYS ou similar) que > > > > controla o tamanho máximo de I/O, talvez erradamente ele deve > > estar > > > > como 64 Kb (que corresponde a 8 blocos de 8Kb) - digo erradamente > > > > porque na MAIORIA esmagadora dos hardwares modernos se consegue > > mais > > > > q isso... > > > > > > > > b) o seu volume de disco tem stripping de 64 Kb : quando vc cria > > um > > > > volume (principalmente num array de discos) vc entre outras coisas > > > > informa o stripping , ie, qual o mínimo de I/O que será feito em > > cada > > > > acesso, se foi informado 64 Kb, é is
Re: [oracle_br] Re: Valor máximo do MULTIBLOCK_READ
Nesse caso WAIT #3: nam='db file scattered read' ela= 27789 p1=24 p2=10 p3=36 Qual seria então o valor ideal ja que o I/o maximo é 36kb ? On 4/18/06, jlchiappa <[EMAIL PROTECTED]> wrote: > > Desconheço bugs pra isso, dá uma checada no metalink pra sua versão > mas acho que não vai ter não, é uma funcionalidade bem antiga do db. > O impacto que vc poderá ter é que o CBO vai "pensar" que o full table > scan ficou "mais barato", pode ser que em algum SQL ele passe a dar > preferência pra full table scan, mas isso vc corrige com os params de > optimizer_nn, principalmente o optimizer_index_cost_adj (fazendo o > índice ficar "mais barato" vc deverá ver muito menos table scans), > teste aí seus princiopais SQLs antes de mudar em produção > > > []s > > Chiappa > --- Em oracle_br@yahoogrupos.com.br, Thiago Lazzarotto > <[EMAIL PROTECTED]> escreveu > > > > Fiz o teste aqui e o valor máximo que obtive foi 128 mesmo > colocando o > > parametro para 512 por exemplo... > > > > Acho que vou ter um grande ganho já que hj o meu valor é 8. > > > > Existe algum problema em aumentar esse valor? > > Pode haver algum outro tipo de impacto negativo na performance? > > Algum bug conhecido? > > > > Obrigado. > > > > jlchiappa escreveu: > > > > > Thiago, não achei a msg que enviei originalmente, mas talvez tenha > > > havido erro/omissão de minha parte, segue exemplo completo > (chiappa é > > > o usuário dba, e scott é o usuário "comum") : > > > > > > [EMAIL PROTECTED]:SQL>create tablespace TS_EXT_10 > > > datafile '/u2/oradata/COBPROD/data01/ts_ext_10_01.dbf' size 100M > > > 2 extent management local uniform size 10m nologging; > > > > > > Tablespace criado. > > > > > > [EMAIL PROTECTED]:SQL>alter user scott quota unlimited on TS_EXT_10; > > > > > > Usuário alterado. > > > > > > scott:SQL>create table TAB_TESTE tablespace TS_EXT_10 as (select * > > > from all_objects); > > > > > > Tabela criada. > > > > > > scott:SQL>BEGIN > > > 2 for i in 1..200 loop > > > 3 insert into TAB_TESTE (select * from all_objects); > > > 4 commit; > > > 5 end loop; > > > 6* END; > > > / > > > scott:SQL> commit; > > > > > > scott:SQL> alter session set db_file_multiblock_read_count=128; > > > > > > Sessão alterada. > > > > > > [EMAIL PROTECTED]:SQL>select sid, serial# from v$session where > > > username='SCOTT'; > > > > > > SID SERIAL# > > > --- > > > 625266 > > > > > > 1 linha selecionada. > > > > > > [EMAIL PROTECTED]:SQL>exec sys.dbms_system.set_ev(62, 5266, 10046, > 12, ''); > > > > > > Procedimento PL/SQL concluído com sucesso. > > > > > > scott:SQL> select /*+ FULL */ * FROM TAB_TESTE; > > > > > > scott:SQL> exit > > > > > > olhar dentro do arquivo .trc gerado : > > > > > > sid=PRD:/u1/app/oracle/admin/PRD/udump>grep -i 'db file' > > > prd_ora_26020.trc > > > > > > WAIT #3: nam='db file scattered read' ela= 27789 p1=24 p2=10 p3=36 > > > > > > Note que o evento de table scan se chama 'db file scattered > read', e > > > não 'sequential', como está na msg. Caso vc não saia de 8 blocos > no > > > multiblock read reproduzindo o exemplo acima, duas possibilidades > aí : > > > > > > a) na maioria dos unix há um parâmetro (MAXPHYS ou similar) que > > > controla o tamanho máximo de I/O, talvez erradamente ele deve > estar > > > como 64 Kb (que corresponde a 8 blocos de 8Kb) - digo erradamente > > > porque na MAIORIA esmagadora dos hardwares modernos se consegue > mais > > > q isso... > > > > > > b) o seu volume de disco tem stripping de 64 Kb : quando vc cria > um > > > volume (principalmente num array de discos) vc entre outras coisas > > > informa o stripping , ie, qual o mínimo de I/O que será feito em > cada > > > acesso, se foi informado 64 Kb, é isso que vc obterá > > > > > > []s > > > > > > Chiappa > > > > > > --- Em oracle_br@yahoogrupos.com.br, Thiago Lazzarotto > > > <[EMAIL PROTECTED]> escreveu > > > > > > > > Senhores... > > > > > > > > Eu tenho definido no meu banco o db_file_multiblock_read_count > = 8. > > > > > > > > Eu fiz o teste que o chiappa passou para ver qual o valor máximo > > > para > > > > ser definido no meu parâmetro... > > > > Acontece que o valor é sempre 8. > > > > Daí surgiu a minha dúvida: esse é o valor máximo que o > SO/Hardware > > > > suporta ou ele está usando esse valor ao máximo por causa do > > > parâmetro > > > > já setado? > > > > Meu banco é 8.1.7.4 HPUX 11.11 > > > > > > > > Segue o teste do chiappa. > > > > > > > > "Existem outras maneiras, mas como normalmente isso é uma > quantidade > > > > de blocos que totaliza 1Mb, ou coisa do tipo, pra vc saber é > testar, > > > > vc cria uma tablespace LMT uniform size de 10Mb, cria nela uma > > > tabela > > > > qquer com PCTFREE 1 PCTUSED 99 e com várias centenas de > milhares de > > > > linhas, e faz um trace 10046 level 12 de uma sessão fazendo > > > > SELECT /*+ FULL */ * from nomedatabela, isso resulta num > > > > arquivo .TRC que entre muitas outras vai ter linhas do tipo : > > > > > > > > WAIT #3: nam=
[oracle_br] Re: Valor máximo do MULTIBLOCK_READ
Desconheço bugs pra isso, dá uma checada no metalink pra sua versão mas acho que não vai ter não, é uma funcionalidade bem antiga do db. O impacto que vc poderá ter é que o CBO vai "pensar" que o full table scan ficou "mais barato", pode ser que em algum SQL ele passe a dar preferência pra full table scan, mas isso vc corrige com os params de optimizer_nn, principalmente o optimizer_index_cost_adj (fazendo o índice ficar "mais barato" vc deverá ver muito menos table scans), teste aí seus princiopais SQLs antes de mudar em produção []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Thiago Lazzarotto <[EMAIL PROTECTED]> escreveu > > Fiz o teste aqui e o valor máximo que obtive foi 128 mesmo colocando o > parametro para 512 por exemplo... > > Acho que vou ter um grande ganho já que hj o meu valor é 8. > > Existe algum problema em aumentar esse valor? > Pode haver algum outro tipo de impacto negativo na performance? > Algum bug conhecido? > > Obrigado. > > jlchiappa escreveu: > > > Thiago, não achei a msg que enviei originalmente, mas talvez tenha > > havido erro/omissão de minha parte, segue exemplo completo (chiappa é > > o usuário dba, e scott é o usuário "comum") : > > > > [EMAIL PROTECTED]:SQL>create tablespace TS_EXT_10 > > datafile '/u2/oradata/COBPROD/data01/ts_ext_10_01.dbf' size 100M > > 2 extent management local uniform size 10m nologging; > > > > Tablespace criado. > > > > [EMAIL PROTECTED]:SQL>alter user scott quota unlimited on TS_EXT_10; > > > > Usuário alterado. > > > > scott:SQL>create table TAB_TESTE tablespace TS_EXT_10 as (select * > > from all_objects); > > > > Tabela criada. > > > > scott:SQL>BEGIN > > 2 for i in 1..200 loop > > 3 insert into TAB_TESTE (select * from all_objects); > > 4 commit; > > 5 end loop; > > 6* END; > > / > > scott:SQL> commit; > > > > scott:SQL> alter session set db_file_multiblock_read_count=128; > > > > Sessão alterada. > > > > [EMAIL PROTECTED]:SQL>select sid, serial# from v$session where > > username='SCOTT'; > > > > SID SERIAL# > > --- > > 625266 > > > > 1 linha selecionada. > > > > [EMAIL PROTECTED]:SQL>exec sys.dbms_system.set_ev(62, 5266, 10046, 12, ''); > > > > Procedimento PL/SQL concluído com sucesso. > > > > scott:SQL> select /*+ FULL */ * FROM TAB_TESTE; > > > > scott:SQL> exit > > > > olhar dentro do arquivo .trc gerado : > > > > sid=PRD:/u1/app/oracle/admin/PRD/udump>grep -i 'db file' > > prd_ora_26020.trc > > > > WAIT #3: nam='db file scattered read' ela= 27789 p1=24 p2=10 p3=36 > > > > Note que o evento de table scan se chama 'db file scattered read', e > > não 'sequential', como está na msg. Caso vc não saia de 8 blocos no > > multiblock read reproduzindo o exemplo acima, duas possibilidades aí : > > > > a) na maioria dos unix há um parâmetro (MAXPHYS ou similar) que > > controla o tamanho máximo de I/O, talvez erradamente ele deve estar > > como 64 Kb (que corresponde a 8 blocos de 8Kb) - digo erradamente > > porque na MAIORIA esmagadora dos hardwares modernos se consegue mais > > q isso... > > > > b) o seu volume de disco tem stripping de 64 Kb : quando vc cria um > > volume (principalmente num array de discos) vc entre outras coisas > > informa o stripping , ie, qual o mínimo de I/O que será feito em cada > > acesso, se foi informado 64 Kb, é isso que vc obterá > > > > []s > > > > Chiappa > > > > --- Em oracle_br@yahoogrupos.com.br, Thiago Lazzarotto > > <[EMAIL PROTECTED]> escreveu > > > > > > Senhores... > > > > > > Eu tenho definido no meu banco o db_file_multiblock_read_count = 8. > > > > > > Eu fiz o teste que o chiappa passou para ver qual o valor máximo > > para > > > ser definido no meu parâmetro... > > > Acontece que o valor é sempre 8. > > > Daí surgiu a minha dúvida: esse é o valor máximo que o SO/Hardware > > > suporta ou ele está usando esse valor ao máximo por causa do > > parâmetro > > > já setado? > > > Meu banco é 8.1.7.4 HPUX 11.11 > > > > > > Segue o teste do chiappa. > > > > > > "Existem outras maneiras, mas como normalmente isso é uma quantidade > > > de blocos que totaliza 1Mb, ou coisa do tipo, pra vc saber é testar, > > > vc cria uma tablespace LMT uniform size de 10Mb, cria nela uma > > tabela > > > qquer com PCTFREE 1 PCTUSED 99 e com várias centenas de milhares de > > > linhas, e faz um trace 10046 level 12 de uma sessão fazendo > > > SELECT /*+ FULL */ * from nomedatabela, isso resulta num > > > arquivo .TRC que entre muitas outras vai ter linhas do tipo : > > > > > > WAIT #3: nam='db file scattered read' ela= 249287 p1=41 p2=4234 > > p3=nnn > > > > > > nnn é a quantidade de blocos que ele pôde ler duma vez, > > > db_file_multiblock_read_count deve ter o maior dos nnn que vc achar > > > no arquivo." > > > > > > Obrigado. > > > Thiago. > > > > > > > > > > > > > > > > > > > -- > > Atenção! As mensagens deste
[oracle_br] Re: Valor máximo do MULTIBLOCK_READ
Thiago, não achei a msg que enviei originalmente, mas talvez tenha havido erro/omissão de minha parte, segue exemplo completo (chiappa é o usuário dba, e scott é o usuário "comum") : [EMAIL PROTECTED]:SQL>create tablespace TS_EXT_10 datafile '/u2/oradata/COBPROD/data01/ts_ext_10_01.dbf' size 100M 2 extent management local uniform size 10m nologging; Tablespace criado. [EMAIL PROTECTED]:SQL>alter user scott quota unlimited on TS_EXT_10; Usuário alterado. scott:SQL>create table TAB_TESTE tablespace TS_EXT_10 as (select * from all_objects); Tabela criada. scott:SQL>BEGIN 2 for i in 1..200 loop 3 insert into TAB_TESTE (select * from all_objects); 4 commit; 5 end loop; 6* END; / scott:SQL> commit; scott:SQL> alter session set db_file_multiblock_read_count=128; Sessão alterada. [EMAIL PROTECTED]:SQL>select sid, serial# from v$session where username='SCOTT'; SID SERIAL# --- 625266 1 linha selecionada. [EMAIL PROTECTED]:SQL>exec sys.dbms_system.set_ev(62, 5266, 10046, 12, ''); Procedimento PL/SQL concluído com sucesso. scott:SQL> select /*+ FULL */ * FROM TAB_TESTE; scott:SQL> exit olhar dentro do arquivo .trc gerado : sid=PRD:/u1/app/oracle/admin/PRD/udump>grep -i 'db file' prd_ora_26020.trc WAIT #3: nam='db file scattered read' ela= 27789 p1=24 p2=10 p3=36 Note que o evento de table scan se chama 'db file scattered read', e não 'sequential', como está na msg. Caso vc não saia de 8 blocos no multiblock read reproduzindo o exemplo acima, duas possibilidades aí : a) na maioria dos unix há um parâmetro (MAXPHYS ou similar) que controla o tamanho máximo de I/O, talvez erradamente ele deve estar como 64 Kb (que corresponde a 8 blocos de 8Kb) - digo erradamente porque na MAIORIA esmagadora dos hardwares modernos se consegue mais q isso... b) o seu volume de disco tem stripping de 64 Kb : quando vc cria um volume (principalmente num array de discos) vc entre outras coisas informa o stripping , ie, qual o mínimo de I/O que será feito em cada acesso, se foi informado 64 Kb, é isso que vc obterá []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Thiago Lazzarotto <[EMAIL PROTECTED]> escreveu > > Senhores... > > Eu tenho definido no meu banco o db_file_multiblock_read_count = 8. > > Eu fiz o teste que o chiappa passou para ver qual o valor máximo para > ser definido no meu parâmetro... > Acontece que o valor é sempre 8. > Daí surgiu a minha dúvida: esse é o valor máximo que o SO/Hardware > suporta ou ele está usando esse valor ao máximo por causa do parâmetro > já setado? > Meu banco é 8.1.7.4 HPUX 11.11 > > Segue o teste do chiappa. > > "Existem outras maneiras, mas como normalmente isso é uma quantidade > de blocos que totaliza 1Mb, ou coisa do tipo, pra vc saber é testar, > vc cria uma tablespace LMT uniform size de 10Mb, cria nela uma tabela > qquer com PCTFREE 1 PCTUSED 99 e com várias centenas de milhares de > linhas, e faz um trace 10046 level 12 de uma sessão fazendo > SELECT /*+ FULL */ * from nomedatabela, isso resulta num > arquivo .TRC que entre muitas outras vai ter linhas do tipo : > > WAIT #3: nam='db file scattered read' ela= 249287 p1=41 p2=4234 p3=nnn > > nnn é a quantidade de blocos que ele pôde ler duma vez, > db_file_multiblock_read_count deve ter o maior dos nnn que vc achar > no arquivo." > > Obrigado. > Thiago. > -- 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
