Re: [oracle_br] Re: CONTINUAÇÂO porcetagem de acerto da db cache
é isso ae Valeu pela força - Original Message - From: "jlchiappa" <[EMAIL PROTECTED]> To: Sent: Thursday, October 13, 2005 1:24 PM Subject: [oracle_br] Re: CONTINUAÇÂO porcetagem de acerto da db cache Ou seja, numa palavra, vc configouro o CBO e o implantou : é, via de regra CBO adequadamente configurado é quase sempre superior. Vc não fala, mas SUPONHO que os outros params decisivos no CBO, que eu cito no e-mail anterior, como os *enabled*, *size*, os outros optimizer*, *parallel*, etc, FORAM analisados também, e onde vc julgou adequado alterados, né ?? Só com TODOS analisados e onde necessário corrigidos é que vc obtém PICO de eficiência do CBO Só como complemento, também : vc não disse, mas se com a implementação do CBO houve melhoras, CERTAMENTE o plano de execução mudou, era ruim e melhorou. Sabe vc ** quando ** vc ia "pegar" um problema desses se preocupando com valor de cache hit ??? NUNQUINHA, zero, zipardônia, no dia de São Nunca... E MUITOS problemas de performance são desse tipo, então RECOMENDO DE NOVO : cesse, desista, PARE DE USAR cache hits como método pra analizar performance, e JOGUE FORA todo e qquer livro, apostila, dica, texto ou o que for que diga o contrário, E se foi algo que alguém te "ensinou", arquive mentalmente a informação na área do cérebro dedicada à mitos e lendas, junto com o negrinho do pastoreio, a mãe-do-mato, o saci, a cuca. E finalmente : já que vc aumentou o db_multiblock e teve efeito positivo, PODE SER que vc tenha relatórios extensos (ou programas do tipo) que não se beneficiam de índice (pois querem ler a tabela toda, ou quase), e protanto precisam de um table scan o mais eficiente possível - SE for isso mesmo, eu recomendo que vc (se ainda não o faz) passe a usar apenas tablespaces LMT, E que tenha os extents de um tamanho apropriado para full scan eficiente (ie, igual ou maior mas múltiplo exato do maximo IO simultâneo, E que tenha ** absoluta ** certeza que os seus datafiles estão bem distribuídos entre os seus pontos de I/O , E que não haja conflitos de I/O (por exemplo, área TEMP no mesmo local/spindle que datafiles, aí enquanto uma sessão está tentando fazer I/O temporário a outra que queira fazer scan físico vai ter q esperar... Enfim, trabalho rotineiro e comum de DBA. []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "zbdv" <[EMAIL PROTECTED]> escreveu > Olá jlchiappa, > Obrigado pela ajuda. > Fiz algumas alterações de parametros como: > > db_multiblock de 16 para 32. > optimizer_indeX_caching de 0 para 50. > . > . > . > e obtive melhoras significantes , ressaltando que foi gerado analyze de > table e index anteriormente. > Obrigado pela força > > > > > - Original Message - > From: "jlchiappa" <[EMAIL PROTECTED]> > To: > Sent: Wednesday, October 12, 2005 9:44 PM > Subject: [oracle_br] Re: CONTINUAÇÂO porcetagem de acerto da db cache > > > 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
Re: [oracle_br] Re: CONTINUAÇÂO porcetagem de acerto da db cache
Olá jlchiappa, Obrigado pela ajuda. Fiz algumas alterações de parametros como: db_multiblock de 16 para 32. optimizer_indeX_caching de 0 para 50. . . . e obtive melhoras significantes , ressaltando que foi gerado analyze de table e index anteriormente. Obrigado pela força - Original Message - From: "jlchiappa" <[EMAIL PROTECTED]> To: Sent: Wednesday, October 12, 2005 9:44 PM Subject: [oracle_br] Re: CONTINUAÇÂO porcetagem de acerto da db cache 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: > 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: > > 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
