requests' foi ** ELIMINADO ** do banco a partir do 8i :
SQL*Plus: Release 8.1.7.0.0 - Production on Sex Mai 12 13:39:43 2006
(c) Copyright 2000 Oracle Corporation. All rights reserved.
Conectado a:
Personal Oracle8i Release 8.1.7.4.1 - Production
With the Partitioning option
JServer Release 8.1.7.4.1 - Production
[EMAIL PROTECTED]:SQL>select * from v$sysstat where lower(name) in
('summed dirty queue length','write requests');
STATISTIC#
NAME
CLASS VALUE
------------------ ---------------------------------------------------
------------- ------------------ ------------------
46 summed dirty queue
length
8 0
[EMAIL PROTECTED]:SQL>
pois no 8i o DBWR foi modificado, ele não mais lê de um único queue,
há vários queues para os vários tipos de write que o bd pode
fazer,portanto vários pontos de write request, não fazia mais sentido
essa estatística. Se o seu objetivo é ter alguma medida do trabalho
do dbwr, talvez vc pode usar as estats de 'free buffer waits'
and 'write
complete waits' , e se desejado se aprofundar mais no assunto,
recomendo o paper "The Mysteries of DBWR Tuning", de Steve Adams, vc
deve achar cópia dele procurando na net.
Pra encerrar, porém, aviso que :
a) tunning de detalhes internos como este são *** EXTREMAMENTE ***
complexos, então vc só deveria fazer isso *** DEPOIS *** que já
alocou o mais corretamente possível a RAM no servidor e no Oracle, já
distribuiu o I/O, e mais importante de tudo já fez o tunning DE SQL -
se vc está se metendo nisso porque um script brocoió qualquer te
falou, CESSE imediatamente isso, vá atrás dos outros pontos que
citei, o retorno do investimento vai ser N! vezes maior...
b) trabalhos internos do banco (como os feitos pelo DBWR, ou como os
latches, etc, etc) naturalmente NÃO ocorrem "sozinhos", eles estão
sendo feitos PORQUE algum SQL enviado pelo usuário assim exigiu :
assim, se vc tem um SQL que fazia X LIOs e melhorando-o ele passou a
fazer X/100 LIOs, ** AUTOMAGICAMENTE ** já houve uma diminuição
equivalente (ao ao menos perceptível) nos trabalhos do DBWR, na
quantidade de latches, no gasto de CPU, etc, etc, etc.... Assim pela
segunda vez, TUNNING DE SQL !!!!
c) ratios do tipo são basicamente INÚTEIS pra tunning por si só :
uma vez feito o tunning de sql , de hardware e de configs de banco, o
que vc pode fazer com eles é tomar uma medida deles com o banco em
atividade baixa, tomar outra com o banco em carga maior, e essa
comparação vai te dar uma idéia ** GERAL ** de como anda a atividade
do seu banco. Interpretações do tipo "ah, se o ratio X for > do que o
valor n aumente o buffer cache" são puro LIXO (há palavras mais
exatas para os descrever, mas este fórum é de ambiente familiar :)
Leia os papers "Why You Should Focus on LIOs Instead of PIOs Cary"
e "Why a 99%+ Database Buffer Cache Hit Ratio is Not Ok" em
http://www.hotsos.com/e-library/index.html e
http://www.jlcomp.demon.co.uk/myths.html
==> O resumo da história é : SE vc quer fazer um "diagnóstico",
absolutamente NÃO É só rodando uns poucos scripts (coisa que um
macaco treinado poderia fazer!) que vc obtém algum resultado
confiável, vc TEM QUE ter um DBA habilitado, que depois de levantar o
status do banco em relação à cosnumo de CPU, RAM e I/O e os
principais SQLs, DEPOIS de os analizar e corrigir onde possível, aí
sim esse DBA até pode usar scripts (ou mesmo o Statspack), e vai
interpretar o resultado de acordo com o feeling e com a expertise
dele, NÃO É obedecendo a IFs, ok ??
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, "Marcelo Cauduro"
<[EMAIL PROTECTED]> escreveu
>
> Pessoal, quero realizar a seguinte consulta para identificar Dirty
Blocks,
> mas esse evento eu não acho na V$SYSSTAT...
> ja olehi no 8i, 9i e 10g.... e nada ... por favor... alguem pode me
ajudar
>
> Dirty Queue Length
>
> SELECT SUM(DECODE(name,'summed dirty queue length',value)) /
> SUM(DECODE(name,'write requests',value)) "Average Write
Queue Length"
> FROM v$sysstat
> WHERE name IN ( 'summed dirty queue length','write requests')
> AND value > 0;
>
>
> [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.
| Yahoo! Grupos, um serviço oferecido por: | |
|
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 Termos do Serviço do Yahoo!.
