veja vc : o ponto principal que invalida a análise por cache hit ratio
é que ela é uma razão, é um proporção entre a qtdade de I/Os físicos e
I/Os do cache. Ora, num banco não-trivial vc VAI TER SIM mais blocos
de tabelas/índices do que o que cabe em RAM, a RAM é ** LONGE ** de
ser infinita, então SIM vc vai ter I/Os físicos, é inevitável. E a
falha desse método de análise em que recomenda-se cache hit de x% é
que o cache hit é GERAL DO BANCO, não tem como vc saber se o cache hit
está baixo porque um usuário acabou de rodar um relatório grande, que
não tem como não fazer I/O físico ( o que seria normal), ou se não, ok
?? Então por esse (entre alguns outros motivos) é que se recomenda que
vc faça é a ANÀLISE dos waits só da sessão que está executando o SQL
lento, aí vc está vendo só o que ocorre com a sessão em questão, certo
? Então é por isso que recomendo : ESQUEÇA se o cache vai pra x ou
pra y%, e vá procurar as causas, o que normalmente se encontra mais
facilmente via análise de waits e por trace, é isso...
Quanto a aão de "fazer analyze" que vc diz que ia fazer : eu já
respondi algumas vezes aqui mesmo no fórum, digo de novo : quando vc
coleta estatísticas, vc passa a usar otimização por custo (CBO) : é
uma açao esperta, recomendada, MAS é absolutamente EXIGIDO que :
a) vc tenha os parâmetros de configuração do CBO (como *enable*,
optimizer_xx, multiblock_read, sort / hash area se não estiver usando
workarea automática no 9i), etc, bem configurados
e
b) não basta só sair "rodando analyze" de qquer jeito, vc TEM QUE
saber quais tabelas precisam ou não de histograma, em quais é lícito
um ESTIMATE, em quais é obrigatório COMPUTE...
e
c) os SQLs tem que estar "limpos", ie, SEM hints, com todas as opções
de ligação mostradas no WHERE dos joins, etc
e
d) não deve estar havendo operações que "impossibilitam" alguns
planos, como por exemplo conversão implícita de dados ou aplicação de
funções/cálculos em campso indexados, o que impossibilita índices
e
e) sempre, sempre que possível vc dev estar usando SQL puro, apenas :
se for um relatório o programa problemático (digamos) e internamento
(por exemplo) ele faz algo do tipo :
for r in (select * from tabela) loop
-- buscar detalhe...
select nome into :camponome from tabeladet where id = r.id;
...
isso é IMPOSSÌVEL de ser otimizado pelo CBO, o CBO só serve pra
otimizar SQLs não procedurais, tipo :
SELECT T.c1, T.c1, D.NOME
FROM tabela T, tabeladet D
where T.id = D.id.....
Usar CBO sem a) , b), c) d) e e) é na maior parte dos casos ** inútil
**, perda de tempo mesmo, e muitas vezes só PIORA a situação...
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, "zbdv" <[EMAIL PROTECTED]> escreveu
> Bom jlchiappa,
> Li o artigo referente ao segundo link e achei super interessante
PORÉM eu
> não me concordei em partes , já que o problema que estou passando
(razão de
> acerto da db_cache) é muito significante.
> Tipo quando eu starteio o banco ele me retorna um valor de acerto da
cache
> em 100% , mas com o passar do tempo ele cai para 20% 26%... o que quero
> dizer que não é apenas uma simples margem de erro e sim uma significante
> diferença de acerto da cache.
> Hoje o banco tem +- 60 GB alocado junto de mais 8 instancias ( absurdo
> né ), mas o processo de migração já está sendo feito.
> Voltando ao assunto , vale a pena ressaltar que quando os
relatorios são
> executados no banco eu desligo o serviço das outas 8 instancias ,
para ter
> um sofrimento menor da maquina.
> Mesmo hoje a db cache está em 30 m e quando começa a ter esse
problema eu
> aumento a cache para uns 40 , mas mesmo assim a porcentagem de acerto
> continua significantemente baixa. Procuro não aumenta muito para ão ter
> problema de SWAPPING.
> Ontem deixei rodando os analyze da table e index , tentando assim
diminuir a
> perda de performace. ( só posso dizer se resulto em algo
significativo na
> quinta )
> Teria alguma sugestão sobre o processo que está acontecendo ?
>
> ----- Original Message -----
> From: "zbdv" <[EMAIL PROTECTED]>
> To: <oracle_br@yahoogrupos.com.br>
> Sent: Wednesday, October 12, 2005 3:08 PM
> Subject: Re: [oracle_br] Re: porcetagem de acerto da db cache
>
>
> > Obrigado jlchiappa
> > ----- Original Message -----
> > From: "jlchiappa" <[EMAIL PROTECTED]>
> > To: <oracle_br@yahoogrupos.com.br>
> > Sent: Wednesday, October 12, 2005 1:00 AM
> > Subject: [oracle_br] Re: porcetagem de acerto da db cache
> >
> >
> > Colega, eu ** duvido ** que o seu problema de performance seja devido
> > à taxa de acerto (o famigerado cache hit ratio) : 99.99% das vezes não
> > é nada disso... Pra vc ter uma idéia, vá para
> > http://www.oracledba.co.uk/, no link "Tunning" escolha o item "Custom
> > Hit ratio", lá vc vai achar uma rotina que deixa vc escolher o hit
> > ratio que quiser, SE vc a executar num banco com probs de performance
> > vc VAI ver que certamente o hit ratio vai ir lá pra cima, mas o
> > problema de performance CONTINUARÁ... E pra dar o tiro de misericórdia
> > nessa idéia, em http://www.hotsos.com/e-library/index.html escolha e
> > leia o paper "Why a 99%+ Database Buffer Cache Hit Ratio is Not Ok", o
> > autor dá todas as razões porque tunning por cache hit ratio (e hit
> > ratios de modo geral) simplesmente não funciona na maioria das vezes.
> > A minha dica portanto é : faça uma pilha com TODAS as apostilas,
> > livros, etc, que te dizem que "se hit ratio é baixo, aumentar área de
> > cache", e TOQUE FOGO nelas, sem dó nem pena, elas são menos que
> > inúteis, IMHO. Feito isso, aí sim vc poderá começar a fazer a pesquisa
> > REAL, encontar as CAUSAS reais da sua má-performance, usando as
> > ferramentas apropriadas, ie : wait interface e trace, e se acado SQl
> > ineficiente, corrigindo-o. Os livros bons de referência pra isso são :
> >
> > - para tunning com traces , "Optimizing Oracle Performance", Cary
Millsap
> >
> > - para wait interface, "Oracle Wait Interface: A Practical Guide to
> > Performance Diagnostics & Tuning" , de Richmond Shee, Kirtikumar
> > Deshpande e K Gopalakrishnan
> >
> > - para quando vc localizar SQLs ineficientes, "Oracle SQL
> > High-Performance Tuning (2nd Edition)", de Guy Harrison
> >
> > []s
> >
> > Chiappa
> >
> > --- Em oracle_br@yahoogrupos.com.br, "zbdv" <[EMAIL PROTECTED]> escreveu
> > > Pessoal,
> > > Estou com uma porcentagem de acerto da db cache de 51% , onde acaba
> > > refletindo numa performace do banco.
> > > Já aumentei a db cache size pra 32 e ainda continuo com o problema.
> > > alguem teria alguma dica??
> >
> >
> >
> >
> > ORACLE_BR APOIA 2ºENPO-BR
> > _____________________________________________________________________
> > O 2º Encontro Nacional de Profissionais Oracle será realizado no dia
> > 05/11/2005 no auditório da FIAP em São Paulo. Serão apresentadas
Palestras
> e
> > Cases dirigidos exclusivamente por profissionais especialistas e
renomados
> > no mercado. Confira a programação no site do evento!
> http://www.enpo-br.org/
> > _____________________________________________________________________
> >
> > Links do Yahoo! Grupos
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ORACLE_BR APOIA 2ºENPO-BR
> _____________________________________________________________________
> > O 2º Encontro Nacional de Profissionais Oracle será realizado no dia
> 05/11/2005 no auditório da FIAP em São Paulo. Serão apresentadas
Palestras e
> Cases dirigidos exclusivamente por profissionais especialistas e
renomados
> no mercado. Confira a programação no site do evento!
http://www.enpo-br.org/
> > _____________________________________________________________________
> >
> > Links do Yahoo! Grupos
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
ORACLE_BR APOIA 2ºENPO-BR
_____________________________________________________________________
O 2º Encontro Nacional de Profissionais Oracle será realizado no dia 05/11/2005
no auditório da FIAP em São Paulo. Serão apresentadas Palestras e Cases
dirigidos exclusivamente por profissionais especialistas e renomados no
mercado. Confira a programação no site do evento! http://www.enpo-br.org/
_____________________________________________________________________
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
