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
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
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, "Seba
*
SQL> select name, value from v$parameter where name in
('db_block_size','db_file_multiblock_read_count');
NAME VALUE
--
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 tinh
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, en
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
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
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 10
